| Oracle® Database VLDBおよびパーティショニング・ガイド 11g リリース2 (11.2) B56316-03 |
|
 前 |
 次 |
パーティション化を行うと、様々なアプリケーションのパフォーマンス、管理性および可用性が向上し、大量のデータを保存するための総所有コストの削減に役立ちます。パーティション化により、表、索引および索引構成表をより細かい単位に細分化できるようになり、これらのデータベース・オブジェクトのよりきめ細かい管理およびアクセスが可能になります。あらゆるビジネス要件に対応するための、パーティション化計画および拡張が豊富に用意されています。完全に透過的であるため、コストが高く時間のかかるアプリケーションの変更を行わずに、パーティション化をほぼすべてのアプリケーションに適用できます。
この章では次の項について説明します。
パーティション化により、表、索引および索引構成表をより細かい単位に細分化できるようになります。このようなデータベース・オブジェクトの単位をパーティションと呼びます。各パーティションには独自の名前があり、独自の記憶特性を持つことができます。
この項の内容は次のとおりです。
データベース管理者の視点からすると、パーティション・オブジェクトには、まとめて管理することも個別に管理することも可能な複数の単位があります。このため、管理者は、パーティション・オブジェクトをかなり柔軟に管理できます。ただし、アプリケーションにとっては、パーティション表はパーティション化されていない表と同じであるため、SQL問合せやDML文を使用してパーティション表にアクセスする際に変更は必要ありません。
図2-1に、パーティション表とパーティション化されていない表の違いを図で示します。
|
注意: パーティション・オブジェクトのすべてのパーティションは、単一ブロック・サイズの表領域に存在する必要があります。 |
|
関連項目: 複数ブロック・サイズの詳細は、『Oracle Database概要』を参照してください。 |
パーティション表の各行は、明示的に単一のパーティションに割り当てられています。パーティション化キーは、各行が格納されるパーティションを決定する1つ以上の列で構成されています。パーティション化キーにより、適切なパーティションに対する挿入、更新および削除操作が自動的に指示されます。
LONGまたはLONG RAWデータ型の列を含む表を除き、任意の表を多数の別々のパーティションにパーティション化できます。ただし、使用できるのはCLOBまたはBLOBデータ型の列を含む表です。
この項の項目は次のとおりです。
|
注意: ディスク使用率およびメモリー使用量(特にバッファ・キャッシュ)を低減するために、表およびパーティション表のパーティションをデータベース内に圧縮形式で保存できます。多くの場合、これにより、読取り専用操作がさらにスケールアップされます。表の圧縮も、問合せ実行の高速化につながります。ただし、CPUオーバーヘッドに多少コストがかかります。 |
|
関連項目: 表の圧縮の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。 |
次に、表のパーティション化のタイミングに関する推奨事項を示します。
2GBを超える表は、常にパーティション化の候補として考慮する必要があります。
新規データが最新のパーティションに追加される、履歴データを含む表。典型的な例は、現在の月のデータのみが更新可能で、残りの11か月分は読取り専用の履歴表です。
表のコンテンツを、種類の異なるストレージ・デバイスに分散する必要がある場合。
パーティション化索引構成表は、索引構成表のパフォーマンス、管理性および可用性を向上させるのに非常に便利です。
索引構成表をパーティション化する場合の注意点は次のとおりです。
パーティション化列は主キー列のサブセットである必要があります。
2次索引もパーティション化できます(ローカルおよびグローバルの両方)。
OVERFLOWデータ・セグメントは、表パーティションと同一レベル・パーティション化されます。
|
関連項目: 索引構成表の詳細は、『Oracle Database概要』を参照してください。 |
システム・パーティション化では、データベースによりデータの配置を制御せずに、アプリケーション制御のパーティション化を実行できます。個々のパーティションの用途を指定せずに表をパーティションに分割する機能が、データベースにより提供されます。パーティション化のすべてをアプリケーションによって制御する必要があります。たとえば、パーティションを明示的に指定せずにシステム・パーティション表に挿入しようとすると失敗します。
システム・パーティション化により、パーティション化の利点(スケーラビリティ、可用性および管理性)がもたらされますが、パーティション化および実際のデータの配置はアプリケーションによって制御されています。
|
関連項目: システム・パーティション化の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。 |
情報ライフサイクル管理(ILM)は、存続期間中のデータ管理に関連しています。パーティション化は、データのグループ(パーティション)を種類の異なるストレージ・デバイスに分散し、個別に管理することを可能にするため、ILMにおいて重要な役割を果します。
情報ライフサイクル管理の詳細は、第5章「情報ライフサイクル管理のためのパーティション化の使用」を参照してください。
LOB列に格納されている非構造化データ(画像や文書など)もパーティション化できます。表がパーティション化されたとき、すべての列はそのパーティションの表領域に含まれますが、LOB列のみは独自の表領域に格納されます。
LOBをメイン・データとは別に格納できるため、表が大規模なLOBで構成されている場合、この機能は非常に便利です。これは、メイン・データは頻繁に更新されるがLOBデータは更新されない場合に役立ちます。たとえば、従業員レコードに、頻繁に変更される可能性が低い写真が含まれている場合などです。ただし、従業員の個人情報(住所、部署、管理者など)は変更される可能性があります。この方法では、LOBデータの保存にはより安価なストレージを使用し、従業員レコードにはより高価で高速なストレージを使用することができます。
XMLTypeおよびオブジェクトの表や列を使用するときにパーティション化すると、パーティション化の一般的な利点が得られます。つまり、表および索引をより細かい単位に分割できるため、これらのデータベース・オブジェクトの管理やアクセスをよりきめ細かいレベルで行えるようになります。
XMLType表、すなわちXMLType列を含む表を、リスト、レンジまたはハッシュ・パーティション化を使用してパーティション化すると、データに含まれるOrdered Collection Table(OCT)もデフォルトで自動的にパーティション化されます。このような同一レベル・パーティション化では、OCTのパーティション化は親(実)表のパーティション化方法に従って行われます。実表の各パーティションに対して、対応するコレクション表パーティションがあります。子要素は、親要素の実表パーティションに対応するコレクション表パーティションに格納されます。
ネストした表を含む表をパーティション化する場合、Oracle Databaseは、ネストした表をパーティション化する方法の基礎として元の実表のパーティション化方法を利用します。このように、ネストした表の各パーティションに実表の1パーティションを対応させるパーティション化は、同一レベル・パーティション化と呼ばれます。デフォルトでは、ネストした表は、実表がパーティション化されるときに自動的にパーティション化されます。ただし、OCTまたはネストした表ではコンポジット・パーティション化はサポートされないので注意してください。
XMLType表のパーティション化の詳細は、 「XMLTypeおよびオブジェクトのコレクションのパーティション化」を参照してください。
|
関連項目:
|
パーティション化によって、パフォーマンス、管理性および可用性が向上し、多様なアプリケーションに大きなメリットがもたらされます。特定の問合せまたはメンテナンス操作のパフォーマンスが大きく向上するのは、パーティション化では珍しいことではありません。また、パーティション化によって、通常の管理タスクを大幅に簡略化できます。
また、パーティション化を使用して、データベースの設計者や管理者が、最先端のアプリケーションによってもたらされる難しい問題を解決することも可能になります。パーティション化は、数TBのシステムまたは非常に高い可用性を必要とするシステムを構築するための主要なツールです。
この項の内容は次のとおりです。
調査または操作対象のデータ量を制限し、パラレル実行を行うためにデータを分散することで、パーティション化によりパフォーマンスに関連する多くの利点がもたらされます。パーティション化の機能を次に示します。
パーティション・プルーニングは非常に簡単で、パーティション化を使用してパフォーマンスを向上するための最も実質的な方法でもあります。パーティション・プルーニングにより、問合せのパフォーマンスが大幅に向上します。たとえば、アプリケーションに注文の履歴レコードを含むOrders表があり、この表が週ごとにパーティション化されているとします。1週間の注文をリクエストする問合せでは、Orders表の単一のパーティションにのみアクセスします。Orders表に2年分の履歴データがある場合、この問合せでは104のパーティションではなく1つのパーティションにのみアクセスします。この問合せは、単純にパーティション・プルーニングの効果で、100倍高速に実行される可能性があります。
パーティション・プルーニングは、Oracle製品のすべてのパフォーマンス機能と連携します。パーティション・プルーニングは、索引や結合の技術またはパラレル・アクセスの手法とともに使用されます。
パーティション化により、表および索引をより細かく管理しやすい単位にパーティション化できるため、データベース管理者は分断攻略法でデータを管理できます。パーティション化を使用すると、表の特定の部分に集中してメンテナンス操作を実行できます。たとえば、表全体ではなく表の単一のパーティションをバックアップできます。データベース・オブジェクト全体にメンテナンス操作を実行する場合には、それらの操作をパーティションごとに実行できるため、メンテナンス・プロセスをさらに管理しやすい単位に分割できます。
管理性を向上させるための一般的なパーティション化の使用方法は、データ・ウェアハウスでローリング・ウィンドウ・ロード・プロセスをサポートすることです。新規データを週単位で表にロードするとします。各パーティションに1週間分のデータが保存されるように、その表をパーティション化できます。ロード・プロセスは、パーティション交換ロードを使用した、単純な新規パーティションの追加です。その他のパーティションを変更する必要がないため、単一のパーティションの追加は、表全体を変更するよりはるかに効率的です。
パーティション化データベース・オブジェクトにより、パーティションの独立性が実現されます。パーティションの独立性のこの特性は、高可用性計画の重要な要素の一部です。たとえば、パーティション表の1つのパーティションが使用できなくなっても、その表のその他すべてのパーティションはオンラインで使用可能なままです。アプリケーションは、その表の使用可能なパーティションに対して問合せやトランザクションを実行し続けることができ、使用できないパーティションにアクセスする必要がなければ、それらのデータベース操作は正常に実行されます。
データベース管理者は、各パーティションを別の表領域に格納するように指定できます。一般的には、これらの表領域は異なるストレージ層に格納されます。様々なパーティションをそれぞれ異なる表領域に格納すると、バックアップ操作やリカバリ操作を各パーティションに対して、表の他のパーティションとは独立して実行できます。このため、データベースのアクティブな部分はすぐに使用できるようになり、非アクティブなデータをリストアしながら、システムへのアクセスは継続できます。また、パーティション化により、スケジュールされる停止時間を短縮できます。パーティション化によってパフォーマンスが向上するため、大規模なデータベース・オブジェクトのメンテナンス操作を比較的短いバッチ期間間で終了できます。
Oracle Partitioningには、個々のパーティションにデータを配置する方法を制御する基本的なパーティション化計画として、3つの基本的なデータ分散方法が用意されています。
レンジ
ハッシュ
リスト
これらのデータ分散方法を使用して、単一のリストまたはコンポジット・パーティション表として表をパーティション化できます。
各パーティション化計画の利点と設計の指針は異なります。そのため、各計画にはそれぞれに適した状況があります。
1つ以上の列をパーティション化キーとして使用し、次のデータ分散方法のいずれかを指定することで表を定義します。
たとえば、NUMBER型の列がパーティション化キーで、less_than_five_hundredおよびless_than_one_thousandという2つのパーティションのある表があるとします。less_than_one_thousandパーティションには、次の条件に一致する行が含まれています。
500 <= partitioning key < 1000
図2-2に、単一レベル・パーティション表の基本的なパーティション化計画を図で示します。
レンジ・パーティション化では、パーティションごとに設定するパーティション化キーの値範囲に基づいて、データがパーティションにマッピングされます。これは、最も一般的なタイプのパーティション化であり、通常は日付とともに使用されます。日付列がパーティション化キーの表では、January-2010パーティションには、パーティション化キーの値が01-Jan-2010から31-Jan-2010までの行が含まれます。
各パーティションには、パーティションの上限を指定するVALUES LESS THAN句(最上限値は含まない)があります。値がこのリテラル以上のパーティション化キーは、次に大きなパーティションに追加されます。最初のパーティションを除くすべてのパーティションには、前のパーティションのVALUES LESS THAN句によって指定された暗黙的な下限があります。
MAXVALUEリテラルは、最大のパーティションに定義できます。MAXVALUEは、NULL値も含み、そのパーティション化キーで可能なその他の値よりも大きい値を選別する仮想無限値を表します。
ハッシュ・パーティション化では、ユーザーが指定するパーティション化キーに適用されるハッシング・アルゴリズムに基づいて、データがパーティションにマッピングされます。ハッシング・アルゴリズムでは、パーティションの行が均等に分散され、パーティションはほぼ同じサイズになります。
ハッシュ・パーティション化は、データをデバイス全体に均等に分散する場合に理想的な方法です。また、ハッシュ・パーティション化は、特に、パーティション化するデータが履歴データではない場合や、パーティション化キーが明示的に設定されていない場合に、レンジ・パーティション化のかわりに簡単に使用できます。
|
注意: パーティション化によって使用されているハッシング・アルゴリズムは変更できません。 |
リスト・パーティション化では、各パーティションの説明にパーティション化キーの離散値のリストを指定することで、行のパーティションへのマッピング方法を明示的に制御できます。リスト・パーティション化の利点は、順序付けおよび関連付けされていない一連のデータを自然にグループ化および編成できることです。パーティション化キーがリージョン列の表の場合、East Sales RegionパーティションにはNew York、VirginiaおよびFloridaという値が含まれます。
DEFAULTパーティションでは、デフォルトのパーティションを使用するため、リスト・パーティション表に可能な値をすべて指定する必要がありません。そのため、その他のパーティションにマッピングされていないすべての行でエラーが発生しません。
コンポジット・パーティション化は、基本的なデータ配分方法を組み合せたものです。1つのデータ配分方法で表をパーティション化し、別のデータ配分方法を使用して、各パーティションをさらに小さなサブパーティションに分割します。1つのパーティションのすべてのサブパーティションは、データの論理的サブセットを表します。
コンポジット・パーティション化では、新規レンジ・パーティションの追加などの履歴操作がサポートされていますが、高レベルで可能なパーティション・プルーニングや、サブパーティションを使用した粒度の細かいデータ配置も提供されています。図2-3に、レンジ - ハッシュおよびレンジ - リスト・コンポジット・パーティション化の図を例として示します。
この項では、次のタイプのパーティション化について説明します。
コンポジット・レンジ - レンジ・パーティション化では、order_dateによるパーティションとshipping_dateによるレンジ・サブパーティションなど、2つのディメンションに従った論理レンジ・パーティション化が可能です。
コンポジット・レンジ - ハッシュ・パーティション化では、レンジ・メソッドを使用してデータがパーティション化され、各パーティションはハッシュを使用してサブパーティション化されます。コンポジット・レンジ - ハッシュ・パーティション化では、レンジ・パーティション化の管理性が向上し、ハッシュ・パーティション化のデータ配置、ストライプ化および並列性も向上します。
コンポジット・レンジ - リスト・パーティション化では、レンジ・メソッドを使用してデータがパーティション化され、各パーティションはリストを使用してサブパーティション化されます。コンポジット・レンジ - リスト・パーティション化では、レンジ・パーティション化の管理や、サブパーティションのリスト・パーティション化の明示的な制御が可能です。
コンポジット・リスト - レンジ・パーティション化では、country_idによるリスト・パーティションおよびorder_dateによるレンジ・サブパーティションなど、特定のリスト・パーティション化計画における論理的なレンジ・サブパーティション化が可能です。
コンポジット・リスト - ハッシュ・パーティション化では、パーティション・ワイズ結合の有効化など、リスト・パーティション・オブジェクトのハッシュ・サブパーティション化が可能です。
基本的なパーティション化計画に加え、Oracle Databaseには次のタイプのパーティション化の拡張が用意されています。
これらの拡張により、パーティション表の管理性が大幅に向上します。
時間隔パーティション化は、表に挿入されたデータが既存のすべてのレンジ・パーティションを超える場合に、指定された間隔のパーティションを自動的に作成するようデータベースに指示するレンジ・パーティション化の拡張機能です。少なくとも1つのレンジ・パーティションを指定してください。レンジ・パーティション化キーの値は、遷移ポイントと呼ばれるレンジ・パーティションの値の上限を決定します。値が遷移ポイントを超えるデータのために、データベースによって時間隔パーティションが作成されます。各時間隔パーティションの下限は、前の範囲つまり時間隔の上限であり、そのパーティションには含まれません。
たとえば、間隔が月単位の時間隔パーティション表を作成し、遷移ポイントを2007年1月に設定した場合、2007年1月の間隔の下限は2007年1月1日です。2007年7月の間隔の下限は、2007年6月のパーティションがすでに作成されているかどうかに関係なく2007年7月1日です。
時間隔パーティション化を使用している場合は、次の制限事項を考慮してください。
指定できるパーティション化キー列は1列のみで、NUMBERまたはDATE型である必要があります。
時間隔パーティション化は、索引構成表ではサポートされていません。
時間隔パーティション表には、ドメイン索引は作成できません。
単一レベルの時間隔パーティション表と次に示すコンポジット・パーティション表を作成できます。
時間隔 - レンジ
時間隔 - ハッシュ
時間隔 - リスト
これらの拡張により、パーティション化キーの定義の柔軟性が高まります。
参照パーティション化では、参照制約により相互に関連する2つの表のパーティション化が可能です。パーティション化キーは、既存の親子関係を介して解決され、有効化されたアクティブな主キーおよび外部キー制約により強制されます。
この拡張の利点は、キー列を複製せずに親表からパーティション化キーを継承することで、親子関係にある複数の表を論理的に同一レベル・パーティション化できることです。論理的な依存性もパーティションのメンテナンス操作に自動的にカスケードされるため、アプリケーション開発が容易になり、ミスも少なくなります。
参照パーティション化の例として、参照制約orderid_refconstraintによって互いに関連するOrders表とLineItems表があります。つまり、LineItems.order_idがOrders.order_idを参照しています。Orders表は、order_dateでレンジ・パーティション化されています。LineItemsのorderid_refconstraintで参照パーティション化を行うと、図2-4および図2-5に示す、Orders表と同一レベルでパーティション化されたパーティション表が作成されることになります。
参照パーティション化では、基本的なパーティション化計画をすべて使用できます。参照パーティション化では、時間隔パーティション化は使用できません。
旧リリースのOracle Databaseでは、表をパーティション化できるのは、表に物理的にパーティション化キーが存在する場合のみでした。仮想列を使用することでその制限がなくなり、表の1つ以上の既存の列を使用し、パーティション化キーを式で定義できるようになりました。式はメタデータとしてのみ保存されています。
Oracle Partitioningでは、仮想列に対してパーティション化計画を定義できるようになりました。たとえば、10桁の口座番号の上3桁に支店情報が含まれる場合があります。仮想列ベースのパーティション化という拡張機能により、ACCOUNT_ID列を含むACCOUNTS表を仮想(導出)列ACCOUNT_BRANCHを使用して拡張できます。ACCOUNT_BRANCHは、ACCOUNT_ID列の上3桁から導出され、この表のパーティション化キーになります。
仮想列ベースのパーティション化は、参照パーティション化、時間隔パーティション化および時間隔 - *コンポジット・パーティション化を含め、基本的なすべてのパーティション化計画でサポートされています。
パーティション表と同じように、パーティション索引の管理性、可用性、パフォーマンスおよびスケーラビリティも向上しました。個別にパーティション化(グローバル索引)することも、表のパーティション化メソッド(ローカル索引)に自動的にリンクすることも可能です。一般的に、OLTPアプリケーションにはグローバル索引を使用し、データ・ウェアハウスまたは意思決定支援(DSS)アプリケーションにはローカル索引を使用します。また、管理が簡単なため、可能な場合にはローカル索引を使用してみてください。
この項の内容は次のとおりです。
使用するパーティション索引の種類を決定する際には、次のガイドラインに順に従ってください。
表パーティション化列が索引キーのサブセットである場合は、ローカル索引を使用します。この場合、作業はこれで終了です。そうでない場合には、ガイドライン2に進みます。
索引が一意でパーティション化キー列が含まれていない場合は、グローバル索引を使用します。この場合、作業はこれで終了です。そうでない場合には、ガイドライン3に進みます。
管理性を重視する場合は、ローカル索引を使用します。この場合、作業はこれで終了です。そうでない場合には、ガイドライン4に進みます。
アプリケーションがOLTPでレスポンス時間を短くする必要がある場合は、グローバル索引を使用します。アプリケーションがDSSでスループットを重視する場合には、ローカル索引を使用します。
パーティション索引および使用するタイプの決定方法の詳細は、第6章「データ・ウェアハウス環境でのパーティション化の使用」および第7章「オンライン・トランザクション処理環境でのパーティション化の使用」を参照してください。
次に示すように、ローカル・パーティション索引は、他の種類のパーティション索引よりも管理が容易です。また、可用性が非常に高く、DSS環境で一般的です。これは同一レベル・パーティション化されているためです。つまり、ローカル索引の各パーティションは、表の1つのパーティションに一対一で関連付けられています。このため、索引パーティションと表パーティションの同期を自動的に維持でき、表と索引の各ペアが独立した状態になります。あるパーティションのデータを無効または使用不可にするアクションが発生しても、影響を受けるのは1つのパーティションだけです。
ローカル・パーティション索引を使用すると、表でパーティションまたはサブパーティションのメンテナンス操作が行われる場合の可用性が高まります。ローカル非同一キー索引と呼ばれるタイプの索引は、履歴データベースに非常に便利です。このタイプの索引では、パーティション化は索引列の左側の接頭辞では行われません。同一キー索引の詳細は、「索引のパーティション化」を参照してください。
ローカル索引には、明示的にパーティションを追加できません。かわりに、基礎となる表にパーティションを追加した場合にのみ、ローカル索引に新しいパーティションを追加できます。同様に、ローカル索引から明示的にパーティションを削除することもできません。かわりに、基礎となる表からパーティションを削除した場合にのみ、ローカル索引パーティションが削除されます。
ローカル索引は一意索引にできます。ただし、ローカル索引を一意にするためには、表のパーティション化キーが索引のキー列の一部である必要があります。
図2-6に、ローカル・パーティション索引を図で示します。
ローカル・パーティション索引の詳細は、「ローカル・パーティション索引」を参照してください。
Oracleでは、グローバル・レンジ・パーティション索引とグローバル・ハッシュ・パーティション索引が提供されます。これらについて次に説明します。
グローバル・レンジ・パーティション索引は、パーティション化の程度とパーティション化キーが表のパーティション化メソッドから独立しているため柔軟です。
グローバル索引の最高位パーティションにはパーティション・バウンドが必要で、値はすべてMAXVALUEです。これにより、基礎となる表のすべての行を索引に含めることができます。グローバル同一キー索引は、一意索引にすることも一意ではない索引にすることもできます。
最高位パーティションにはMAXVALUEというパーティション・バウンドがあるため、グローバル索引にはパーティションを追加できません。新しい最高位パーティションを追加するには、ALTER INDEX SPLIT PARTITION文を使用します。グローバル索引パーティションが空の場合は、ALTER INDEX DROP PARTITION文を発行することでそのパーティションを明示的に削除できます。グローバル索引パーティションにデータが含まれる場合は、パーティションを削除すると次の最高位パーティションが使用不可とマークされる原因になります。グローバル索引では、最高位パーティションを削除できません。
グローバル・ハッシュ・パーティション索引では、索引が増え続けた場合に競合が分散され、パフォーマンスが向上します。つまり、索引の挿入のほとんどが索引の右端でのみ行われます。
デフォルトでは、ヒープ構成表のパーティションに次の操作を行うと、グローバル索引すべてが使用不可とマークされます。
ADD (HASH) COALESCE (HASH) DROP EXCHANGE MERGE MOVE SPLIT TRUNCATE
これらの索引は、操作用のSQL文にUPDATE INDEXES句を追加することでメンテナンスできます。グローバル索引のメンテナンスには、次の2つの便利な点があります。
操作中、索引が使用可能かつオンラインに保たれます。そのため、その他のアプリケーションがこの操作に影響されません。
操作後に索引を再作成する必要がありません。
|
注意: この機能は、ヒープ構成表でのみサポートされています。 |
図2-7に、グローバル・パーティション索引を図で示します。
グローバル・パーティション索引の詳細は、「グローバル・パーティション索引」を参照してください。
パーティション表にビットマップ索引を作成できますが、ビットマップ索引がパーティション表に対してローカルである必要があるという制限があります。グローバル索引にはできません。
グローバル索引は一意索引にすることができます。ローカル索引は、パーティション化キーが索引キーの一部である場合、一意索引にしかできません。
