表を再編成する方式の選択

表の再編成には、次の 4 つの方法があります。 CLASSIC 再編成 (オフライン)、 INPLACE 再編成 (FULL: スペースを再クラスタリングまたは再利用)(オンライン)、 INPLACE 再編成 (CLEANUP OVERFLOWS: オーバーフローのクリーンアップのみ)(オンライン)、RECLAIM EXTENTS (オンライン)。

オフライン (つまり CLASSIC) 再編成がデフォルトの動作です。 オンライン再編成操作を指定するには、REORG コマンドの、FULL を指定した INPLACE 節、CLEANUP OVERFLOWS を指定した INPLACE 節、または RECLAIM EXTENTS 表節を使用します。

それぞれの方法には、以下のセクションに要約されているように利点と欠点があります。 再編成の方法を選択するときは、どの方法がユーザーの優先順位に適合する利点を備えているか考慮してください。 例えば、影響を受けるオブジェクトの利用不能時間を短くする必要がある場合は、オンライン再編成が望ましいでしょう。 再編成操作に必要な時間を短くすることを優先する場合は、オフライン再編成の方が望ましいかもしれません。

CLASSIC 再編成の利点

この方法では以下の利点があります。
  • 最も高速な表再編成操作。特に、ラージ・オブジェクト (LOB) またはロング・フィールドのデータが含まれていない場合に当てはまります。
  • 完了時に表と索引が完全にクラスター化されている。
  • 表の再編成後に索引が自動的に再作成される。索引の再作成のための別個のステップはありません。
  • TEMPORARY 表スペースを使用してシャドー・コピーを構築する。 シャドー・コピーを使用すると、ターゲットの表や索引を格納する表スペースのスペース要件が削減されます。
  • データを再クラスタリングするために、クラスタリング索引以外の既存の索引を使用できる。

CLASSIC 再編成の欠点

この方法には、以下の特徴があります。
  • 表アクセスが限られている。REORG 操作のソートと作成フェーズで可能なのは読み取りアクセスのみです。
  • 再編成されている表のシャドー・コピーに関するスペース要件が大きい。
  • REORG プロセスを十分に制御できない。オフライン REORG 操作を一時停止して再始動することはできません。
  • 操作全体が 1 つの作業単位で処理されるため、大規模なアクティブ・ログが必要になることがある。

FULL オプションを指定した INPLACE 再編成の利点

この方法では以下の利点があります。
  • すべての表アクセスが可能。ただし、REORG 操作の切り捨てフェーズの間は除きます。
  • REORG プロセスを十分に制御できる。バックグラウンドで非同期的に実行されるため、一時停止、再開、または停止が可能です。 例えば、表に対して更新や削除が大量に実行される時に、進行中の REORG 操作を一時停止できます。
  • 万一の失敗時には、プロセスを再開できる。
  • 表が徐々に処理されるので、作業用ストレージに対する要件が軽減する。
  • REORG 操作が完了する前でさえ、再編成の利点をすぐに活かせる。

FULL オプションを指定した INPLACE 再編成の欠点

この方法には、以下の特徴があります。
  • REORG 操作時に表にアクセスするトランザクション・タイプによっては、データまたは索引のクラスター化が不完全になる。
  • オフライン REORG 操作に比べてパフォーマンスが低い。
  • ロギング要件が高くなる可能性がある。 要件は、移動される行の数、表に対して定義される索引の数、それらの索引のサイズに応じて決まります。
  • 索引は保持されているが再作成されていないので、後に索引再編成を行う必要性が生じる可能性がある。
  • オンライン再編成で内部レコードを移動できないため、スペース再利用が不完全になる。

CLEANUP OVERFLOWS オプションを指定した INPLACE 再編成の利点

この方法では以下の利点があります。
  • すべての表アクセスが可能。
  • REORG プロセスを十分に制御できる。バックグラウンドで非同期的に実行されるため、一時停止、再開、または停止が可能です。 例えば、表に対して更新や削除が大量に実行される時に、進行中の REORG 操作を一時停止できます。
  • 万一の失敗時には、プロセスを再開できる。
  • 表内に存在するすべてのポインターとオーバーフローのペアが修正されるため、表に対する SQL アクセスのパフォーマンス特性が改善される。
  • 表が徐々に処理されるので、作業用ストレージに対する要件が軽減する。
  • REORG 操作が完了する前でさえ、再編成の利点をすぐに活かせる。
  • INPLACE 再編成では、FULL オプションを指定する場合よりも、ロギング要件や悪影響が全体的に低い。

CLEANUP OVERFLOWS オプションを指定した INPLACE 再編成の欠点

この方法には、以下の特徴があります。
  • ポインターとオーバーフローのペアを解決する以外のメリットがない。 このモードは、表に多数のポインターとオーバーフローのペアが存在し、これらのペアがパフォーマンスに悪影響を与えている場合にのみ使用してください。

RECLAIM EXTENTS の利点

この方法では以下の利点があります。
  • すべての表アクセスが可能。
  • 万一の失敗時には、プロセスを再開できる。 障害の発生時点までの作業が失われません。 障害の発生時点から操作が再開され、最後まで実行されます。
  • 操作が軽量。
  • スペースが解放されて表スペースに戻されるため、表スペースを必要とする他の操作でそのスペースを利用できる。
  • 表が徐々に処理されるので、作業用ストレージに対する要件が軽減する。

RECLAIM EXTENTS の欠点

