Can coalesce increase index size ?

Question

Hi,
I'm trying to understand how space usage changes after coalesce of an index.
I'm using Tom Kyte show_space procedure .
DB is 9.2.0.8 .
before Coalesce:
Unformatted Blocks .....................               0
FS1 Blocks (0-25)  .....................               0
FS2 Blocks (25-50) .....................           1,811
FS3 Blocks (50-75) .....................               0
FS4 Blocks (75-100).....................               0
Full Blocks        .....................           2,969
Total Blocks............................           4,864
Total Bytes.............................      39,845,888
Total MBytes............................              38
Unused Blocks...........................               0
Unused Bytes............................               0
Last Used Ext FileId....................             149
Last Used Ext BlockId...................       2,979,081
Last Used Block.........................             128
After Coalesce
Unformatted Blocks .....................               0
FS1 Blocks (0-25)  .....................               0
FS2 Blocks (25-50) .....................           4,142
FS3 Blocks (50-75) .....................               0
FS4 Blocks (75-100).....................               0
Full Blocks        .....................             638
Total Blocks............................           4,864
Total Bytes.............................      39,845,888
Total MBytes............................              38
Unused Blocks...........................               0
Unused Bytes............................               0
Last Used Ext FileId....................             149
Last Used Ext BlockId...................       2,979,081
Last Used Block.........................             128Look like only two values changed:
before:
FS2 Blocks (25-50) ..................... 1,811
after:
FS2 Blocks (25-50) ..................... 4,142
before
Full Blocks ..................... 2,969
after:
Full Blocks ..................... 638
So we got more blocks 25-50% free space
and less full occupied blocks .
And thats strange, how we can have less full blocks after coalescing ?
Second question is there any reason my index can grow up after coalescing , when would this happen ?
Please explain :).
Regards
GregG

Answer 1

>
SQL> select * from index_stats;
HEIGHT     BLOCKS NAME                           PARTITION_NAME                    LF_ROWS    LF_BLKS LF_ROWS_LEN LF_BLK_LEN    BR_ROWS    BR_BLKS BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS MOST_REPEATED_KEY BTREE_SPACE USED_SPACE   PCT_USED ROWS_PER_KEY BLKS_GETS_PER_ACCESS   PRE_ROWS PRE_ROWS_LEN OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
3       4864 INDEX_NAME_1                                                    598311       4730     8622004       7348       4729         16       71606       8028      309286         4374735           593             93530    34884488    8693610         25   1008.95616           507.978078          0            0              1               23
and after coalesce
SQL> select * from index_stats;
HEIGHT     BLOCKS NAME                           PARTITION_NAME                    LF_ROWS    LF_BLKS LF_ROWS_LEN LF_BLK_LEN    BR_ROWS    BR_BLKS BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS MOST_REPEATED_KEY BTREE_SPACE USED_SPACE   PCT_USED ROWS_PER_KEY BLKS_GETS_PER_ACCESS   PRE_ROWS PRE_ROWS_LEN OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
3       4864 INDEX_NAME_1                                                     289025        708     4247269       7996        707         16       10965       8028           0               0           347             67594     5789616    4258234         74   832.925072           419.962536          0            0              1               24It's a little hard to tell exactly what's happened based on summary statistics - but there are a couple of extra guesses we can make from these stats.
The coalesce command won't try to coalesce blocks with active transactions (that't not a guess, by the way) - but when you hit a block which requires a lot of delayed block cleanout the recursive transaction for cleanout may make coalesce skip the block. You started with a lot of deleted leaf rows in the leaf blocks - so a lot of your "full" blocks may have been subject to cleanout, perhaps leaving them 25% free and bypassing a coalesce. You may find that if you issue the coalesce command a second time, right after the first, that Oracle manages to coalesce a lot more block.
Apart from the 65,000 "most repeated key" you have an average of about 600 rows per key (that's indicated by doubling the blks_gets_per_access, after allowing for the single most repeated). Very repetitive keys can easily lead to space utilisation dropping to "below average" for b-trees, so 50% utilisation wouldn't be a surprise. Add to this the very repetitive key which could be a hot spot for concurrent inserts and the "ITL explosion" issue (see http://jonathanlewis.wordpress.com/category/oracle/indexing/index-explosion/ ) that halves the storage efficiency again. It's possible, though, that some of your performance overhead is simply the problem of fairly large range scans.
Regards
Jonathan Lewis