Iot
- 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