この方法には、以下の特徴があります。
  • データが再クラスタリングされない。
  • 表内に存在するすべてのポインターとオーバーフローのペアを修正することをしない。
  • 既存のすべての行を現在の表スキーマに変換することをしない。
  • 索引は保持されているが再作成されていないので、後に索引再編成を行う必要性が生じる可能性がある。
表 1. オンライン再編成とオフライン再編成の比較
特性 CLASSIC 再編成 FULL を指定した INPLACE 再編成 CLEANUP OVERFLOWS を指定した INPLACE 再編成 RECLAIM EXTENTS
パフォーマンス 高速 低速 高速 高速
完了時のデータのクラスター係数 良い 完全にはクラスタリングされない クラスタリングは実行されない クラスタリングは実行されない
並行性 (表へのアクセス) アクセスなしから読み取り専用の範囲 読み取り専用からフルアクセスの範囲 読み取り専用からフルアクセスの範囲 アクセスなしからフルアクセスの範囲
データ・ストレージ・スペース所要量 大きい 大きくない 大きくない 大きくない
ロギング・ストレージ・スペース所要量 大きくない 大きくなることがある 大きくなることがある 大きくなることがある
ユーザー制御 (処理を一時停止/再開できるかどうか) あまりよく制御できない よく制御できる よく制御できる あまりよく制御できない (一時停止/再開できない)
リカバリー可能性 リカバリー可能。ただし、オンライン再編成より時間がかかることがある リカバリー可能 リカバリー可能 リカバリー可能
索引再ビルド 行われる 行われない 行われない 行われない
すべてのタイプの表のサポート はい いいえ いいえ いいえ
クラスタリング索引以外の索引を指定する機能 はい いいえ いいえ いいえ
TEMPORARY 表スペースの使用 はい いいえ いいえ いいえ
表 2. オンライン再編成およびオフライン再編成に関してサポートされる表タイプ
表タイプ オフライン再編成のサポート オンライン再編成のサポート
マルチディメンション・クラスタリング表 (MDC) はい 1 あり 8
挿入時クラスタリング表 (ITC) あり 1, 7 あり 6, 7
範囲がクラスター化された表 (RCT) いいえ 2 いいえ
付加モードの表 はい いいえ3
ロング・フィールドまたはラージ・オブジェクト (LOB) データのある表 あり 5 はい 5
システム・カタログ表:
  • SYSIBM.SYSCODEPROPERTIES
  • SYSIBM.SYSDATATYPES
  • SYSIBM.SYSNODEGROUPS
  • SYSIBM.SYSROUTINES
  • SYSIBM.SYSSEQUENCES
  • SYSIBM.SYSTABLES
  • SYSIBM.SYSTABLESPACES
  • SYSIBM.SYSVARIABLES
 はい いいえ
注:
  1. クラスター化は MDC ブロック索引経由で自動的に維持されるため、MDC 表の再編成にはスペース再利用のみが関係します。 指定できる索引はありません。 同様に、ITC 表では、クラスタリング索引を使用して再編成を指定することはできません。
  2. RCT の範囲域は常にクラスター化されたままになります。
  3. オンライン再編成は、付加モードが使用不可になってから実行できます。
  4. ロング・フィールドまたはラージ・オブジェクト (LOB) データの再編成にはかなりの時間がかかる可能性があり、照会パフォーマンスが向上することはありません。 再編成は、スペース再利用のためにのみ行います。
  5. オンライン表再編成では、LONG/LOB データは再編成されませんが、その他の列は再編成されます。
  6. ITC 表のオンライン再編成がサポートされます。 再編成は、REORG コマンドの既存の RECLAIM EXTENTS 表節を使用して実行します。
  7. REORG コマンドの RECLAIM EXTENTS 表節では、疎エクステントが暗黙的に統合されます。 この統合により、スペース再利用が増加しますが、 Db2® バージョン 10.1と比較すると、ユーティリティー実行の所要時間が長くなります。
  8. RECLAIM EXTENTS を使用する場合はサポートされません。
注:

INPLACE 再編成の代替手段として、オンライン表移動ストアード・プロシージャーを使用できます。 ADMIN_MOVE_TABLE プロシージャーを使用したオンラインでの表の移動を参照してください。

XML 列のある表の場合、従来の表再編成は、システム生成の XML 索引を再作成する必要があるので、終了するまでに長時間かかる可能性があります。 表内のすべての文書を全探索する必要があります。 この間、表にはアクセスできません。 したがって、一般的にはインプレース表再編成が推奨されています。システム生成の XML 索引を再作成する必要がなく、再編成中 (切り捨てフェーズを除く) も表に引き続きアクセスできるからです。

表再編成の進行状況のモニター

表 REORG 操作の現在の進行状況は、履歴ファイルに書き込まれます。 履歴ファイルには、 それぞれの再編成イベントに関するレコードが含まれます。 このファイルを表示するには、再編成の対象となっている表が格納されているデータベースに対して LIST HISTORY コマンドを実行してください。

このほか、表スナップショットを使用して、表 REORG 操作の進行状況をモニターすることもできます。 表再編成モニター・データは、データベース・システム・モニター表スイッチの設定値にかかわらず記録されます。

エラーが発生した場合、SQLCA メッセージが履歴ファイルに書き込まれます。 INPLACE の表 REORG 操作では、状況は PAUSED として記録されます。

再編成された表がない場合は、モニター・ユーティリティーによりモニター・データが戻されません。