Regular index rebuilds in Oracle are a vital necessity – this old myth has been proven wrong long ago. But here is the story about an index where at first we did not understand why a rebuild reduced the size so heavily.After a blooper involving a DROP …

The first block pointed to by the root block is at level three, it holds 118 entries; there are 13 other branch blocks at this level

The first block pointed to by the first level 3 branch block is at level 2, it holds 112 entries; there are 117 branch blocks at this level pointed to by the same parent level 3. We could “guesstimate” that there are roughly 13 * 118 other blocks at level 2 (assuming each of the 14 level 3 branch blocks all hold the same number of pointers.

etc. etc. etc.

Few questions to understand the treedump…

1.I checked first 30K rows and last 1k rows(rows for leaf blocks) in my treedump and i found that ‘nrow’ is same as ‘rrow’ everywhere. How should i interpret it ?
2.snap of my treedump

----- begin tree dump
branch: 0x40b700d 67858445 (0: nrow: 14, level: 4)
   branch: 0x161bada0 370912672 (-1: nrow: 118, level: 3)
      branch: 0x14036237 335766071 (-1: nrow: 112, level: 2)
         branch: 0x16002253 369107539 (-1: nrow: 187, level: 1)
            leaf: 0x40b700e 67858446 (-1: nrow: 205 rrow: 205)

Am i right in interpretation that,
there are 14 branch blocks at level 4 (just below root block),118 branch blocks at level-3,112 branch blocks are level-2 and 187 branch blocks at level-1.
First branch block(i.e. ‘-1′) at level-1 points to 205 leaf blocks…and so on…???

Thanks for that comment – excellent point about the transportable tablespace as well, that’s another of those things that’s easy to forget.

I put in a “!=” on your comment, I’m guessing that the HTML parser took out a “less than, greater than” that you’d had there.

It is not only the number of datafiles that makes them different: when you use transportable tablespaces, the relative file number do not change (or that would involve visiting all data blocks in the tablespace, and all rowids that reference a block within that tablespace…)

Thanks for that, it’s a very good point, and one that I had completely overlooked. I think you’re probably correct (it certainly makes sense), but I haven’t actually checked but I will remember to verify it one day.

I think the difference won’t be visible to many DBA’s, though; my memory of the change in file number formats is that Oracle rigged their implementation so that the relative file number and absolute file number were the same until you had about 1,024 files (possibly 1,022 if you want to be precise) – and there is an event you can set to break this connection so that you can test without having to create a thousand files.

I have a remark about dbms_utility.data_block_address_file(20976011) file#. If if I’m not mistaken, the treedump gives the relative DBA (data block address) of the leaves. But block dump takes the absolute file#.
So in your example dbms_utility.data_block_address_file(20976011) gives the rfile# that we need to convert into file# (from v$datafile – knowing the index segment’s tablespace) before using it for block dump. They were probably equals in your example.

Plase correct me if I’m wrong.

Regards,
Franck.