階層型DBMSにおける「イメージコピー」の深淵 —— 物理構造を制する者がリカバリを制する
階層型DBMS（IMS等）において、イメージコピーユーティリティを単なる「データのバックアップツール」と見なしているなら、君はまだこのアーキテクチャの本質に触れていない。
この世界において、データベースの物理レイアウトは単なるデータの箱ではない。ポインタチェーン、セグメントのオフセット計算、そして物理ストレージ上の物理的近接性（Physical Adjacency）そのものが、システムの性能と可用性を決定づける。本稿では、イメージコピーの内部メカニズムを、エンジンアーキテクトの視点から解剖する。
—
1. 物理的整合性の極致としてのイメージコピー
階層型DBMSのデータセット（OSAMやVSAM）は、リレーショナルDBMSのようなページ単位の論理的な抽象化とは異なり、物理的なセグメントIDやRBA（Relative Byte Address）による直接アクセスが前提となる。
イメージコピーの真の役割は、単なるファイルのコピーではない。「物理ストレージ上のポインタ整合性を、ある一点のタイムスタンプにおいて凍結（Freeze）すること」にある。
なぜ「オンライン・イメージコピー」は地獄の技術なのか
多くのエンジニアは「オンラインでコピーが取れるのは便利だ」と言うが、その裏側にある技術的難易度を理解していない。
- バッファ・フラッシュの非同期性: メモリ上の更新済みブロック（Dirty Page）が物理ストレージに書き込まれるタイミングと、スキャン処理が物理ブロックを読み取るタイミングの間に生じる「ズレ」をどう解消するか。
- ポインタの不整合: コピー中に親セグメントのポインタが更新された場合、物理的に矛盾したコピーが出来上がるリスク。
これらを解決するために、エンジンはコピー実行中、内部的に「ログ・シーケンス・ナンバー（LSN）」のバリアを張るか、あるいは物理ブロックのコピーに対して「未確定の変更」をログから適用する、いわゆる「後処理的な整合性担保」を行っている。
—
2. メモリ最適化とスループットのボトルネック
イメージコピーユーティリティの性能を左右するのは、I/Oのアルゴリズムではない。「バッファキャッシュをいかに汚さずに物理層を直叩きできるか」という一点に集約される。
アーキテクトの視点：バッファプールの回避
通常、OSのファイルシステムキャッシュを経由するような素人設計は、大規模な階層型DBでは致命傷になる。
- ダイレクトI/Oの強制: OSのキャッシュ層をバイパスし、DBMSのバッファプール管理テーブルをスキャンせずに、物理ブロックを直接読み取る。
- ストリーミング・スキャン: セグメントの論理的な階層構造を辿るのではなく、物理的なブロック番号順にシーケンシャル・リードをかける。これにより、ディスクヘッドのシーク時間を理論限界まで削り出す。
/ 物理ブロック直叩きの概念的実装 /
void perform_physical_copy(int fd, char buffer, size_t block_size) {
// OSキャッシュをバイパスするフラグ（O_DIRECT）を使用
// 物理的な連続性を維持し、ディスクI/Oのキューイングを最大化する
ssize_t bytes_read = read(fd, buffer, block_size);
if (bytes_read < 0) {
handle_io_error();
}
// ここでバッファを書き出す際、チェックサムを計算し
// 物理的なブロックの破損を後続のリカバリで検知できるようにする
verify_checksum(buffer);
write_to_backup_storage(buffer);
}
---
3. リカバリの起点としての「物理的完全性」
イメージコピーは、後のリカバリ処理において「ベースライン」として機能する。しかし、アーキテクトとしては、このコピーが「再構築可能か」を常に疑う必要がある。
もし物理ディスクが破損していた場合、イメージコピーが正常であっても、その後のログ（チェンジ・アキュムレーション）の適用において物理的なポインタ不整合が発覚することがある。
これを防ぐための極限の知見は以下の通りだ。
1. 二重化の戦略: 物理メディアの劣化を考慮し、必ず複数の物理ドライブへ並行してコピーを走らせる。
2. 検証（Verification）の自動化: コピー完了直後に、全ポインタチェーンを辿る「内部整合性チェック」を物理レベルで走らせる。これが重すぎて実行できないようであれば、設計自体が破綻していると言わざるを得ない。
—
結びに：エンジニアへの提言
階層型DBMSのイメージコピーを運用することは、墓場から記憶を呼び戻す儀式に似ている。物理レイアウトを理解せず、ただツールを回すだけの運用は、いつかシステムが物理的に死んだ時、君を絶望の淵に突き落とすだろう。
「物理層のバイト列は嘘をつかない」
これが、何十年とこのアーキテクチャを回し続けてきた私の結論だ。バックアップのログを見るたびに、その裏側でどの物理セグメントが動いているのか、どのRBAが更新されているのかを想像せよ。それが、システムエンジニアとして極限の信頼性を担保するための唯一の道である。
次回の記事では、このイメージコピーからログを適用する「リカバリの極意」について、トランザクション・ログのバイナリ解剖を交えて解説する。準備しておいてほしい。
コメント