表制御パーティションを使用するための表スペースの変換
インデックス制御パーティションを使用するパーティション化された（非UTS）テーブルスペースを範囲パーティション（PBR）テーブルスペースに変換する前に、テーブル制御パーティションを使用するように変換する必要があります。 索引制御のパーティションを使用する表スペース (すべての非 UTS 表スペースと同様に) は推奨されません。
始める前に
変換後にパーティション・キーからのパーティションに影響しない末尾の列を除外するには、IX_TB_PART_CONV_EXCLUDE サブシステム・パラメーターを YES に設定します。 詳細は、「EXCLUDE PART KEY COLUMNS フィールド（IX_TB_PART_CONV_EXCLUDE サブシステム・パラメータ ）」を参照してください。
インデックス制御パーティショニングを使用する新しいテーブルの作成を防止するには、サブシステム・パラメータ PREVENT_NEW_IXCTRL_PART をデフォルト値の YES に設定します。 詳細については、 マクロ DSN6SPRM の PREVENT_NEW_IXCTRL_PART を参照してください。
このタスクについて
パーティション化 (非 UTS) 表スペースの場合、Db2は、表制御のパーティション化と索引制御のパーティション化の両方をサポートします。 表制御のパーティション化は、索引制御のパーティション化に比べて、より多くのオプションと柔軟性が提供されます。 インデックス制御によるパーティショニングには、パーティショニングを制御するためのパーティショニングインデックスが必要です。 ベーステーブル用の非UTSテーブルスペースは非推奨となり、将来的にサポートされなくなります。
| 表制御のパーティション化 | 索引制御のパーティション化 |
|---|---|
| パーティション索引またはクラスタリング索引は必要ありません。 | パーティション索引とクラスタリング索引が必要です。 |
| 1 つの表スペース内に複数のパーティション化索引を作成可能。 | 1 つの表スペース内にはパーティション化索引を 1 つだけ作成可能。 |
| 表スペース・パーティションは、物理パーティション番号と論理パーティション番号の両方により識別される。 | 表スペース・パーティションは、物理パーティション番号により識別される。 |
上限キーは常に適用されます。つまり、範囲外のキー値は、関係する操作に応じて、エラーまたは破棄されたデータになる可能性があります。 |
大容量テーブルスペース以外では、上限キーは強制されません。 |
非推奨の従来のパーティション化 (非 UTS) 表スペースを範囲によるパーティション化表スペースに変換するためのさまざまなパスの包括的な背景、方法、および例については、ホワイト ペーパー 「索引制御パーティションからユニバーサル表スペース (UTS) への変換」を参照してください。
プロシージャー
特定の索引操作によっては、常にDb2が索引制御のパーティション化表スペースを表制御のパーティション化表スペースに自動的に変換する原因となるものがあります。 索引制御パーティション化を使用する表を、表制御のパーティション化を使用するように変換するには、次のいずれかのアクションを使用します。
結果
テーブル制御パーティショニングへの変換後、 Db2 は、大規模ではないテーブルスペースの既存の高限界キー値を、そのキーの最高値に変更します。 Db2は、ハイ・リミット・キー値の適用も開始します。これは、索引制御パーティションを使用する表の場合には当てはまりません。
また、Db2は、変換された表スペース内の表に依存するパッケージも無効にします。
Db2は、以下の状況では、表スペースの最後のパーティションを REORG ペンディング (REORP) 状態にします。
- 新規パーティションの追加または回転
- Db2は、デフォルトの上限キー値ではなく、元の上限キー値を保管します。 Db2 上限キー値がすでに適用されている場合、または最後のパーティションが空でない場合を除き、最後のパーティションをREORP状態にします。
- パーティションを変更すると、表制御パーティションへの変換が行われます
- Db2は、限界キー列のデータ・タイプに可能な最大値に、既存の上限キーを変更します。 表制御のパーティション化への変換後、Db2は上限キー値をユーザー指定値に変更し、最後のパーティションを REORP 状態にします。
例
- ACCTID はお客様のアカウント ID です
- POSTED はトランザクションの日付です
TRANS を含む表スペースは 13 のパーティションに分割され、それぞれが 1 カ月分のデータを含んでいます。 既存の 2 つの索引は、以下のように定義されています。
- パーティショニング・インデックスは、以下のCREATE INDEXステートメントのPARTITION ENDING AT句によって、トランザクション日付で定義されます。パーティショニング・インデックスはクラスタリング・インデックスであり、テーブル内のデータ行はトランザクション日付順に並びます。 パーティション索引は表スペース内のデータのパーティション化を制御します。
- 非パーティション索引が、カスタマー・アカウント ID に基づいて定義されています。
CREATE INDEX IX2 ON TRANS(ACCTID);
Db2は、通常、非パーティション索引 IX2 を使用して、顧客アカウント ID を介してトランザクション表にアクセスします。 パーティション索引 IX1 はデータ・アクセスには使用されず、スペースを無駄にしています。 さらに、表の可用性について重大な要件があり、データ使用可能性の最小限の中断でパーティション・レベルでのオンライン REORG ジョブを実行できる必要があります。
- パーティション索引 IX1 をドロップします。
DROP INDEX IX1;パーティショニングインデックスを削除すると、 IX1、 Db2 はテーブルスペースをインデックス制御パーティショニングからテーブル制御パーティショニングに変換します。 Db2 キー列に指定された最高値に、もともと指定されていた上限キー値を変更します。
- IX2 の代わりとして、表内の 13 個のデータ・パーティションに一致するパーティション・クラスタリング索引 IX3 を作成します。
CREATE INDEX IX1 ON TRANS(POSTED) CLUSTER (PARTITION 1 ENDING AT ('01/31/2002'), PARTITION 2 ENDING AT ('02/28/2002'), ... PARTITION 13 ENDING AT ('01/31/2003'));索引 IX3 を作成すると、Db2は、表内の 13 個のデータ・パーティションに一致する 13 個のパーティションを持つパーティション索引を作成します。 各索引パーティションには、その月のトランザクションのアカウント番号が含まれ、それらのアカウント番号は各パーティション内で順番に配置されます。 例えば、索引のパーティション 11 は、2002 年 11 月のトランザクションを含む表パーティションに対応します。また、そのパーティションには、それらのトランザクションのアカウント番号が順序付けされて含まれています。
- 索引 IX2 をドロップしました。IX3 は置き換えられました。
DROP INDEX IX2; COMMIT;
次の作業