この章では、一般的なデータ複製構成について説明し、よくある業務要件を満たす複製ソリューションの例を示します。 ここに示す構成では、他の製品で DB2 DataPropagator を活用して固有の複製ソリューションを作成するための方法も示されています。 次々に新しく独創的な実装方法が開発されているため、ここで取り上げる複製構成は、すべてを網羅したものではありません。
重要: DB2 は非同期複製を目的としたものであり、次のような状況には適していません。
業務要件を満たすためにいくつかの構成を組み合わせることができます。 以下において、これらの一般的な構成について説明します。個々の構成には、次のようないくつかのバリエーションが含まれています。
データ分散およびデータ統合は他の構成よりもセットアップと保守が簡単です。
データ配布 構成では、1 次データ・ソースがソース・サーバー上にあります (図 2 を参照)。 データ・ソースに加えられた変更は、分散ネットワーク内にある 1 つまたは複数のターゲット表に複製されます。 ターゲット表は読み取り専用です。したがって、複製中の更新対立は発生しないので、対立検出をセットアップする必要はありません。 アプリケーションではローカル・コピーであるターゲット表を使用して、ネットワーク・サーバーや中央サーバーで過負荷が生じないようにします。 この構成は、いくつかのサイト間でデータを共用する必要があっても、アプリケーションのパフォーマンスを低下させたくない場合に役立ちます。
図 2. データ分散. ソース表に加えられた変更は読み取り専用ターゲット表に複製されます。
![]() |
データ統合 構成では、中央データ・サーバーをリポジトリーとして使用し、たくさんのデータ・ソースからのデータを処理します (図 3 を参照)。 したがって、この構成はたくさんのソース表または視点、および複数のサブセット視点を持つ 1 つのターゲット表で構成されます。 各データ・ソースに加えられた変更は、読み取り専用の中央データ・サーバーに複製されます。
制約事項: 複数サーバーからのデータを 1 つの CCD ターゲット表に統合する場合、 その CCD 表を他のターゲット表の複製ソースとして使用しない でください。 元の複数のサーバーはそれぞれ別個の順序を使用しており、それ以降の複製でそれらを区別できなくなってしまいます。
データ統合構成は、ローカル意思決定支援システム (DSS) を保守して、実動データベース・リソースの競合を招かずにデータを分析したい場合に役立ちます。 更新の対立を回避するには、データ項目ごとに 1 つソースだけがあるように複製環境を設計する必要があります。 各ソースが固有の行セットを更新すれば、更新の対立は発生しなくなります。
図 3. データ統合. 個々のソース表は、読み取り専用ターゲット表にある固有の行セットを更新できます。
![]() |
随時更新 構成では、複製ソースのターゲット表は読み取り / 書き込みコピーです。 ターゲット表に加えられた変更はソース表に適用され、ソース表で最新のデータが保守されます。 ソースとターゲットの間で対立が発生した場合、ソースが優先します。 それから、ソース表への変更がすべてのターゲット表に適用されます。 アプリケーションの設計が正しくないと、 データの複製時に更新の対立が発生する場合があります (図 4 を参照)。 最善なのは、ソースからすべてのターゲット表へデータを複製する時に、 対立が決して発生しないようにアプリケーションを設計することです (図 5 を参照)。 対立を無視したり、対立する更新を拒否したりすることもできます。 対立する更新を拒否すれば、一部の情報を失う可能性があります。
図 4. ターゲット表同士の対立の危険性がある随時更新複製. この構成には対立検出が必要です。ソース表とターゲット表のいずれもすべての行を更新できるからです。
![]() |
図 5. ターゲット表同士の対立の危険性がない随時更新複製. 個々の読み取り / 書き込みターゲット表には、ローカルで更新できる固有の行セットがあります。ソース・サーバーにあるソース表に最新のデータが保守されます。
![]() |
不定期接続 構成では、1 次ソースとの接続およびデータの転送をオンデマンドで柔軟に実行できます。 このタイプの構成では、ユーザーがローカル・データベースの同期に必要な時間だけ 1 次データ・ソースに接続すればよく、 複製管理のために連続接続する必要がありません。(図 6 を参照)。
不定期接続構成はラップトップ・コンピューターやホーム・オフィスでのデータの同期に最適です。 この構成は通信回線接続の頻度と所要時間を最小限に抑え、遠隔通信費用が少なくなるものの、 データの更新が可能です。 このタイプの構成は、ネットワークに常時接続されていないオンサイト・コンピューターへのデータ複製処理 (たとえば従業員が週に 3 日しかオフィスにいない場合) にも適しています。
図 6. 不定期接続構成. ターゲット・サーバーはソース・サーバーに連続的に接続されてはいません。 表に加えられた変更は、ターゲット・サーバーがソース・サーバーに接続された時点で複製されます。
![]() |
DB2 サーバーに不定期接続するサテライト を管理するには、 DB2 ユニバーサル・データベース サテライト・エディション (またはサテライト環境内のその他の DB2 サーバーのいずれか) を使用できます。 DB2 のデータ複製により、 中央の制御サイトと多数のサテライトの間でデータの同期を取ることができます。 ホーム・オフィスにおいて、複製環境をセットアップおよびテストし、 不定期接続システムで運用する準備が整ったら、 これを サテライト・アドミニストレーション・センター・データベースに保管します。 不定期接続システムのいずれかにアクセスする必要はなく、 環境のセットアップは 1 回で済みます。
サテライトのデータ複製のセットアップ方法、 サテライト環境で複製を使用可能にする方法、 およびサテライトで複製のテストを行う方法については、 DB2 ユニバーサル・データベース サテライト管理 手引きおよび解説書 を参照してください。
一般的な複製構成を発展させることにより、特定の必要に合った複製モデルを構築することができます。 ここでは、よくあるいくつかの業務要件と、その要件を満たす DB2 複製ソリューションの例を取り上げます。 各複製ソリューションに特有の設計上の問題も説明します。
要件: DB2-IMS トランザクション管理プログラム (TM) 環境にある顧客は、IMS ログに監査情報を書き込むことによって監査データを生成します。 新しいアプリケーションは DRDA によって DB2 にアクセスし、IMS TM を完全にバイパスします。 顧客は監査目的でリレーショナル表に加えられた変更すべてを記録し、どのユーザーがデータに対して特定の変更を加えたかを判断する必要があります。
複製ソリューション: 収集および変更適用プログラム (DB2 DataPropagator 用) を使って、 ターゲット表に DB2 (OS/390 版) の変更を収集および保管します (図 7 を参照)。
図 7. 監査情報. 監査情報は、顧客のアプリケーションが読み取れるターゲット表に複製されます。
![]() |
設計の特徴: 各行の変更前イメージと変更後イメージの両方の値が収集されて保管されます。 監査表には、データを変更したユーザーの許可 ID も保管されます。 これらの情報はすべて DB2 (OS/390 版) ログから収集されます。
要件:ある大型小売チェーン店は、国内に約 500 店舗を所有し、そのおのおのがコンピューター店頭 (EPOS) システムを介して販売明細を収集しています。 各店舗は、DB2 (AIX 版) 上のローカル・データベースにデータを保管しています。 そのデータは、 事前設定されたファイル転送プロセスを使って EPOS 端末から夜間に中央の DB2 (OS/390 版) サイトに転送されます。 この会社は、データを中央サイトで拡張したいと考えています。
複製ソリューション: DB2 (AIX 版) 上の収集プログラムを使って、 各小売店からのデータ変更を収集および保管します (図 8 を参照)。 DB2 (OS/390 版) 上の変更適用プログラムは全店舗のデータを統合して要約します。
図 8. 分散データベースからのデータの統合. 3 つのソース・サーバーからのデータがターゲット・サーバー上の 2 つのターゲット表に複製されます。
![]() |
設計の特徴: 変更適用プログラムは基礎集約表と変更集約表を使うことによって、統合された保管データを要約します。 基礎集約表はソース・ファイルの内容を要約します。 変更集約表は、変更適用プログラムがターゲットの最新表示を実行してから、 次の最新表示を実行するまでの間に加えられた変更の結果を要約します。
要件: ある小さな銀行が、85 の支店にいくつかの Windows NT クライアント / サーバー・アプリケーションを新たにインストールしました。 この新しいアプリケーションの主なデータ・ソースは、顧客および金融の参照データです。 このデータは抽出されて、1 つは DB2 (OS/390 版)、もう 1 つは DB2 (AIX 版) 上の 2 つの稼働システム内のホスト・サイトに保管されます。 支店がホスト・サイトから直接データにアクセスすると、ネットワーク・トラフィックは混雑し、実動データの可用性が影響を受ける可能性があります。
複製ソリューション: ネットワーク・トラフィックを最低限に抑えるには、データベースのローカル・コピーを各支店で保守します (図 9 を参照)。 したがって、各支店がターゲット・サーバーになります。 変更は DB2 (OS/390 版) と DB2 (AIX 版) から収集されて、DB2 (AIX 版) 上の制御表に圧縮され、夜間に各支店に複製されます。
図 9. リモート・サイトへのデータの配布. ソース・データは AIX サーバー上で圧縮され、支店に複製されます。 各支店はすべての金融データと顧客データの一部を取得します。 各支店がそれぞれの顧客に関係したレコードだけを取得できるようにするには、WHERE 文節を使用します。
![]() |
設計の特徴: AIX には 1 つの変更適用プログラムがあり、DB2 (OS/390 版) および DB2 (AIX 版) からの複製を実行します。 DB2 (OS/390 版) から DB2 (AIX 版) への複製用に 1 つのサブスクリプション・セット、DB2 (AIX 版) から DB2 (AIX 版) への複製用に 1 つのサブスクリプション・セットがあります。
各支店のターゲット・サーバーにも、変更適用プログラムがあります。 ソース・サーバー上の変更適用プログラムは、ターゲット・サーバーにある変更適用プログラムとは別個に実行されます。 各支店の変更適用プログラムは、ホスト・サイトの DB2 (AIX 版) 上の制御表から複製します。 ターゲット・サーバー上の各変更適用プログラムには、ホスト・サイトからローカル・データベースに複製するためのサブスクリプション・セットがあります。 各支店はすべての金融データと顧客データの一部を取得します。 各支店がそれぞれの顧客に関係したレコードだけを取得できるようにするには、WHERE 文節を使用します。
収集および変更適用プログラムは DB2 (AIX 版) 内で完全圧縮 CCD 表を保守します。 管理者は、圧縮 CCD 表を選択しました。このタイプのステージング表には、行に加えられた最新の変更だけが入れられるので、複製中のネットワーク・トラフィックが軽減されるからです。
各支店用のサブスクリプション・セットが作成された時点で、管理者は Windows NT サーバーに制御サーバーを置きました。 管理者が制御サーバーを DB2 (AIX 版) に置いた場合、個々の Windows NT サーバー上の変更適用プログラムは、 サブスクリプション・セットに関する制御情報を読んで更新するためにネットワーク経由でホスト・サイトに接続し、制御情報への変更を検出する必要があります。
要件:ある大型の金融機関が、2 つのレガシー動作システムからその OS/2 ベースの支店への情報の流れを改善したいと考えています。 ローン申請時の調査に役立てたり、クレジット・カードの不正使用を検出したりするために、より正確でタイムリーなデータを提供したいと考えています。 ローン申請用のデータは DB2 (OS/390 版) にあり、クレジット・カードの詳細は IMS システムにあります。 これまでもレガシー・データのコピーは試みられていましたが、その結果は、随時レポートとファイル転送技法が混在していて、うまく動作しないものでした。
複製ソリューション: IMS DataPropagator を使って IMS データへの変更を収集し、DB2 (OS/390 版) の CCD 表に保管します (図 10 を参照)。 DB2 (OS/390 版) への変更を収集して保管するには、収集プログラムを使用します。 保管したデータは活動記録であり、加えられた変更がすべて記録されています。 変更適用プログラムは支店で実行され、IMS および DB2 (OS/390 版) からの活動記録データを使って DB2 (OS/2 版) を保守します。
図 10. リモート・サイトへの IMS データの配布. IMS DataPropagator は IMS データを OS/390 ソース・サーバー上のターゲット表に複製します。 DB2 DataPropagator は OS/390 ソース・サーバーからデータを収集し、そのデータを OS/2 サーバーに複製します。
![]() |
設計の特徴: IMS DataPropagator は IMS ログから変更を収集し、OS/390 ソース・サーバー上に DB2 DataPropagator 形式の非圧縮 CCD 表を作成します。 DB2 DataPropagator はこの CCD 表を複製ソースとして使用します。 OS/390 サーバー上の収集プログラムは、クレジット・カードとローン申請データが入ったローカル表から情報を収集します。 OS/2 ターゲット・サーバー上の変更適用プログラムは、ターゲット表への変更データをプルします。
要件: ある国際的な銀行が、システムをオンラインで 1 日に 24 時間稼働したいと考えています。 そのシステムは現在、オンラインで 1 日に 23 時間 45 分使用されています。 その銀行は毎日システムを停止してバッチ・アプリケーションのために休止しますが、バッチ・アプリケーションにはちょうど 1 日分のデータが必要です。 必要な表は、システムが停止している 15 分の間に抽出されます。 抽出が終わると、システムは翌日の金融業務に使えるようになります。
複製ソリューション: 日中になされたデータ変更を収集し、CCD 表に複製します (図 11 を参照)。 表の抽出ではなく CCD 表の変更を処理するよう、バッチ・アプリケーションを変更します。 バッチ・アプリケーションに整合性のあるデータを提供するためにオンライン・システムが停止する必要はありません。
図 11. 複製されたデータを使用するバッチ・アプリケーション. ソース・データは CCD 表に複製されます。 バッチ・アプリケーションは、ソース表が使用不能の場合に CCD 表からデータを抽出します。
![]() |
設計の特徴: CCD 表には、時間枠 (この場合は 1 日) 内になされた変更を識別するためのタイム・スタンプが入っています。
要件: ある金融機関は、DB2 (AS/400 版) 上の顧客情報データベースから、やはり DB2 (AS/400 版) 上にある意思決定支援システムに更新を複製しなければなりません。 更新に関する活動記録データをコード変更なしで実動アプリケーションに保管および格納しながらも、それらのアプリケーションのパフォーマンスに影響を与えないようにする必要があります。
複製ソリューション: 主要な操作可能表から更新を収集し、それを時間単位で意思決定支援システムの CCD 表に複製します (図 12 を参照)。
図 12. 操作可能データを意思決定支援システムに複製する. 非圧縮 CCD ターゲット表は、ソース・データベースに加えられた変更すべてを記録するために使用します。
![]() |
設計の特徴: 収集および変更適用プログラムは不完全非圧縮 CCD 表を保守します。 非圧縮 CCD 表を使用するのは、この表が顧客情報データベースに加えられた変更すべてを記録するからです。 また、不完全 CCD 表を使用するのは、金融機関がソースの元の内容を記録しないで、変更だけを記録したいと考えているからです。
収集および変更適用プログラムには、複製が実動 CPU リソースに影響を与えないようなジョブ優先順位が指定されます。 意思決定支援システムは、サポートされているどのターゲット・プラットフォームにも簡単に実装でき、必要なら他のプラットフォームに移植することもできます。
要件: ある金融機関はいくつかの支店に数百人の外交員を持ち、支店でオンライン用紙に記入して顧客の会計を設定したり変更したりする必要があります。 外交員は、本店で生成されて支店に送られた情報に基づいて取り引き価格の比率を決定します。 外交員は本店に報告書を送信しますが、会計は本店で情報が検査された後に初めて決済されます。 外交員が最新のデータにアクセスし、中央データベースに直接アクセスしてネットワークの問題が生じることがないなら、外交員の生産性は向上します。
複製ソリューション: レプリカ という特殊タイプのターゲット表を使って、 循環サブスクリプションをセットアップします (図 13 を参照)。 レプリカへの変更は、ユーザー表 である 1 次複製ソースに複製されます。 1 つの場所でなされた更新は、別の場所のデータベースに反映されます。 外交員は顧客との面談中に会計の決済に必要な最新情報を手に入れ、本店にはその日に生成された新しい業務データが入れられます。
図 13. 随時更新複製. 1 次データ・ソース、つまり親レプリカは OS/390 サーバー上にあり、従属レプリカは Windows NT クライアント・システム上にあります。
![]() |
設計の特徴: 1 次複製ソースはユーザー表です。 ユーザー表には最新情報が入っています。
このタイプの複製が最も適しているのは、中央データベースと更新可能コピーの間のトランザクションの対立を回避できる場合です。 たとえば、特定のサイトにおいてはコピーが一定のキー範囲しか更新できない場合や、サイトがある特定の期間しか更新できないような場合です。
DB2 DataPropagator は、ホスト・システムと外交販売員のシステムで同じ行が更新され、どちらの変更も複製されていない場合に生じる対立を検出します。 外交販売員が対立状態の更新操作を実行した場合、データ保全性を確保するため、その更新は複製中に破棄されます。 対立が含まれているトランザクション、および検出されて収集された対立トランザクションに従属するすべてのトランザクションは、バックアウトされます。
要件: ある保険会社は、ふだんは本社に出勤しない販売外交員に商品のセットを持たせ、 新しい顧客にも既存の顧客にもその特別な導入商品と個人別パッケージを勧めたいと考えています。 外交員のコンピューターは大半の時間、本社に接続されていません。 本社に接続する場合は、中央データベースから更新済み情報を取得する必要があります。 変更のバックログの管理が問題になる可能性があります。
複製ソリューション: 販売スタッフには、DB2 ユニバーサル・データベース サテライト・エディションを実行するラップトップ・コンピューターを支給します。 販売キャンペーンが始まると、各外交員は顧客のプロファイルと履歴、および最新商品をダウンロードします。 また、DB2 複製は情報を最新に保つという問題も解決します。 新しい変更済みデータ行だけがネットワークを経由してコピーされます。
設計の特徴: DB2 ユニバーサル・データベース サテライト・エディションを使用するのは、この製品が複製要件を満たしており、中央管理者によって管理できるからです。 本社の管理者は複製環境をセットアップしてテストし、その環境を不定期接続システムにコピーします。 また、現場にいる外交員にユーザー ID とパスワードを提供すれば、その外交員は自分のラップトップ・コンピューターから本社のサーバーに接続できます。 ログオン中、外交員はボタンを押せば、ラップトップ・コンピューター上の情報とソース・サーバーの情報とを同期化できます。
要件: ある製造業者は、 顧客からの注文の処理に Oracle アプリケーションを使用し、 中央操作データ・ストアとして OS/390 上で DB2 を使用しています。 新しい注文情報は、夜間にバッチで抽出され、DB2 にアップロードされます。 顧客の要望に応えて、より迅速な注文処理を実現するため、 この会社ではデータをすぐに複製したいと考えています。
複製ソリューション: Oracle 表に対してトリガーを実行し、 変更レコードを Oracle サーバーの CCD 表に記録することによって、 収集プログラムをシミュレートできます。 DataJoiner のニックネームを使うと、 Oracle ソース表と CCD 表を、DB2 データベースの表のように見せることができます。 こうして、OS/390 上の変更適用プログラムが、 それらの表を DB2 (OS/390 版) 表に複製できるようになります。 営業日に 1 時間ごとに複製を実行するよう、変更適用プログラムを設定します。
図 14. DB2 以外の分散データ・ストアからデータを取り出す. Oracle のソース表に加えられた変更を収集するためにトリガーが使用されます。 DB2 (OS/390 版) 上のターゲット表への複製を行うために DataJoiner が使用されます。
![]() |
設計の特徴: 収集トリガーと Oracle データベースの CCD 表を定義するために、 DataJoiner 複製管理 (DJRA) が使用されます。 DJRA はまた、 すべてのデータベース・オブジェクトとデータ・タイプのマッピングを作成するために SQL ステートメントも生成します。 DataJoiner により、変更適用プログラムは、 IBM 以外のデータに、DB2 のデータであるかのようにアクセスできます。 データをプルするために、DB2 (OS/390 版) で変更適用プログラムを実行することもできます。
要件: ある大型小売チェーン店では、 DB2 (OS/390 版) サブシステムを使用するメインフレーム上で、 ビジネス・オペレーション・アプリケーションを使用しています。 スタッフと本部の職員は、操作データを照会してレポートを作成する必要があります。 小売チェーン店では、照会とレポートに必要なデータを、 UNIX サーバー上の Informix データベース管理システムに複製することを考えています。 この小売チェーン店では、 過去 4 時間未満のデータに基づくレポートおよび照会の結果が必要とされています。
複製ソリューション: 収集プログラムは、 操作データに対して加えられた更新を DB2 (OS/390 版) 表に挿入します。 サブスクリプションのタイミング間隔を 4 時間に設定し、 現在の操作データに基づく照会の結果とレポートが得られるようにします。 変更適用プログラムは、DataJoiner のニックネームを使用することにより、 更新を DB2 表から Informix データベースの照会およびレポート表に複製します。
図 15. 操作データを DB2 以外のレポートおよび照会データベースに複製する例. DB2 (OS/390 版) のソース表に加えられた変更は、収集されると、 DataJoiner で定義されたニックネームを使用して Informix 上のターゲット表に複製されます。
![]() |
設計の特徴: 正しい Informix データ・タイプを使って Informix 上にターゲット表を作成するため、 DataJoiner 複製管理 (DJRA) が使用されます。 変更適用プログラムは、データを Informix に複製する時、 DataJoiner のニックネームと必要なデータ・タイプ変換を使用します。