プライマリ・コンテンツに移動
Oracle® Database VLDBおよびパーティショニング・ガイド
12c リリース1 (12.1)
B71291-10
目次へ移動
目次
索引へ移動
索引

前
次

パフォーマンス

OLTP環境のパフォーマンスは、効率のよい索引アクセスに大きく左右されるため、最適な索引戦略の選択が重要です。次の項では、OLTP環境で索引をパーティション化するかどうかを決定するためのベスト・プラクティスを説明します。

索引をパーティション化するかどうかの決定

問合せの選択性とOLTPアプリケーションの高い同時実行性のため、OLTP環境でのパーティション化の使用に関して、正しい索引戦略の選択が重要な決定事項であることは疑う余地もありません。様々な索引構造の主な利点とトレードオフを説明するために、次に基本的なルールを示します。

  • 非パーティション索引(パーティション索引の個々のセグメントよりも大きい)では、索引のアクセス・パスが選択される場合は常に索引プローブ(スキャン)が1回行われます。1つの表に対して1つのセグメントしかないためです。データ・アクセス時間とアクセスされるブロック数は、パーティション表でも非パーティション表でも同じです。

    非パーティション索引には、パーティションの自律性はないため、行IDに影響するすべてのパーティション・メンテナンス操作(たとえば、削除、切捨て、移動、マージ、結合、分割などの操作)について索引メンテナンス操作が必要です。

  • パーティション索引には常に複数のセグメントがあります。Oracle Databaseが1つの索引セグメントにプルーニングできない場合、データベースは常に複数のセグメントにアクセスする必要があります。これによってI/O要件が高まる可能性が潜在的にあり(非パーティション索引の1回のプローブに対して、n個の索引セグメントのプローブ)、実行時パフォーマンスに(測定可能または不可能にかかわらず)影響が出ることがあります。これはすべてのパーティション索引に当てはまります。

    パーティション索引は、ローカル・パーティション索引またはグローバル・パーティション索引のいずれかになります。ローカル・パーティション索引は、常に表のパーティション化キーを継承し、表パーティションとまったく同様に配置されます。結果として、あらゆる種類のパーティション・メンテナンス操作で、索引メンテナンス作業はほとんどまたはまったく必要ありません。たとえば、パーティションの削除または切捨てによって発生する索引メンテナンスのオーバーヘッドはほとんど目立ちません。このとき、ローカル索引パーティションは削除または切り捨てされます。

    表と一緒に配置されていないパーティション索引は、グローバル・パーティション索引と呼ばれます。ローカル索引とは異なり、表と索引パーティションの間に関係はありません。グローバル・パーティション索引は柔軟性が高く、効率のよいパーティション索引アクセスに最適なパーティション化キーを選択できます。パーティション・メンテナンス操作は、操作のタイプや索引のパーティション化キーによって異なりますが、通常はグローバル・パーティション索引の(すべてでないとしても)いくつかのパーティションに影響します。

  • 状況によっては、1つの索引を複数のセグメントに分けることでパフォーマンスが向上することがあります。OLTP環境では、連番を利用して人工的なキーを作成することがごく一般的です。したがって、単調に増加するキー値を作成することになり、そのために多くの挿入プロセスが同じ索引ブロックを競合するようになります。グローバル・パーティション索引の導入(たとえば、キー列でのグローバル・ハッシュ・パーティション化の使用)により、この問題が緩和されます。たとえば、そのような索引1つに4つのハッシュ・パーティションがある場合は、データを挿入するために4つの索引セグメントがあるため、挿入プロセスに関してこれらのセグメントに対する同時実行が4分の1に減少します。

競合が減ることにより、アプリケーションでサポートできるユーザー数が増加します。例7-1は、orders_oltp表のorder_id列での一意索引の作成を示します。このOLTPアプリケーションのorder_idには連番が入力されます。この一意索引では、ハッシュ・パーティション化を使用して、単調に増加するorder_id値への競合を減らします。また、この一意キーが主キー制約を作成するために使用されます。

一意性の施行は、OLTP環境のための重要なデータベース機能です。一意性は、非パーティション索引でもパーティション索引でも施行できます。ただし、パーティション索引にはパーティションの自律性があるため、一意索引を実装するために次の要件を満たす必要があります。

  • 非パーティション索引は、任意の列、または列の組合せに対して一意性を施行できます。非パーティション索引の動作は、非パーティション表についてもパーティション表についても同じです。

  • パーティション索引の各パーティションは、自律型セグメントとみなされます。これらのセグメントの自律性を施行するには、一意キー定義のサブセットとしてパーティション化キー列を必ず含める必要があります。

    • グローバル・パーティション索引には、常に、索引列の少なくとも先頭列(パーティション・グローバル索引のパーティション化列)に接頭辞を付ける必要があります。

    • 一意ローカル索引の一意キー定義のサブセットは、表のパーティション化キーであることが必要です。

例7-1 一意索引および主キー制約の作成

CREATE UNIQUE INDEX orders_pk
  ON orders_oltp(order_id)
  GLOBAL PARTITION BY HASH (order_id)
  ( PARTITION p1 TABLESPACE tbs1
   , PARTITION p2 TABLESPACE tbs2
   , PARTITION p3 TABLESPACE tbs3
   , PARTITION p4 TABLESPACE tbs4
  ) NOLOGGING;

ALTER TABLE orders_oltp ADD CONSTRAINT orders_pk
  PRIMARY KEY (order_id)
  USING INDEX;

索引構成表でのパーティション化の使用方法

ワークロードが索引構成表の使用に適している場合は、索引構成表および2次索引でのパーティション化の使用方法を検討する必要があります。パーティション索引構成表の作成方法の詳細は、「パーティションの管理」を参照してください。

関連項目:

索引構成表の詳細は、『Oracle Database管理者ガイド』を参照してください。

索引構成表の2次索引をパーティション化するかどうかは、通常のヒープ表の索引と同じように検討してください。索引構成表をパーティション化できますが、パーティション化キーは主キーのサブセットであることが必要です。索引構成表をパーティション化する一般的な理由は競合の低減です。通常、これはハッシュ・パーティション化を使用して達成されます。

索引構成表をパーティション化するもう1つの理由は、主キー列に基づいて物理的にデータセットを分割できることです。たとえば、アプリケーション・ホスティング企業が、企業IDのリスト・パーティション化により顧客別にアプリケーション・インスタンスを物理的に分割することができます。このようなシナリオの問合せでは、索引のパーティション・プルーニングを利用して、索引スキャンの時間を短縮できます。索引構成表とパーティション化を使用するILMシナリオは、主キーの一部として日付列が必要なため、それほど一般的ではありません。