【実務・中級編】物理再編成 (Reorganization) – 階層型DBMS

階層型DBMSの物理再編成（Reorganization）：ポインタチェインの呪縛を解き放つ夜

おい、設計レビューの手を止めてくれ。
お前たちが今書いているそのスキーマ定義、そして「運用バッチで何とかなるだろう」と楽観視しているデータローディングの設計、本当に大丈夫か？

現代の若手エンジニアは、リ relazioni（関係型）やNoSQLのドキュメントモデルに毒されている。だから、リポポジトリのツリー構造を見ただけで「ああ、親子関係ね」と分かったつもりになる。だが、階層型DBMS（IMS DBやその系譜を引くレガシー、あるいはカスタムツリー型ストア）の本質は「物理的ポインタによるハードコードされた迷宮」だ。

今回は、この階層型DBMSの生命線であり、最もエンジニアの腕が試される領域――「物理再編成（Reorganization）」について、現場の修羅場をくぐり抜けてきた俺が徹底的に叩き込んでやる。

—

1. なぜ階層型DBMSに「物理再編成」が必要なのか？

関係型データベース（RDBMS）であれば、データが断片化（フラグメンテーション）しようとも、オプティマイザが勝手にインデックスを走査し、B-Treeを再構築してくれる。だが、階層型DBMSの世界には「スマートなオプティマイザ」など存在しない。あるのは「物理アドレス（あるいは相対RBA）」と「ポインタチェイン」だけだ。

ツリーの崩壊：物理的近接性の喪失

階層型DBMSの最大の武器は、親セグメントと子セグメント、あるいは兄弟セグメントが物理的に同一あるいは隣接するストレージブロック（OSAMやVSAMのコントロール・インターバル）に配置されること（物理的近接性）による、I/Oコストの劇的な削減だ。

しかし、日々のオンライン処理による「動的挿入（INSERT）」と「削除（DELETE）」の繰り返しは、残酷な現実を招く。

1. レコードの削除: 領域に空き（Hole）ができる。
2. レコードの挿入: 空き領域に収まらない場合、オーバーフローエリアへ飛ばされる。
3. ポインタの分断: 本来、ディスク上で連続しているべきセグメント間が、ポインタを辿るための遠隔ジャンプ（I/Oの発生）を余儀なくされる。

結果として何が起きるか？ 「シーケンシャルアクセスのつもりが、完全なランダムI/Oの嵐と化す」のだ。これが、階層型DBMSにおけるパフォーマンス劣化の正体である。

—

2. 物理再編成のメカニズム：Unload と Reload の死闘

物理再編成の基本プロセスは、シンプルに言えば「一旦すべてをフラットなシーケンシャルファイルに吐き出し（Unload）、きれいなストレージへ理想的な順序で詰め直し（Reload）、ポインタを再構築する」というものだ。

だが、数テラバイトを超える階層型DBにおいて、このバッチをどう安全に回すかが腕の見せ所となる。

思考実験：論理子（Logical Child）と双方向ポインタの罠

単なる親子関係（Physical Parent / Physical Child）の再編成ならまだ易しい。問題は、異なるツリー間を橋渡しする論理関係（Logical Relationship）が存在する場合だ。

[DB A: 顧客ルート]
└── 注文セグメント (Physical)
└── [論理子ポインタ] ──> [DB B: 商品マスタ (Logical Parent)]

この状態で再編成を行う際、単にDB AをReloadしただけでは、DB Bを指していたポインタが無効（あるいはズレたRBA）になる。
そのため、再編成ユーティリティは以下のステップを厳密に踏まなければならない。

1. Unload段階: 既存の物理ポインタに加え、論理関係の「シンボリックキー（論理的なキー値）」を退避データに含める。
2. Reload段階: 新しい物理アドレス空間にセグメントを配置しながら、シンボルを元にポインタを再解決（Resolution）する。

このプロセスを定義するDDLおよびユーティリティ制御文のイメージを見てみよう。

