Index Organized Tables: Indexes have some drawbacks such as it stores data in two places, one in table and

in index. If a query is issued (it is assumed that it uses the index), it checks the index and retrieves the address of data in table. Then the data is fetched from the tables to produce the query output. But in case of an Index Organized Table, data is stored in the index itself with the rows placed in a key-sequenced order, thus eliminating the necessity of duplicate data being stored in index and table. An Index Organized Table is created using the keyword ORGANIZATION INDEX at the end of the CREATE TABLE script. Refer the following example for creation of a IOT: CREATE TABLE temp1 ( slno NUMBER (3) NOT NULL, CONSTRAINT PK_temp1 PRIMARY KEY ( slno)) ORGANIZATION INDEX; Now we will check in what order the data is actually stored by inserting some rows into the table temp1. insert into temp1 values(6); insert into temp1 values(1); insert into temp1 values(5); insert into temp1 values(4); insert into temp1 values(3); insert into temp1 values(2); insert into temp1 values(9); insert into temp1 values(7); insert into temp1 values(8); insert into temp1 values(10); Now after inserting these rows by issuing a select statement without any order clause will retrieve the rows in stored order. Let's check this by issuing the

following statement: select * from temp1; The output is: SLNO 1 2 3 4 5 6 7 8 9 10 Now from this exercise we are clear as to how Oracle stores the data in an Index Organized Table for a normal table the rows would have been selected in the inserted order. What is IOT? So what is an IOT? An IOT has entirely different logic of storage and indexing. In normal tables as soon as we create a row it is associated with a ROWID. This ROWID is permenant as long as the data is there. When an index is created, it stores the column data as well as the ROWID of the table data as it provides its physical location. IOTs do not consider ROWID. This is because the data is actually stored in a BTree index that sorts the data with the leaves in the order of the primary key's data. As and when INSERTs or UPDATEs are fired against this IOT, the rows are re-arranged to store the data in sorted order of the primary key. The access to the data is fast because as soon as the values are found in the BTree index, Oracle is ready to pump the output directly as it is not tied up with ROWIDs. Hence there are two benefits of using IOT: 1. Lookup to table from index is eliminated 2. Storage requirements are reduced as data is stored only in one place. Index-Organized Tables versus Ordinary Tables A row in an ordinary table has a stable physical location. Once it is given its first physical location, it never completely moves. Even if the row is partially moved with the addition of new data, there is always a row piece at the original physical address--identified by the original physical rowid--from which the system can find the rest of the row. As long as the row exists, its physical rowid does not change.

When you index a column in an ordinary table, the newly created index stores both the column data as well as the rowid. A row in an index-organized table does not have a stable physical location. An index-organized table is, on the one hand, like an ordinary table with an index on one or more of its columns. It is unique, however, in that it holds its data, not in stable rows, but in sorted order in the leaves of a B*-tree index built on the table's primary key. These rows may move around to retain the sorted order. An insertion, for example, can cause an index leaf to split and the existing row to be moved to a different slot, or even to a different block. The leaves of the B*-tree index hold the primary key and the actual row data. Changes to the table data--for example, adding new rows, or updating or deleting existing rows--result only in updating the index. Benefits of Index-Organized Tables Index-organized tables provide faster access to table rows by the primary key or any key that is a valid prefix of the primary key. Presence of nonkey columns of a row in the B-tree leaf block itself avoids an additional block access. Also, because rows are stored in primary key order, range access by the primary key (or a valid prefix) involves minimum block accesses. In order to allow even faster access to frequently accessed columns, you can use a row overflow segment (as described later) to push out infrequently accessed nonkey columns from the B-tree leaf block to an optional (heap-organized) overflow segment. This allows limiting the size and content of the portion of a row that is actually stored in the B-tree leaf block, which may lead to a higher number of rows in each leaf block and a smaller B-tree. Unlike a configuration of heap-organized table with a primary key index where primary key columns are stored both in the table and in the index, there is no such duplication here because primary key column values are stored only in the B-tree index. Because rows are stored in primary key order, a significant amount of additional storage space savings can be obtained through the use of key compression. Use of primary-key based logical rowids, as opposed to physical rowids, in secondary indexes on index-organized tables allows high availability. This is because, due to the logical nature of the rowids, secondary indexes do not become unusable even after a table reorganization operation that causes movement of the base table rows. At the same time, through the use of physical guess in the logical rowid, it is possible to get secondary index based indexorganized table access performance that is comparable to performance for secondary index based access to an ordinary table.

