3.5 パーティション化戦略の選択に関する推奨事項

パーティション化計画の選択時には、パフォーマンスに関する考慮事項に基づいた次の推奨事項を確認してください。

次の各トピックでは、パーティション化戦略の選択に関する推奨事項を示します。

• レンジ・パーティション化または時間隔パーティション化を使用する場合

• ハッシュ・パーティション化を使用する場合

• リスト・パーティション化を使用する場合

• コンポジット・パーティション化を使用する場合

• 時間隔パーティション化を使用する場合

• 参照パーティション化を使用する場合

• 仮想列でパーティション化する場合

• 読取り専用表領域を使用する場合の考慮事項

3.5.1 レンジ・パーティション化または時間隔パーティション化を使用する場合

レンジまたは時間隔パーティション化は、特に日付および時間データなど類似のデータを整理する場合に便利です。

レンジ・パーティション化は、履歴データをパーティション化する場合に便利です。レンジ・パーティション化の境界は、表または索引内でのパーティションの順序を定義します。

時間隔パーティション化は、レンジ・パーティション化の機能が拡張されたものです。ある時点を過ぎると、パーティションが時間の間隔によって定義されます。データがパーティションに挿入されると、データベースによって時間隔パーティションが自動的に作成されます。

レンジ・パーティション化または時間隔パーティション化は、DATE型の列の時間隔でデータを整理するためによく使用されます。したがって、レンジ・パーティションにアクセスするほとんどのSQL文では期間が指定されます。たとえば、特定の期間のデータを選択するSQL文です。このようなシナリオで、各パーティションが1か月のデータを表す場合、「2006年12月のデータを検索する」という問合せは2006年12月のパーティションだけにアクセスする必要があります。これにより、スキャンされるデータ容量が、存在するデータ全体の一部にまで減少します。これはパーティション・プルーニングと呼ばれる最適化方法です。

レンジ・パーティション化は、パーティションを簡単に追加または削除できるため、定期的に新しいデータをロードして、古いデータを削除する場合にも最適です。たとえば、過去36か月間のデータをオンラインでアクセスできるように、データのローリング・ウィンドウを維持することが一般的です。レンジ・パーティション化によりこのプロセスが簡略化されます。新しい月のデータを追加するには、別の表にロードし、クリーニングし、索引を作成してから、EXCHANGE PARTITION文を使用してレンジ・パーティション表に追加します。この間、元の表はオンラインになっています。新しいパーティションを追加したら、DROP PARTITION文を使用して一番古い月を削除できます。DROP PARTITION文を使用するかわりに、パーティションをアーカイブして読取り専用にすることもできますが、この方法を利用できるのはパーティションが別の表領域にある場合のみです。パーティション表への挿入を使用して、データのローリング・ウィンドウを実装することもできます。

時間隔パーティション化を使用すると、データが届いたときに時間隔パーティションを自動的かつ容易に作成できるようになります。また、時間隔パーティションは、その他すべてのパーティション・メンテナンス操作でも使用できます。

つまり、次のような場合にレンジ・パーティション化または時間隔パーティション化の使用を検討してください。

• 非常に大規模な表が、適切なパーティショニング化列(ORDER_DATEやPURCHASE_DATEなど)の範囲述語により頻繁にスキャンされる場合。その列で表をパーティション化することで、パーティション・プルーニングが可能になります。

• データのローリング・ウィンドウを保持する場合。

• 大きい表では、割り当てられた時間枠内でバックアップやリストアなどの管理操作を完了できない場合。パーティション・レンジ列に基づいて表を小さい論理単位に分割できます。

例3-5では、2005年および2006年の2年間分の表salestableを作成し、その表を列s_salesdateの範囲でパーティション化して、8つの四半期にデータを分割します(1四半期が1つのパーティションに対応)。将来のパーティションは、月単位の間隔の定義により自動的に作成されます。時間隔パーティションは、ラウンドロビン法で指定リストの表領域に作成されます。短い間隔で売上数を分析するときに、パーティション・プルーニングを利用できます。sales表では、ローリング・ウィンドウの使用もサポートされます。

例3-5 レンジおよび時間隔パーティション化による表の作成

CREATE TABLE salestable
  (s_productid  NUMBER,
   s_saledate   DATE,
   s_custid     NUMBER,
   s_totalprice NUMBER)
