Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

428
CHAPTER 11 ■ INDEXES
analyze index t_idx validate structure;
insert into idx_stats
select 'compress &1', a.*
from index_stats a;
For comparison reasons, we run this script not only with one column, but also two and
three compressed columns, to see what happens. At the end, we query IDX_STATS and should
observe this:
ops$tkyte@ORA10G> select what, height, lf_blks, br_blks,
2 btree_space, opt_cmpr_count, opt_cmpr_pctsave
3 from idx_stats
4 /
WHAT
HEIGHT LF_BLKS BR_BLKS BTREE_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------------- ------- -------- ------- ----------- -------------- ----------------
noncompressed 3 337 3 2718736 2 28
compress 1 3 300 3 2421684 2 19
compress 2 2 240 1 1926108 2 0
compress 3 3 375 3 3021084 2 35
We see that the COMPRESS 1 index is about 89 percent the size of the noncompressed index
(comparing BTREE_SPACE). The number of leaf blocks has decreased measurably. Further, when
we use COMPRESS 2, the savings are even more impressive. The resulting index is about 70 percent
the size of the original, and so much data is able to be placed on individual blocks that
the height of the index actually decreased from 3 to 2. In fact, using the column OPT_CMPR_
PCTSAVE, which stands for optimum compression percent saved or the expected savings from
compression, we could have guessed the size of the COMPRESS 2 index:
ops$tkyte@ORA10G> select 2718736*(1-0.28) from dual;
2718736*(1-0.28)
----------------
1957489.92
■Note The ANALYZE command against the noncompressed index populated the OPT_CMPR_
PCTSAVE/OPT_CMPR_COUNT columns and estimated a 28 percent savings with COMPRESS 2, and
we achieved just about exactly that.
But notice what happens with COMPRESS 3. The resulting index is actually larger: 110 percent
the size of the original index. This is due to the fact that each repeated prefix we remove
saves the space of N copies, but adds 4 bytes of overhead on the leaf block as part of the
compression scheme. By adding in the OBJECT_NAME column to the compressed key, we made
that key unique—in this case, meaning there were no duplicate copies to factor out. Therefore,