Beruflich Dokumente
Kultur Dokumente
Other database systems such as MAXDB or DB2 use IOTs by default, whereas on Oracle, you must
configure this function explicitly.
• The IOT combines a table and index in one, saving you the effort of creating an index.
• Queries using the fields of this index result in fewer block accesses, since all of the information is
already in the index blocks and an additional access to table blocks is no longer necessary. This
fact means there are significant performance gains, especially when compared to indexes with a
high clustering factor. The higher the number of blocks that have to be read on average from the
hard disk (see also Note 832343), the more important these gains.
The IOT is always defined on the basis of a PRIMARY KEY constraint. In just the same way as the UNIQUE
KEY constraint, a PRIMARY KEY constraint requires unique combinations of the indexed columns.
However, NULL values are not allowed in the indexed columns.
All data is stored in the index. The IOT table is in the database, but does not occupy any space in the
database and is therefore not a segment.
To avoid having to store too large data records in the index, you can define an overflow segment when
creating an IOT in which the last columns of long data records are stored.
If secondary indexes are defined on the IOT, the fields of the PRIMARY KEYs are always stored at the end
of the secondary index entries.
Secondary indexes accessed the IOT using Logical ROWIDs that provide a "Guess" for the correct data
block of a data record in the IOT.
• Before you can create a PRIMARY KEY constraint, there must be one or more columns with
unique value combinations that do not contain any NULL values.
• The maximum length of a table entry is limited to slightly less than half of an index block (for
example, 3215 bytes). When you try to define an IOT with table rows or index fields that are too
long, errors such as ORA-01429 or ORA-01450 are generated.
• If there is already a PRIMARY KEY constraint for the table, you cannot create another PRIMARY
KEY constraint as the basis for the IOT. In this case, you must check whether the existing
constraint is required at all. For example, PRIMARY KEY constraints were added to the SAP
primary indices with earlier R/3 releases. However, these constraints are not required for SAP
operation and can be deleted if required. With newer releases, PRIMARY KEY constraints are no
longer created on SAP tables.
• The storage requirement and the growth of the IOT may be significantly higher than for a normal
table because indexes generally fragment more easily than tables.
• Since the PRIMARY KEY columns are also included in the secondary indexes, these indexes
require proportionately more space.
• A defragmentation of the relevant index using REBUILD or COALESCE is not possible. A MOVE
ONLINE can be carried out instead, however.
• Columns of the ROWID type cannot be defined.
• Parallel Data Manipulation Language (DML) is not possible for IOTs that are not partitioned.
Therefore, for example, long unavoidable runtimes may occur with
DBMS_REDEFINITION.START_REDEF_TABLE if the target object is defined as an IOT and a
large number of data records must be inserted.
• If you use IOTs on Oracle 9i and upgrade to 10g, data may become corrupt. For more information,
see Note 1135589.
The ABAP DDIC supports the creation of IOTs based on the SAP primary index. You can convert a normal
table to a primary index IOT as follows:
Transaction SE14
-> Storage Parameters
-> For new Creation
-> INDEX ORGANIZED: X
Transaction SE14
-> Tools
-> Force conversion
to an IOT.
Creating an IOT based on a secondary index is not supported by ABAP DDIC, but is permitted. In this case,
you can expect the following restrictions:
6. Can the PRIMARY KEY of an IOT differ from the SAP primary index?
The PRIMARY KEY constraint underlying an IOT does not have to be the same as the primary index of the
table on the SAP system. For example, if you have performance problems in the availability run, you can
support important RESB accesses with MANDT and MATNR using an IOT with the PRIMARY KEY
constraint using MANDT, MATNR, RSNUM, RSPOS and RSART, while the primary index only contains the
columns MANDT, RSNUM, RSPOS and RSART. Note, however, that such a setup is not supported by
ABAP DDIC (see above).
If the above IOT is filled with data, these are stored directly in the <index_name> index and not in the
<table_name> table.
If Oracle decides on a "Full Table Scan", this corresponds to an Index Full Scan or an Index Fast Full Scan
in the case of an IOT because the data records are stored in the form of an index.
If the PRIMARY KEY on which the IOT is based is used for the access, this is the same as an Index Range
Scan or Index Unique Scan on the IOT. There is no need to perform a final table access via ROWID
because all data is already in the index.
The following steps occur if an index other than the PRIMARY KEY index is used for the access:
• The index is searched (as part of an Index Range Scan or similar) for appropriate data records.
Both columns from the index itself and the columns from the PRIMARY KEYs can be analyzed in
this case because these are also stored in all indexes.
• If required, a guess is used to determine a data record directly in the IOT for each suitable data
record. The guess is based on a logical ROWID, but this may rendered invalid in certain situations
(such as block splits, for example).
• If the guess is not valid, the related IOT record is determined using an Index Unique Scan on the
PRIMARY KEY index.
This type of access is therefore more like a Nested Loop Join (with the PRIMARY KEY columns as
join conditions between PRIMARY KEY index and other index) than a normal index table access.
The percentage of valid logical ROWIDS of a secondary index are stored in the CBO statistical value
PCT_DIRECT_ACCESS in DBA_INDEXES. You can query this value for all indexes of the IOT using the
following command:
For values close to 100 %, no action is required. For values below 90 %, the logical ROWIDS (see below)
may be updated.
Note that the values are only as current as the corresponding CBO statistics. If in doubt, create new CBO
characteristics for the IOT in advance.
You can reorganize an IOT by executing the following command in the current operation:
Note that double the space is temporarily required in the tablespace for this reorganization.
12. How I can check whether (and which) IOTs exist in the system?
In this case, TABLE_NAME contains the name of the table, while INDEX_NAME is the name of the index
that supports the PRIMARY KEY constraint and contains all the data.
Since SAP is not adapted to the monitoring of IOTs, certain information such as space consumption or
extent allocation must be determined directly on the database. The following options are available for this
purpose (<index_name> can be determined as described in the previous question):
Executing an ALTER INDEX on the index of an IOT (to adjust storage parameters, for example) is not
authorized. This type of attempt fails with:
If you encounter this error, you must adapt the IOT instead (using ALTER TABLE).
If R3UP encounters this problem during an upgrade, import a current version of R3UP that is no longer
affected by the problem.
Indexes of IOTs are created under the name SYS_IOT_TOP_ ... if no explicit name was entered during the
definition.
If the name of the IOT is SYS_JOURNAL_< object_id>, the IOT frame of an INDEX REBUILD ONLINE is
temporarily created. If an unexpected error (for example, tablespace overflow) occurs during the rebuild with
Oracle 9.2.0.3, the temporary IOT and their index are no longer tidied up correctly and remain available in
the system. If you discover this type of relics, you can delete the IOT and its related index after you have
made sure that the index whose rebuild has terminated exists correctly in the system. If you are no longer
able to determine the index in question, you can make your conclusions as follows:
With the following statement, you can determine the affected table using the <object_id> contained
in the IOT name:
With the following statement, you can determine when the index rebuild terminated:
You can now search in the alert log for error entries (from which you can usually see the affected index) for
the period in question (and subsequent hours).
If the IOT is based on the SAP primary index, the changeover can be carried out by a coversion based on
the SAP DDIC function. If the IOT is based on other columns, however, the conversion is carried out based
on an BRSPACE online reorganization (Note 646681). Proceed as described in comment 5 in Note 646681
and edit the DDL script to create the table ("CREATE TABLE ..."):
Call BRSPACE:
If BRSPACE stops with the message "BR1148I: You can check/change the DDL statements now",
you must make the following changes to the generated ddl.sql script and save those changes: