oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

1. Index-Organized Tables Administration Tips
What is an Index Organised Table?
An Index Organised Table (IOT) is a table that is, er, organised like an index! In other
words, it is stored in a B-tree format, complete with root nodes, branch nodes and leaf
nodes, with the rows of data stored in the order of the primary key of the table (that
means an IOT must be created with a primary key constraint).
Where they differ from a regular B-tree index is that, in an index, we would only store the
key columns. There would then be a row id to point from that key value to where the rest
of the non-key columns are stored -in the regular, heap table on which the index was built
in the first place. In an IOT, by contrast, not only do we store the primary key column(s)
of the table, but we also store all the non-key columns, too.
That means that access to those non-key columns does not have to be made by taking time
out to read parts of the index first. Indeed, the whole point of the IOT is that it gives us
the speed of access to non-key data usually associated with using an index, but without
having to maintain two separate segments (the index and the table). We can actually
improve on the performance of regular index access to non-key data because we don't
have the overhead associated with two block reads (one from the index and one from the
regular table) -instead we only read one block from the IOT itself.
They sound great -so there must be a catch (I hate to be cynical, but it's usually the case
that any benefits you get from doing X usually implies some drawback Y!!!).
The catch is that IOTs are structured like indexes -which means that they are subject to all
the usual horrors associated with index maintenance. For a start, you'll likely get block
splits in an IOT. That means they become progressively more inefficient over time. To try
and prevent block splits in regular indexes, we usually set quite a high PCTFREE (in the
order of 35%+), and the same is true of IOTs -which mean our blocks are full of fresh air
even before we begin to use the thing. Updates to the Primary Key column results in a
'mark for deletion' of the original row, and an insert of a new one in the correct location,
not a direct update -that's more expensive than a similar update would be on a regular
table. It also means the old row data is still effectively sitting in the block taking up space.
As with normal indexes, we don't tidy that mess up until the entire leaf node is emptied of
all records -effectively, that means PCTUSED is set to 0 and cannot be changed.
Potentially, that means you could have IOT leaf nodes sitting there 99.9% empty -and still
having to be read by full table scans.
Summing all of that up: IOTs, just like regular B-tree indexes, can become inefficient users
of space, and thus performance using them degrades over time. They therefore need to
be 'rebuilt' regularly, just as normal indexes do. Actually, we don't really rebuild IOTs -we
issue the 'alter table blah move tablespace X' command, but that has precisely the same
effect as a rebuild of an index.
Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 3

2. Index-Organized Tables Administration Tips
So, as with many things Oracle, the deal is: extra performance for extra maintenance.
There are additional issues to consider when using IOTs, though, as well. Think for a
moment about regular indexes. Their leaf nodes contain the key column data, and a row
id of the main table where the non-key data can be found. But they don't have row ids of
their own! That's fair enough for a regular index: the purpose of the row id is to physically
identify each table row. In an index, that function is performed by the key column data
itself.
But now translate that into IOTs: IOT rows don't have a row id, either.
What does that mean? It means that you can't have indexes on an IOT, because what
would those secondary indexes use as their means of pointing back to the full IOT row?
They can't use a rowid for the job, because IOTs don't have rowids!
That's a bit of a killer restriction, because apart from ruling out creating your own indexes
on non-primary key columns, it also rules out declaring a unique constraint on other
columns of the IOT, because unique constraints require a index as their enforcement
mechanism.
In Oracle 8.0, that was a sufficient reason not to use IOTs, except on those rare occasions
when you could honestly state that secondary indexes and unique constraints on other
columns were totally unnecessary.
Fortunately, in 8i all these restrictions were lifted. IOTs still don't have genuine row ids,
but instead they were given "logical row ids", otherwise known as the UROWID (for
"universal row id"). And that meant that secondary indexes and unique constraints on non-
primary key columns were now possible. (Incidentally, the Oracle documentation for 8i
still states that whilst secondary indexes are allowed, unique constraints aren't. The
documentation is wrong.)
The UROWID is not perfect, however. When you first create the secondary index on an IOT,
all the UROWIDs will be accurate -they'll point to the right bit of the IOT data every time.
As you perform DML to the IOT, however, you'll induce block splits on the IOT itself, and
that means that the secondary index UROWIDs might now be pointing to the wrong block
(since they aren't updated when the IOT itself is). If you are accessing IOT data via a 'stale'
secondary index in this way, Oracle will have to do I/O to read the wrong block from the
IOT and then, when it discovers it is the wrong block, it has to go back to the IOT and
scanit in its entirety for the right one.
What that all boils down to is: in 8i, whilst secondary indexes are allowed, they need to be
rebuilt rather more frequently than an index on a normal table would be, if they are to be
of much use. Yet more maintenance costs, therefore.
Having said all of that, when would it make sense to use an IOT?
Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 3

3. Index-Organized Tables Administration Tips
Broadly speaking, any table that is frequently searched and accessed almost exclusively via
the primary key is a candidate for IOT treatment. But a table which needs secondary
indexes and unique key constraints needs to be thought about carefully: if it is moderately
static in nature, then the maintenance costs might be easily bearable. But a wildly-
updated table with secondary indexes and unique key constraints, even if regularly
accessed via the Primary Key, is probably going to be more trouble than it is worth.
Another real candidate for IOT treatment is any table where there is a concatenated
primary key which represents a substantial proportion of the entire row length. As a real
example, I once had to design a table consisting of 8 columns, 6 of which (when
concatenated) were the primary key. What is the point of building a regular index
containing 6 columns'-worth of data simply to point to a regular table where those same 6
columns of data were duplicated, thereby allowing retrieval of the other 2 columns? Why
not just store all 8 columns in one segment in the first place -which is exactly what an IOT
lets you do?
Used with due care, IOTs can give you huge performance gains (by reducing the I/O
associated with having to read blocks from both an index and a table segment). They can
also save you significant amounts of space (because they avoid the need to duplicate key
columns in both an index and a table segment). But they come at the cost of increased
maintenance requirements, both for the IOT itself and for any secondary indexes that may
be built on it -all need regular re-building if efficiency of access is to be kept up.
Copyright © Howard Rogers 2001 10/17/2001 Page 3 of 3