2 パーティション化の概念
パーティション化を行うと、様々なアプリケーションのパフォーマンス、管理性および可用性が向上し、大量のデータを保存するための総所有コストの削減に役立ちます。
パーティション化により、表、索引および索引構成表をより細かい単位に細分化できるようになり、これらのデータベース・オブジェクトのよりきめ細かい管理およびアクセスが可能になります。あらゆるビジネス要件に対応するための、パーティション化計画および拡張が豊富に用意されています。完全に透過的であるため、コストが高く時間のかかるアプリケーションの変更を行わずに、パーティション化をほぼすべてのアプリケーションに適用できます。
この章の構成は、次のとおりです。
2.1 パーティション化の概要
パーティション化は、オブジェクトをさらに小さな部分に分割する技法を提供します。
パーティション化により、表、索引および索引構成表をより細かい単位に細分化できるようになります。このようなデータベース・オブジェクトの単位をパーティションと呼びます。各パーティションには独自の名前があり、独自の記憶特性を持つことができます。
次の内容について説明します。
2.1.1 パーティション化の基本
パーティション化により、まとめてまたは個別にオブジェクトを管理できます。
データベース管理者の視点からすると、パーティション・オブジェクトには、まとめて管理することも個別に管理することも可能な複数の単位があります。このため、管理者は、パーティション・オブジェクトをかなり柔軟に管理できます。ただし、アプリケーションにとっては、パーティション表はパーティション化されていない表と同じであるため、SQL問合せやDML文を使用してパーティション表にアクセスする際に変更は必要ありません。
図2-1に、パーティション表とパーティション化されていない表の違いを図で示します。
ノート:
パーティション・オブジェクトのすべてのパーティションは、同じブロック・サイズの表領域に存在する必要があります。
関連項目:
-
複数ブロック・サイズの詳細は、『Oracle Database概要』を参照してください。
-
パーティション化の一般的な制限、パーティション表や索引を作成および変更するためのパーティション化句の正確な構文、その使用に関する制限、および表の作成や変更に必要な特定の権限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
2.1.2 パーティション化キー
パーティション表内の各行は、キーを使用して1つのパーティションに明確に割り当てられます。
パーティション化キーは、各行が格納されるパーティションを決定する1つ以上の列で構成されています。パーティション化キーにより、適切なパーティションに対する挿入、更新および削除操作が自動的に指示されます。
2.1.3 パーティション表
ほとんどの表は、パーティション化できます。
LONGまたはLONG RAWデータ型の列を含む表を除き、任意の表を最大100万の別々のパーティションにパーティション化できます。ただし、使用できるのはCLOBまたはBLOBデータ型の列を含む表です。
次の内容について説明します。
ノート:
ディスク使用率およびメモリー使用量(特にバッファ・キャッシュ)を低減するために、表およびパーティション表のパーティションをデータベース内に圧縮形式で保存できます。多くの場合、これにより、読取り専用操作がさらにスケールアップされます。表の圧縮も、問合せ実行の高速化につながります。ただし、CPUオーバーヘッドに多少コストがかかります。
関連項目:
表の管理のガイドラインの詳細は、『Oracle Database管理者ガイド』を参照してください
2.1.3.1 表をパーティション化するタイミング
表をパーティション化する必要がある、特定の状況があります。
次に、表のパーティション化を検討する状況に関する推奨事項を示します。
-
2GBを超える表。
これらの表は、常にパーティション化の候補として考慮する必要があります。
-
新規データが最新のパーティションに追加される、履歴データを含む表。
典型的な例は、現在の月のデータのみが更新可能で、残りの11か月分は読取り専用の履歴表です。
-
コンテンツを種類の異なるストレージ・デバイスに分散する必要がある表。
2.1.4 パーティション化索引構成表
パーティション化索引構成表は、索引構成表のパフォーマンス、管理性および可用性を向上させるのに非常に便利です。
索引構成表をパーティション化する場合の注意点は次のとおりです。
-
パーティション化列は主キー列のサブセットである必要があります。
-
2次索引もパーティション化できます(ローカルおよびグローバルの両方)。
-
OVERFLOWデータ・セグメントは、常に表パーティションと同一レベルでパーティション化されます。
関連項目:
索引構成表の詳細は、『Oracle Database概要』を参照してください。
2.1.5 システム・パーティション化
システム・パーティション化では、データベースによりデータの配置を制御せずに、アプリケーション制御のパーティション化を実行できます。
個々のパーティションの用途を指定せずに表をパーティションに分割する機能が、データベースにより提供されます。パーティション化のすべてをアプリケーションによって制御する必要があります。たとえば、パーティションを明示的に指定せずにシステム・パーティション表に挿入しようとすると失敗します。
システム・パーティション化により、パーティション化の利点(スケーラビリティ、可用性および管理性)がもたらされますが、パーティション化および実際のデータの配置はアプリケーションによって制御されています。
関連項目:
システム・パーティション化の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。
2.1.6 情報ライフサイクル管理のためのパーティション化
情報ライフサイクル管理(ILM)は、存続期間中のデータ管理に関連しています。
パーティション化は、データのグループ(パーティション)を種類の異なるストレージ・デバイスに分散し、個別に管理することを可能にするため、ILMにおいて重要な役割を果します。
関連項目:
情報ライフサイクル管理の詳細は、「時間ベース情報の管理およびメンテナンス」を参照してください
2.1.7 ハッシュ・クラスタのレンジ・パーティション化
パーティション化されたハッシュ・クラスタは、Oracle Databaseでサポートされています。
パーティション化されたハッシュ・クラスタでは、単一レベルのレンジ・パーティション化のみサポートされます。
関連項目:
パーティション化されたハッシュ・クラスタの詳細は、『Oracle Databaseリファレンス』を参照してください。
2.1.8 パーティション化およびLOBデータ
データベース内のLOB列に格納される画像やドキュメントなどの非構造化データもパーティション化できます。
表がパーティション化されたとき、すべての列はそのパーティションの表領域に含まれますが、LOB列のみは独自の表領域に格納されます。
LOBをメイン・データとは別に格納できるため、表が大規模なLOBで構成されている場合、この機能は非常に便利です。これは、メイン・データは頻繁に更新されるがLOBデータは更新されない場合に役立ちます。たとえば、従業員レコードに、頻繁に変更される可能性が低い写真が含まれている場合などです。ただし、従業員の個人情報(住所、部署、管理者など)は変更される可能性があります。この方法では、LOBデータの保存にはより安価なストレージを使用し、従業員レコードにはより高価で高速なストレージを使用することができます。
2.1.9 外部表のパーティション化
パーティション化は、外部表でサポートされています。
この機能では、パーティション化された複数の外部表にわたる問合せのための静的パーティション・プルーニング、動的プルーニングおよびパーティション・ワイズ結合など、最適化が可能です。また、この機能では、より優れたオプティマイザ計画を可能にする、外部表パーティションごとの、パーティションベースの増分統計収集を提供します。
関連項目:
外部表の詳細は、『Oracle Databaseユーティリティ』を参照してください。
2.1.10 XMLTypeデータおよびオブジェクト・データのコレクション
XMLTypeおよびオブジェクトの表や列を使用するときにパーティション化すると、パーティション化の一般的な利点が得られます。つまり、表および索引をより細かい単位に分割できるため、これらのデータベース・オブジェクトの管理やアクセスをよりきめ細かいレベルで行えるようになります。
XMLType表、すなわちXMLType列を含む表を、リスト、レンジまたはハッシュ・パーティション化を使用してパーティション化すると、データに含まれるOrdered Collection Table(OCT)もデフォルトで自動的にパーティション化されます。このような同一レベル・パーティション化では、OCTのパーティション化は親(実)表のパーティション化方法に従って行われます。実表の各パーティションに対して、対応するコレクション表パーティションがあります。子要素は、その親要素の実表パーティションに対応するコレクション表パーティションに格納されます。
ネストした表を含む表をパーティション化する場合、Oracle Databaseは、ネストした表をパーティション化する方法の基礎として元の実表のパーティション化方法を利用します。このように、ネストした表の各パーティションに実表の1パーティションを対応させるパーティション化は、同一レベル・パーティション化と呼ばれます。デフォルトでは、ネストした表は、実表がパーティション化されるときに自動的にパーティション化されます。ただし、OCTまたはネストした表ではコンポジット・パーティション化はサポートされないので注意してください。
関連項目:
-
XMLType表のパーティション化の詳細は、「XMLTypeおよびオブジェクトのコレクションのパーティション化」を参照してください -
ネストした表の構文は、『Oracle Database SQL言語リファレンス』を参照してください
2.2 パーティション化の利点
パーティション化によって、パフォーマンス、管理性および可用性が向上し、多様なアプリケーションに大きなメリットがもたらされます。
特定の問合せまたはメンテナンス操作のパフォーマンスが大きく向上するのは、パーティション化では珍しいことではありません。また、パーティション化によって、通常の管理タスクを大幅に簡略化できます。
また、パーティション化を使用して、データベースの設計者や管理者が、最先端のアプリケーションによってもたらされる難しい問題を解決することも可能になります。パーティション化は、数TBのシステムまたは非常に高い可用性を必要とするシステムを構築するための主要なツールです。
次の内容について説明します。
2.2.1 パフォーマンス改善のためのパーティション化
パーティション化を使用してパフォーマンスを改善できます。
調査または操作対象のデータ量を制限し、パラレル実行を行うためにデータを分散することで、パーティション化によりパフォーマンスに関連する多くの利点がもたらされます。パーティション化の機能を次に示します。
2.2.1.1 パーティション・プルーニング
パーティション・プルーニングは非常に簡単で、パーティション化を使用してパフォーマンスを向上するための最も実質的な方法でもあります。
パーティション・プルーニングにより、問合せのパフォーマンスが大幅に向上します。たとえば、アプリケーションに注文の履歴レコードを含むOrders表があり、この表が週ごとにパーティション化されているとします。1週間の注文をリクエストする問合せでは、Orders表の単一のパーティションにのみアクセスします。Orders表に2年分の履歴データがある場合、この問合せでは104のパーティションではなく1つのパーティションにのみアクセスします。この問合せは、単純にパーティション・プルーニングの効果で、100倍高速に実行される可能性があります。
パーティション・プルーニングは、Oracle製品のすべてのパフォーマンス機能と連携します。パーティション・プルーニングは、索引や結合の技術またはパラレル・アクセスの手法とともに使用されます。
2.2.2 管理性のためのパーティション化
パーティション化により、表および索引をより細かく管理しやすい単位にパーティション化できるため、データベース管理者は分断攻略法でデータを管理できます。
パーティション化を使用すると、表の特定の部分に集中してメンテナンス操作を実行できます。たとえば、表全体ではなく表の単一のパーティションをバックアップできます。データベース・オブジェクト全体にメンテナンス操作を実行する場合には、それらの操作をパーティションごとに実行できるため、メンテナンス・プロセスをさらに管理しやすい単位に分割できます。
管理性を向上させるための一般的なパーティション化の使用方法は、データ・ウェアハウスでローリング・ウィンドウ・ロード・プロセスをサポートすることです。新規データを週単位で表にロードするとします。各パーティションに1週間分のデータが保存されるように、その表をパーティション化できます。ロード・プロセスは、パーティション交換ロードを使用した、単純な新規パーティションの追加です。その他のパーティションを変更する必要がないため、単一のパーティションの追加は、表全体を変更するよりはるかに効率的です。
2.2.3 可用性のためのパーティション化
パーティション化データベース・オブジェクトにより、パーティションの独立性が実現されます。パーティションの独立性のこの特性は、高可用性計画の重要な要素の一部です。
たとえば、パーティション表の1つのパーティションが使用できなくなっても、その表のその他すべてのパーティションはオンラインで使用可能なままです。アプリケーションは、その表の使用可能なパーティションに対して問合せやトランザクションを実行し続けることができ、使用できないパーティションにアクセスする必要がなければ、それらのデータベース操作は正常に実行されます。
データベース管理者は、各パーティションを別の表領域に格納するように指定できます。一般的には、これらの表領域は異なるストレージ層に格納されます。様々なパーティションをそれぞれ異なる表領域に格納すると、バックアップ操作やリカバリ操作を各パーティションに対して、表の他のパーティションとは独立して実行できます。このため、データベースのアクティブな部分はすぐに使用できるようになり、非アクティブなデータをリストアしながら、システムへのアクセスは継続できます。また、パーティション化により、スケジュールされる停止時間を短縮できます。パーティション化によってパフォーマンスが向上するため、大規模なデータベース・オブジェクトのメンテナンス操作を比較的短いバッチ期間で終了できます。
2.3 パーティション化計画
Oracle Partitioningには、個々のパーティションにデータを配置する方法を制御する基本的なパーティション化計画として、3つの基本的なデータ配分方法が用意されています。
これらの計画を次に示します。
-
レンジ
-
ハッシュ
-
リスト
これらのデータ分散方法を使用して、単一レベルまたはコンポジット・パーティション表として表をパーティション化できます。
各パーティション化計画の利点と設計の指針は異なります。そのため、各計画にはそれぞれに適した状況があります。
2.3.1 単一レベル・パーティション化
単一レベル・パーティション化には、レンジ、ハッシュおよびリスト・パーティション化があります。
1つ以上の列をパーティション化キーとして使用し、次のデータ分散方法のいずれかを指定することで表を定義します。
たとえば、NUMBER型の列がパーティション化キーで、less_than_five_hundredおよびless_than_one_thousandという2つのパーティションのある表があるとします。less_than_one_thousandパーティションには、次の条件に一致する行が含まれています。
500 <= partitioning key < 1000
図2-2に、単一レベル・パーティション表の基本的なパーティション化計画を図で示します。
2.3.1.1 レンジ・パーティション化
レンジ・パーティション化では、パーティションごとに設定するパーティション化キーの値範囲に基づいて、データがパーティションにマッピングされます。
レンジ・パーティション化は、最も一般的なタイプのパーティション化であり、通常は日付とともに使用されます。日付列がパーティション化キーの表では、January-2017パーティションには、パーティション化キーの値が01-Jan-2017から31-Jan-2017までの行が含まれます。
各パーティションには、パーティションの上限を指定するVALUES LESS THAN句(最上限値は含まない)があります。値がこのリテラル以上のパーティション化キーは、次に大きなパーティションに追加されます。最初のパーティションを除くすべてのパーティションには、前のパーティションのVALUES LESS THAN句によって指定された暗黙的な下限があります。
MAXVALUEリテラルは、最大のパーティションに定義できます。MAXVALUEは、NULL値も含み、そのパーティション化キーで可能なその他の値よりも大きい値を選別する仮想無限値を表します。
2.3.1.2 ハッシュ・パーティション化
ハッシュ・パーティション化では、ユーザーが指定するパーティション化キーに適用されるハッシング・アルゴリズムに基づいて、データがパーティションにマッピングされます。
ハッシング・アルゴリズムでは、パーティションの行が均等に分散され、パーティションはほぼ同じサイズになります。
ハッシュ・パーティション化は、データをデバイス全体に均等に分散する場合に理想的な方法です。また、ハッシュ・パーティション化は、特に、パーティション化するデータが履歴データではない場合や、パーティション化キーが明示的に設定されていない場合に、レンジ・パーティション化のかわりに簡単に使用できます。
ノート:
パーティション化によって使用されているハッシング・アルゴリズムは変更できません。
2.3.1.3 リスト・パーティション化
リスト・パーティション化では、各パーティションの説明にパーティション化キーの離散値のリストを指定することで、行のパーティションへのマッピング方法を明示的に制御できます。
リスト・パーティション化の利点は、順序付けおよび関連付けされていない一連のデータを自然にグループ化および編成できることです。パーティション化キーがリージョン列の表の場合、East Sales RegionパーティションにはNew York、VirginiaおよびFloridaという値が含まれます。
DEFAULTパーティションでは、デフォルトのパーティションを使用するため、リスト・パーティション表に可能な値をすべて指定する必要がありません。そのため、その他のパーティションにマッピングされていないすべての行でエラーが発生しません。
2.3.2 コンポジット・パーティション化
コンポジット・パーティション化は、基本的なデータ配分方法の組合せです。
コンポジット・パーティション化では、1つのデータ配分方法で表をパーティション化し、別のデータ配分方法を使用して、各パーティションをさらに小さなサブパーティションに分割します。1つのパーティションのすべてのサブパーティションは、データの論理的サブセットを表します。
コンポジット・パーティション化では、新規レンジ・パーティションの追加などの履歴操作がサポートされていますが、高レベルで可能なパーティション・プルーニングや、サブパーティションを使用した粒度の細かいデータ配置も提供されています。図2-3に、レンジ - ハッシュおよびレンジ - リスト・コンポジット・パーティション化の図を例として示します。
コンポジット・パーティション化のタイプは次のとおりです。
2.3.2.1 コンポジット・レンジ - レンジ・パーティション化
コンポジット・レンジ - レンジ・パーティション化では、2つのディメンションに従って論理レンジ・パーティション化できます。
コンポジット・レンジ - レンジ・パーティション化の例は、order_dateによるパーティションおよびshipping_dateによるレンジ・サブパーティションです。
2.3.2.2 コンポジット・レンジ - ハッシュ・パーティション化
コンポジット・レンジ - ハッシュ・パーティション化では、レンジ・メソッドを使用してデータがパーティション化され、各パーティションはハッシュを使用してサブパーティション化されます。
コンポジット・レンジ - ハッシュ・パーティション化では、レンジ・パーティション化の管理性が向上し、ハッシュ・パーティション化のデータ配置、ストライプ化および並列性も向上します。
2.3.2.3 コンポジット・レンジ - リスト・パーティション化
コンポジット・レンジ - リスト・パーティション化では、レンジ・メソッドを使用してデータがパーティション化され、各パーティションはリストを使用してサブパーティション化されます。
コンポジット・レンジ - リスト・パーティション化では、レンジ・パーティション化の管理や、サブパーティションのリスト・パーティション化の明示的な制御が可能です。
2.3.2.4 コンポジット・リスト - レンジ・パーティション化
コンポジット・リスト - レンジ・パーティション化では、指定されたリスト・パーティション化計画内で論理レンジ・サブパーティション化できます。
コンポジット・リスト - レンジ・パーティション化の例は、country_idによるリスト・パーティションおよびorder_dateによるレンジ・サブパーティションです。
2.3.2.5 コンポジット・リスト - ハッシュ・パーティション化
コンポジット・リスト - ハッシュ・パーティション化では、リスト・パーティション化されたオブジェクトのハッシュ・サブパーティション化が可能です。
コンポジット・リスト - ハッシュ・パーティション化は、パーティション・ワイズ結合を可能にするために役立ちます。
2.3.2.6 コンポジット・リスト - リスト・パーティション化
コンポジット・リスト - リスト・パーティション化では、2つのディメンションに従って論理リスト・パーティション化できます。
コンポジット・リスト - リスト・パーティション化の例は、country_idによるリスト・パーティションおよびsales_channelによるリスト・サブパーティションです。
2.3.2.7 コンポジット・ハッシュ - ハッシュ・パーティション化
コンポジット・ハッシュ - ハッシュ・パーティション化は、2つのディメンションにハッシュ・パーティション化が可能です。
コンポジット・ハッシュ - ハッシュ・パーティション化技法は、2つのディメンションに従ったパーティション・ワイズ結合を可能にするために役立ちます。
2.3.2.8 コンポジット・ハッシュ - リスト・パーティション化
このトピックでは、コンポジット・ハッシュ - リスト・パーティション化を紹介します。
コンポジット・ハッシュ - リスト・パーティション化は、2つのディメンションにハッシュ・パーティション化が可能です。
2.4 パーティション化の拡張
基本的なパーティション化計画に加え、Oracle Databaseにはパーティション化の拡張が用意されています。
Oracle Databaseには、次のタイプのパーティション化拡張が用意されています。
2.4.1 管理性の拡張
2.4.1.1 時間隔パーティション化
時間隔パーティション化は、レンジ・パーティション化の拡張機能です。
時間隔パーティション化は、表に挿入されたデータが既存のすべてのレンジ・パーティションを超える場合に、指定された間隔のパーティションを自動的に作成するようデータベースに指示します。少なくとも1つのレンジ・パーティションを指定してください。レンジ・パーティション化キーの値は、遷移ポイントと呼ばれるレンジ・パーティションの値の上限を決定します。値が遷移ポイントを超えるデータのために、データベースによって時間隔パーティションが作成されます。各時間隔パーティションの下限は、前の範囲つまり時間隔の上限であり、そのパーティションには含まれません。
たとえば、間隔が月単位の時間隔パーティション表を作成し、遷移ポイントを2007年1月に設定した場合、2007年1月の間隔の下限は2007年1月1日です。2007年7月の間隔の下限は、2007年6月のパーティションがすでに作成されているかどうかに関係なく2007年7月1日です。
単一レベルの時間隔パーティション表と次に示すコンポジット・パーティション表を作成できます。
-
時間隔 - レンジ
-
時間隔 - ハッシュ
-
時間隔 - リスト
時間隔パーティション化では、レンジ・パーティション化の機能のサブセットがサポートされます。
関連項目:
時間隔パーティション化を使用する際の制限事項の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
2.4.2 パーティション化キーの拡張
2.4.2.1 参照パーティション化
参照パーティション化では、参照制約により相互に関連する2つの表のパーティション化が可能です。
パーティション化キーは、既存の親子関係を介して解決され、有効化されたアクティブな主キーおよび外部キー制約により強制されます。
この拡張の利点は、キー列を複製せずに親表からパーティション化キーを継承することで、親子関係にある複数の表を論理的に同一レベル・パーティション化できることです。論理的な依存性もパーティションのメンテナンス操作に自動的にカスケードされるため、アプリケーション開発が容易になり、ミスも少なくなります。
参照パーティション化の例として、参照制約orderid_refconstraintによって互いに関連するOrders表とLineItems表があります。つまり、LineItems.order_idがOrders.order_idを参照しています。Orders表は、order_dateでレンジ・パーティション化されています。LineItemsのorderid_refconstraintで参照パーティション化を行うと、図2-4および図2-5に示す、Orders表と同一レベルでパーティション化されたパーティション表が作成されることになります。
参照パーティション化では、基本的なパーティション化計画をすべて使用できます。参照パーティション化では、時間隔パーティション化も使用できます。
ノート:
参照パーティション化は、オンライン再定義パッケージ(DBMS_REDEFINITION)ではサポートされません。
2.4.2.2 仮想列ベースのパーティション化
Oracleのパーティション化には、仮想列で定義されたパーティション化計画が含まれます。
仮想列を使用することで、表の1つ以上の既存の列を使用し、パーティション化キーを式で定義できるようになりました。式はメタデータとしてのみ保存されています。たとえば、10桁の口座番号の上3桁に支店情報が含まれる場合があります。仮想列ベースのパーティション化という拡張機能により、ACCOUNT_ID列を含むACCOUNTS表を仮想(導出)列ACCOUNT_BRANCHを使用して拡張できます。ACCOUNT_BRANCHは、ACCOUNT_ID列の上3桁から導出され、この表のパーティション化キーになります。
仮想列ベースのパーティション化は、参照パーティション化、時間隔パーティション化および時間隔 - *コンポジット・パーティション化を含め、基本的なすべてのパーティション化計画でサポートされています。
2.5 パーティション表の索引
パーティション表の索引を非パーティション化またはパーティション化できます。
パーティション表と同じように、パーティション索引の管理性、可用性、パフォーマンスおよびスケーラビリティも向上しました。個別にパーティション化(グローバル索引)することも、表のパーティション化メソッド(ローカル索引)に自動的にリンクすることも可能です。一般的に、OLTPアプリケーションにはグローバル索引を使用し、データ・ウェアハウスまたは意思決定支援(DSS)アプリケーションにはローカル索引を使用します。
次の内容について説明します。
2.5.1 使用するパーティション索引の種類の決定
使用するパーティション索引のタイプは、様々な要因を確認した後に選択する必要があります。
使用するパーティション索引の種類を決定する際には、次のガイドラインに順に従ってください。
-
表パーティション化列が索引キーのサブセットである場合は、ローカル索引を使用します。この場合、作業はこれで終了です。そうでない場合には、ガイドライン2に進みます。
-
索引が一意でパーティション化キー列が含まれていない場合は、グローバル索引を使用します。この場合、作業はこれで終了です。そうでない場合には、ガイドライン3に進みます。
-
管理性を重視する場合は、ローカル索引を考慮します。この場合、作業はこれで終了です。そうでない場合には、ガイドライン4に進みます。
-
アプリケーションがOLTPでレスポンス時間を短くする必要がある場合は、グローバル索引を使用します。アプリケーションがDSSでスループットを重視する場合には、ローカル索引を使用します。
関連項目:
-
パーティション索引、およびデータ・ウェアハウス環境で使用するタイプの決定方法の詳細は、「データ・ウェアハウス環境でのパーティション化の使用」を参照してください
-
パーティション索引、およびオンライン・トランザクション処理環境で使用するタイプの決定方法の詳細は、「オンライン・トランザクション処理環境でのパーティション化の使用」を参照してください
2.5.2 ローカル・パーティション索引
次に示すように、ローカル・パーティション索引は、他の種類のパーティション索引よりも管理が容易です。
また、可用性が非常に高く、DSS環境で一般的です。これは同一レベル・パーティション化されているためです。つまり、ローカル索引の各パーティションは、表の1つのパーティションに一対一で関連付けられています。このため、索引パーティションと表パーティションの同期を自動的に維持でき、表と索引の各ペアが独立した状態になります。あるパーティションのデータを無効または使用不可にするアクションが発生しても、影響を受けるのは1つのパーティションだけです。
ローカル・パーティション索引を使用すると、表でパーティションまたはサブパーティションのメンテナンス操作が行われる場合の可用性が高まります。ローカル非同一キー索引と呼ばれるタイプの索引は、履歴データベースに非常に便利です。このタイプの索引では、パーティション化は索引列の左側の接頭辞では行われません。
パーティションは、明示的にローカル索引に追加することはできません。基礎となる表にパーティションを追加した場合のみ、新しいパーティションがローカル索引に追加されます。同様に、パーティションを明示的にローカル索引から削除することもできません。かわりに、基礎となる表からパーティションを削除した場合にのみ、ローカル索引パーティションが削除されます。
ローカル索引は一意索引にできます。ただし、ローカル索引を一意にするためには、表のパーティション化キーが索引のキー列の一部である必要があります。
図2-6に、ローカル・パーティション索引を図で示します。
関連項目:
-
同一キー索引の詳細は、「索引のパーティション化」を参照してください
-
ローカル・パーティション索引の詳細は、「ローカル・パーティション索引」を参照してください
2.5.3 グローバル・パーティション索引
このトピックでは、グローバル・パーティション索引について説明します。
Oracleでは、グローバル・レンジ・パーティション索引とグローバル・ハッシュ・パーティション索引が提供されます。これらについて次に説明します。
2.5.3.1 グローバル・レンジ・パーティション索引
グローバル・レンジ・パーティション索引は、パーティション化の程度とパーティション化キーが表のパーティション化メソッドから独立しているため柔軟です。
グローバル索引の最高位パーティションにはパーティション・バウンドが必要で、値はすべてMAXVALUEです。これにより、基礎となる表のすべての行を索引に含めることができます。グローバル同一キー索引は、一意索引にすることも一意ではない索引にすることもできます。
最高位パーティションにはMAXVALUEというパーティション・バウンドがあるため、グローバル索引にはパーティションを追加できません。新しい最高位パーティションを追加するには、ALTER INDEX SPLIT PARTITION文を使用します。グローバル索引パーティションが空の場合は、ALTER INDEX DROP PARTITION文を発行することでそのパーティションを明示的に削除できます。グローバル索引パーティションにデータが含まれる場合は、パーティションを削除すると次の最高位パーティションが使用不可とマークされる原因になります。グローバル索引では、最高位パーティションを削除できません。
2.5.3.2 グローバル・ハッシュ・パーティション索引
グローバル・ハッシュ・パーティション索引では、索引が増え続けた場合に競合が分散され、パフォーマンスが向上します。
つまり、ほとんどの索引の挿入は、グローバル・ハッシュ・パーティション索引のNハッシュ・パーティションで均一に分散される索引の右端でのみ発生します。
2.5.3.3 グローバル・パーティション索引のメンテナンス
このトピックでは、グローバル・パーティション索引のメンテナンスについて説明します。
デフォルトでは、ヒープ構成表のパーティションに次の操作を行うと、グローバル索引すべてが使用不可とマークされます。
ADD (HASH) COALESCE (HASH) DROP EXCHANGE MERGE MOVE SPLIT TRUNCATE
これらの索引は、操作用のSQL文にUPDATE INDEXES句を追加することでメンテナンスできます。ただし、UPDATE INDEXES句を追加すると、パーティション・メンテナンス操作の一部としてグローバル索引がメンテナンスされ、操作の実行時間が延長されてリソース要件が増える可能性があるので注意してください。
グローバル索引のメンテナンスには、次の2つの利点があります。
-
操作中、索引が使用可能かつオンラインに保たれます。そのため、その他のアプリケーションがこの操作に影響されません。
-
操作後に索引を再作成する必要がありません。
-
DROPおよびTRUNCATEのグローバル索引メンテナンスは、メタデータのみの操作として実装されます。
ノート:
この機能は、ヒープ構成表でのみサポートされています。
図2-7に、グローバル・パーティション索引を図で示します。
関連項目:
グローバル・パーティション索引の詳細は、「グローバル・パーティション索引」を参照してください
2.5.5 パーティション表に索引を作成する場合のその他の情報
いくつかの制約がありますが、パーティション表でビットマップ索引を作成できます。
ビットマップ索引は、そのパーティション表に対してしか使用できなくする必要があります。グローバル索引にはできません。
グローバル索引は一意索引にすることができます。ローカル索引は、パーティション化キーが索引キーの一部である場合、一意索引にしかできません。
2.5.6 パーティション表の部分索引
表のパーティションのサブセットにローカルおよびグローバル索引を作成して、索引の作成の柔軟性を高めることができます。
この機能は、デフォルトの表索引付けプロパティを使用してサポートされます。表が作成または変更される場合、デフォルト索引付けプロパティを表またはそのパーティションに指定できます。表索引付けプロパティは、部分索引にのみ考慮されます。
索引が表にPARTIALとして作成される場合:
-
ローカル索引: 索引付けが表パーティションに有効な場合に使用でき、無効な場合に使用できない索引パーティションが作成されます。索引または索引パーティション・レベルで
USABLE/UNUSABLEを指定して、この動作を上書きできます。 -
グローバル索引: 索引付けが有効なパーティションのみを含み、その他は除外します。
この機能は、一意の索引または一意の制約の施行に使用される索引にサポートされません。FULLおよびPARTIALの両方が指定されない場合、FULLがデフォルトです。
デフォルトでは、索引がFULL索引として作成され、表索引付けプロパティから索引を分離します。
INDEXING句は、パーティションおよびサブパーティション・レベルで指定することもできます。
次のSQL DDLは、次の項目で表を作成します。
-
パーティション
ORD_P1およびORD_P3がすべての部分グローバル索引に含まれます -
上の2つの表パーティションに対応するローカル索引パーティション(
PARTIALで作成された索引用)が作成され、デフォルトで使用できます。 -
他のパーティションはすべての部分グローバル索引から除外され、ローカル索引で使用不可で作成されます(
PARTIALで作成された索引用)。
CREATE TABLE orders (
order_id NUMBER(12),
order_date DATE CONSTRAINT order_date_nn NOT NULL,
order_mode VARCHAR2(8),
customer_id NUMBER(6) CONSTRAINT order_customer_id_nn NOT NULL,
order_status NUMBER(2),
order_total NUMBER(8,2),
sales_rep_id NUMBER(6),
promotion_id NUMBER(6),
CONSTRAINT order_mode_lov CHECK (order_mode in ('direct','online')),
CONSTRAINT order_total_min CHECK (order_total >= 0))
INDEXING OFF
PARTITION BY RANGE (ORDER_DATE)
(PARTITION ord_p1 VALUES LESS THAN (TO_DATE('01-MAR-1999','DD-MON-YYYY'))
INDEXING ON,
PARTITION ord_p2 VALUES LESS THAN (TO_DATE('01-JUL-1999','DD-MON-YYYY'))
INDEXING OFF,
PARTITION ord_p3 VALUES LESS THAN (TO_DATE('01-OCT-1999','DD-MON-YYYY'))
INDEXING ON,
PARTITION ord_p4 VALUES LESS THAN (TO_DATE('01-MAR-2000','DD-MON-YYYY')),
PARTITION ord_p5 VALUES LESS THAN (TO_DATE('01-MAR-2010','DD-MON-YYYY')));
INDEXING PARTIAL句を指定する前のSQL例の表索引付けプロパティに従って、ローカルまたはグローバル部分索引を作成できます。
CREATE INDEX ORDERS_ORDER_TOTAL_GIDX ON ORDERS (ORDER_TOTAL) GLOBAL INDEXING PARTIAL;
ORDERS_ORDER_TOTAL_GIDX索引が作成され、INDEXING ONを指定したパーティションのみ索引付けされ、残りのパーティションは除外されます。
ビューの更新には、次の内容が含まれます。
-
表索引付けプロパティ - 列
INDEXINGが*_PART_TABLES、*_TAB_PARTITIONSおよび*_TAB_SUBPARTITIONSビューに追加されます。この列は、索引付けの有効または無効を指定する2つの値
ONおよびOFFのいずれかを含みます。 -
索引レベル・プロパティとしての部分グローバル索引 - 新しい列
INDEXINGがUSER_INDEXESビューに追加されます。この列をFULLまたはPARTIALに設定できます。 -
部分グローバル索引の最適化 - グローバル索引(パーティション)が
DROP/TRUNCATEPARTITIONまたはMODIFYPARTITIONINDEXINGOFFの実行中に遅延した索引メンテナンスのために古いエントリを含む場合、列ORPHANED_ENTRIESがディクショナリ・ビューUSER_INDEXESおよびUSER_IND_PARTITIONSに追加されて表示されます。列には、次のいずれかの値を含むことができます。-
YES=> 索引(パーティション)は親がないエントリを含みます -
NO=> 索引(パーティション)は親がないエントリを含みません
-
関連項目:
データベース・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください