DB2 Version 10.1 for Linux, UNIX, and Windows

データ・パーティションのアタッチ

表パーティション化は、表データの効率的なロールインおよびロールアウトを可能にします。ALTER TABLE ステートメントで ATTACH PARTITION 節を使用すると、データのロールインが簡単になります。

始める前に

データ・サーバーから独立したアプリケーション・ロジックを使用して、アタッチ操作の前に、範囲の妥当性その他の制約検査を含むデータ保全性検査を実行できる場合、新規にアタッチされたデータはずっと迅速に使用可能になります。SET INTEGRITY...ALL IMMEDIATE UNCHECKED ステートメントを使用して、範囲および制約の違反に対する検査をスキップすることにより、データのロールイン処理を最適化できます。この場合、ターゲット表のユーザー索引がすべてパーティション索引である限り、表は SET INTEGRITY 保留状態ではなくなり、即時に新規データがアプリケーションから使用可能になります。

アタッチ操作の後で維持する必要のある非パーティション索引 (ただし、XML 列パス索引を除く) が表にある場合、SET INTEGRITY...ALL IMMEDIATE UNCHECKED ステートメントは、SET INTEGRITY...IMMEDIATE CHECKED ステートメントであるかのように振る舞います。すべての整合性処理、非パーティション索引の保守、および表の状態の遷移は、SET INTEGRITY...IMMEDIATE CHECKED ステートメントが発行された場合のように実行されます。この動作により、SET INTEGRITY...ALL IMMEDIATE UNCHECKED を使用するロールイン・スクリプトによる処理が、そのロールイン・スクリプトの使用開始後に非パーティション索引がターゲット表に作成された場合でも停止しないようにします。

データ・パーティションをアタッチする ALTER TABLE を行うには、ステートメントの許可 ID によって保持される特権に、ソース表に対する以下の権限または特権が少なくとも 1 つ含まれていなければなりません。

表に対する SELECT 特権、および表のスキーマに対する DROPIN 特権
表に対する CONTROL 特権
DATAACCESS 権限

このタスクについて

データ・パーティションのアタッチにより、既存の表 (ソース表) が新しいデータ・パーティションとしてターゲット表にアタッチされます。 DB2® V10.1 以降のリリースで、ALTER TABLE ステートメントに ATTACH PARTITION 節を付けて使用することにより、パーティション表にデータ・パーティションをアタッチする場合、ターゲット・パーティション表はオンライン状態を維持し、この表に対して RS、CS、または UR の分離レベルで実行されている動的照会は実行を継続します。

制約事項および使用ガイドライン

データ・パーティションをアタッチする前に、以下の条件を満たさなければなりません。

