【テクニカル・上級編】データベースリカバリ制御（DBRC） – 階層型DBMS

IMSの心臓部を鳴らす：DBRC（Database Recovery Control）という名の「絶対的な整合性」

現代のRDBMSが複雑な並行制御や分散トランザクションの迷宮に迷い込んでいる間、我々は半世紀前に完成された、ある種の「神聖な堅牢性」に思いを馳せるべきだ。

IBM IMSにおけるDBRC (Database Recovery Control)。これは単なるバックアップ管理ツールではない。階層型DBMSの心臓部において、物理的なバイナリと論理的なトランザクションの「時空」を同期させ、物理的な障害を論理的な事実として確定させるための、いわば宇宙の調律器である。

今日は、マニュアルの行間を読み解き、なぜDBRCがメインフレームという過酷な環境で生き残ったのか、その内部メカニズムの核心に切り込む。

—

1. RECONデータセット：究極の「真実のソース」

DBRCの要諦はRECON (Recovery Control) データセットにある。これはIMSの全データベースの「歴史」と「現在」を記述した、極めて高度なメタデータストアだ。

なぜRECONが必要か？それは、階層型データベースが物理的なポインタ（Child/Twin Pointer）に強く依存する構造だからだ。RDBMSのようにインデックスを再構築すれば済む世界ではない。物理的なセグメントの物理的配置が壊れれば、論理的なリンクは即座に崩壊する。

DBRCは、以下の極めて低レイヤな情報を常に監視・記録している。

Allocation/Deallocationの全履歴: どのジョブがどのデータセットをオープンし、どの時点で「排他制御」を解除したか。
ログのシーケンス（SLDS/RLDS）: トランザクションのリカバリに必要なログの連鎖を物理的なボリューム単位で管理。
イメージコピーの世代管理: どの時点のバックアップが、どの時点のログと論理的に連結可能か。

2. ログ管理とリカバリの自動化：物理的整合性の強制

DBRCの真骨頂は、リカバリ実行時の「自動判断」にある。リカバリ担当者が「どのテープから復旧するか」を迷う余地を与えない。

DBRCは、ログのシーケンス番号（LSNではなく、IMS特有のRBA: Relative Byte Address）を用いて、物理的なデータブロックとトランザクションログを厳密にマッピングする。

// 内部的なリカバリ・ロジックの概念
IF (Database_State == “NOT_CLOSED_CLEANLY”) {
// 前回の正常終了を示すマーカー（Log Checkpoint）がない場合、
// DBRCはRECONから最後にコミットされたRBAを特定する。
Target_RBA = RECON.GetLastCommitRBA(DB_ID);

// バックアップからリストアした状態に対し、
// ログの差分（Redo/Undo）を論理的に適用する。
Apply_Logs(Start_RBA, End_RBA);

// ここで物理的なポインタの整合性をチェックする
Validate_Pointer_Integrity();
}

このプロセスにおいて、DBRCは「ログの未適用」を許さない。もしバックアップとログの間に穴（Gap）があれば、DBRCは即座にエラーを吐き、データの不整合を未然に防ぐ。これが、現代のNoSQLがしばしば陥る「結果整合性の罠」に対する、メインフレーム側の回答だ。

3. メモリ最適化と排他制御：非同期の重圧をどう捌くか

DBRCは、高頻度のトランザクション下でもオーバーヘッドを最小化するために、徹底したメモリ最適化が施されている。

ローカル・バッファリングと共有メモリ: DBRCはRECONへのI/Oを極限まで減らすため、メモリ上にカタログのキャッシュを持つ。このキャッシュの同期は、z/OSのグローバル・エンキュー（ENQ/DEQ）メカニズムと密接に連携しており、並行する複数のIMSシステム間でRECONを破壊しないための「調停者」として機能する。
物理的ブロックの保護: データベースのオープン時にDBRCがチェックするのは、単なるファイル属性ではない。ログのタイムスタンプと、データセット内の管理ブロックに含まれるタイムスタンプが一致しているかを検証する。これが一致しなければ、物理的な破壊を検知し、即座にオフラインにする。

4. アーキテクトとして見抜くべき「DBRCの真実」

多くのエンジニアは、DBRCを単なる「管理用サブシステム」と見なす。しかし、真のアーキテクトであれば、これが「データベースの可用性を定義する境界線」であることを理解しているはずだ。

物理的破壊の検知: DBRCなしでは、階層型データベースは単なる「壊れやすいデータの塊」に過ぎない。
論理的保全: ログ適用が完了するまでデータベースを「使用不可」として固定するその頑固さこそが、データの絶対的な正しさを担保している。

現代のクラウドネイティブなデータベースは「可用性」のために「整合性」を犠牲にすることが多い。しかし、IMS/DBRCの哲学は逆だ。「整合性」こそが唯一の拠り所であり、それがあれば「リカバリによる復旧」という形で可用性は自ずと導かれるという思想だ。

結びに代えて

DBRCは、過去の遺物ではない。膨大な物理的資産を管理し、何十年もの間、一ビットの不整合も許さずに稼働し続けるための「究極のガバナンス」である。

君たちがもし、将来的に大規模な分散システムを設計する機会があるならば、この「RECON」の思想を思い出してほしい。各ノードで何が起きているか、その歴史を誰が管理し、誰が故障時の「正解」を決定するのか。

その答えが、システムの寿命を決める。

— チーフアーキテクトより