Db2 REORGコマンド解説

Db2のREORGコマンドは、データの物理的な再構成（整理整頓）を行い、データベースのパフォーマンスを最適化するための重要なツールです。

1. なぜREORGが必要か？

データの追加・更新・削除を繰り返すと、以下のような問題が発生します：

• 断片化（フラグメンテーション）: データがバラバラに配置され、読み取り効率が低下。
• オーバーフロー・レコード: 更新によって行が長くなり、別のページにデータが跨がってしまう。
• クラスタリング指数の低下: インデックスの順序と物理データの並び順が乖離する。

2. 実行モードの比較

3. 実行中の進捗状況を確認する

進捗を確認する方法は主に2つあります。

A. LIST UTILITIES コマンド

db2 LIST UTILITIES SHOW DETAIL

出力結果の例：

Type                             = REORG
Description                      = Table Reorg
Start Time                       = 2026/03/27 10:00:00
State                            = Executing
Progress Monitoring:
   Completed Work                = 500000 bytes
   Total Work                    = 1000000 bytes
    

• Completed Work / Total Work: 処理済みの量と全体の比率を確認。この例では「50%完了」と判断できます。

B. db2pd コマンド

db2pd -db <DB名> -reorgs

出力結果の例（抜粋）：

Address            TableName          Status      TotalPages   CompletedPages
0x00007F           EMPLOYEE           Started     1000         450
    

• Status: 現在のフェーズ（Started, Sorted, Rebuilding Indexesなど）を詳細に確認。
• Total Pages / Completed Pages: ページ単位でのより細かい進捗率がわかります。

4. 実行時間の見積もりについて

正確な時間は算出できませんが、以下の要素に依存します。

• データ量とインデックス数: 数とサイズに比例して増加。
• LOBデータの有無: ラージオブジェクトが含まれると極端に遅くなる場合があります。

実務では過去の履歴（db2 list history reorg for db <DB名>）を参考にバッファを積んで計画します。

5. 基本的なコマンド例

-- テーブルの再構成
REORG TABLE スキーマ名.テーブル名;

-- インデックスの再構成
REORG INDEXES ALL FOR TABLE スキーマ名.テーブル名;
    

【重要】
REORG実行後は、必ず RUNSTATS を実行して統計情報を更新してください。

6. 実行の判断基準

以下のコマンドで、再構成が必要なテーブルを確認できます。

db2 REORGCHK UPDATE STATISTICS ON TABLE ALL

結果リストの右側にあるフラグ（F1～F8）にアスタリスク（*）が付いているものが、REORG推奨のサインです。

実行タイミングの判断をもっと詳しく（実機ログつきの詳解）

REORGCHK の結果の読み方、インプレースとオフラインの使い分け、REORG直後のバッチがかえって遅くなる落とし穴まで含めた詳しい解説は、Zennのフル記事にまとめています。