新規のデータ・パーティションをアタッチする対象のターゲット表が、既存のパーティション表でなければなりません。
ソース表は、既存の非パーティション表であるか、またはデータ・パーティションを 1 つ持ち、ATTACHED データ・パーティションまたは DETACHED データ・パーティションを持たないパーティション表でなければなりません。複数のデータ・パーティションをアタッチするには、複数の ATTACH ステートメントを発行する必要があります。
ソース表は型付き表になることができません。
ソース表は、範囲がクラスター化された表になることができません。
ソース表の定義とターゲット表の定義は一致していなければなりません。
列の数、タイプ、および順序は、ソースとターゲットで一致していなければなりません。
デフォルト値があるかどうかについて、ソース表の列とターゲット表の列で一致していなければなりません。
NULL を許可するかどうかについて、ソース表の列とターゲット表の列で一致していなければなりません。
ソース表とターゲット表で、VALUE COMPRESSION 節および COMPRESS SYSTEM DEFAULT 節などの圧縮の指定が、一致していなければなりません。
ソース表とターゲット表で、DATA CAPTURE、ACTIVATE NOT LOGGED INITIALLY、および APPEND オプションに関する指定が、一致していなければなりません。
ターゲット列が生成列であり、対応するソース列は生成列ではない場合でも、データ・パーティションのアタッチは可能です。次のステートメントは、アタッチされた行の生成列に、値を生成します。
```
SET INTEGRITY FOR table-name
  ALLOW WRITE ACCESS
  IMMEDIATE CHECKED FORCE GENERATED
```
生成列に対応するソース表の列は、タイプと NULL 可能性について一致しなければなりません。ただし、デフォルト値については必要ありません。推奨されるアプローチは、アタッチ操作のソース表が、生成列に正しい生成値を確実に持つようにするというものです。推奨されるアプローチに従う場合は、FORCE GENERATED オプションを使用する必要はなく、次のステートメントを使用できます。
```
SET INTEGRITY FOR table-name
  GENERATED COLUMN
  IMMEDIATE UNCHECKED
```
このステートメントは、生成列の検査を省略するように指定しています。
```
SET INTEGRITY FOR table-name
  ALLOW WRITE ACCESS
  IMMEDIATE CHECKED
  FOR EXCEPTION IN table-name USE table-name
```
このステートメントは、アタッチされたデータ・パーティションの整合性検査を実行しますが、生成列検査は実行しません。
ターゲット列が ID 列であり、ソース列は ID 列ではない場合でも、データ・パーティションのアタッチは可能です。ステートメント SET INTEGRITY IMMEDIATE CHECKED は、アタッチ行に ID 値を生成しません。ステートメント SET INTEGRITY FOR T GENERATE IDENTITY ALLOW WRITE ACCESS IMMEDIATE CHECKED は、アタッチ行に ID 値を入力します。 ID 列と一致する列は、タイプと NULL 可能性が一致しなければなりません。この列はデフォルト値を必要としません。推奨されるのは、ステージング表に正しい ID 値を入力するというアプローチです。 ATTACH の後 GENERATE IDENTITY オプションを使用する必要はありません。 ID 値はすでにソース表で保証されているからです。
データがデータベース・パーティション全体に分散される表の場合、ソース表も、同じ分散キーおよび同じ分散マップを使って同じデータベース・パーティション・グループ内に分散する必要があります。
ソース表はドロップ可能でなければなりません (つまり RESTRICT DROP セットを持つことができません)。
データ・パーティション名を指定する場合、それがターゲット表に存在していてはなりません。
ターゲット表がマルチディメンション・クラスタリング (MDC) 表の場合、ソース表も MDC 表でなければなりません。
非パーティション表を使用する場合、ソース表のデータ表スペースとターゲット表のデータ表スペースの間で、タイプ (DMS または SMS)、ページ・サイズ、エクステント・サイズ、およびデータベース・パーティション・グループが一致していなければなりません。プリフェッチ・サイズが一致しない場合、警告が戻されます。ソース表の索引表スペースと、ターゲット表のパーティション索引によって使用される索引表スペースとの間で、タイプ、データベース・パーティション・グループ、ページ・サイズ、エクステント・サイズが一致している必要があります。ソース表の LARGE 表スペースとターゲット表の LARGE 表スペースは、タイプ、データベース・パーティション・グループ、およびページ・サイズが一致している必要があります。パーティション表を使用する場合、ソース表のデータ表スペースとターゲット表のデータ表スペースの間で、タイプ、ページ・サイズ、エクステント・サイズ、およびデータベース・パーティション・グループが一致していなければなりません。
構造化、XML、または LOB 列を持つパーティション表への ALTER TABLE ATTACH ステートメントを発行する場合、ソース表における構造化、XML、または LOB 列の INLINE LENGTH は、ターゲット表における対応する構造化、XML、または LOB 列の INLINE LENGTH と一致する必要があります。
ATTACH PARTITION 節と共に REQUIRE MATCHING INDEXES 節を使用する場合、ソース表と一致しないパーティション索引がターゲット表に存在するなら、SQL20307N が戻されます。
ターゲット表上のパーティション化された各ユニーク索引に対して一致する索引を持たないソース表をアタッチした場合、アタッチ操作は失敗して、エラー SQL20307N、理由コード 17 が返されます。
索引の据え置きクリーンアップ・メカニズムを使用する MDC ロールアウトをパーティション索引に対して実行することはできません。MDC ロールアウトの結果として索引の据え置きクリーンアップ操作が表で実行されている場合、索引の据え置きクリーンアップ操作の影響を受ける RID 索引がソース表に保持されているなら、アタッチ操作は実行できません。アタッチ操作中に保持されるのではなくて、再作成される索引については、この制限を受けません。
ターゲット表の XML データ形式とは異なる XML データ形式を持つソース表をアタッチする操作は、サポートされません。
バージョン 9.5 以前の XML レコード形式を使用する XML 列が表に含まれる場合、バージョン 9.7 以降のレコード形式を使用する XML 列を持つパーティション表に表をアタッチする操作はサポートされません。
表をアタッチする前に、ターゲット・パーティション表のレコード形式と一致するように表の XML レコード形式を更新する必要があります。以下の 2 つの方法のいずれかによって、表の XML レコード形式を更新できます。
- ADMIN_MOVE_TABLE プロシージャーを使用して、オンライン表移動を表に対して実行します。
- 以下の手順を実行します。
  1. EXPORT コマンドを使って表データのコピーを作成します。
  2. TRUNCATE ステートメントを使って表のすべての行を削除し、表に割り振られたストレージを解放します。
  3. LOAD コマンドを使って表の中にデータを追加します。
