Published on

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

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Index-Organized Tables Administration TipsWhat is an Index Organised Table?An Index Organised Table (IOT) is a table that is, er, organised like an index! In otherwords, it is stored in a B-tree format, complete with root nodes, branch nodes and leafnodes, with the rows of data stored in the order of the primary key of the table (thatmeans 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 thekey columns. There would then be a row id to point from that key value to where the restof the non-key columns are stored -in the regular, heap table on which the index was builtin 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 timeout to read parts of the index first. Indeed, the whole point of the IOT is that it gives usthe speed of access to non-key data usually associated with using an index, but withouthaving to maintain two separate segments (the index and the table). We can actuallyimprove on the performance of regular index access to non-key data because we donthave the overhead associated with two block reads (one from the index and one from theregular 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 its usually the casethat 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 allthe usual horrors associated with index maintenance. For a start, youll likely get blocksplits in an IOT. That means they become progressively more inefficient over time. To tryand prevent block splits in regular indexes, we usually set quite a high PCTFREE (in theorder of 35%+), and the same is true of IOTs -which mean our blocks are full of fresh aireven before we begin to use the thing. Updates to the Primary Key column results in amark for deletion of the original row, and an insert of a new one in the correct location,not a direct update -thats more expensive than a similar update would be on a regulartable. It also means the old row data is still effectively sitting in the block taking up space.As with normal indexes, we dont tidy that mess up until the entire leaf node is emptied ofall 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 stillhaving to be read by full table scans.Summing all of that up: IOTs, just like regular B-tree indexes, can become inefficient usersof space, and thus performance using them degrades over time. They therefore need tobe rebuilt regularly, just as normal indexes do. Actually, we dont really rebuild IOTs -weissue the alter table blah move tablespace X command, but that has precisely the sameeffect as a rebuild of an index.Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 3
  2. 2. Index-Organized Tables Administration TipsSo, 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 amoment about regular indexes. Their leaf nodes contain the key column data, and a rowid of the main table where the non-key data can be found. But they dont have row ids oftheir own! Thats fair enough for a regular index: the purpose of the row id is to physicallyidentify each table row. In an index, that function is performed by the key column dataitself.But now translate that into IOTs: IOT rows dont have a row id, either.What does that mean? It means that you cant have indexes on an IOT, because whatwould those secondary indexes use as their means of pointing back to the full IOT row?They cant use a rowid for the job, because IOTs dont have rowids!Thats a bit of a killer restriction, because apart from ruling out creating your own indexeson non-primary key columns, it also rules out declaring a unique constraint on othercolumns of the IOT, because unique constraints require a index as their enforcementmechanism.In Oracle 8.0, that was a sufficient reason not to use IOTs, except on those rare occasionswhen you could honestly state that secondary indexes and unique constraints on othercolumns were totally unnecessary.Fortunately, in 8i all these restrictions were lifted. IOTs still dont 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 8istill states that whilst secondary indexes are allowed, unique constraints arent. Thedocumentation is wrong.)The UROWID is not perfect, however. When you first create the secondary index on an IOT,all the UROWIDs will be accurate -theyll point to the right bit of the IOT data every time.As you perform DML to the IOT, however, youll induce block splits on the IOT itself, andthat means that the secondary index UROWIDs might now be pointing to the wrong block(since they arent updated when the IOT itself is). If you are accessing IOT data via a stalesecondary index in this way, Oracle will have to do I/O to read the wrong block from theIOT and then, when it discovers it is the wrong block, it has to go back to the IOT andscanit in its entirety for the right one.What that all boils down to is: in 8i, whilst secondary indexes are allowed, they need to berebuilt rather more frequently than an index on a normal table would be, if they are to beof 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. 3. Index-Organized Tables Administration TipsBroadly speaking, any table that is frequently searched and accessed almost exclusively viathe primary key is a candidate for IOT treatment. But a table which needs secondaryindexes and unique key constraints needs to be thought about carefully: if it is moderatelystatic in nature, then the maintenance costs might be easily bearable. But a wildly-updated table with secondary indexes and unique key constraints, even if regularlyaccessed 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 concatenatedprimary key which represents a substantial proportion of the entire row length. As a realexample, I once had to design a table consisting of 8 columns, 6 of which (whenconcatenated) were the primary key. What is the point of building a regular indexcontaining 6 columns-worth of data simply to point to a regular table where those same 6columns of data were duplicated, thereby allowing retrieval of the other 2 columns? Whynot just store all 8 columns in one segment in the first place -which is exactly what an IOTlets you do?Used with due care, IOTs can give you huge performance gains (by reducing the I/Oassociated with having to read blocks from both an index and a table segment). They canalso save you significant amounts of space (because they avoid the need to duplicate keycolumns in both an index and a table segment). But they come at the cost of increasedmaintenance requirements, both for the IOT itself and for any secondary indexes that maybe 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