PARTITION BY RANGE(s_saledate)
INTERVAL(NUMTOYMINTERVAL(1,'MONTH')) STORE IN (tbs1,tbs2,tbs3,tbs4)
 (PARTITION sal05q1 VALUES LESS THAN (TO_DATE('01-APR-2005', 'DD-MON-YYYY')) TABLESPACE tbs1,
  PARTITION sal05q2 VALUES LESS THAN (TO_DATE('01-JUL-2005', 'DD-MON-YYYY')) TABLESPACE tbs2,
  PARTITION sal05q3 VALUES LESS THAN (TO_DATE('01-OCT-2005', 'DD-MON-YYYY')) TABLESPACE tbs3,
  PARTITION sal05q4 VALUES LESS THAN (TO_DATE('01-JAN-2006', 'DD-MON-YYYY')) TABLESPACE tbs4,
  PARTITION sal06q1 VALUES LESS THAN (TO_DATE('01-APR-2006', 'DD-MON-YYYY')) TABLESPACE tbs1,
  PARTITION sal06q2 VALUES LESS THAN (TO_DATE('01-JUL-2006', 'DD-MON-YYYY')) TABLESPACE tbs2,
  PARTITION sal06q3 VALUES LESS THAN (TO_DATE('01-OCT-2006', 'DD-MON-YYYY')) TABLESPACE tbs3,
  PARTITION sal06q4 VALUES LESS THAN (TO_DATE('01-JAN-2007', 'DD-MON-YYYY')) TABLESPACE tbs4);

関連項目:

時間隔パーティションのパーティション・メンテナンス操作の詳細は、「パーティションの管理」を参照してください

3.5.2 ハッシュ・パーティション化を使用する場合

ハッシュ・パーティション化は、類似データをグループ化するのではなく、ハッシュ・アルゴリズムに基づいて、データをパーティションにランダムに分散する場合に便利です。

パーティション化キーを指定できても、どのパーティションにデータを含めるべきかがわかりにくい場合があります。また、レンジ・パーティション化のように、類似したデータをグループ化するのではなく、データの業務上の意味や論理的な意味に対応しないようにデータを分散することが望ましい場合があります。ハッシュ・パーティション化では、パーティション化キーをハッシング・アルゴリズムに渡した結果に基づいて行がパーティションに配置されます。

この方法を使用すると、データはグループ化されるのではなく複数のパーティションにランダムに分散されます。この方法はデータによっては適していますが、履歴データを管理する方法としては効率的ではありません。ただし、ハッシュ・パーティションの一部のパフォーマンス特性は、レンジ・パーティションと同じです。たとえば、パーティション・プルーニングが行われるのは等価述語の場合のみです。また、パーティション・ワイズ結合、パラレル索引アクセスおよびパラレルDMLを使用することもできます。

一般的なルールとして、次のような場合にハッシュ・パーティション化を使用します。

• パーティション・サイズが同一である可能性が高いときに、パラレルのパーシャル・パーティション・ワイズ結合またはフル・パーティション・ワイズ結合を使用可能にする場合。

• Oracle Real Application Clustersを使用するMPPプラットフォームのノード間に、データを均等に分散させる場合。結果として、インターノード・パラレル文を処理するときにインターコネクト・トラフィックが最小限になります。

• パーティション化キー(多くの場合、値指定か値リストの制約がある)に基づいてパーティション・プルーニングおよびパーティション・ワイズ結合を使用する場合。

• 使用可能なすべてのデバイスに対してストライプ化およびミラー化を行うストレージ管理方法を使用しないときに、I/Oボトルネックを回避するためにデータをランダムに分散させる場合。

ノート:

ハッシュ・パーティション化では、パーティション・プルーニングで使用できるのは等価述語またはINリスト述語のみです。

最適なデータ分散を実現するには次の要件を満たす必要があります。

• 一意またはほぼ一意の列または列の組合せを選択します。

• 作成するパーティションの数と、各パーティションのサブパーティションの数を2の累乗にします。たとえば、2、4、8、16、32、64、128などです。

例3-6では、パーティション化キーとして列s_productidを使用して、表sales_hashに4つのハッシュ・パーティションを作成します。products表とのパラレル結合では、パーシャル・パーティション・ワイズ結合またはフル・パーティション・ワイズ結合を利用できます。1つの製品または一連の製品の売上金額にアクセスする問合せでは、パーティション・プルーニングが利用されます。

