The author has totaly confused the roles of PCTFREE and PCTUSED parameters. What we have:

PCTFREE = 20, PCTUSED = 55

We inserted 6 rows, each consuming 10% of the net block size, so 60% of block is occupied. Block will remain in free list, not being removed from it as the article claims. Now we updated one of the rows, increasing its size from 10% to 25% of the block size. So now we have 75% of block occupied. 25% of space is still available for future updates, no? Not according to the author. He claims that another update wich would require another 10% of the block space will fail!?!? He has got confused some basic concepts about PCTFREE and PCTUSED. He obviously belive that each increase of the row size by the update takes space only from the PCTFREE reserved area. However this is totaly wrong. Updates has all the free space in the block availbale, it is inserts that are blocked by the PCTFREE size. Even after that update block is still available for inserts, as we still haven't reach PCTFREE.

So the correct behavior in the author scenario would be:

The second update will occupy another 10 units of the block, and the row will remain in that block in one piece, leaving 15% of block still available to future updates. However at that moment block will be removed from free list, as there is less free space available (15%) than it was specified with PCTFREE.

Now even next update which requires 10% of additional space will succeed without the row chaining. Only if we try another update demanding another 10% space, Oracle will need to chain that updated row, moving its contents into another block.

I can't help myself not to state: The article is a failure, it gives a totaly wrong description of the basic concepts regarding PCTFREE and PCTUSED. And if you don't understand those basics you can't realy understand what row chaining/row migration realy is and what is causing it.

No offence to anyone....