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

CHAPTER 10 ■ DATABASE TABLES 369
In this situation, regardless of the size of the data stored in it, Z will be stored “out of line”
in the overflow segment.
Which is better, then: PCTTHRESHOLD, INCLUDING, or some combination of both? It depends
on your needs. If you have an application that always, or almost always, uses the first four
columns of a table and rarely accesses the last five columns, using INCLUDING would be appropriate.
You would include up to the fourth column and let the other five be stored out of line. At
runtime, if you need them, the columns will be retrieved in much the same way as a migrated
or chained row would be. Oracle will read the “head” of the row, find the pointer to the rest of
the row, and then read that. If, on the other hand, you cannot say that you almost always access
these columns and hardly ever access those columns, you should give some consideration to
PCTTHRESHOLD. Setting PCTTHRESHOLD is easy once you determine the number of rows you would
like to store per index block on average. Suppose you wanted 20 rows per index block. Well, that
means each row should be one-twentieth (5 percent). Your PCTTHRESHOLD would be 5, and each
chunk of the row that stays on the index leaf block should consume no more than 5 percent of
the block.
The last thing to consider with IOTs is indexing. You can have an index on an IOT itself—
sort of like having an index on an index. These are called secondary indexes. Normally, an index
contains the physical address of the row it points to, the rowid. An IOT secondary index cannot
do this; it must use some other way to address the row. This is because a row in an IOT can
move around a lot, and it does not “migrate” in the way a row in a heap organized table would.
A row in an IOT is expected to be at some position in the index structure, based on its primary
key value; it will only be moving because the size and shape of the index itself is changing.
(We’ll cover more about how index structures are maintained in the next chapter.) To accommodate
this, Oracle introduced a logical rowid. These logical rowids are based on the IOT’s
primary key. They may also contain a “guess” as to the current location of the row, although
this guess is almost always wrong because after a short while, data in an IOT tends to move.
The guess is the physical address of the row in the IOT when it was first placed into the secondary
index structure. If the row in the IOT has to move to another block, the guess in the
secondary index becomes “stale.” Therefore, an index on an IOT is slightly less efficient than
an index on a regular table. On a regular table, an index access typically requires the I/O to
scan the index structure and then a single read to read the table data. With an IOT, typically
two scans are performed: one on the secondary structure and the other on the IOT itself. That
aside, indexes on IOTs provide fast and efficient access to the data in the IOT using columns
other than the primary key.
Index Organized Tables Wrap-Up
Getting the right mix of data on the index block versus data in the overflow segment is the most
critical part of the IOT setup. Benchmark various scenarios with different overflow conditions,
and see how they will affect your INSERTs, UPDATEs, DELETEs, and SELECTs. If you have a structure
that is built once and read frequently, stuff as much of the data onto the index block as
you can. If you frequently modify the structure, you will have to achieve some balance between
having all of the data on the index block (great for retrieval) versus reorganizing data in the
index frequently (bad for modifications). The freelist consideration you had for heap tables
applies to IOTs as well. PCTFREE and PCTUSED play two roles in an IOT. PCTFREE is not nearly
as important for an IOT as for a heap table, and PCTUSED doesn’t come into play normally.