I think the first thing to say is that you’ve found an error in the book, the lf_rows figures include the del_lf_rows figures. The book was based on 8.1.5, but I don’t think that the calls to index_stats would have changed from 8.1.5 to 8.1.7.4 which is the earliest version I can get my hands on. (I’ve added an item to my list of errata.)

Your stats mean: there are 1,000 entries visible in the row-directories of the leaf blocks (lf_rows=1,000), but every entry has its Deleted flag set (del_lf_rows = 1,000).

analyze index i1 validate structure;

And receved those numbers

LF_ROWS,DEL_LF_ROWS from index_stats;

LF_ROWS DEL_LF_ROWS
———- ———–
1000 1000

Could you please explain, what they mean. Especially remembering your description for LF_ROWS in book Practical Oracle8i: “Number of current rows in the index (excluding deleted rows)”

Oracle 11.2.0.2

Richard’s question was “what if the commit was inside the loop”. In this case each time you insert the next entry, the previous entry will be wiped out of the index and the space will re-used. If you dump the table block, though, you will see that Oracle stacks the incoming rows into the block’s free space, even though it will keep recycling the block’s row directory so that it never grows and only the last inserted/deleted row is identified and the “heap block compress” (see pingback) happens in the same way.

Flado’s question was “what if you do a rollback outside the loop”. In this case the rollback would actually happen, and the table’s row directory would be reduced to a minimum and the row directories of the index leaf blocks would be emptied, but the leaf blocks would still be in the index structure and the root block would still have entries pointing to the leaf blocks.

I am still curious about the answers to Richard Foote’s question and Flado’s.
- commit outside the loop
- rollback instead of commit

Regards Hans-Peter

Good to think about the number of branch blocks and the dependency on the size of the entry that has to be in the branch block. In my example the way I defined the index entry requires very large entries in the branch blocks too – Oracle tries to trim branch block entries to the smallest size that will allow it to distinguish the first entry in one leaf block from the largest possible entry in the previous leaf block, but my entries match over almost their entire length.

You’ve raised a couple of interesting points beyond the answers given by Martin and Narenda.

Definitely worth mentioning that their arithmetic was valid because of the so-called “90/10″ splits cause by the monotonic increasing values. I don’t think 32/64 bit would make a difference, nor the version (so long as it was 6 or above)

The comment about _bump_highwater_mark_count is worth a mention. People do fiddle with it occasionally, of course, but the reason for mentioning it is that there could be some blocks that are on the index free list because the HWM has been recently bumped (by its default of 5) which aren’t in the index yet.

In fact, the table is a special case for the HWM – when you start inserting data into a segment it allocates blocks one at a time for the first few before the 5 block “bump” takes over; so in this case there were no extra empty blocks on the free list. (I think this behaviour is just a hangover from the old days when keeping space to a minimum was more important that pausing briefly to allocate a new block).