ローカル・パーティション索引

ローカル索引の場合、特定の索引パーティションのキーはすべて、基礎となる表の1つのパーティションに格納されている行のみを参照します。ローカル索引は、基礎となる表と同一レベルでパーティション化されます。基礎となる表と同じ列で索引をパーティション化し、同じ数のパーティションまたはサブパーティションを作成して、基礎となる表の対応するパーティションと同じパーティション・バウンドを設定します。

また、Oracle Databaseは、基礎となる表のパーティションが追加、削除、マージまたは分割されたり、ハッシュ・パーティションやサブパーティションが追加または結合されたりした場合は、索引のパーティション化を自動的にメンテナンスします。これにより、索引のパーティションが表と同一レベルに保たれます。

データ・ウェアハウス・アプリケーションでは、ローカル非同一キー索引によってパフォーマンスを向上させることができます。これは、索引キーに基づくレンジ問合せによって、多数の索引パーティションをパラレルにスキャンできるためです。次の例では、ローカルBツリー索引がパーティション表customers_dwに作成されます。

CREATE INDEX cust_last_name_ix
 ON customers_dw(last_name) LOCAL
 PARALLEL NOLOGGING ;

ビットマップ索引では、カーディナリティが低い列を非常に効率よく格納できる方法が使用されます。ビットマップ索引はデータ・ウェアハウス環境で使用され、特にスター・スキーマを実装しているデータ・ウェアハウスで広く使用されています。1つのスター・スキーマは、中心の大きなファクト表と、ファクト表のデータについて説明する複数の小さなディメンション表で構成されます。

たとえば、Oracle Databaseのサンプルshスキーマのsales表はファクト表です。これは、customers、products、promotions、timesおよびchannelsというディメンション表によって説明されます。ビットマップ索引では、スター・スキーマ(またはスターに似ているスキーマ)に対する高速の問合せ取得を最適化する、スター型変換を使用できます。

ファクト表の外部キー列は、ビットマップ索引の理想的な候補です。一般的に、全行数に比べて固有の値が少ないためです。ファクト表は、レンジ・パーティション化、またはレンジと他の方法を組み合せてパーティション化されていることが多いですが、その場合は、ローカル・ビットマップ索引を作成する必要があります。パーティション表のグローバル・ビットマップ索引はサポートされません。

次の例では、ローカル・パーティション・ビットマップ索引がsales表に作成されます。

CREATE BITMAP INDEX prod_id_ix
ON sales(prod_id) LOCAL
PARALLEL NOLOGGING;