【実務・中級編】 GHU/GHN/GHNP (Get Hold Calls) – 階層型DBMS

階層型DBMSの心臓部：GHU/GHN/GHNPによる「排他制御」という名の戦場

諸君、今さらIMSやその末裔たる階層型データベースの話かと思うかもしれない。だが、この「古臭い」はずのアーキテクチャこそが、RDBMSが複雑な抽象化のレイヤーで隠蔽してしまった「データへの物理的な接近」を最も純粋に突きつけてくる。

特に `GHU` (Get Hold Unique), `GHN` (Get Hold Next), `GHNP` (Get Hold Next within Parent) は、単なる読み込み命令ではない。これらは、「このセグメントを今から書き換える」というシステムに対する宣戦布告だ。

今日は、この「Hold系コール」を巡る戦術について、現場で血を流した者だけが知る知見を共有する。

—

階層型DBMSにおいて、データはポインタを介したツリー構造で管理されている。RDBMSのように「行をSELECTして、後からUPDATE」という二段階の操作は、高並列環境では致命的なレースコンディションを生む。

`GHU`系コールは、「読み込み」と「排他ロックの獲得」を不可分な操作（アトミック）として実行する。このコールを発行した瞬間、DBMSはそのセグメントに対して他のプロセスの介入を許さない「占有権」を立てる。これが理解できていないエンジニアは、デッドロックの迷宮に引きずり込まれることになる。

実務では、この3つを適切に使い分けなければ、処理速度（スループット）をドブに捨てることになる。

GHU (Get Hold Unique):
用途: キーを指定したピンポイント更新。
知見: ルートセグメントや、一意な子セグメントへのアクセスに使う。これが最もクリーンだが、過剰に使うとポインタの追い回しでCPU負荷が跳ね上がる。
GHN (Get Hold Next):
用途: 階層全体をスキャンして順次更新。
知見: スキャン範囲を絞り込めない場合、全セグメントをHoldし続けるとロック競合が多発する。「読み込みは通常のGN、更新が必要な時だけGHNに切り替える」というスイッチングの設計が重要だ。
GHNP (Get Hold Next within Parent):
用途: 親配下の子セグメントのみの反復処理。
知見: 階層設計の肝。これを使いこなせば、ツリー全体をスキャンすることなく、特定の親セグメントのコンテキスト内で効率的に更新を行える。パフォーマンスを追求するなら、常にこれを意識せよ。

若手がよくやるミスが、「広範囲のHoldによるロックのインフレ」だ。

PERFORM UNTIL END-OF-FILE
CALL ‘GHN’ USING … > ここで全レコードをロック
PERFORM DO-COMPLEX-CALC > CPU負荷の高い計算をここでやるな！
CALL ‘REPL’ USING … > 更新
END-PERFORM

トランザクションの原則は「Holdしている時間を最小にする」ことだ。

1. GN (Get Next) で対象を検索・特定する。
2. 更新対象のセグメントのキー（または物理アドレス）のみを保持する。
3. GHU (Get Hold Unique) で再取得し、直後に REPL (Replace) を発行。
4. 即座に次の処理へ移る。

この「再取得」という一手間が、実はロック競合を劇的に減らし、システム全体のレスポンスを改善する特効薬になる。

階層型DBMSの最大の武器は「物理的近接性」だ。同じ親を持つ子セグメントは、物理的に隣接して格納されている可能性が高い。

`GHNP` を使用する際、DBMSは内部で「親セグメント」へのポインタを保持し続ける。これを維持できている間、DBMSはルートからの物理的な探索（I/O）をスキップできる。この「ポインタのコンテキスト」を意識したコードを書けるかどうかで、処理時間は桁違いに変わる。

階層型DBMSは、現代の疎結合なアーキテクチャから見れば「制約が強い」と感じるだろう。しかし、その制約こそが、「物理的なデータ配置」を制御できる唯一の武器だ。

`GHU/GHN/GHNP` を使うときは、常に以下の問いを自問自答してほしい。
「今、私はどれだけの範囲をロックしているのか？」
「このロックは、後続のプロセスを止めていないか？」

アーキテクチャを理解するとは、DBMSの内部状態（ポインタやロック管理）を頭の中に可視化することに他ならない。泥臭いチューニングこそが、真のエンジニアリングだ。健闘を祈る。