I don’t really see this enhancement coming along in the near future – the strategy of copying the ITL has been around since version 6.

Funny you should mention index rebuilding though …

You are right (as always! lol!) the reasons can be: HD-space cost is very low (so, some wastage is “not a great problem”) or when split occurs you already got the itc so just copy it (lazy programming technique).
Possible future enhancements? Maybe…

As a conclusion:
When you need to rebuild your index?
When you got a lot of excess space in the ITL! ;-)
(just kidding a little bit)

Just playing devil’s advocate and talking around the possibilities:

a) looking up initrans need not be expensive – especially compared to clearing a buffer for the split and writing all that undo and redo; if it gets expensive you could alway ensure that initrans is copied into the root block, and you will probably have pinned the root block already.

b) the drawback to cloning the ITL is that a single burst of concurrency once in the life time of the index could leave a lot of excess space in the ITL for all new blocks from there onwards. I can’t see any obvious reason why the copy process doesn’t avoid copying ITL entries which have not been used when a split occurs, as this might help to minimise the future wastage.

When “playing” the “Index Quiz 2″ I was thinking on this (ehm…wrong) model:

- every index block start with 4 itc (because I say I want 4 ITC)
- on block split every block is “initialized” with 4 itc
- the itc can grow to MAXTRANS

Quite linear, but quite expensive also because every time a new block is added you have to read the initial INITRANS value.

The implementation explained by Jonathan is very time effective: it minimize time creation of the block (you have to “copy” the data from the block you are splitting, so no additional look up is required), it also try to optimize concurrency (block are created with a “high” itc so the index is ready for future high transaction burst)

You’re right, it should be four; thanks for pointing out the error. Now corrected.

Yes, every leaf that splits off from either of those two will inherit 11 ITL entries.

If you do a block dump, the phrase “Leaf block dump” or “Branch block dump” will appear in the header section. However, you cannot, in general, identify a block as “the root block” of an index by looking at the dump – you have to know that it is the first block after the segment header.

If you happen to know the blevel or height (= blevel + 1) of the index, then you can search for the entry kdxcolev in the dump as this records the level of the block in the index – and if kdxcolev = blevel then you are looking at the root block.

Shouldn’t it be 4?

Just so I can get this straight: if a single session inserts 300 rows (or something enough to cause another split) after the other 10 concurrent sessions have commited, then all the “child” blocks will inherit 11 ITL entries, including the service ITL?

Another question: how do you know if a block is the root, branch or leaf block?