I think the only possible answer to your question is that there is simply too much detail to document. Possibly the problem is made worse by the fact that the official documentation is not written by the people who write the code, and the people who write the code probably don’t make a note of every detail of their implementation so we end up with lots of cases where little bits of information are “lost” until someone (usually a DBA or support analyst) re-discovers them as a side effect of researching a performance issue.

Sorry for the delay – I missed this question first time around.

The comment is just trying to pin down a case where the coalesce approach could be most effective.

If you start with a “clean” time-based or sequence-based index – the “right-hand index” – and then have an accident that results in excess ITLs from there on, a call to coalesce will:

a) walk the index up to the damage point and won’t have to fix anything before that point
b) fix the damage at the right hand edge of the index and stop the damage moving forward.

It’s a case where you’d hope to get maximum benefit for minimum resource consumption.

In other cases, the coalesce might have to do lots of (essentially pointless) work all over the index just to fix one or two little pockets of damage.

I have read several times this post but I can´t still understand what do you mean when you say this:

“If the level of concurrency appears only when you are inserting the data then it may be a good idea – and this would only be relevant if the index was the “right-hand index” suggested by Asif.”

Please, could you clarify this point a bit more?, I assume the coalesce is after the insert, right? . Why are inserts especially different?

In Index Quiz II, you wrote that initrans in index blocks are ignored because it is always possible to get an ITL to do the split. Does this behaviour remain intact in “all” kind on index blocks (branch blocks, leaf blocks …) ?

Thank you Jonathan for this blog.

The 8,048 is the total amount of free space after elimination of the index leaf block overheads (excluding the default 2 ITL entries). It’s just a number I happen to know.

8048 is the size of the block.

^_^

when yout say “the validate command has worked out that available space for a leaf block is (8048 – 169 * 24) = 3,992 bytes”,

where does the 8048 figure come from?.

Greetings.