パーティション名を明示的に指定せず、ハッシュ・パーティション数を指定した場合は、パーティションの内部名が自動的に生成されます。また、STORE IN句を使用して、ラウンドロビン法で表領域にハッシュ・パーティションを割り当てることもできます。

例3-6 ハッシュ・パーティション化による表の作成

CREATE TABLE sales_hash
  (s_productid  NUMBER,
   s_saledate   DATE,
   s_custid     NUMBER,
   s_totalprice NUMBER)
PARTITION BY HASH(s_productid)
( PARTITION p1 TABLESPACE tbs1
, PARTITION p2 TABLESPACE tbs2
, PARTITION p3 TABLESPACE tbs3
, PARTITION p4 TABLESPACE tbs4
);

関連項目:

• パーティション・ワイズ結合の詳細は、「パーティション・ワイズ結合」を参照してください

• VLDBの記憶域の管理の詳細は、「VLDBの記憶域管理」を参照してください

• ハッシュ・パーティション表の作成のその他の例は、「パーティションの管理」を参照してください

• パーティション化の構文は、『Oracle Database SQL言語リファレンス』を参照してください

3.5.3 リスト・パーティション化を使用する場合

リスト・パーティション化は、離散値に基づいて行をパーティションに明示的にマップする場合に便利です。

例3-7では、オレゴン州とワシントン州のすべての顧客が1つのパーティションに格納され、他の州の顧客はその他のパーティションに格納されているとします。地域ごとに顧客の取引を分析する顧客口座担当者は、パーティション・プルーニングを利用できます。

例3-7 リスト・パーティション化による表の作成

CREATE TABLE accounts
( id             NUMBER
, account_number NUMBER
, customer_id    NUMBER
, branch_id      NUMBER
, region         VARCHAR(2)
, status         VARCHAR2(1)
)
PARTITION BY LIST (region)
( PARTITION p_northwest VALUES ('OR', 'WA')
, PARTITION p_southwest VALUES ('AZ', 'UT', 'NM')
, PARTITION p_northeast VALUES ('NY', 'VM', 'NJ')
, PARTITION p_southeast VALUES ('FL', 'GA')
, PARTITION p_northcentral VALUES ('SD', 'WI')
, PARTITION p_southcentral VALUES ('OK', 'TX')
);

3.5.4 コンポジット・パーティション化を使用する場合

コンポジット・パーティション化には、複数のディメンションでパーティション化する利点があります。

パフォーマンスの観点では、SQL文にもよりますが1つまたは2つのディメンションでのパーティション・プルーニングを利用できます。また、いずれかのディメンションでのフル・パーティション・ワイズ結合またはパーシャル・パーティション・ワイズ結合を使用できます。

1つの表でパラレル・バックアップおよびパラレル・リカバリを利用できます。また、コンポジット・パーティション化ではパーティション数が大幅に増加するため、効果的なパラレル実行が可能になります。管理の観点では、履歴データをサポートするためのローリング・ウィンドウを実装でき、多くの文がパーティション・プルーニングまたはパーティション・ワイズ結合の恩恵を受ける場合には、別のディメンションでのパーティション化も可能です。

表のバックアップを分割して、パーティション化キーによる指定に基づいてデータの格納方法を変更することができます。たとえば、特定の製品タイプのデータは読取り専用として圧縮形式で格納し、その他の製品タイプのデータは圧縮せずに保存することができます。

データベースでは、コンポジット・パーティション化された表の各サブパーティションが個別のセグメントとして格納されます。このため、サブパーティションのプロパティは、表のプロパティや、そのサブパーティションが属するパーティションとは異なる場合があります。

次の内容について説明します。

• レンジ・パーティション化または時間隔パーティション化を使用する場合

• ハッシュ・パーティション化を使用する場合

• リスト・パーティション化を使用する場合

• コンポジット・パーティション化を使用する場合

• 時間隔パーティション化を使用する場合

• 参照パーティション化を使用する場合

• 仮想列でパーティション化する場合

関連項目:

構文と制約の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

3.5.4.1 コンポジット・レンジ・ハッシュ・パーティション化を使用する場合

コンポジット・レンジ - ハッシュ・パーティション化が特によく使用されるのは、履歴を格納する表、結果として非常に大規模になる表、および他の大きな表と頻繁に結合される表です。

このようなタイプの表(データ・ウェアハウス・システムの典型的な表)では、コンポジット・レンジ・ハッシュ・パーティション化によって、レンジ・レベルでのパーティション・プルーニングと、ハッシュ・レベルでのパラレルのフル・パーティション・ワイズ結合またはパーシャル・パーティション・ワイズ結合を利用できるようになります。場合によっては、特定のSQL文で両方のディメンションでのパーティション・プルーニングを利用できます。

また、コンポジット・レンジ・ハッシュ・パーティション化は、従来ハッシュ・パーティション化を使用し、同時にローリング・ウィンドウ方法も利用していた表で使用できます。時間経過に伴い、データをストレージ層間で移動し、圧縮して読取り専用表領域に格納し、最終的にはパージすることができます。情報ライフサイクル管理(ILM)シナリオでは、階層ストレージ方式を実装するためにレンジ・パーティションがよく使用されます。

例3-8は、インターネット・サービス・プロバイダのレンジ・ハッシュ・パーティション化されたpage_history表です。この表定義は、特定のclient_ip値(問合せがパーティション・プルーニングを利用可能)または多数のIPアドレス(問合せがフル・パーティション・ワイズ結合またはパーシャル・パーティション・ワイズ結合を利用可能)に関する履歴分析用に最適化されています。

この例では、時間隔パーティション化が使用されています。データが表に挿入されたときに時間隔パーティションを自動的に作成するために、レンジ・パーティション化に加えて時間隔パーティション化を使用できます。

例3-8 コンポジット・レンジ - ハッシュ・パーティション化による表の作成

CREATE TABLE page_history
( id                NUMBER NOT NULL
, url               VARCHAR2(300) NOT NULL
, view_date         DATE NOT NULL
, client_ip         VARCHAR2(23) NOT NULL
, from_url          VARCHAR2(300)
, to_url            VARCHAR2(300)
, timing_in_seconds NUMBER
) PARTITION BY RANGE(view_date) INTERVAL (NUMTODSINTERVAL(1,'DAY'))
SUBPARTITION BY HASH(client_ip)
SUBPARTITIONS 32
(PARTITION p0 VALUES LESS THAN (TO_DATE('01-JAN-2006','dd-MON-yyyy')))
PARALLEL 32 COMPRESS;

関連項目:

情報ライフサイクル管理(ILM)およびパーティション化を使用した階層ストレージの実装の詳細は、「時間ベース情報の管理およびメンテナンス」を参照してください

3.5.4.2 コンポジット・レンジ・リスト・パーティション化を使用する場合

コンポジット・レンジ・リスト・パーティション化は、履歴データを格納する大きな表でよく使用され、一般的に複数のディメンションでアクセスされます。

通常は、データの履歴ビューが1つのアクセス・パスですが、業務によってはアクセス・パスとしてその他のカテゴリも使用されます。たとえば、地区の経理担当者は、その地区で特定の期間に加入した新顧客数に高い関心があります。ILMとその階層ストレージ方式が、レンジ・リスト・パーティション表を作成する一般的な理由です。古いデータを移動して圧縮しても、リスト・ディメンションのパーティション・プルーニングを引き続き行うことができます。

例3-9では、レンジ・リスト・パーティション化されたcall_detail_records表を作成します。電気通信会社はこの表を使用して、時間経過に応じて特定の種類の通信を分析できます。この表では、from_numberとto_numberに対するローカル索引が使用されます。

この例では、時間隔パーティション化が使用されています。データが表に挿入されたときに時間隔パーティションを自動的に作成するために、レンジ・パーティション化に加えて時間隔パーティション化を使用できます。

例3-9 コンポジット・レンジ - リスト・パーティション化による表の作成

CREATE TABLE call_detail_records
( id NUMBER
, from_number        VARCHAR2(20)
, to_number          VARCHAR2(20)
, date_of_call       DATE
, distance           VARCHAR2(1)
, call_duration_in_s NUMBER(4)
) PARTITION BY RANGE(date_of_call)
INTERVAL (NUMTODSINTERVAL(1,'DAY'))
SUBPARTITION BY LIST(distance)
SUBPARTITION TEMPLATE
( SUBPARTITION local VALUES('L') TABLESPACE tbs1
, SUBPARTITION medium_long VALUES ('M') TABLESPACE tbs2
, SUBPARTITION long_distance VALUES ('D') TABLESPACE tbs3
, SUBPARTITION international VALUES ('I') TABLESPACE tbs4
)
(PARTITION p0 VALUES LESS THAN (TO_DATE('01-JAN-2005','dd-MON-yyyy')))
PARALLEL;

