ちょっと待てよ。そもそも今回の要件は，レプリケーションの実現ではない。新国際システムのデータを情報系システムに提供できればよいのだ。極端に言えば，新国際システムの該当DB（20種類）のデータを，毎日全件アンロード（エクスポート）し，それを情報系側で全件ロード（インポート）する方式でもよいのである。
もっとも，この方式では毎日500Gバイトのデータ送信と，情報系側でのロード処理が発生する。そう考えると，あまり現実的ではないのかもしれない。できればレプリケーションと同様に，情報系には差分のみを送信して更新したい。この考えを原点にしつつ，なおかつ脱レプリケーション方式の検討をする必要があった。
解決策は必ずあるはず！
情報系側で差分データの更新を行うプログラムを開発するのは，それほど難しくはない。なんとか基幹系のデータから差分データを作り出す方法さえ見つけられればよい。そこで私は以下のような過程で，複数案を挙げ，その長所/短所/制約を検討してみた。
業務プログラムを変更すれば差分データを作成できる ↓ だがそれでは制約に抵触する ↓ ほかの方法はないのか ↓ 前日分と当日分の全件アンロードを比較すれば，差分データを作成できる ↓ 差分データを作成するための作業用ディスクの余裕はあるのか ↓ ディスクの余裕はある ↓ いつアンロードするのか ↓ バッチ処理終了からオンライン開始までの2時間 ↓ 2時間以内にアンロードできるのか ↓ 到底2時間では全件アンロードできない ↓ バッチ更新がないDBはバッチ処理と並行してアンロードすることも考えられるが， バッチ処理中には追加処理をしてはいけないという制約に抵触する ↓ ほかの方法はないのか ↓ 基幹系のDBMSは，DBからではなく，バックアップ・データからでもアンロードする 機能を備える ↓ それなら2時間以内に全データのバックアップが可能か ↓ 2時間では無理 ↓ ほかの方法はないのか ↓ 新国際システムのDBMSは全バックアップではなく，前回の全バックアップとの差分 だけをバックアップする機能を持つ ↓ それなら2時間以内に差分バックアップできるのか ↓ できる！
行き着いた「ユーザー・レプリケーション方式」
このような詳細検討の末，図1のような構成を作り上げた。決して美しい方法ではない。だが少なくとも「二段階レプリケーション」や「情報系の妥協案」よりは現実味がある。何よりも新国際システムの制約にも抵触しない。
 |
| 図1●行き着いた「ユーザー・レプリケーション方式」 |
これだと「オンライン処理に影響を与えないのか」という疑問を持つ方がいるかもしれない。だが差分バックアップ以降の処理はすべてバッチ処理である。メインフレームでは通常，バッチ処理よりもオンライン処理を優先するので影響はほとんどない。幸い，新国際システムではオンライン時間帯，システム資源に余裕があった。ピークとなる夜間バッチの開始までに情報系への差分送信が完了できれば制約には抵触しないのである。
よしこれでいこう！ 後はお客様に報告するための詳細検討とまとめのみである。この方式は，レプリケーション・ソフトを使用しないレプリケーションという意味で，「ユーザー・レプリケーション方式」と名付けた。
| 宮治 徹（みやじ とおる） 日本IBM アプリケーション・サービス シニアITアーキテクト |
| 1988年に日本IBM入社。主として通信メディア系の大規模SIプロジェクトのSEを歴任。現在はインフォメーション・マネージメント部に所属し，データベース関連を中心としたアーキテクト活動を手掛けている。 |
