階層型DBMSの心臓部を撃つ：データベースイメージコピーと物理整合性の実務解剖
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、若手が「単にOSのファイルコマンダーでデータベースのデータセットをコピーすればバックアップになるのでは？」と発言したのを聞き、私は思わずコーヒーを吹き出しそうになった。
現代の分散リレーショナルデータベースやNoSQLに慣れ親しんだエンジニアにとって、階層型DBMS（IBM IMS/DBなど）の物理構造は「古臭いブラックボックス」に映るかもしれない。だが、基幹システムの足元を支えるメインフレームの世界において、物理データセットの構造と、それを寸分違わず複製するデータベースイメージコピー（Image Copy）のメカニズムを理解していない者は、障害時に組織を破滅へと導く爆弾を抱えているようなものだ。
今回は、階層型DBMSにおける物理データセットのバックアップの真実と、障害復旧（リカバリ）における整合性確保の極意を、実務の現場で使える知見として徹底的に伝授する。
—
1. なぜ「OSのファイルコピー」では絶対にダメなのか？
階層型DBMSのデータは、OSのファイルシステム上では単なるVSAM（Virtual Storage Access Method）などのリニアなデータセット、あるいはOSネイティブのダイレクトアクセスファイルとして存在している。
ここで素朴な疑問が湧くだろう。「データベースが停止している（あるいは静止点を作った）状態で、`IEBCOPY`や`fcopy`でデータセット丸ごとバックアップすればいいのではないか？」と。
答えは「No」だ。実務において、単純な物理バイト列の複製が通用しない理由は以下の3点に集約される。
1. ポインタチェインの脆弱性
階層型DBMSの本質は、親セグメントと子セグメントを物理的・論理的なポインタ（RBA: Relative Byte Address等）で結ぶネットワーク構造にある。OSレベルのコピーは単なるバイト列の転送であり、DBMS内部の論理的・物理的なポインタ整合性を自律的に検証・再構築する機能を持たない。
2. フリースペース（空き領域管理）のメタデータ不整合
レコードの挿入・更新・削除に伴い発生するフラグメンテーションと空き領域マップ（Bitmap/Free Space Element）の状態は、DBMSのバッファプール内で動的に管理されている。強制的なファイルコピーは、このメタデータと実データの不整合をそのまま凍結する。
3. ロギング（ジャーナル）との同期欠落
オンライン稼働中、DBMSは変更ログ（System Log / Write-Ahead Log）を吐き出しながら動いている。イメージコピーは、単体のファイルスナップショットではなく、ログと完全に同期した「復旧可能な静止点（Point of Consistency）」として取得されなければ意味がない。
したがって、階層型DBMSでは、DBMSのエンジンが介在し、ポインタの健全性を担保しながらデータをシリアライズして出力する専用のイメージコピーユーティリティが不可欠となる。
—
2. 物理構造の整合性確保：イメージコピーのメカニズム
では、実務において堅牢なイメージコピーとはどのように行われるのか。
概念的なイメージコピー処理のジョブ制御言語（JCL）または実行スクリプトの構造を見てみよう。
//IMGCCOPY JOB (ACCT#), ‘IMS DB IMAGE COPY’, CLASS=A, MSGCLASS=X
//STEP1 EXEC PGM=DFSUDMP0, // IMS標準のデータベースイメージコピーユーティリティ
// PARM=’DB=CUSTDB,PART=PART01′
//STEPLIB DD DSN=IMS.SDFSRESL,DISP=SHR
//IMS DD DSN=IMS.DBDFLDS,DISP=SHR
//SYSUDUMP DD SYSOUT=
//DFSRECDD DD DSN=IMS.RECLOG,DISP=SHR // 復旧用ログデータセット
//DBIN DD DSN=PROD.IMS.CUSTDB.A001, // 対象の物理データセット (OS領域)
// DISP=SHR
//DFSUCIN DD
COPY DB=CUSTDB DSN=BACKUP.IMS.CUSTDB.IC001
/
//SYSPRINT DD SYSOUT=
設計レビューのポイント：静止点（Quiesce）の概念
上記のユーティリティ実行時、最も重要なのは「いつコピーを取るか」だ。
オンラインTPモニター（CICSやIMS/TM）が稼働している最中にダーティページを含んだまま物理コピーを走らせると、破損したポインタを持つ「ゾンビバックアップ」が完成する。
堅牢なシステム設計では、以下の手順を厳守する。
1. Quiesce（静止点）の確立：データベースに対する新たな更新トランザクションをブロックし、バッファプール上の全ダーティページを物理データセットへ強制フラッシュ（Force Write）する。
2. イメージコピーの実行：ポインタ構造が完全に安定した状態でユーティリティが走る。
3. ログとの紐付け：このイメージコピー取得時点のログ・シークエンス・ナンバー（LSN / Checkpoint ID）がバックアップヘッダに記録される。
—
3. 障害復旧（リカバリ）の現場：フォワード・リカバリの数理
イメージコピー単体では、バックアップ取得時点までのデータしか戻せない。
真価を発揮するのは、イメージコピー ＋ 変更ログ（Forward Recovery）の組み合わせによるロールフォワードだ。
万が一、ディスク障害等で物理データセットがクラッシュした際の復旧シナリオをコード（擬似的な運用コマンド）で追ってみよう。
1. 物理データセットの初期化と、最新の正常なイメージコピーからのリストア
（前回のフルイメージコピー、または累進バックアップからの復元）
ims-restore –db=CUSTDB –source=BACKUP.IMS.CUSTDB.IC001 –target=PROD.IMS.CUSTDB.A001
2. フォワード・リカバリの実行（ログを適用して障害発生直前まで状態を進める）
ims-recover \
–database=CUSTDB \
–image-copy=BACKUP.IMS.CUSTDB.IC001 \
–log-stream=IMS.RECLOG.VIRTUAL \
–to=LATEST
この時、DBMSのリカバリエンジンは何をしているか？
イメージコピー時点の物理構造に対し、ログに記録された「セグメントの挿入・更新・削除の差分」を時系列順に再適用（Redo）していく。この際、階層構造特有の「親が存在しない状態で子を挿入しようとしていないか」「ポインタチェーンの双方向リンクが正しく張られているか」を厳密に検証しながら処理を進める。
もしこの検証ロジックを無視して単なるファイルの上書き復旧を行うと、孤立したセグメント（ロスト・チャイルド）が発生し、次回起動時にデータベースが致命的な異常検知（Abend）を起こすことになる。
—
4. チーフアーキテクトからの提言：堅牢なバックアップ・設計パターン
実務の現場でインフラ・アーキテクチャを設計する際、以下の3点を必ず設計書に盛り込むこと。
① 世代管理とチェイン・リカバリの罠を断つ
「毎日フルイメージコピーを取れば安全」というのはコストの無駄遣いであり、メインフレームのリソースを圧迫する。
- 標準パターン: 週に1回のフルイメージコピー（Full Image Copy）＋日次の差分イメージコピー（Cumulative / Differential Image Copy）、そしてリアルタイムの変更ログ（Archive Log）の常時退避。
- これにより、リカバリ時は「直近のフル ＋ 差分 ＋ ログ」の最小限のチェーンで復旧時間を最小化（RTOの短縮）できる。
② ポインタ検証（Pointer Checking）の定期実行
イメージコピーを取得する前後に、必ずデータベースの構造検証ユーティリティ（例：IMS DB Pointer Checker）を定期実行する組み込みを行え。
バックアップデータそのものが「構造的におかしなデータ」であった場合、いざという時のリカバリで全工程が水の泡となる。「バックアップの取得＝整合性の検証完了」という方程式を忘れてはならない。
③ ストレージ側のスナップショット（FlashCopy等）との共存
近年のハードウェア（ハイエンドストレージ）は、瞬間的なハードウェア・スナップショット機能を持っている。これを利用して物理データセットを別ボリュームに瞬時に退避させる手法は有効だが、必ずDBMS側でトランザクションの静止（Quiesce）コマンドを発行し、メモリ上のバッファをフラッシュした「その瞬間」にスナップショットを取ること。さもなければ、ストレージスナップショットは単なる「クラッシュしたOSファイル」の山でしかない。
—
結びにかえて
階層型DBMSのデータ構造は、リレーショナルデータベースのような「スキーマの抽象化」の裏で、極めてシビアな物理的整合性の支配を受けている。
「動いているから触らない」「とりあえずファイルをコピーしておけばいい」という甘えは、システムが巨大化し、データが複雑化するほど、障害時のリカバリ不能という最悪の形で牙をむく。
物理を知り、論理を統べる。
それこそが、我々エンジニアが守るべきプロフェッショナリズムだ。次の設計レビューでは、このレベルの整合性担保がアーキテクチャに組み込まれているか、徹底的にチェックさせてもらう。
コメント