CREATE INDEX from_number_ix ON call_detail_records(from_number)
LOCAL PARALLEL NOLOGGING;

CREATE INDEX to_number_ix ON call_detail_records(to_number)
LOCAL PARALLEL NOLOGGING;

3.5.4.3 コンポジット・レンジ・レンジ・パーティション化を使用する場合

コンポジット・レンジ - レンジ・パーティション化は、時間関連のデータを複数の時間ディメンションで格納するアプリケーションに役立ちます。

多くの場合、このようなアプリケーションは、データにアクセスするために特定の1つの時間ディメンションを使用するのではなく、別の時間ディメンションを使用することもあれば、同時に両方の時間ディメンションを使用することもあります。たとえば、Webショップが、発注時間と出荷時間(運送会社に渡した時間)に基づいて売上データを分析する場合があります。

コンポジット・レンジ・レンジ・パーティション化の他の業務例としては、ILMシナリオや、履歴データを格納して、データを別のディメンションの範囲で分類するアプリケーションがあります。

例3-10では、レンジ・レンジ・パーティション化された表account_balance_historyを示します。銀行は、低残高通知や特定の顧客カテゴリ向けキャンペーンについて顧客に連絡するために、個々のサブパーティションへのアクセスを利用できます。

この例では、時間隔パーティション化が使用されています。データが表に挿入されたときに時間隔パーティションを自動的に作成するために、レンジ・パーティション化に加えて時間隔パーティション化を使用できます。ここでは、2007年1月1日(月曜日)から開始する7日間(1週間)の間隔が作成されています。

例3-10 コンポジット・レンジ - レンジ・パーティション化による表の作成