— 【概念的スキーマ定義例】物理構造とポインタの指定
— ※実際のIMS DBD定義などの概念をモダンに表現したもの
DATABASE CUSTOMER_DB (
ACCESS = HDAM, — 乱数づけ直接アクセス法 (Hash)
BLOCK_SIZE = 4096
)
SEGMENT ROOT (
NAME = CUST_ROOT,
BYTES = 128,
PTR = (TWIN) — 兄弟セグメントへのポインタチェイン
)
SEGMENT CHILD (
NAME = ORDER_SEG,
BYTES = 256,
PARENT = CUST_ROOT,
PTR = (TWIN, LPARNT) — 兄弟ポインタ＋論理親ポインタ
);

—

3. 現場で使える堅牢な設計・運用パターン

「夜間バッチで再編成をかければいいや」などと考えているなら、今すぐその甘い考えを捨てろ。24時間365日稼働のシステムにおいて、大規模DBの排他制御とリカバリ戦略はプロジェクトの生死を分ける。

パターンA：世代管理による「オンライン再編成」の模倣

大規模データベースでは、データベース全体を長時間ロックしてのUnload/Reloadは許されない。

対策:

1. データベースを複数の「エリア（Partition / DBNAME）」に分割して設計する。
2. 業務のトランザクションが集中する時間帯を避け、エリア単位でローリング再編成（Rolling Reorganization）を実装する。
3. 再編成中は、アクセスパスを一時的にシャドウエリアへ切り替えるか、変更差分をスプール（JSL等）に溜めてリロード後に適用するアーキテクチャを組む。

パターンB：フリースペース（FSPC）の科学的チューニング

再編成の頻度を最小限に抑える唯一の方法は、「最初から余裕を持たせた配置（Free Space）」を作ることだ。

[コントロール・インターバル (CI)]
+——————+——————+——————+
| セグメントA | セグメントB | [Free Space 20%] |
+——————+——————+——————+

設計指針:
データのINSERT頻度が高いセグメントには、必ず `FSPC`（例: 20%のフリースペース、5%のフリーブロック）を指定しろ。
ただし、無駄にフリースペースを広げすぎると、今度は1ブロックあたりの格納レコード数が減り、シーケンシャルスキャン時のI/O効率が落ちる。過去のトランザクションログから「月間増加率」を算出し、ミリ単位で逆算してパラメータを決めろ。

—

4. パフォーマンス上の注意点とチーフアーキテクトからの警告

最後に、現場でよくある失敗と、それを防ぐための鉄則を挙げておく。

1. 「再編成すれば速くなる」という盲信を捨てろ

HDAM（ハッシュアクセス）を使用している場合、ハッシュアルゴリズムの衝突（Collision）が起きる領域で再編成を行っても、根本的な解決にはならない。根本的な解決は「ルートセグメントのハッシュキー設計の見直し」である。物理再編成は対症療法に過ぎないことを忘れるな。

2. ソートワークスペースの枯渇に備えよ

Reload時には、ポインタを正しく繋ぎ直すために膨大なソート処理が発生する。バッチ実行時のSORTWK（ソート用ワークファイル）の容量見積もりを誤り、夜間バッチが異常終了した時の絶望感を味わいたくなければ、本番同等のデータ量で必ずストレージ負荷テストを行え。

3. 論理エラーの検知（Pointer Checking）を怠るな

再編成ユーティリティの実行後には、必ずポインタチェインの整合性を検証するチェッカー（例: DBVF/DF_PUNCH系ユーティリティ）を走らせろ。これをサボると、数日後に「特定の顧客を検索すると無限ループに陥る（ポインタが自分自身やループを指している）」という悪夢のような障害に直面する。

—

結びにかえて

階層型DBMSの物理再編成とは、いわば「硬化した血管を外科手術で再構築する作業」だ。
データ構造の物理的実体を理解し、ストレージの特性を愛し、ポインタの１本１本に責任を持つ者だけが、このレガシーにして強靭なアーキテクチャを極めることができる。

コードや設定ファイルに向き合うとき、画面の向こう側でディスクヘッドがどう動き、ポインタがどうメモリ上で解決されているか――それを脳内にイメージしろ。

次の設計レビューでは、お前たちの口から「このセグメントのポインタチェイン長とFSPCの根拠は何か？」という鋭い質問が出ることを期待している。さあ、仕事に戻れ。