表の XML レコード形式を更新した後、ターゲット・パーティション表に表をアタッチします。
表に非パーティション索引がある場合、その表に新しいデータ・パーティションを作成した追加操作またはアタッチ操作と同じトランザクションにおいてその表が排他モードでロックされていないと、そのトランザクションでその新しいパーティションにアクセスすることはできません (SQL0668N、理由コード 11)。

アタッチ操作を実行する前に、ターゲット表のそれぞれのパーティション化索引に一致する索引をソース表に作成します。パーティション化索引を一致させることで、ロールイン操作の効率が上がり、必要なアクティブ・ログ・スペースが減ります。ソース表の索引を適切に準備しない場合、データベース・マネージャーはそれらを自動的に保守する必要があります。ロールインによってパーティション化索引の保守コストを増やさないために、パーティションのアタッチ操作で REQUIRE MATCHING INDEXES を指定することができます。REQUIRE MATCHING INDEXES を指定すると、ターゲット上のパーティション索引に一致する索引がソース表にない場合、アタッチ操作は失敗します。その後、修正アクションを行ってアタッチ操作を再発行することができます。

さらに、アタッチ操作を実行する前に、ソース表にある余分な索引をすべてドロップしてください。ソース表における余分な索引とは、ターゲット表の索引と一致しない索引、またはターゲット表の非パーティション索引と一致する索引です。アタッチ操作を実行する前に余分な索引をドロップすると、操作の実行が速くなります。

例えば、ORDERS というパーティション表に、(一年の各月に対応する) 12 個のデータ・パーティションがあるとします。毎月終わりに NEWORDERS という別の表が、パーティション化された ORDERS 表にアタッチされます。

パーティション化索引を ORDERS 表に作成します。

CREATE INDEX idx_delivery_date ON orders(delivery) PARTITIONED
CREATE INDEX idx_order_price ON orders(price) PARTITIONED

アタッチ操作の準備として、対応する索引を NEWORDERS 表に作成します。

CREATE INDEX idx_delivery_date_for_attach ON neworders(delivery)
CREATE INDEX idx_order_price_for_attach ON neworders(price)

アタッチ操作には、以下の 2 つのステップが含まれます。
1. ATTACH。 ORDERS 表のパーティション化索引に一致する NEWORDERS 表の索引は保持されます。
```
ALTER TABLE orders ATTACH PARTITION part_jan2009
   STARTING FROM ('01/01/2009')
   ENDING AT ('01/31/2009') FROM TABLE neworders
```
  ORDERS 表は自動的に SET INTEGRITY ペンディング状態に置かれます。アタッチ操作の完了後、idx_delivery_date_for_attach 索引および idx_order_price_for_attach 索引の両方が ORDERS 表に含まれるようになります。この操作中にデータの移動は発生しません。
