階層型DBMSの深淵：論理データベース再編成とポインタ整合性の極意
こんにちは、チーフアーキテクトの私だ。
今日のコードレビューで、誰かが「階層型DBMSの再編成なんて、要はバックアップしてリストアするだけだろ」と軽口を叩いているのを耳にした。
甘い。
リレーショナルデータベース（RDBMS）の頭のまま階層型DBMS（IMS等）の再編成（Reorganization）に挑む者は、必ず深夜の障害対応で泣きを見る。ツリー構造の根幹を成す「物理ポインタ」と、セグメント間をまたぐ「論理ポインタ」が織りなす迷宮を理解していないからだ。
特に、複数データベース間の双方向の論理関係（Logical Relationship）が絡むとき、物理的なアンロードとロードの順序を誤れば、ポインタは容易に宙を舞い、孤児セグメントの山が築かれる。
今回は、実務の現場で絶対に踏んではならない地雷を踏み抜かないための、「論理データベース再編成」の設計パターンと極限の知見を伝授する。
—
1. なぜ階層型DBMSの再編成はこれほど厄介なのか？
RDBMSであれば、外部キー制約とインデックスなど、論理と物理の整合性はオプティマイザやストレージエンジンが自動で担保してくれる。しかし、階層型DBMSの世界では、「ポインタ」という名の生々しいメモリアドレスの鎖を私たちが直接（あるいは定義を通じて）管理している。
物理的なデータセットの再編成（例：HDAM/HIDAMのデフラグメンテーションや、CI/RBAの最適化）を行う際、単一のデータベースであれば、シーケンシャルにロードし直すだけでポインタは再計算される。
しかし、「論理関係（Logical Relationship）」が存在途端に話は変わる。
親セグメント（Logical Parent）と子セグメント（Logical Child）が、全く異なる物理データベース（DBD）に存在する場合、片方だけを再編成しても、もう片方の指し示すアドレス（RBAやLRECL）が狂い、論理ポインタは永遠に見失われる。
—
2. スキーマ定義（DBD）における論理関係の罠
まずは、論理親・論理子を持つスキーマ定義（DBD: Database Definition）の典型例を見てみよう。ここでは、在庫管理DB（INVSDB）の注文セグメントから、顧客管理DB（CUSTDB）の顧客セグメントへ論理ポインタを張るケースを想定する。
- =====================================================================
- 顧客管理データベース (CUSTDB) – 物理親
- =====================================================================
DBD NAME=CUSTDB,ACCESS=HIDAM
SEGM NAME=CUSTOMER,BYTES=100,PTR=TWIN
LCHILD NAME=(CUSTX,INVSDB),POINTER=LOGICAL
- =====================================================================
- 在庫管理データベース (INVSDB) – 論理子を持つ物理DB
- =====================================================================
DBD NAME=INVSDB,ACCESS=HDAM,RMNAME=(DFSHDC40,10,500)
SEGM NAME=ORDER,BYTES=80,PTR=TWIN
- 以下のセグメントが別のDB（CUSTDB）への論理ポインタを持つ
SEGM NAME=CUSTX,BYTES=50,PARENT=ORDER, X
PTR=(LOGICAL,TWIN), X
LCHILD=(CUSTOMER,CUSTDB)
この定義において、`CUSTX` セグメントは `INVSDB` に物理的に属しつつ、`CUSTDB` の `CUSTOMER` セグメントを論理親として仰いでいる。
ここで発生するのが、「ポインタの非対称性」だ。
物理ロード時に、`CUSTDB` と `INVSDB` のロード順序、そしてユーティリティ（DFSURG10 / DFSURDR0など）に与える論理解決パラメータを誤ると、論理ポインタは「Dangling Pointer（宙ぶらりんのポインタ）」と化す。
—
3. 実務で求められる堅牢な再編成プロセス（3ステップの鉄則）
論理関係を含むデータベースを再編成する場合、単に `UNLOAD` して `LOAD` するだけでは不十分だ。以下の厳密なパイプラインを踏む必要がある。
Step 1: 論理関係の解決を伴うアンロード (Prefix Resolution & Update)
論理関係を持つデータベースのアンロード時には、単なるデータ抽出だけでなく、論理子セグメントに埋め込まれた「論理親の物理アドレス（またはシュリンクされたプレフィックス）」の整合性を検証するプレフィックス解決の準備を行う。
//REORG01 EXEC PGM=DFSRRC00,PARM=(ULU,INVSDB)
//STEPLIB DD DSN=IMS.SDFSRESL,DISP=SHR
//DFSDBLIB DD DSN=IMS.DB.RESLIB,DISP=SHR
//SYSUT1 DD DSN=IMS.INVSDB.DATA,DISP=SHR
//DFSURWF1 DD DSN=IMS.WORK.WF1,DISP=(NEW,PASS), <-- プレフィックス作業ファイル
// UNIT=SYSDA,SPACE=(CYL,(50,10))
//SYSPRINT DD SYSOUT=
//SYSIN DD
OPTIONS STAT
/
アーキテクトの知見:
この `DFSURWF1`（Work File 1）こそが、論理関係の命綱だ。ここに論理親を指し示すための解決キーが書き出される。この作業ファイルを破損させたら、その日の夜は徹夜が確定する。
Step 2: プレフィックス解決ユーティリティ (DFSURG10)
複数のDBにまたがる論理ポインタを解決するためには、両方のDBのワークファイルをマージし、ポインタの逆引き（Logical Twin / Logical Parent の双方向リンク）を再構築しなければならない。
//PREFIX EXEC PGM=DFSRRC00,PARM=(UEX,DFSURG10)
//STEPLIB DD DSN=IMS.SDFSRESL,DISP=SHR
//DFSDBLIB DD DSN=IMS.DB.RESLIB,DISP=SHR
//DFSURWF1 DD DSN=IMS.WORK.WF1,DISP=SHR <-- INVSDBのワーク
// DD DSN=IMS.WORK.WF2,DISP=SHR <-- CUSTDBのワーク
//DFSURCDS DD DSN=IMS.WORK.CDS,DISP=(NEW,PASS) <-- 制御データセット
//SYSPRINT DD SYSOUT=
ここで、`DFSURG10` は論理親と論理子のペアを突き合わせ、新しいRBA（Relative Byte Address）やUIR（User-Data-Independent RBA）に基づいたポインタ値を計算し、コントロールデータセット（CDS）に書き込む。
Step 3: 最終ロードとポインタの埋め込み (DFSURDR0)
最後に、ロードユーティリティを使用し、計算済みの正しいポインタをセグメントのプレフィックスに埋め込みながらデータベースを再構築する。
—
4. パフォーマンス上の注意点とアンチパターン
設計レビューにおいて、私が若手エンジニアのコードやJCL（Job Control Language）を見る際、以下のポイントを厳しくチェックしている。これらを破ると、バッチウインドウが爆発的に延びるか、本番障害を引き起こす。
アンチパターン 1: 論理関係のあるDBの「単独・非同期」再編成
「CUSTDBのデータ量が増えたから、CUSTDBだけ週末に再編成しよう」――これを見た瞬間、私はその変更を即座に差し戻す。
論理関係を持つDB群（Inter-related DBs）は、必ず同一のメンテナンスウインドウで同時に（あるいは厳密に定義された順序で）再編成・プレフィックス解決を行わなければならない。片側だけを再編成すると、既存の論理ポインタは無効なアドレスを指し、アプリケーションが異常終了（U0844やU0855などの致命的なABEND）を起こす。
アンチパターン 2: ワークファイル（WF1）の容量見積もり不足
論理関係の解決において、ワークファイル `DFSURWF1` のI/Oはボトルネックになりやすい。
インメモリ（VIOやハイパーバッチ）を活用せず、低速な物理ディスクに直ガケしてI/O待機でバッチが沈没する事故が後を絶たない。データ量が増大している現代のシステムでは、ワークスペースの割り当ては常にピーク時の150%を見積もり、可能であれば高速ストレージプールに配置せよ。
堅牢な設計のためのチェックリスト
1. ポインタタイプの選定: 頻繁に論理親を辿るパスがある場合、`PTR=L(LOGICAL)` だけでなく、必要に応じて `TWIN` や `BACK` ポインタを適切に定義し、走査コストをO(N)からO(1)へ落としているか？
2. カスケード削除の定義: 論理親が削除された際の子の振る舞い（`RULES=(…,RESTRICT)` または `VIRTUAL`）が、業務要件と一致しているか確認したか？ 誤ったカスケード設定は、再編成時のデータ欠損を誘発する。
3. イメージコピープラン: 再編成の前後には必ず `DB Image Copy`（DFSUDMP0）を取得し、万が一の再編成失敗時には即座にロールバック（リストア＋前進リカバリ）できる体制が担保されているか？
—
結びにかえて
階層型DBMSの論理データベース再編成は、単なる「お片付け」ではない。それは、システムが持つ情報のトポロジー（位相幾何学）を一度完全に分解し、再び寸分の狂いもなく縫い合わせるという、極めて高度な外科手術なのだ。
「ポインタの向こう側にいるのは、生きたデータである」――この畏敬の念を忘れないこと。
構造の本質を理解し、ポインタの鎖を意のままに操るエンジニアであれ。君たちの設計レビューを楽しみにしている。
コメント