How Do Indexes Become Unusable? (Doc ID 1054736.6)

How Do Indexes Become Unusable? (Doc ID 1054736.6)

Description of which operations mark index partitions as INDEX UNUSABLE.

CAUSE

There are six types of maintenance operations and adding a partition to a Hash-Partitioned Table that mark index partitions INDEX UNUSABLE (IU). In all cases, you must rebuild the index partitions when the operation is complete.

SOLUTION

NOTE: In the images and/or the document content below, the user information and data used represents fictitious data from the Oracle sample schema(s) or Public Documentation delivered with an Oracle database product. Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.

Maintenance operations causing index partitions to become INDEX UNUSABLE (IU):

1. IMPORT PARTITION or conventional path SQL*Loader.

2. Direct-path SQL*Loader leaves affected local index partitions and global indexes in an IU state if it does not complete successfully.

3. Partition maintenance operations like ALTER TABLE MOVE PARTITION.

4. Partition maintenance operations like ALTER TABLE TRUNCATE PARTITION.

5. Partition maintenance operations like ALTER TABLE SPLIT PARTITION.

6. Index maintenance operations like ALTER INDEX SPLIT PARTITION.

7. Adding a Partition to a Hash-Partitioned Table

Adding a Partition to a Hash-Partitioned Table

When you add a partition to a hash-partitioned table, the database populates the new partition with rows rehashed from an existing partition (selected by the database) as determined by the hash function. Consequently, if the table contains data, then it may take some time to add a hash partition.

The following statements show two ways of adding a hash partition to table <Table_Name>. Choosing the first statement adds a new hash partition whose partition name is system generated, and which is placed in the default tablespace. The second statement also adds a new hash partition, but that partition is explicitly named <Partition_Name> and is created in tablespace <Tablespace_Name>.

ALTER TABLE <Table_Name> ADD PARTITION;

ALTER TABLE <Table_Name> ADD PARTITION <Partition_Name> TABLESPACE <Tablespace_Name>;

Indexes may be marked UNUSABLE as explained in the following table:

Table Type Index Behavior

Regular (Heap) Unless you specify UPDATE INDEXES as part of the ALTER TABLE statement:

The local indexes for the new partition, and for the existing partition from which rows were redistributed, are marked UNUSABLE and must be rebuilt.

All global indexes, or all partitions of partitioned global indexes, are marked UNUSABLE and must be rebuilt.

Index-organized For local indexes, the behavior is identical to heap tables.

All global indexes remain usable.

Each of these operations may cause index partitions to be marked IU which will require the index partitions to be rebuilt.

Version 10.2 and later

By default, many table maintenance operations on partitioned tables invalidate (mark UNUSABLE) the corresponding indexes or index partitions. You must then rebuild the entire index or, in the case of a global index, each of its partitions. The database lets you override this default behavior if you specify UPDATE INDEXES in your ALTER TABLE statement for the maintenance operation. Specifying this clause tells the database to update the index at the time it executes the maintenance operation DDL statement.

The following operations support the UPDATE INDEXES clause:

* ADD PARTITION | SUBPARTITION

* COALESCE PARTITION | SUBPARTITION

* DROP PARTITION | SUBPARTITION

* EXCHANGE PARTITION | SUBPARTITION

* MERGE PARTITION | SUBPARTITION

* MOVE PARTITION | SUBPARTITION

* SPLIT PARTITION | SUBPARTITION

* TRUNCATE PARTITION | SUBPARTITION

Note:12c has come up with Optimized Global index maintenance during drop or truncate partition.Please refer the below note for more details:

12c Partitioning Enhancements, New Features (Doc ID 1568010.1)

REFERENCES

Database Administrator's Guide 10g Release 2 (10.2)