階層型DBMSの極限：データ再編成（Reorganization）のアーキテクチャと実務戦略
チーフアーキテクトの私だ。今日のコードレビューで、また「物理構造の老朽化を放置したまま、なんとなくインデックスを追加しようとしている」ジュニアのプルリクエストを見かけた。呆れてものも言えない。
リレーショナルデータベース（RDBMS）全盛の昨今において、「階層型DBMS（IMS DBやそれに類するシステム）」を触る機会は絶滅危惧種的かもしれない。しかし、超高スループット、ミリ秒単位の決定論的応答速度が求められる金融・航空系の基幹系システムでは、今なお階層型モデルの物理的局所性は最強の武器として君臨している。
そして、その最強の武器を錆び付かせるか、永遠の切れ味を保つかの分かれ道が 「データベース再編成（Reorganization）ユーティリティの精密なチューニング」 だ。
今日は、教科書には載っていない、現場で泥を食ってきた者だけが知る「階層型DBMSの再編成プロセスにおける極限の知見」を伝授する。
—
1. なぜ階層型DBMSに「再編成」が絶対に必要なのか
RDBMSのB+Treeインデックスとは異なり、階層型DBMSは親セグメント（Segment）と子セグメントが物理的なポインタ（ダイレクトアドレスまたはRBA: Relative Byte Address）で直接結びつけられている。
[根: Root Segment]
│
├── (物理ポインタ) ──> [子: Child Segment A]
│ │
│ └── (物理ポインタ) ──> [孫: Grandchild Segment]
│
└── (物理ポインタ) ──> [子: Child Segment B]
このアーキテクチャの美しさは「JOINがいらない（物理的に隣接しているためポインタを辿るだけ）」という圧倒的な速度にある。しかし、代償もある。
「データの挿入・更新・削除を繰り返すと、物理空間が断片化（Fragmentation）し、オーフロー（Overflow）が発生する」 という致命的な弱点だ。
- 物理的断片化: 削除されたセグメントの空き領域（Free Space）が分散し、新規挿入データが本来あるべき「物理的に連続したブロック」に収まらなくなる。
- ポインタチェインの肥大化: オーバーフロー領域へのジャンプが発生し、I/Oコストが跳ね上がる。
結果として、論理的には同じデータ量であっても、アクセスパスの物理的整合性が崩壊し、システム全体がスローダウンする。これを解消する唯一の手段が「再編成（Unload / Reload）」なのだ。
—
2. 再編成プロセス（Unload/Reload）のメカニズム
再編成の基本フローは以下の通りだ。
1. Unload（アンロード）: 現行の物理データベースから論理順序（Hierarchical Sequence）に従ってデータを順次読み出し、シーケンシャルなバックアップファイルへ吐き出す。この際、無効なポインタや断片化したフリースペースは削ぎ落とされる。
2. Reload（リロード）: 定義された物理スキーマ（DBD: Database Definition）に基づき、最適化された配置で新しい物理スペースへデータを再書き込みする。
この「Reload」の瞬間に、いかに正しい物理パラメータを与えるかが、アーキテクトとしての腕の見せ所となる。
—
3. 実務で直面する設定パラメータと設計パターン
ここからが本題だ。再編成ユーティリティ（例：IBM IMSのHD Reorgユーティリティ等）を設定する際、コードレビューでチェックすべき重要パラメータと、堅牢な設計パターンを解説する。
パターンA: フリースペース（FSE / Free Space）の動的配分設計
よくある悪手は、「とりあえずフリースペースを全体に均一に20%残す」という設定だ。データの増加傾向がルートセグメントとリーフセグメント（最下層）で全く異なるにもかかわらず、一律に設定するのはリソースの無駄遣いでしかない。
DATABASE_REORG:
DB_NAME: “ACCOUNTS_DB”
UNLOAD_METHOD: “HISAM_HDAM”
# ルートセグメント領域: 更新頻度が低いため密に配置
ROOT_SEGMENT:
NAME: “CUST_ROOT”
FREE_SPACE_PERCENT: (5, 5) # (ブロック内空き, 制御ブロック空き)
# 子セグメント領域: 日々のトランザクションで頻繁に挿入・拡張される
DEPENDENT_SEGMENT:
NAME: “TRANS_DETAIL”
FREE_SPACE_PERCENT: (25, 15) # 拡張を見越し、十分な空きを確保
【チーフアーキテクトの知見】
- `TRANS_DETAIL` のような動的セグメントには、直近3ヶ月のインサート量を統計的に算出し、「予測増加量の1.5倍」のフリースペースをあらかじめ確保させろ。
- 過剰なフリースペースは物理的なシーケンシャルスキャン効率を落とすため、パージバッチの頻度とセットで逆算してチューニングすること。
パターンB: ルートアドレスableエリア（RBA/CISIZE）の最適化
HDAM（Hierarchical Direct Access Method）を使用する場合、ルートセグメントはランダム化モジュール（Randomizing Module）によって物理ブロックに割り振られる。ここでのCISIZE（Control Interval Size）の選択が生死を分ける。
; 物理ストレージ定義パラメータの例
[STORAGE_PROFILE]
CI_SIZE = 4096 ; コントロールインターバルサイズ (4KB)
ROOT_ADDRESSABLE_BLOCKS = 50000 ; 仮想バイナリ上のバケット数
MAX_BYTES_PER_ROOT = 300 ; ルートセグメントの最大バイト数
【チーフアーキテクトの知見】
- CISIZEが小さすぎるとI/O回数が増え、大きすぎるとバッファプール（Buffer Pool）のヒット率が低下する。
- 近代のSSD/フラッシュストレージ環境であっても、OSのページサイズやコントローラーのストライピング単位（通常 4KB, 8KB, 16KB）の境界を意識し、「ルートセグメントが1つのCI内に綺麗に収まる（あるいはオーバーフローしない）」サイズに厳密に計算して合わせ込む必要がある。これを怠ると、ランダムアクセスのたびに無駄な物理I/Oが発生する。
—
4. パフォーマンス上の注意点とトラブルシューティング
最後に、現場で障害を起こさないための鉄則を共有する。
1. 排他制御（Locking）と稼働時間窓のジレンマ
- 大規模な階層型DBの再編成は膨大な時間がかかる。オンライン処理が稼働中に強引に再編成をかけるような愚行は厳禁である。
- 対策: パーティショニング（HALDB等：High Availability Large Database）を導入し、DB全体ではなく「ホットスポットとなっているパーティション単位」で分割して再編成を行えるアーキテクチャに最初から設計しておけ。
2. ポインタ検証（Pointer Checking）の省略は「死刑宣告」
- 再編成ユーティリティ実行時に、ポインタの整合性チェック（DFSUDPC0等のユーティリティによる検証）を「時間がかかるから」という理由でスキップする開発者がいる。これは時限爆弾を抱えるのと同じだ。
- 対策: リロード直後には必ずポインタチェインのループ検知・孤立セグメント検知のバリデーションをパイプラインに組み込め。
3. 統計情報の更新（Statistics Gathering）
- 再編成によって物理レイアウトが変わると、オプティマイザ（あるいはアプリケーション側で持つアクセス制御の統計値）が陳腐化する。再編成のスクリプトの最終ステップには、必ず物理統計情報の再収集プロセスをアトミックに含めろ。
—
結びにかえて
階層型DBMSはレガシーではない。それは「極限まで無駄を削ぎ落とした、ハードウェアに最も近いデータ駆動の哲学」だ。
コードレビューで「なぜこのフリースペース値にしたのか？」「なぜこのパーティション分割なのか？」と問われたとき、物理アーキテクチャの根拠をもってロジックを語れないようでは、真のエンジニアとは言えない。
次にデータベースのパフォーマンス低下の兆候を見つけたら、安易な力技のスケールアップに走る前に、物理スキーマの深淵を覗き込み、完璧な再編成計画を叩きつけてやれ。それができる者だけが、真のシステムを統括する資格を持つ。
コメント