CREATE TABLE account_balance_history
( id                 NUMBER NOT NULL
, account_number     NUMBER NOT NULL
, customer_id        NUMBER NOT NULL
, transaction_date   DATE NOT NULL
, amount_credited    NUMBER
, amount_debited     NUMBER
, end_of_day_balance NUMBER NOT NULL
) PARTITION BY RANGE(transaction_date)
INTERVAL (NUMTODSINTERVAL(7,'DAY'))
SUBPARTITION BY RANGE(end_of_day_balance)
SUBPARTITION TEMPLATE
( SUBPARTITION unacceptable VALUES LESS THAN (-1000)
, SUBPARTITION credit VALUES LESS THAN (0)
, SUBPARTITION low VALUES LESS THAN (500)
, SUBPARTITION normal VALUES LESS THAN (5000)
, SUBPARTITION high VALUES LESS THAN (20000)
, SUBPARTITION extraordinary VALUES LESS THAN (MAXVALUE)
)
(PARTITION p0 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy')));

3.5.4.4 コンポジット・リスト・ハッシュ・パーティション化を使用する場合

コンポジット・リスト - ハッシュ・パーティショニングが役立つのは、通常1つのディメンションに関してアクセスされる大規模な表で、(そのサイズのために)他の大きな表との結合で、別のディメンションに関してパラレルのフル・パーティション・ワイズ結合またはパーシャル・パーティション・ワイズ結合を利用する必要がある表です。

例3-11にcredit_card_accounts表を示します。この表は、経理担当者がその地域の口座にすぐにアクセスできるように、regionでリスト・パーティション化されています。サブパーティション計画はcustomer_idでのハッシュです。これにより、transactions表(customer_idでサブパーティション化されている)に対する問合せはフル・パーティション・ワイズ結合を利用できます。ハッシュ・パーティション化されたcustomers表との結合では、フル・パーティション・ワイズ結合を利用することもできます。この表にはis_active列にローカル・ビットマップ索引があります。

例3-11 コンポジット・リスト - ハッシュ・パーティション化による表の作成

CREATE TABLE credit_card_accounts
( account_number  NUMBER(16) NOT NULL
, customer_id     NUMBER NOT NULL
, customer_region VARCHAR2(2) NOT NULL
, is_active       VARCHAR2(1) NOT NULL
, date_opened     DATE NOT NULL
) PARTITION BY LIST (customer_region)
SUBPARTITION BY HASH (customer_id)
SUBPARTITIONS 16
( PARTITION emea VALUES ('EU','ME','AF')
, PARTITION amer VALUES ('NA','LA')
, PARTITION apac VALUES ('SA','AU','NZ','IN','CH')
) PARALLEL;

CREATE BITMAP INDEX is_active_bix ON credit_card_accounts(is_active)
LOCAL PARALLEL NOLOGGING;

3.5.4.5 コンポジット・リスト・リスト・パーティション化を使用する場合

コンポジット・リスト・リスト・パーティション化が役立つのは、様々なディメンションに関してアクセスされることが多い大きな表です。

特に、離散値に基づいてそれらのディメンションに行をマップできます。

例3-12に、非常にアクセス回数の多いcurrent_inventory表を示します。この表は、スーパーマーケット納入業者の地方倉庫の現在の在庫を反映するように絶えず更新されています。生鮮食品はその倉庫からスーパーマーケットに供給されるため、供給と配送を最適化することが重要です。この表は、warehouse_idとproduct_idにローカル索引があります。

例3-12 コンポジット・リスト - リスト・パーティション化による表の作成

CREATE TABLE current_inventory
( warehouse_id      NUMBER
, warehouse_region  VARCHAR2(2)
, product_id        NUMBER
, product_category  VARCHAR2(12)
, amount_in_stock   NUMBER
, unit_of_shipping  VARCHAR2(20)
, products_per_unit NUMBER
, last_updated      DATE
) PARTITION BY LIST (warehouse_region)
SUBPARTITION BY LIST (product_category)
SUBPARTITION TEMPLATE
( SUBPARTITION perishable VALUES ('DAIRY','PRODUCE','MEAT','BREAD')
, SUBPARTITION non_perishable VALUES ('CANNED','PACKAGED')
, SUBPARTITION durable VALUES ('TOYS','KITCHENWARE')
)
( PARTITION p_northwest VALUES ('OR', 'WA')
, PARTITION p_southwest VALUES ('AZ', 'UT', 'NM')
, PARTITION p_northeast VALUES ('NY', 'VM', 'NJ')
, PARTITION p_southeast VALUES ('FL', 'GA')
, PARTITION p_northcentral VALUES ('SD', 'WI')
, PARTITION p_southcentral VALUES ('OK', 'TX')
);

CREATE INDEX warehouse_id_ix ON current_inventory(warehouse_id)
LOCAL PARALLEL NOLOGGING;

CREATE INDEX product_id_ix ON current_inventory(product_id)
LOCAL PARALLEL NOLOGGING;

3.5.4.6 コンポジット・リスト・レンジ・パーティション化を使用する場合

コンポジット・リスト・レンジ・パーティション化が役立つのは、様々なディメンションに関してアクセスされる大きな表です。

最もよく使用されるディメンションでは、離散値について行をパーティションに具体的にマップすることができます。リスト・レンジ・パーティション化は、リスト・パーティション内で範囲値を使用する表でよく使用されます。一方、レンジ・リスト・パーティション化は、レンジ・パーティション内の離散リスト値についてよく使用されます。リスト・レンジ・パーティション化は、履歴データの格納にはそれほど使用されませんが、同様のシナリオにはすべて対応します。レンジ・リスト・パーティション化は、時間隔リスト・パーティション化を使用して実装できますが、リスト・レンジ・パーティション化は時間隔パーティション化をサポートしていません。

例3-13に、様々な通貨単位での寄付額を格納するdonations表を示します。donationsは、金額に応じて、低、中、高にカテゴリ分けされています。通貨によってレンジは異なります。

例3-13 コンポジット・リスト - レンジ・パーティション化による表の作成

CREATE TABLE donations
( id             NUMBER
, name           VARCHAR2(60)
, beneficiary    VARCHAR2(80)
, payment_method VARCHAR2(30)
, currency       VARCHAR2(3)
, amount         NUMBER
) PARTITION BY LIST (currency)
SUBPARTITION BY RANGE (amount)
( PARTITION p_eur VALUES ('EUR')
  ( SUBPARTITION p_eur_small VALUES LESS THAN (8)
  , SUBPARTITION p_eur_medium VALUES LESS THAN (80)
  , SUBPARTITION p_eur_high VALUES LESS THAN (MAXVALUE)
  )
, PARTITION p_gbp VALUES ('GBP')
  ( SUBPARTITION p_gbp_small VALUES LESS THAN (5)
  , SUBPARTITION p_gbp_medium VALUES LESS THAN (50)
  , SUBPARTITION p_gbp_high VALUES LESS THAN (MAXVALUE)
  )
, PARTITION p_aud_nzd_chf VALUES ('AUD','NZD','CHF')
  ( SUBPARTITION p_aud_nzd_chf_small VALUES LESS THAN (12)
  , SUBPARTITION p_aud_nzd_chf_medium VALUES LESS THAN (120)
  , SUBPARTITION p_aud_nzd_chf_high VALUES LESS THAN (MAXVALUE)
  )
, PARTITION p_jpy VALUES ('JPY')
  ( SUBPARTITION p_jpy_small VALUES LESS THAN (1200)
  , SUBPARTITION p_jpy_medium VALUES LESS THAN (12000)
  , SUBPARTITION p_jpy_high VALUES LESS THAN (MAXVALUE)
  )
, PARTITION p_inr VALUES ('INR')
  ( SUBPARTITION p_inr_small VALUES LESS THAN (400)
  , SUBPARTITION p_inr_medium VALUES LESS THAN (4000)
  , SUBPARTITION p_inr_high VALUES LESS THAN (MAXVALUE)
  )
, PARTITION p_zar VALUES ('ZAR')
  ( SUBPARTITION p_zar_small VALUES LESS THAN (70)
  , SUBPARTITION p_zar_medium VALUES LESS THAN (700)
  , SUBPARTITION p_zar_high VALUES LESS THAN (MAXVALUE)
  )
, PARTITION p_default VALUES (DEFAULT)
  ( SUBPARTITION p_default_small VALUES LESS THAN (10)
  , SUBPARTITION p_default_medium VALUES LESS THAN (100)
  , SUBPARTITION p_default_high VALUES LESS THAN (MAXVALUE)
  )
) ENABLE ROW MOVEMENT;

3.5.5 時間隔パーティション化を使用する場合

時間隔パーティション化は、レンジ・パーティション化されており、新しいパーティションで固定間隔を使用するほぼすべての表で使用できます。

時間隔パーティションは、そのパーティションのデータが挿入されたときに自動的に作成されます。このときまで、時間隔パーティションは存在しますが、そのパーティションのセグメントは作成されていません。

時間隔パーティション化の利点は、レンジ・パーティションを明示的に作成する必要がないことです。様々な間隔のレンジ・パーティションを作成しない場合、またはレンジ・パーティションを作成するときに常に特定のパーティション属性を設定する場合は、時間隔パーティション化の使用を検討する必要があります。時間隔の定義では表領域のリストを指定できます。時間隔パーティションは、データベースによってラウンドロビン法で指定リストの表領域に作成されます。

アプリケーションをアップグレードし、レンジ・パーティション化または、様々なコンポジット・レンジ・パーティション化を使用する場合は、既存の表定義を簡単に変更して、時間隔パーティション化を使用することができます。時間隔パーティション表へのパーティションの手動追加はできません。新しいパーティションの作成を自動化している場合は、将来、レンジ・パーティションの明示的な作成が行われないようにアプリケーション・コードを変更する必要があります。

次のSQL文では、sales表でのレンジ・パーティション化から月次時間隔パーティション化の使用への変更が開始されます。

ALTER TABLE sales SET INTERVAL (NUMTOYMINTERVAL(1,'MONTH'));

参照パーティション表では時間隔パーティションを使用することはできません。

シリアル化可能トランザクションは、時間隔パーティションでは動作しません。まだセグメントのない時間隔パーティション表のパーティションにデータを挿入すると、エラーが発生します。

3.5.6 参照パーティション化を使用する場合

参照パーティション化は、特定の状況で役に立ちます。

参照パーティション化は次のシナリオで役立ちます。

• マスター表と子表の両方でパーティション・プルーニングを利用できるように、マスター表の列を子表に非正規化した場合(または、これから非正規化する場合)。

  たとえば、order_dateはorders表には格納されますが、注文ごとに1つ以上の品目を格納するorder_items表には格納されません。注文データの履歴分析のパフォーマンスを高めるには、従来であれば、order_items表にorder_date列を複製して、order_items表でパーティション・プルーニングを使用できるようにするはずです。

  このようなシナリオでは、order_dateを複製せずにすむように、参照パーティション化を検討する必要があります。両方の表を結合してorder_dateに対する条件を使用する問合せは、両方の表のパーティション・プルーニングを自動的に利用します。

• 2つの大きな表を頻繁に結合するときに、2つの表が結合キーでパーティション化されていないが、パーティション・ワイズ結合を利用する場合。

  参照パーティション化により、フル・パーティション・ワイズ結合が暗黙に使用可能になります。

• 複数の表のデータが1つのライフサイクルに関連している場合。参照パーティション化を使用すると、管理上で大きなメリットが得られます。

  マスター表でパーティション管理操作を行うと、子表でも自動的に行われます。たとえば、マスター表にパーティションを追加すると、その追加がすべての子表に自動的に伝播されます。

  参照パーティション化を使用するには、マスター表と参照表の間の外部キー関係を有効にして施行する必要があります。参照パーティション表をカスケードできます。

  主キー - 外部キーの関係を常に有効にする必要があり、無効にできません。また、関係は遅延として宣言できません。有効な主キーと外部の関係が子表のデータの配置を決定するために必要なため、これらは必須要件です。

3.5.7 仮想列でパーティション化する場合

仮想列でのパーティション化により、導出列でより柔軟にパーティション化できます。

仮想列でのパーティション化では、式についてパーティション化できます。つまり、他の列のデータを使用し、それらの列で計算を実行できます。PL/SQL関数コールは、パーティション化キーとして使用される仮想列の定義ではサポートされません。

仮想列のパーティション化では、すべてのパーティション化方法に加えて、パフォーマンスや管理のための機能もサポートされます。表のアクセスに頻繁に使用される述語が、列から直接取得するのではなく導出する場合には、パーティション・プルーニングの効果を得るために仮想列の使用を検討してください。従来、パーティション・プルーニングの効果を上げるためには、正しい値を取得して計算するために別の列を追加し、問合せで適切な検索を行えるように、列が常に正しい値を含むようにする必要がありました。

例3-14にcar_rentals表を示します。顧客の確認番号には、レンタカーを借りた場所として2文字の国名が含まれます。レンタカーの分析では通常は地域パターンが評価されるため、国別にパーティション化することに意味があります。

この例では、列countryは、確認番号から導出される仮想列として定義されています。仮想列には記憶域は必要ありません。この例が示すように、行の移動は仮想列でサポートされています。仮想列が別のパーティションにある異なる値と評価されると、その行はデータベースによって別のパーティションに移動されます。

例3-14 仮想列でのパーティション化による表の作成

CREATE TABLE car_rentals
( id                  NUMBER NOT NULL
 , customer_id         NUMBER NOT NULL
 , confirmation_number VARCHAR2(12) NOT NULL
 , car_id              NUMBER
 , car_type            VARCHAR2(10)
 , requested_car_type  VARCHAR2(10) NOT NULL
 , reservation_date    DATE NOT NULL
 , start_date          DATE NOT NULL
 , end_date            DATE
 , country as (substr(confirmation_number,9,2))
) PARTITION BY LIST (country)
SUBPARTITION BY HASH (customer_id)
SUBPARTITIONS 16
( PARTITION north_america VALUES ('US','CA','MX')
 , PARTITION south_america VALUES ('BR','AR','PE')
 , PARTITION europe VALUES ('GB','DE','NL','BE','FR','ES','IT','CH')
 , PARTITION apac VALUES ('NZ','AU','IN','CN')
) ENABLE ROW MOVEMENT;

3.5.8 読取り専用表領域を使用する場合の考慮事項

読取り専用表を使用する際の考慮事項を確認してください。

参照整合性制約が親表と子表の間に定義されているとき、索引は外部キーに定義され、その索引が格納される表領域は読取り専用になり、制約の整合性チェックが、読取り一貫性バッファ・アクセスを介してではなく、SQLで実装されます。

この実装が意味するのは、子がパーティション化されると、一部の子パーティションの索引のみが読取り専用表領域に含まれることと、非読取り専用子セグメントの1つに対して挿入が行われると、TMエンキューが子表に対してSXモードで獲得されることです。

SXモードはSリクエストとの互換性がありません。したがって、親に対する挿入の試行は、子に対するS TMエンキューを獲得しようとするため妨げられます。