> Once your block reaches 90% full, it is removed from the free list.
So, you are implying that it can be removed from the free list based on the PCTFREE value too, right? So far I was under the impression that it can be removed from the free list based on the PCTUSED value.
> It will not be put on the free list again until used space in the block > falls below PCTUSED, which is 40% in your example.
Well, why cant it be placed back on the list based on the fact that it dropped below 90%?
> So, a block fills up, it is removed from the free list, then a couple of > rows are deleted and used space falls to 60%. The block is still > not on the free list, as the space used has remained above 40%.
and
> PCTUSED comes into play when rows are deleted from the block. If enough > data is deleted from a block to cause the block to fall below 60% used > (PCTUSED), the block goes back on the freelist for subsequent > inserts/updates.
Nice explanation, thanks.
It could have been setup so that if it falls below 90%, then its placed on the free list. This would not require the second paramater PCTUSED. But thats hypothetical and not the real case. Oracle will not put it back on the free list, unless its full-percentage drops below 40%. Why is that important, and why has Oracle set it up that way? Why couldnt they say something like, we'll put it on the free list again, since its now less than 90% full?
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Maryann Atkinson INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
