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

CHAPTER 11 ■ INDEXES 447
an index is not the optimal plan, even for the very ordered table). However, if we select only 10
percent of the table data, we observe the following:
ops$tkyte@ORA10G> select * from colocated where x between 20000 and 30000;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=143 Card=10002 Bytes=800160)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'COLOCATED' (TABLE) (Cost=143 ...
2 1 INDEX (RANGE SCAN) OF 'COLOCATED_PK' (INDEX (UNIQUE)) (Cost=22 ...
ops$tkyte@ORA10G> select * from disorganized where x between 20000 and 30000;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=337 Card=10002 Bytes=800160)
1 0 TABLE ACCESS (FULL) OF 'DISORGANIZED' (TABLE) (Cost=337 Card=10002 ...
Here we have the same table structures and the same indexes, but different clustering factors.
The optimizer, in this case, chose an index access plan for the COLOCATED table and a full
scan access plan for the DISORGANIZED table. Bear in mind that 10 percent is not a threshold
value—it is just a number that is less than 25 percent and that caused an index range scan to
happen in this case (for the COLOCATED table).
The key point to this discussion is that indexes are not always the appropriate access
method. The optimizer may very well be correct in choosing to not use an index, as the preceding
example demonstrates. Many factors influence the use of an index by the optimizer,
including physical data layout. You might be tempted, therefore, to run out and try to rebuild
all of your tables now to make all indexes have a good clustering factor, but that would be a
waste of time in most cases. It will affect cases where you do index range scans of a large percentage
of a table. Additionally, you must keep in mind that in general the table will have only
one index with a good clustering factor! The rows in a table may be sorted in only one way. In
the example just shown, if I had another index on the column Y, it would be very poorly clustered
in the COLOCATED table, but very nicely clustered in the DISORGANIZED table. If having the
data physically clustered is important to you, consider the use of an IOT, a B*Tree cluster, or a
hash cluster over continuous table rebuilds.
B*Trees Wrap-Up
B*Tree indexes are by far the most common and well-understood indexing structures in the
Oracle database. They are an excellent general-purpose indexing mechanism. They provide
very scalable access times, returning data from a 1,000-row index in about the same amount
of time as a 100,000-row index structure.
When to index and what columns to index are things you need to pay attention to in your
design. An index does not always mean faster access; in fact, you will find that indexes will
decrease performance in many cases if Oracle uses them. It is purely a function of how large of
a percentage of the table you will need to access via the index and how the data happens to be