Secondary Indexes on Index-Organized Tables Secondary index support on index-organized tables provides efficient access to index-organized table using columns that are not the primary key nor a prefix of the primary key. Oracle Database constructs secondary indexes on index-organized tables using logical row identifiers (logical rowids) that are based on the table's primary key. A logical rowid includes a physical guess, which identifies the block location of the row. Oracle Database can use these physical guesses to probe directly into the leaf block of the index-organized table, bypassing the primary key search. Because rows in index-organized tables do not have permanent physical addresses, the physical guesses can become stale when rows are moved to new blocks. For an ordinary table, access by a secondary index involves a scan of the secondary index and an additional I/O to fetch the data block containing the row. For index-organized tables, access by a secondary index varies, depending on the use and accuracy of physical guesses:

Without physical guesses, access involves two index scans: a secondary index scan followed by a scan of the primary key index. With accurate physical guesses, access involves a secondary index scan and an additional I/O to fetch the data block containing the row. With inaccurate physical guesses, access involves a secondary index scan and an I/O to fetch the wrong data block (as indicated by the physical guess), followed by a scan of the primary key index.

Bitmap Indexes on Index-Organized Tables Oracle Database supports bitmap indexes on partitioned and nonpartitioned index-organized tables. A mapping table is required for creating bitmap indexes on an index-organized table. Mapping Table The mapping table is a heap-organized table that stores logical rowids of the index-organized table. Specifically, each mapping table row stores one logical rowid for the corresponding index-organized table row. Thus, the mapping table provides one-to-one mapping between logical rowids of the index-organized table rows and physical rowids of the mapping table rows. A bitmap index on an index-organized table is similar to that on a heap-organized table except that the rowids used in the bitmap index on an index-organized table are those of the mapping table as opposed to the base table. There is one mapping table for each index-organized table and it is used by all the bitmap indexes created on that index-organized table. In both heap-organized and index-organized base tables, a bitmap index is accessed using a search key. If the key is found, the bitmap entry is converted to

a physical rowid. In the case of heap-organized tables, this physical rowid is then used to access the base table. However, in the case of index-organized tables, the physical rowid is then used to access the mapping table. The access to the mapping table yields a logical rowid. This logical rowid is used to access the index-organized table. Though a bitmap index on an index-organized table does not store logical rowids, it is still logical in nature. Logical Rowid Like indexes, IOTs are subject to inserts, deletes, block splits and coalsces, all of which affect the rowid. This means a standard rowid cannot always be used to retrieve an IOT record from a secondary index. For this reason secondary indexes on IOTs use a logical rowid which is made up of the original rowid and the primary key of the row. When a secondary index is referenced the rowid is used to find the block. If the block is not present at that disk address the primary key is used to find the block. This initial rowid access is know as a guess, since the block may not be at its origninal disk address anymore. Physical movements of the row do not affect the logical rowid, so long as the primary key is not updated. With time the percentage of hits using the guess rowid will drop. When the hitrate gets sufficiently low the index should be dropped and recreated to refesh the guess rowids. The guess hitrate can be monitored using the PCT_DIRECT_ACCESS column of DBA_INDEXES, ALL_INDEXES and USER_INDEXES: SELECT index_name, index_type, pct_direct_access FROM user_indexes WHERE pct_direct_access IS NOT NULL; Bitmap Secondary Indexes A bitmap index contains a series of bitmaps that represent row locations corresponding to each key value. The bitmap can locate the row because it assumes the rows are contiguous within the block. Since this is not the case in IOTs Oracle8i did not allow secondary bitmap indexes on IOTs. Oracle9i removes this restriction by introducing a mapping table which literally maps the bit position to the row location within the IOT. The mapping table is created as part of the CREATE TABLE statement: CREATE TABLE countries ( country_id CHAR(2) CONSTRAINT country_id_nn NOT NULL, country_name VARCHAR2(40), currency_name VARCHAR2(25),

currency_symbol VARCHAR2(3), region VARCHAR2(15), CONSTRAINT country_c_id_pk PRIMARY KEY (country_id) ) ORGANIZATION INDEX MAPPING TABLE TABLESPACE tbs_1; Maintenance of the mapping tables causes a performance overhead so they should only be created for IOTs that need to support secondary bitmap indexes. A single mapping table can support multiple bitmap indexes on the same table.