Db2のREORGとは ― 読み方とコマンドの書き方、REORGCHKで要否を判断する

REORG（リオルグ）は reorganize の略で、表や索引の中身を詰め直して並べ直す Db2 のコマンドです。更新や削除を繰り返して空きだらけになったページや、行が別ページにはみ出した状態（オーバーフロー）を解消します。この記事の出力は Db2 12.1.4 で採りました。

まず見る（結論）

• 表を詰め直す: db2 "REORG TABLE スキーマ.表"（実行中は表を読めるが書けない）
• 業務を止めずに詰め直す: db2 "REORG TABLE スキーマ.表 INPLACE ALLOW WRITE ACCESS"（非同期で戻る）
• 要るかどうかは db2 "REORGCHK CURRENT STATISTICS ON TABLE スキーマ.表" の REORG 列に * が付くかで見る
• REORG の後は RUNSTATS を流して統計を新しくする（RUNSTATS の記事）
• ALTER TABLE ... DROP COLUMN などの後は REORG しないと表にアクセスできない（SQL0668N 理由コード 7）

REORG で何が変わるか

5万行の表で、3行に1行を長い値に更新し、半分の行を削除しました。

値は SYSCAT.TABLES の列です。オーバーフローした行は、元のページとはみ出し先のページの両方を読むことになり、遅くなります。

コマンドの書き方

スキーマを省くと、接続ユーザーのスキーマ（CURRENT SCHEMA）で補われます。存在しない表を指定すると SQL2211N The specified table does not exist. が返ります。

クラシック REORG は表のコピーを作ってから入れ替えるので、表と同じくらいの空きが表スペースに要ります。表スペースの空きを取り戻すのが目的なら、REORG TABLE スキーマ.表 USE 一時表スペース と一時表スペースを指定します。指定しないと同じ表スペースにコピーを作るため、表は縮んでも表スペースの割り当ては増えることがあります。

$ db2 "reorg table db2inst1.fsv_reorg inplace allow write access"
DB20000I  The REORG command completed successfully.
DB21024I  This command is asynchronous and may not be effective immediately.

DB20000I は「受け付けた」という意味で、終わったという意味ではありません。終わったかどうかは後の「進捗と結果を見る」の方法で確かめます。

REORGCHK で要否を見る

REORGCHK は統計から F1〜F8 の式を計算し、しきい値を外れた式に * を付けます。上の「更新・削除の後」の表で実行した結果です。

$ db2 "reorgchk current statistics on table db2inst1.fsv_reorg"

F1: 100 * OVERFLOW / CARD < 5
F2: 100 * (Effective Space Utilization of Data Pages) > 70
F3: 100 * (Required Pages / Total Pages) > 80

SCHEMA.NAME                     CARD     OV     NP     FP ACTBLK    TSIZE  F1  F2  F3 REORG
----------------------------------------------------------------------------------------
Table: DB2INST1.FSV_REORG
                               25000   4224    747    989      -  3875000  16  48  75 ***

REORG 列の3文字が F1・F2・F3 に対応し、外れた式の位置が * になります。REORG の後に同じコマンドを打つと F1=0・F2=99・F3=100 で --- になりました。

索引は F4〜F8 の5文字で判定されます。この表では F5（リーフページの使用率）と F7（削除済みの RID の割合）が外れて -*-*- でした。クラシック REORG で表を詰め直すと索引も作り直されるので、REORG の後は索引も ----- になりました。

CURRENT STATISTICS はカタログにある統計で計算します。統計が古いと判定も実態とずれるので、先に RUNSTATS を流します。REORGCHK UPDATE STATISTICS にすると RUNSTATS を流してから判定しますが、全表を対象にすると時間がかかります。

進捗と結果を見る

インプレース REORG の状態は db2pd -db データベース名 -reorgs で見ます。終わっていれば Status が Done です。

Table Reorg Stats:
Address            TableName          Start               End                 ... Status  Completion
0x00007FEA14365988 FSV_REORG          10/24/2026 16:30:22 10/24/2026 16:30:24 ... Done    0

SQL で見るなら SYSIBMADM.SNAPTAB_REORG です。

SELECT TABNAME, REORG_TYPE, REORG_STATUS, REORG_COMPLETION
  FROM SYSIBMADM.SNAPTAB_REORG WHERE TABNAME = 'FSV_REORG';

TABNAME      REORG_TYPE                     REORG_STATUS REORG_COMPLETION
------------ ------------------------------ ------------ ----------------
FSV_REORG    RECLAIM+ONLINE+ALLOW_WRITE     COMPLETED    SUCCESS

db2 list utilities show detail に出るのは実行中のものだけです。終わった後は SQL1611W No data was returned になるので、これを「動いていない」と取り違えないようにします。過去に実行した REORG は db2 list history reorg all for データベース名 に開始・終了時刻つきで残ります。

ALTER TABLE の後の SQL0668N 理由コード 7

列の削除など一部の ALTER TABLE は、表を REORG 待ち（REORG PENDING）の状態にします。

$ db2 "alter table FSV_REORG drop column NOTE"
DB20000I  The SQL command completed successfully.
$ db2 "select count(*) from FSV_REORG"
SQL0668N  Operation not allowed for reason code "7" on table
"DB2INST1.FSV_REORG".  SQLSTATE=57007

SYSIBMADM.ADMINTABINFO の REORG_PENDING が Y になっています。クラシック REORG を1回流すと解除され、SELECT が通るようになりました。理由コード 7 以外の SQL0668N は SQL0668N の記事にまとめています。

自動で REORG させる設定

DB CFG の AUTO_REORG を ON にすると、Db2 が要否を判断して REORG を流します。この検証機の既定は OFF でした（AUTO_RUNSTATS は ON）。いつ流れるかを業務の都合で決めたい表が多いなら、自動にせず REORGCHK の結果を見て手で流す運用になります。

どの表をいつ REORG するか（実機ログつきの詳解）

REORGCHK の結果から対象を絞る手順、インプレースとクラシックの使い分け、REORG の直後にかえってバッチが遅くなる落とし穴は、Zenn のフル記事にまとめています。

関連: Db2のRUNSTATSとは ／ SQL0668N

「とりあえず週次で全テーブルREORG」がなぜ問題を招くのか――“なぜ実行するのか”を自分で判断できるようになるための考え方を、本書 第10章「RUNSTATS・REORGを意図して制御する」で詳説しています。