2. SET INTEGRITY (保全性の設定)。新しくアタッチされたパーティションに対して範囲検査が行われます。制約が存在する場合は、それらがすべて実施されます。完了すると、新しくアタッチされたデータは、データベース内で表示できるようになります。
```
SET INTEGRITY FOR orders IMMEDIATE CHECKED
```

ターゲット表に非パーティション索引が存在する場合、SET INTEGRITY ステートメントでは、新しくアタッチされたパーティションのデータに対する制約の検査や範囲の妥当性検査といった他のタスクに加えて、索引の保守も実行されなければなりません。非パーティション索引の保守では、新しくアタッチされたパーティションのデータ量、それぞれの非パーティション索引のキー・サイズ、および非パーティション索引の数に比例して、大容量のアクティブ・ログ・スペースが必要になります。

ソース表の表スペース ID とオブジェクト ID を使用して、新しいデータ・パーティション上のそれぞれのパーティション索引に関する項目が SYSINDEXPARTITIONS カタログ表に追加されます。ID 情報は (非パーティション表の場合は) SYSINDEXES 表から、または (パーティション表の場合は) SYSINDEXPARTITIONS 表から取得されます。索引 ID は、対応するターゲット表のパーティション索引から取得されます。

ソース表がパーティション化されている場合、ターゲット表のパーティション化索引に一致するソース表のパーティション化索引はアタッチ操作の一部として保持されます。 SYSINDEXPARTITIONS 表の索引パーティション項目が更新されて、新しい索引 ID を持つ新しいターゲット表の索引パーティションとして示されます。

データ・パーティションのアタッチ時に、索引およびデータに関するいくつかの統計が、新規パーティションのソース表からターゲット表に持ち越されます。特に、ターゲット上の新規パーティションに関する SYSDATAPARTITIONS 表および SYSINDEXPARTITIONS 表のすべてのフィールドがソースから移植されます。ソース表が非パーティション化されている場合、これらの統計は SYSTABLES 表および SYSINDEXES 表から得られます。ソース表が単一パーティションから成るパーティション表である場合、これらの統計は単一ソース・パーティションの SYSDATAPARTITIONS 表および SYSINDEXPARTITIONS 表から得られます。

注: 持ち越される統計は SYSINDEXES 表および SYSTABLES 表の集約統計に影響を与えないため、アタッチ操作の完了後に RUNSTATS 操作を実行してください。

SET INTEGRITY...ALL IMMEDIATE UNCHECKED での非パーティション索引の保守。パーティション表に対して SET INTEGRITY...ALL IMMEDIATE UNCHECKED を発行して、新規にアタッチされたパーティションの範囲検査をスキップする場合、XML 列パス索引以外の非パーティション索引が表にあると、SET INTEGRITY...ALL IMMEDIATE UNCHECKED は以下のように振る舞います。

SET INTEGRITY...ALL IMMEDIATE UNCHECKED ステートメントが 1 つのターゲット表を参照している場合、SET INTEGRITY...ALLOW WRITE ACCESS...IMMEDIATE CHECKED ステートメントが発行されたかのように振る舞います。SET INTEGRITY...ALL IMMEDIATE UNCHECKED ステートメントは、すべての非パーティション索引 (ただし、XML 列パス索引を除く) を保守し、その他のすべての整合性処理を実行し、SYSCAT.TABLES カタログ・ビューの CONST_CHECKED 列内にある制約チェック・フラグの値を更新し、制約違反が検出されるとエラーを戻して即時に停止します。
SET INTEGRITY...ALL IMMEDIATE UNCHECKED ステートメントが複数のターゲット表を参照している場合、エラーが戻されます (SQL20209N および理由コード 13)。

SET INTEGRITY での無効なパーティション索引の再作成。SET INTEGRITY ステートメントは、新規にアタッチされたパーティションのパーティション索引オブジェクトが無効であるかどうかを検出できます。無効の場合、必要に応じて、パーティション索引の再作成を実行します。