05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

426<br />

CHAPTER 11 ■ INDEXES<br />

big_table@ORA9IR2> select id from big_table where id = 12345;<br />

Statistics<br />

----------------------------------------------------------<br />

... 3 consistent gets<br />

... 1 rows processed<br />

big_table@ORA9IR2> select id from big_table where id = 1234567;<br />

Statistics<br />

----------------------------------------------------------<br />

...<br />

3 consistent gets<br />

...<br />

1 rows processed<br />

The B*Tree is an excellent general-purpose indexing mechanism that works well for large<br />

<strong>and</strong> small tables, <strong>and</strong> experiences little, if any, degradation in retrieval performance as the size<br />

of the underlying table grows.<br />

Index Key Compression<br />

One of the interesting things you can do with a B*Tree index is “compress” it. This is not compression<br />

in the same manner that ZIP files are compressed; rather, this is compression that<br />

removes redundancies from concatenated (multicolumn) indexes.<br />

We covered compressed key indexes in some detail in the section “Index Organized<br />

Tables” in Chapter 10, <strong>and</strong> we will take a brief look at them again here. The basic concept<br />

behind a compressed key index is that every entry is broken into two pieces: a “prefix” <strong>and</strong><br />

“suffix” component. The prefix is built on the leading columns of the concatenated index <strong>and</strong><br />

will have many repeating values. The suffix is built on the trailing columns in the index key<br />

<strong>and</strong> is the unique component of the index entry within the prefix.<br />

By way of example, we’ll create a table <strong>and</strong> a concatenated index <strong>and</strong> measure its space<br />

without compression using ANALYZE INDEX. We’ll then re-create the index with index key compression,<br />

compressing a different number of key entries, <strong>and</strong> see the difference. Let’s start<br />

with this table <strong>and</strong> index:<br />

ops$tkyte@ORA10G> create table t<br />

2 as<br />

3 select * from all_objects;<br />

Table created.<br />

ops$tkyte@ORA10G> create index t_idx on<br />

2 t(owner,object_type,object_name);<br />

Index created.<br />

ops$tkyte@ORA10G> analyze index t_idx validate structure;<br />

Index analyzed.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!