10gリリース2（10.2）
B19215-02
 目次 |
 索引 |
| Oracle Database 概要 10gリリース2（10.2） B19215-02 |
|
この章では、パーティション表とパーティション索引について説明します。この章の内容は、次のとおりです。
パーティション化とは、大規模な表や索引を、パーティションというより小さくて管理しやすい部分に分割して、この種の表や索引をサポートするときの主な問題に対処します。パーティション表にアクセスする際、SQL問合せとDML文を変更する必要はありません。ただしパーティションを定義すると、DDL文は表や索引全体ではなく、個々のパーティションへのアクセスやその操作ができるようになります。パーティション化を行うと、このようにしてラージ・データベース・オブジェクトの管理を簡素化できます。また、パーティション化は、アプリケーションに対して完全に透過的です。
表や索引の各パーティションは、列名、データ型、制約といった論理属性は同じものを持つ必要がありますが、PCTFREE、PCTUSEDおよび表領域といった物理属性は別のものを持つことができます。
パーティション化は様々なタイプのアプリケーションで有効ですが、特に大量のデータを管理するアプリケーションで便利です。OLTPシステムは管理性と可用性の改良によって改善されることが多く、データ・ウェアハウス・システムはパフォーマンスと管理性によって改善されます。
|
関連項目
|
パーティション化には次のような利点があります。
パーティションのメンテナンス操作におけるパーティションの独立性により、同じ表や索引にある異なるパーティションのメンテナンス操作を同時に行うことができます。また、メンテナンス操作の影響を受けないパーティションに対して、SELECT操作とDML操作を同時に実行できます。
SELECT文やDML文を一切変更せずに、非パーティション表をパーティション表に変換できます。パーティション化を活用するためにアプリケーションのコードを書き換える必要はありません。
図18-1は、パーティション表と非パーティション表の相違点を図示したものです。
パーティション表の各行は、単一パーティションに明示的に割り当てられます。パーティション・キーは、各行のパーティションを決定する1つ以上の列のセットです。Oracleではパーティション・キーを使用して、挿入、更新および削除の操作を適切なパーティションに自動的に指示します。パーティション・キーには次のような特長があります。
表は最大1024K-1のパーティションに分割できます。どの表もパーティション化できますが、LONGデータ型またはLONG RAWデータ型の列を含む表は例外です。ただし、CLOBまたはBLOBの各データ型の列を含む表は使用できます。
索引構成表に対してレンジ・パーティション化、リスト・パーティション化またはハッシュ・パーティション化を実行できます。パーティション索引構成表は、索引構成表の管理性、可用性およびパフォーマンスの改善に非常に役立ちます。さらに、索引構成表を使用するデータ・カートリッジも、格納したデータをパーティション化する機能を活用できます。この一般的な例は、Image CartridgeおよびinterMedia Cartridgeです。
索引構成表のパーティション化には、次の規定があります。
OVERFLOWデータ・セグメントは、常に表パーティションと同一レベルでパーティション化されます。
用意されているパーティション化方法は次のとおりです。
図18-2は、パーティション化方法の例を図示したものです。
コンポジット・パーティション化は、他のパーティション化方法を組み合せたものです。Oracleは、レンジ-ハッシュ・コンポジット・パーティション化とレンジ-リスト・コンポジット・パーティション化をサポートしています。図18-3は、レンジ-ハッシュ・コンポジット・パーティション化とレンジ-リスト・コンポジット・パーティション化を図示したものです。
レンジ・パーティション化では、各パーティションに設定したパーティション・キー値の範囲に基づいて、データが各パーティションにマップされます。これは最も一般的なタイプのパーティション化で、多くの場合日付とともに使用されます。たとえば、売上データを月別パーティションに分割する場合などです。
レンジ・パーティション化を使用する際は、次のルールを考慮する必要があります。
VALUES LESS THAN句があり、これがパーティションの上限（この値は含まれません）を指定します。このリテラル以上となるパーティション・キーの値は、次のパーティションに追加されます。
VALUES LESS THAN句に指定された暗黙的な下限があります。
MAXVALUEリテラルを定義できます。MAXVALUEは、仮想の無限大値を示しており、そのパーティション・キーの他のどんな可能な値（NULL値を含みます）よりも高い値としてソートされます。
代表的な例を次に示します。この文は、sales_dateフィールドでレンジ・パーティション化される表（sales_range）を作成します。
CREATE TABLE sales_range (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), sales_date DATE) PARTITION BY RANGE(sales_date) ( PARTITION sales_jan2000 VALUES LESS THAN(TO_DATE('02/01/2000','MM/DD/YYYY')), PARTITION sales_feb2000 VALUES LESS THAN(TO_DATE('03/01/2000','MM/DD/YYYY')), PARTITION sales_mar2000 VALUES LESS THAN(TO_DATE('04/01/2000','MM/DD/YYYY')), PARTITION sales_apr2000 VALUES LESS THAN(TO_DATE('05/01/2000','MM/DD/YYYY')) );
リスト・パーティション化では、各パーティションへの行のマップ方法を明示的に制御できます。これは各パーティションの記述で、パーティション化キーの不連続な値のリストを指定して行います。これは値の範囲がパーティションに対応付けられているレンジ・パーティション化や、ハッシュ関数がパーティションへの行のマッピングを制御するハッシュ・パーティション化とは異なります。リスト・パーティション化の利点は、関連もなく順序付けもされていないデータのセットを、自然な形でグループ化および編成できることです。
リスト・パーティション化の詳細は、例示して説明するのが最も有効です。ここでは、売上表を領域別にパーティション化することにします。つまり、次の例のように、州を地理的な位置によってグループ分けします。
CREATE TABLE sales_list (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_state VARCHAR2(20), sales_amount NUMBER(10), sales_date DATE) PARTITION BY LIST(sales_state) ( PARTITION sales_west VALUES('California', 'Hawaii'), PARTITION sales_east VALUES ('New York', 'Virginia', 'Florida'), PARTITION sales_central VALUES('Texas', 'Illinois'), PARTITION sales_other VALUES(DEFAULT) );
行は、行のパーティション化列の値が、そのパーティションを示した値のセットの範囲内にあるかどうかをチェックすることによって、パーティションにマップされます。たとえば、各行は次のように挿入されます。
10, 'Jones', 'Hawaii', 100, '05-JAN-2000')は、パーティションsales_westにマップされます。
21, 'Smith', 'Florida', 150, '15-JAN-2000')は、パーティションsales_eastにマップされます。
32, 'Lee', 'Colorado', 130, '21-JAN-2000')は、パーティションsales_otherにマップされます。
レンジ・パーティション化やハッシュ・パーティション化とは異なり、リスト・パーティション化ではマルチカラム・パーティション・キーはサポートされていません。表をリストによってパーティション化する場合、パーティション化キーは常に表の単一列からなります。
DEFAULTパーティションを使用すると、リスト・パーティション表に可能な値をすべて指定する必要がなく、他のどのパーティションにもマップされない行でもエラーは生成されません。
ハッシュ・パーティション化では、レンジ・パーティション化やリスト・パーティション化ができないデータを容易にパーティション化できます。これは単純な構文で行われ、実装も容易です。レンジ・パーティション化よりハッシュ・パーティション化のほうが適しているのは、次のような場合です。
ハッシュ・パーティションには、パーティションの分割、削除およびマージの概念は当てはまりません。そのかわり、ハッシュ・パーティションは追加および結合ができます。
CREATE TABLE sales_hash (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), week_no NUMBER(2)) PARTITION BY HASH(salesman_id) PARTITIONS 4 STORE IN (ts1, ts2, ts3, ts4);
この文は、salesman_idフィールドでハッシュ・パーティション化される表sales_hashを作成します。表領域名は、ts1、ts2、ts3およびts4です。この構文を使用すると、指定した表領域全体に、パーティションがラウンドロビン方式で作成されます。
コンポジット・パーティション化では、データはレンジ方式でパーティション化されてから、各パーティション内でハッシュまたはリスト方式でサブパーティション化されます。レンジ-ハッシュ・コンポジット・パーティション化では、レンジ・パーティション化の優れた管理性や、ハッシュ・パーティション化のデータ配置、ストライプ化およびパラレル化といった利点が生かされています。レンジ-リスト・コンポジット・パーティション化では、レンジ・パーティション化の管理性と、サブパーティションに対するリスト・パーティション化の明示的な制御が生かされています。
コンポジット・パーティション化では新しいレンジ・パーティションの追加といった履歴操作がサポートされていますが、同時にサブパーティション化を通して、DML操作のより高い並列度やさらにきめの細かいデータ配置も可能になっています。
CREATE TABLE sales_composite (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), sales_date DATE) PARTITION BY RANGE(sales_date) SUBPARTITION BY HASH(salesman_id) SUBPARTITION TEMPLATE( SUBPARTITION sp1 TABLESPACE ts1, SUBPARTITION sp2 TABLESPACE ts2, SUBPARTITION sp3 TABLESPACE ts3, SUBPARTITION sp4 TABLESPACE ts4) (PARTITION sales_jan2000 VALUES LESS THAN(TO_DATE('02/01/2000','MM/DD/YYYY')) PARTITION sales_feb2000 VALUES LESS THAN(TO_DATE('03/01/2000','MM/DD/YYYY')) PARTITION sales_mar2000 VALUES LESS THAN(TO_DATE('04/01/2000','MM/DD/YYYY')) PARTITION sales_apr2000 VALUES LESS THAN(TO_DATE('05/01/2000','MM/DD/YYYY')) PARTITION sales_may2000 VALUES LESS THAN(TO_DATE('06/01/2000','MM/DD/YYYY')));
この文は、sales_dateフィールドでレンジ・パーティション化され、かつsalesman_idでハッシュ・サブパーティション化される表sales_compositeを作成します。テンプレートを使用すると、パーティション名、アンダースコアおよびテンプレートからのサブパーティション名が連結されて、サブパーティション名が作成されます。このサブパーティションは、テンプレートに指定されている表領域に格納されます。前述の文では、sales_jan2000_sp1が作成されて表領域ts1に格納され、sales_jan2000_sp4が作成されて表領域ts4に格納されます。同様に、sales_apr2000_sp1が作成されて表領域ts1に格納され、sales_apr2000_sp4が作成されて表領域ts4に格納されます。図18-4は、前述の例を図示したものです。
CREATE TABLE bimonthly_regional_sales (deptno NUMBER, item_no VARCHAR2(20), txn_date DATE, txn_amount NUMBER, state VARCHAR2(2)) PARTITION BY RANGE (txn_date) SUBPARTITION BY LIST (state) SUBPARTITION TEMPLATE( SUBPARTITION east VALUES('NY', 'VA', 'FL') TABLESPACE ts1, SUBPARTITION west VALUES('CA', 'OR', 'HI') TABLESPACE ts2, SUBPARTITION central VALUES('IL', 'TX', 'MO') TABLESPACE ts3) ( PARTITION janfeb_2000 VALUES LESS THAN (TO_DATE('1-MAR-2000','DD-MON-YYYY')), PARTITION marapr_2000 VALUES LESS THAN (TO_DATE('1-MAY-2000','DD-MON-YYYY')), PARTITION mayjun_2000 VALUES LESS THAN (TO_DATE('1-JUL-2000','DD-MON-YYYY')) );
この文は、txn_dateフィールドでレンジ・パーティション化され、かつstateでリスト・サブパーティション化される表bimonthly_regional_salesを作成します。テンプレートを使用すると、パーティション名、アンダースコアおよびテンプレートからのサブパーティション名が連結されて、サブパーティション名が作成されます。このサブパーティションは、テンプレートに指定されている表領域に格納されます。前述の文では、janfeb_2000_eastが作成されて表領域ts1に格納され、janfeb_2000_centralが作成され表領域ts3に格納されます。同様に、mayjun_2000_eastが作成されて表領域ts1に格納され、mayjun_2000_centralが表領域ts3に格納されます。図18-5は、
表bimonthly_regional_salesとその9個のサブパーティションを図示したものです。
ここでは表をパーティション化する場合についての提案を示します。
パーティション表と同様、パーティション索引も管理性、可用性、パフォーマンスおよび拡張性を改善します。パーティション索引は独立的にパーティション化する（グローバル索引）ことも、表のパーティション化方法に自動でリンクする（ローカル索引）こともできます。一般に、OLTPアプリケーションにはグローバル索引、データ・ウェアハウス・アプリケーションやDSSアプリケーションにはローカル索引を使用する必要があります。また、管理が容易であるため、できるだけローカル索引を使用するようにしてください。使用するパーティション索引の種類を決定する際には、次のガイドラインを順番に考慮する必要があります。
ローカル・パーティション索引は、他のタイプのパーティション索引よりも管理が容易です。ローカル・パーティション索引でも可用性が拡張されており、DSS環境では一般的となっています。その理由は、ローカル索引の各パーティションが必ず表の1つのパーティションに対応付けられている、同一レベル・パーティション化にあります。これにより、索引のパーティションを自動的に表のパーティションと同時保存し、かつ表と索引の各ペアをそれぞれ独立させることができます。1つのパーティションのデータを無効または使用不可能にする処理は、単一パーティションのみに影響します。
ローカル・パーティション索引は、表に対してパーティションまたはサブパーティションのメンテナンス操作を実行するときに、より高い可用性を提供します。ローカルの非同一キー索引と呼ばれる索引タイプは、履歴データベースにきわめて有効です。このタイプの索引では、索引列の左接頭辞に対してパーティション化が存在しません。
パーティションは、明示的にローカル索引に追加することはできません。基礎となる表にパーティションを追加した場合のみ、新しいパーティションがローカル索引に追加されます。同様に、パーティションを明示的にローカル索引から削除することもできません。基礎となる表からパーティションを削除した場合のみ、ローカル索引のパーティションが削除されます。
ローカル索引は一意索引にできます。ただしローカル索引を一意索引にするには、表のパーティション化キーが索引のキー列の一部である必要があります。一意のローカル索引は、OLTP環境では有効です。
図18-6は、ローカル・パーティション索引を図示したものです。
Oracleには、レンジ・パーティションおよびハッシュ・パーティションという2種類のグローバル・パーティション索引があります。
グローバル・レンジ・パーティション索引は、パーティション化の程度とパーティション化キーが表のパーティション化方法から独立しているため、柔軟といえます。この索引は通常はOLTP環境で使用され、あらゆる個別レコードへの効率的なアクセスを提供します。
グローバル索引の最も上位のパーティションのパーティション・バウンドには、すべての値にMAXVALUEを指定する必要があります。これにより、基礎になる表のすべての行を索引に含めることができます。グローバル同一キー索引は、一意の索引にも、一意でない索引にもできます。
最上位のパーティションには常にMAXVALUEのパーティション・バウンドがあるため、グローバル索引にはパーティションを追加できません。新しい最上位パーティションを追加する場合は、ALTER INDEX SPLIT PARTITION文を使用します。グローバル索引のパーティションが空の場合、ALTER INDEX DROP PARTITION文を発行すると明示的に削除できます。グローバル索引のパーティションにデータが含まれている場合は、パーティションを削除すると、次に上位のパーティションにUNUSABLEマークが設定されます。グローバル索引の最上位パーティションは削除できません。
グローバル・ハッシュ・パーティション索引では、索引が直線的に大きくなっていく場合に競合が分散され、パフォーマンスが改善されます。つまり、索引挿入のほとんどは索引の右端でのみ発生します。
デフォルトでは、ヒープ構成表のパーティションに次の操作を行うと、グローバル索引すべてにUNUSABLEマークが設定されます。
ADD (HASH) COALESCE (HASH) DROP EXCHANGE MERGE MOVE SPLIT TRUNCATE
操作のためのSQL文にUPDATE INDEXES句を追加すると、これらの索引をメンテナンスできます。グローバル索引をメンテナンスすることには、次の2つの利点があります。
ALTER TABLE DROP PARTITION P1 UPDATE INDEXES;
図18-7は、グローバル・パーティション索引を図示したものです。
グローバル非パーティション索引は、非パーティション索引と同様に動作します。この索引は通常はOLTP環境で使用され、あらゆる個別レコードへの効率的なアクセスを提供します。
図18-8は、グローバル非パーティション索引を図示したものです。
パーティション表に対してビットマップ索引を作成できますが、ビットマップ索引はパーティション表に対して必ずローカルであるという制限があります。グローバル索引にすることはできません。
グローバル索引は一意索引にできます。ローカル索引は、パーティション化キーが索引キーの一部である場合、一意索引にしかできません。
ここではOLTPアプリケーションにいくつかのガイドラインを示します。
ここではデータ・ウェアハウス・アプリケーションとDSSアプリケーションにいくつかのガイドラインを示します。
ここではコンポジット・パーティションでパーティション索引を使用する際の考慮事項を挙げます。
パーティション化を行うと、パフォーマンスや管理性を改善できます。その理由でパーティション化を使用する際の考慮事項を次に示します。
Oracleデータベース・サーバーは、パーティションとサブパーティションを明示的に認識します。次に、アクセスを必要とするパーティションまたはサブパーティションをマークし、不要なパーティションやサブパーティションがこれらのSQL文によるアクセスから除外（プルーニング）されるようにするために、SQL文を最適化します。言い換えると、パーティション・プルーニングとは、問合せの際に不要な索引およびデータのパーティションやサブパーティションをスキップすることです。
SQL文ごとに、指定された選択基準に応じて不必要なパーティションやサブパーティションが除外されます。たとえば、3月の売上データのみに関する問合せであれば、残りの11か月に関するデータを取り出す必要はありません。このようなインテリジェント・プルーニング機能によって、データの量を大幅に低減できるため、問合せのパフォーマンスが実質的に向上します。
オプティマイザは、アクセスされるパーティションまたはサブパーティションのすべての行がプルーニングによって使用される選択基準を満たすかどうかを判断する場合に、パフォーマンスを向上させるために、評価のときにそれらの基準を述語リスト（WHERE句）から削除します。ただし、SQL文によってパーティション化される列にTO_DATE以外の関数が適用されると、オプティマイザはパーティションをプルーニングできません。同様に、ファンクション索引でないかぎり、SQL文によって索引付きの列に関数が適用されると、オプティマイザは索引を使用できません。
基礎となる表のパーティションを排除できない場合にも、パーティションのプルーニングによって索引パーティションを排除できますが、これは索引と表が別々の列にパーティション化されている場合にかぎります。大規模な表に対する操作のパフォーマンスは、SQL文がアクセスまたは変更する必要のあるデータ量を削減するパーティション索引を作成すると改善できます。
等価、レンジ、LIKEおよびIN-listの述語は、レンジ・パーティション化またはリスト・パーティション化によるパーティション・プルーニングの対象とされ、等価かつIN-listの述語は、ハッシュ・パーティション化によるパーティション・プルーニングの対象とされます。
cust_ordersと呼ばれるパーティション表があります。cust_ordersのパーティション・キーはorder_dateです。cust_ordersには1月から6月までの6か月分のデータがあり、各月のデータが1つのパーティションになっているとします。ここで次のような問合せを実行した場合、
SELECT SUM(value) FROM cust_orders WHERE order_date BETWEEN '28-MAR-98' AND '23-APR-98';
パーティション・プルーニングは次のように行われます。
パーティション・ワイズ結合とは、結合列に沿ってパーティション化された2つの表を結合するための最適化のことです。パーティション・ワイズ結合では、結合の操作が小さな単位に分割され、それぞれが順番にまたはパラレルで実行されます。別の見方をすれば、パーティション・ワイズ結合は、パラレル結合の実行時にデータ配分を考慮することでパラレルのスレーブ間で交換されるデータの量を最小化するものです。
パラレル実行を行うと、主に意思決定支援システムやデータ・ウェアハウスに対応付けられた大規模データベースでの、データ処理集中型の操作における応答時間が劇的に短縮されます。従来型の表に加え、レンジ・パーティションおよびハッシュ・パーティションの表でもパラレル問合せやパラレルDMLが使用できます。これにより、バッチ操作の拡張性およびパフォーマンスを拡張できます。
パラレルDMLセッションの方法および制限事項は、索引構成表の使用の有無によらず変わりません。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|