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