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

364
CHAPTER 10 ■ DATABASE TABLES
Let’s demonstrate the savings by doing a quick test of the preceding CREATE TABLE as
SELECT with NOCOMPRESS, COMPRESS 1, and COMPRESS 2. We’ll start by creating our IOT without
compression:
ops$tkyte@ORA10GR1> create table iot
2 ( owner, object_type, object_name,
3 constraint iot_pk primary key(owner,object_type,object_name)
4 )
5 organization index
6 NOCOMPRESS
7 as
8 select distinct owner, object_type, object_name
9 from all_objects
10 /
Table created.
Now we can measure the space used. We’ll use the ANALYZE INDEX VALIDATE STRUCTURE
command for this. This command populates a dynamic performance view named INDEX_
STATS, which will contain only one row at most with the information from the last execution
of that ANALYZE command:
ops$tkyte@ORA10GR1> analyze index iot_pk validate structure;
Index analyzed.
ops$tkyte@ORA10GR1> select lf_blks, br_blks, used_space,
2 opt_cmpr_count, opt_cmpr_pctsave
3 from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
284 3 2037248 2 33
So, that shows our index is currently using 284 leaf blocks (where our data is) and 3
branch blocks (blocks Oracle uses to navigate the index structure) to find the leaf blocks. The
space used is about 2MB (2,038,248 bytes). The other two oddly named columns are trying to
tell us something. The OPT_CMPR_COUNT (optimum compression count) column is trying to say,
“If you made this index COMPRESS 2, you would achieve the best compression.” The OPT_CMPR_
PCTSAVE (optimum compression percentage saved) is telling us if we did the COMPRESS 2, we
would save about one-third of the storage and the index would consume just two-thirds the
disk space it is now.
■Note The next chapter covers the index structure in more detail.