| Oracle® Database VLDBおよびパーティショニング・ガイド 11g リリース2 (11.2) B56316-03 |
|
 前 |
 次 |
パーティション化は、最初はデータ・ウェアハウスのパフォーマンス要件に対応するために開発されました。オンライン・トランザクション処理(OLTP)システムの急速な発展とユーザー数の増大のため、パーティション化はOLTPシステムできわめて有効です。
多くの場合、OLTPシステムでは、競合を減らして大多数のユーザーをサポートするために、パーティション化が使用されます。また、コスト効率のよい方法での大容量データの格納など、OLTPシステムが直面する規制要件の対処にも役立ちます。
この章では次の項について説明します。
OLTPシステムは、現在の企業でよく使用されているデータ処理システムです。典型的なOLTPシステムの例としては、受注、小売および金融取引のシステムがあります。
OLTPシステムの最大の特徴は、データ・ウェアハウス環境とは異なる独特のデータ使用方法にあります。ただし、大容量データの保持やライフサイクルに応じたデータの使用状況と重要性といった特徴は同じです。
OLTP環境の主な特性は次のとおりです。
短いレスポンス時間
OLTP環境では、電話勧誘販売での調査結果の入力など、様々な種類の対話的で臨機応変の使用方法が大半を占めます。OLTPシステムでは、ユーザーの生産性を保つためにレスポンス時間を短くする必要があります。
小さなトランザクション
通常、OLTPシステムは、限定された少量のデータを読み取って処理します。データ処理の大部分は単純で、複雑な結合は比較的まれです。問合せとDMLのワークロードが常に混在しています。たとえば、コール・センターでは多数の従業員のうちの一人が、通話ごとに顧客詳細を取得し、顧客の苦情を入力しながら、その顧客の過去の通信記録を確認します。
データ・メンテナンス操作
定期的または臨時に実行する必要があるレポート・プログラムやデータ更新プログラムがあることは珍しくありません。このようなプログラムは、ユーザーが他のタスクを行っているときにバックグラウンドで実行されますが、多数のデータ集約型処理を伴うことがあります。たとえば、大学では学生を講義に振り分けるバッチ・ジョブを起動する一方で、学生が自らオンラインで講義の申込みを行うことができます。
多数のユーザー
OLTPシステムのユーザーは非常に多数に及び、そのうち多くのユーザーが同じデータに同時にアクセスしようとします。たとえば、オンライン・オークションのWebサイトでは、数十万人(数百万人ではないにしても)ものユーザーが同時にWebサイトのデータにアクセスする可能性があります。
高い同時実行性
ユーザー数が多く、レスポンス時間が短く、トランザクションが小さいため、OLTP環境の同時実行性は非常に高くなります。数千単位の同時ユーザー数の要件も珍しくありません。
大容量データ
アプリケーションのタイプ、ユーザー数およびデータ保存期間によって変わりますが、OLTPシステムは非常に大規模になることがあります。たとえば、ある銀行ではすべての顧客が、過去12か月のすべての取引を示すオンライン・バンキング・システムにアクセスできます。
高い可用性
OLTPシステムの可用性要件は、しばしば非常に高くなります。OLTPシステムが使用できない場合、非常に多くのユーザーが影響を受け、組織は大きな損失を被ることがあるためです。たとえば、株式取引システムは取引時間においてきわめて高い可用性の要件があります。
ライフサイクルに関連するデータ使用状況
データ・ウェアハウス環境と同じく、OLTPシステムでも、時間の経過に伴ってデータ・アクセス・パターンが変化します。たとえば、月末にはすべての活動口座の月利が計算されます。
OLTP環境をパーティション化する利点を次に示します。
大きなデータベースのサポート
高可用性戦略の一環として、大きなサイズのデータベースを効率よく管理するために、バックアップおよびリカバリを小さな単位で実行できます。通常、OLTPシステムはバックアップ中もオンラインのままであり、バックアップの実行中もユーザーは引き続きシステムにアクセスできます。バックアップ・プロセスによって、オンライン・ユーザーがパフォーマンスの大幅な劣化を被ることはありません。
パーティション化では、データベース・オブジェクトを部分的に圧縮して格納できるため、OLTPシステムの領域要件を抑えることにつながります。圧縮していない行の更新トランザクションは、圧縮データの更新よりも効率よく処理されます。
パーティション化により、データを様々なストレージ層で透過的に保持することができ、大容量データを格納するコストを節減できます。
データ・メンテナンスのためのパーティション・メンテナンス操作(DMLのかわりに使用)
データ・メンテナンス操作(多くの場合はパージ)の場合、Oracle Databaseのオンライン索引メンテナンス機能と組み合せてパーティション・メンテナンス操作を活用できます。パーティション管理操作では、同内容のDML操作に比べて生成されるREDOが少なくなります。
ホット・スポットの消去によって高い同時実行性を得る可能性
OLTP環境の一般的なシナリオでは、主キー制約を施行するために使用される索引値は単調に増加します。このため、同時実行性や潜在的な競合率が高い領域が生成されます。新たに挿入を実行するたびに、同じセットの索引ブロックの更新が試行されるためです。パーティション索引、特にハッシュ・パーティション索引を使用すると、このような状況が緩和されます。
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表のorder_id列での一意索引の作成を示します。このOLTPアプリケーションのorder_idには連番が入力されます。この一意索引では、ハッシュ・パーティション化を使用して、単調に増加するorder_id値への競合を減らします。また、この一意キーが主キー制約を作成するために使用されます。
例7-1 一意索引および主キー制約の作成
CREATE UNIQUE INDEX orders_pk ON orders(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 ADD CONSTRAINT orders_pk PRIMARY KEY (order_id) USING INDEX;
一意性の施行は、OLTP環境のための重要なデータベース機能です。一意性は、非パーティション索引でもパーティション索引でも施行できます。ただし、パーティション索引にはパーティションの自律性があるため、一意索引を実装するために次の要件を満たす必要があります。
非パーティション索引は、任意の列、または列の組合せに対して一意性を施行できます。非パーティション索引の動作は、非パーティション表についてもパーティション表についても同じです。
パーティション索引の各パーティションは、自律型セグメントとみなされます。これらのセグメントの自律性を施行するには、一意キー定義のサブセットとしてパーティション化キー列を必ず含める必要があります。
一意グローバル・パーティション索引のプリフィックスは、常にパーティション化列であることが必要です。
一意ローカル索引の一意キー定義のサブセットは、表のパーティション化キーであることが必要です。
ワークロードが索引構成表の使用に適している場合は、索引構成表および2次索引でのパーティション化の使用方法を検討する必要があります。パーティション索引構成表の作成方法の詳細は、第4章「パーティションの管理」を参照してください。
|
関連項目: 索引構成表の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
索引構成表の2次索引をパーティション化するかどうかは、通常のヒープ表の索引と同じように検討してください。索引構成表をパーティション化できますが、パーティション化キーは主キーのサブセットであることが必要です。索引構成表をパーティション化する一般的な理由は競合の低減です。通常、これはハッシュ・パーティション化を使用して達成されます。
索引構成表をパーティション化するもう1つの理由は、主キー列に基づいて物理的にデータセットを分割できることです。たとえば、アプリケーション・ホスティング企業が、企業IDのリスト・パーティション化により顧客別にアプリケーション・インスタンスを物理的に分割することができます。このようなシナリオの問合せでは、索引のパーティション・プルーニングを利用して、索引スキャンの時間を短縮できます。索引構成表とパーティション化を使用するILMシナリオは、主キーの一部として日付列が必要なため、それほど一般的ではありません。
パーティション化では、パフォーマンスの利点に加え、OLTP環境のラージ・オブジェクトに関して最適なデータ管理が実現できます。Oracle Databaseでのすべてのパーティション・メンテナンス操作は、アトミック性に対応してグローバル索引やローカル索引のメンテナンスを含むように拡張できます。OLTP環境の24時間体制の可用性に影響を与えずに、あらゆるパーティション・メンテナンス操作の実行が可能です。
OLTPシステムのパーティション・メンテナンス操作は、ILMシナリオではよく行われます。このようなシナリオでは、レンジ・パーティション表または時間隔パーティション表、あるいはレンジまたは時間隔と他の方法を組み合せたコンポジット・パーティション表が一般的です。
パーティション・メンテナンス操作を含む事例としては、アプリケーション・データの分割に関連するシナリオがあります。たとえば、ある小売企業が1つのスキーマ内の複数の支店について同じアプリケーションを実行します。支店の収益によって異なりますが、アプリケーション(別のパーティションとして)は効率のよい記憶域に格納されます。リスト・パーティション化またはリストとその他の方法を組み合せたコンポジット・パーティション化は、このような事例のパーティション化戦略として一般的です。
表のハッシュ・(サブ)パーティション化をOLTPシステムで使用すると、データ・ウェアハウス環境で達成できるのと同様のパフォーマンスの向上が得られます。日常的なOLTPワークロードの大半は、シリアルで実行される比較的小さな操作です。ただし、定期的なバッチ操作はパラレルで実行されることがあり、ハッシュ・パーティション化とサブパーティション化がパーティション・ワイズ結合にもたらす優れた分散のメリットを得られます。たとえば、月末の金利計算は、毎晩のバッチ期間内に完了するようにパラレルで実行する必要があります。
この項の内容は次のとおりです。
パーティション化によるパフォーマンスの利点の詳細は、第3章「可用性、管理性およびパフォーマンスのためのパーティション化」を参照してください。
パーティション・メンテナンス操作が行われるときは常に、影響を受ける表パーティションはどのDML操作に関してもロックされます。DROPまたはTRUNCATE操作の場合を除き、影響を受けるパーティションのデータは、すべてのSELECT操作で完全にアクセス可能です。ローカル索引は論理的に表(データ)のパーティションと対になっているため、パーティション・メンテナンス操作の際にメンテナンスを行う必要があるのは、影響を受ける表パーティションのローカル索引パーティションのみです。これで、索引メンテナンスの最適な処理が実現します。
たとえば、ハイエンド・ストレージ層から低コスト・ストレージ層に古くなったパーティションを移動しても、データと索引に対するSELECT操作は常に可能です。必要な索引メンテナンスは、データの新しい物理位置を反映するための既存索引パーティションの更新です。あるいは、索引パーティションも低コスト・ストレージ層に移動して再構築する方が一般的です。古いパーティションをアーカイブした後で削除すると、ローカル索引パーティションも削除されます。このとき、データ・ディクショナリのみに作用する、瞬間的なパーティション・メンテナンス操作が行われます。
グローバル索引がパーティション表または非パーティション表に定義されている場合、常に、個別の表パーティションと索引の間に相関関係はありません。したがって、あらゆるパーティション・メンテナンス操作はすべてのグローバル索引またはグローバル索引パーティションに影響します。ローカル索引を含む表の場合と同じく、影響を受けるパーティションは、影響を受ける表パーティションに対するDML操作を防ぐためにロックされます。ただし、ローカル索引の索引メンテナンスとは異なり、すべてのグローバル索引に対してはDML操作もすべて可能です。OLTPシステムのオンライン可用性にも影響がありません。概念と技術の面では、パーティション・メンテナンス操作に対するグローバル索引のメンテナンスは、同じセマンティックのDML操作で必要になる索引メンテナンスと同じです。
たとえば、古いパーティションの削除(Drop)は、SQL DELETE文を使用して古いパーティションのすべてのレコードを削除することとセマンティックは同じです。どちらの場合も、削除されるデータセットのすべての索引エントリは、通常の索引メンテナンス操作としてどのグローバル索引からも削除する必要があります。この操作は、SELECTおよびDML操作に関する索引の可用性には影響しません。このシナリオでは、削除操作(Drop)が最適な方法です。従来のDELETE操作に伴うオーバーヘッドなしでデータが削除され、可用性を損わずにグローバル索引がメンテナンスされます。
2つの一般的なパーティション・メンテナンス操作は、データの削除と、低コスト・ストレージ層デバイスへのデータの移動です。
DROPまたはTRUNCATE操作を使用し、パーティション化キーの基準に基づいて古くなったデータを削除します。Drop操作ではデータとパーティション・メタデータが削除されます。TRUNCATE操作ではデータは削除されますがメタデータは保存されます。すべてのローカル索引パーティションはそれぞれ削除され、切り捨てされます。パーティション・グローバル索引または非パーティション・グローバル索引では通常の索引メンテナンスが行われます。このとき、SELECTおよびDML操作はすべて可能です。
次の例では、2006年1月よりも前のすべてのデータがorders表から削除されます。Drop文の一部としてUPDATE GLOBAL INDEXES文が実行されることに注意してください。このため、グローバル索引はメンテナンス操作中も使用可能です。ローカル索引パーティションがある場合はこの操作で削除されます。
ALTER TABLE orders DROP PARTITION p_before_jan_2006 UPDATE GLOBAL INDEXES;
情報ライフサイクル管理戦略の一環としてMOVEまたはMERGE操作を使用して、古いパーティションをコスト効率が最も高いストレージ層に移動できます。この操作中、データに対してSELECT文は実行できますがDML操作は行えません。ローカル索引はメンテナンスされます。多くの場合、マージまたは移動操作と同時にローカル索引も移動します。パーティション・グローバル索引または非パーティション・グローバル索引では通常の索引メンテナンスが行われます。このとき、SELECTおよびDML操作はすべて可能です。
次の例は、orders表の2006年1月と2006年2月のパーティションをマージして、別の表領域に格納する方法を示します。ローカル索引パーティションも、この操作でts_low_cost表領域に移動されます。UPDATE INDEXES句により、再構築を行わなくてもすべての索引が操作の間および後で使用可能であることが保証されます。
ALTER TABLE orders MERGE PARTITIONS p_2006_jan,p_2006_feb INTO PARTITION p_before_mar_2006 COMPRESS TABLESPACE ts_low_cost UPDATE INDEXES;
情報ライフサイクル管理でのパーティション・メンテナンス操作の利点の詳細は、第5章「情報ライフサイクル管理のためのパーティション化の使用」を参照してください。
