-
We posted a new article to the site today from first time author Gaurav Sharan Gupta. I wanted to get a thread started on the article to get some feedback and thoughts on the article. Did you find the information helpful? Do you have any suggestions for improvement? Would you like to see additional articles on the same topic/different topics from Gaurav?
Here's the URL for the article:
Oracle 8i Row Chaining and Migration
http://www.dbasupport.com/oracle/ora...chaining.shtml
-
had a quick read
article states that oracle block size starts from 512 bytes, wrong it starts from 2K (minimum)
pctused definition is totally wrong, pctused is used for DELETEs not INSERTs, a block is removed from freelist when it reachs PCTFREE, re-enters to freelist when block usage falls BELOW PCTUSED
-
Some definition is easy to get confused, PCTFREE is for when the block will be removed from the freelist, PCTUSED is for when the block will be put back to the freelist.
DBA OCP 8i
-
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....
Jurij Modic
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
-
I want to say thanks to everyone for their comments. The author has been forwarded the comments as well as a link to this thread, so I'd like to give him a chance to respond before making necessary changes to the article.
-
Please tell me this isn't the same person who authored those terrible 'performance' lessons.
- Chris
-
Completely different author, but a couple similarities -- 1) both really want to contribute to the Oracle community by helping others, and they've taken it upon themselves to do so by writing these articles for free; and 2) they want and encourage feedback on their articles to make them as accurate as possible.
Note: Post edited to remove original comments made in bad taste. Apologies to those who may have taken offense at the poor choice of words used.
-
Little bit more information about article:
Autor(s) has to know that OS (not oracle) block size depend not from OS itself but from
filesystem in this OS (mkfs command). 512 bytes in solaris isn't correct information too.
-
Originally posted by fstroud
Completely different author, but a few similarities -- 1) both are from India and are not entirely comfortable with the English language; 2) both really want to contribute to the Oracle community by helping others, and they've taken it upon themselves to do so by writing these articles for free; and 3) they want and encourage feedback on their articles to make them as accurate as possible.
Forrest,
They'd be kinda perplexed on that poor english defence you've taken on their behalf. We have some active members here from all origins(Re-Edited it!Don't mean to hurt no-one and don't want this thread to go off tangents either)who write horrible english but make sense regarding explanations.
I don't really know if it's a smart idea to first post your stuff and then ask for a review because it'll be shredded first and read later.
Cheers!
Tarry
[Edited by Tarry on 09-26-2002 at 06:59 AM]
Tarry Singh
I'm a JOLE(JavaOracleLinuxEnthusiast)
--- Everything was meant to be---
-
Originally posted by fstroud
Completely different author, but a few similarities -- 1) both are from India and are not entirely comfortable with the English language; 2) both really want to contribute to the Oracle community by helping others, and they've taken it upon themselves to do so by writing these articles for free; and 3) they want and encourage feedback on their articles to make them as accurate as possible.
Pls Don't generalize...
I HAVE SEEN WESTERN PEOPLE WITH HORRIBLE WRITING
SKILLS.......THAT TOO ENGLISH BEING THEIR MOTHER
TOUNGE...
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|