DPropRのご紹介

Comments

1.DPropRとは?

(1)データ・レプリケーション・ソリューションでのDPropRの役割
データ・レプリケーション(複製)とは、複数の場所にある定義済みデータの集まりを保守するためのプロセスです。具体的には、特定の変更内容をある場所(ソース)から別 の場所(ターゲット)にコピーしたり、それら2つの場所にあるデータを同期化したりすることを指します。このソースおよびターゲットの場所としては、分散ネットワーク内の同じマシンまたは異なるマシン上にある論理サーバー(DB2データベース、DB2(OS/390版)サブシステム、またはデータ共用グループなど)が可能です。
DPropR(正式名:D ata P R O P agator R elational以下DPropRと記述します)は、IBMの代表的なデータ複製ツールです。DPropRは、SQL、およびDRDAといった業界標準の上に構築でき、大規模企業データへのアクセスをサポートします。DPropRは、DB2を代表とするリレーショナルデータベースだけでなく、DataHub、DataJoiner、DataRefresher、およびDataPropagatorNonRelationalといった他製品と組み合わせて使うと、IMS、およびVSAMなどのホスト上のクラシカルなデータベースから、データを抽出・格納することができます、また、Oracle、およびSybaseといった、非IBMの製品データベースとの間でデータ複製をすることもできます。
DPropRの主な特徴としては、

  • プラットフォーム共通の一貫したアーキテクチャを実装
  • 差分複製の際、複写元となる表にはアクセスせず、DB2のログから変更分を取り出すため、複写 元表を利用している既存のアプリケーションへの影響が少ない
  • 複製は非同期で行われるため、複写元表に対する更新は複製処理に影響されない
  • 複製のタイミングは連続処理から1年間隔まで、またはイベント起動による複製も使用できる
    全件フルリフレッシュが可能

があげられます。

(2)データ・レプリケーション環境のサポート
DPropRはDB2ファミリー、IMS、VSAM、Oracle、Sybase、MicroSoftSQLServer、Teradata、LotusNotesの各データリソース間でのデータ複製をサポートすることにより、企業内でのタイムリーで、かつ一貫したデータ管理を実現します。DPropRは以下のように、データ複製での異種接続をサポートします。

  • DPropRで実装されているアーキテクチャーは、業界標準であり、格納するデータタイプの拡張、インターネットへの接続性、およびデータの安全保護の点から常に改良・改善され続けているSQL上に構築されています。
  • DPropRではデータステージングエリア(しくみについては後述)を設けることにより、マルチ・ベンダーのデータベース間、および異種のデータ・モデルの間での、データ運用を可能にします。IBMのIMS DataPropagator、およびDataRefresher製品を併用することにより、IMS、VSAM、およびフラット・ファイルのクライアント/サーバー間での複製が可能になります。
  • DPropRは、DataJoinerと併用することにより、Oracle、Sybase、MicroSoftSQLServer、Teradataおよび他のデータベースに透過的なアクセスを実現します。
  • DPropRは、Lotus Notes Pumpと併用することにより、Lotus Notes Pumpがアクセス可能なLotus Notes、およびLotus ApproachやMicroSoft Accessに代表されるようなオープン・データベースへの接続およびデータ複製を可能にします。

次の図では、DPropRを中心としたIBMのデータ・レプリケーション・アーキテクチャーをご紹介しています。

 
DPropRを中心としたIBMのデータ・レプリケーション・アーキテクチャー図
DPropRを中心としたIBMのデータ・レプリケーション・アーキテクチャー図

2.データ・レプリケーションの構成要素

(1)概要
DPropRは、Administration(管理インターフェース)、Capture(変更収集メカニズム)、Apply(変更適用プログラム)の3つの要素で構成されています。それらは主に次のような働きをします。
Administration :GUIのツールで複製基準を保管する制御表を作成するために使用する
Capture :ソース・データベースで発生する変更をLOGから随時収集し、一時的に変更データ表(ステージング表)に書き出す
Apply :変更データ表から変更データを読みとり、ターゲットとなる表に変更を反映する

これら3要素の関連は下記の図のようになっています。

 
DPropR3要素図
DPropR3要素図

以下のセクションでは、複製要求を管理する制御表、DPropRが稼働する各データベース・サーバー、上述の3つの構成要素(Administration、Capture、Apply)とその相互間の通 信方法について説明します。

(2)制御表
レプリケーション構成要素は制御表を使用して、相互に通信したり、各レプリケーション・タスク(ソースおよびターゲット・データベースの管理、変更情報の収集、変更情報の複製、反映された変更情報の数と未反映の変更情報の数のトレースなど)を管理します。
Captureは、例えば、登録情報、UOW情報、制御表およびロック表のクリーンアップ情報、ウォーム・スタート情報、チューニング・パラメーター情報、および変更データ情報などを制御表から取得します。
Applyは、例えば、登録情報、UOW情報、制御表およびロック表のクリーンアップ情報、サブスクリプション(注参照)に関するさまざまな情報、変更適用トレース情報、および変更データ情報などを制御表から取得します。
注:サブスクリプションとは、Applyが必要とする情報を全て含んだ定義体であり、Applyが行うレプリケーションの行為そのものを指すこともあります。

(3)DPropRが稼働する各データベース・サーバー
DPropRが稼働するデータベース・サーバーには、以下の3種類があります。

ソース・サーバー:ソース・サーバーとは、複写元の表が存在するデータベース・サーバーであり、Captureおよび収集プログラム用の制御表(Applyもこれを使用)が存在します。1つのソース・サーバーには1つのCaptureが稼働します。Captureはソース・サーバーにとってのローカルアプリケーションとなります。

ターゲット・サーバー:ターゲット・サーバーとは、複写先の表が存在するデータベース・サーバーであり、Applyが存在します。Applyはターゲット・サーバーにとって、ローカルアプリケーションでもリモートアプリケーションであっても構いません。1つのターゲット・サーバーに対して複数のApplyを同時稼動させることも可能です。

コントロール・サーバー:レプリケーションの制御情報を保管するデータベース・サーバーであり、Applyが稼動時に複製に関する各種情報を検索します。一部の制御情報はソース・サーバーにも保管されます。ターゲット・サーバーあるいはソース・サーバーと同一のデータベース・サーバーであっても構いません。

Applyは、ネットワーク内の上記データベース・サーバーのいずれかに置くことができます。各Applyはそれぞれ1つのコントロール・サーバーに関連付けられ、Applyの開始時にはそのコントロール・サーバーを指定します。複数のApplyで1つのコントロール・サーバーを共用することができます。

下記は3つのデータベース・サーバーの関係を表した図です。

 
データベース・サーバーの関係図
データベース・サーバーの関係図

(4)DPropRの3つの構成要素 : Administration
Administrationは複製基準を保管する制御表を作成するためのGUIツールですが、ユーザー・インターフェースとして、DB2コントロール・センターとDataJoiner Replication Administration(DJRA)の2つがあります。
DB2コントロール・センター:DB2サーバー間のデータ複製を管理するためのデータベース管理ツールです。このツールを使用すれば、ターゲット・コピー情報を指定する際にターゲット表および制御表の作成など、多くの初期設定機能が自動化できます。

DJRA:さまざまな複製管理作業を実行するために使用できるデータベース管理ツールです。このツールはDB2相互間の複製にも使用できますが、環境にIBM以外のデータベースが含まれる場合には必ずこちらを使用してください。

(5)DPropRの3つの構成要素:Capture
Captureは更に下記の2つの機能から構成されます。
収集プログラム:収集プログラム:DB2表をソースとして持つ場合にソースに加えられた表の変更を収集します。収集プログラムは、データベース・ログを使って、ソース・データベースに加えられた変更を収集し、それらの変更を一時的にステージング表に保管します。収集プログラムはソース・サーバーで実行されます。一般 にこのプログラムは継続的に実行しますが、ユーティリティーの実行中またはレプリケーションソースの変更中には停止することができます。収集プログラムは、DB2(MVS版)4.1以降およびDB2ユニバーサル・データベース上の活動状態のアクティブ・ログあるいはアーカイブ・ログから、変更およびコミットされた情報を取り出します。収集プログラム(VSEおよびVM版)5.1は、DB2(VSEおよびVM版)上のアクティブ・ログだけを読むことができます。

収集トリガー:ソース表が非IBMデータベースである場合、ソースに加えられた変更を収集するのは収集トリガーです。収集トリガーは、特定のデータベース・イベント(UPDATE、INSERT、DELETE)が発生した場合に起動します。前述のDJRAは収集トリガーを自動的に作成します。それらのトリガーは、定義済み複製ソースとして定義されている表に加えられた変更を収集して、その変更を一時的にステージング表に保管します。

(6)DPropRの3つの構成要素:Apply
Captureは更に下記の2つの機能から構成されます。
Applyはソース表または視点からデータを直接読み、ターゲット表に初期データを入れます。ソース表がIBM以外のデータベースである場合、ApplyはDataJoinerに定義されたテーブルのニックネーム名を使ってデータを読みます。変更を反映する場合、Applyは、ステージング表に一時的に保管されている変更済みデータを読んで、変更をターゲット表に適用します。
Applyは一般的にはターゲット・サーバーで実行されますが、ソース、コントロール、およびターゲット・サーバーと接続できる、ネットワーク内の任意のサーバーでも実行できます。複数のApplyを、同じまたは異なるサーバーで実行することができます。各Applyは、同じ許可IDを使用して実行したり、異なる許可IDを使用して実行したり、Applyのグループの一部として実行したりできます(グループ内の各Applyが同じ許可IDを使用して実行される場合)。
Applyはそれぞれ1つのコントロール・サーバーにひも付けされます。このサーバーには、サブスクリプション・セットの定義を収めた制御表が入っています。制御表は、複数のApplyによって共用できます。たとえば、ソース・サーバーが1つ、ターゲット・サーバーが2つある場合、それぞれのターゲット・サーバーで別 々のApplyを実行することができます。これら2つのApplyは、制御表を共有できます。その制御表には、それぞれのApplyに関連した特定の情報が収められることになります。

(7)3つの構成要素の相互通信方法
各構成要素は互いに独立しているので、制御表に保管される情報に応じて相互に通 信します。Capture(収集プログラムおよび収集トリガー)、Applyは、複製の進行状況を制御表に書き込み、その進行状況を調整します。各構成要素の通 信方法は、ソース・サーバーがDB2データベースか非IBMデータベースかによって異なります。
DB2データベース間での複製の場合、Captureは、サーバーのログまたはジャーナルを読むことによって、ソース表内のデータに加えられた変更を収集します。その後、Captureは変更をCD(Change-Data)表という表に挿入します。
非IBMデータベースの場合は、収集トリガーが変更を収集し、CCD(Consistent-Change-Data)表に保管します。
Applyがデータをターゲット・データベースにコピーするたびに、ターゲット・データベースの内容にはソース・データベースに加えられた変更が反映されます。Applyは、Applyが最後に実行された後に累積されたトランザクションを適用して処理を実行します。また、Applyは各ターゲットに加えた最後の更新を記録します。
後述しますが、CCD表はDB2データベース間での複製の場合にもターゲット表として、使用することができます。

(8)収集プログラムによる差分更新のしくみ
収集プログラムは制御表の一部を使って、ソース・データベースに加えられた変更を記録し、Applyはそれらの制御表の値を使ってターゲット・データベースにコピーする必要がある情報を検出します。
レプリケーションを始める前に以下の手順で収集プログラムとApplyを開始します。

  1. 1つ以上の複写元のソースを定義しておきます。
  2. 収集プログラムを開始します。収集プログラムは開始と初期設定が完了しても、Applyからの収集の指示を受けない限り、情報を収集しません。また、Applyよりも先に開始を完了しておかなければなりません。
  3. 1つ以上のサブスクリプション・セットを定義しておきます。Applyは、複製ソースおよびそれに関連するサブスクリプション・セットが定義されるまで、収集プログラムに変更収集開始の指示を出しません。
  4. Applyを開始します。すべての新しいサブスクリプション・セットに関し、Applyは、まずソース表からターゲット表に全てのデータをコピーすることによって、ターゲット表とソース表の同期をとります。このアクションは、フルリフレッシュコピーと呼ばれます。フルリフレッシュコピーが終わると、収集プログラムはソースに対する変更情報の収集を開始します。

以下に、収集プログラムによる差分更新のしくみについて説明します。

  • ソース・データベースからデータを収集する
    1. 収集プログラムは制御表の中の登録情報を読んで、変更の収集を開始する必要がある複製ソースを判別 します。収集プログラムの実行中に新しい複製ソースが定義された場合、再初期設定するか、収集プログラムが停止されて再始動されない限り、収集プログラムは新しい複製ソースを認識しません。
    2. 収集プログラムは、DB2ログまたはジャーナルをモニターして、複製ソースとして定義されているソース表から変更レコードを検出します。
    3. 収集プログラムは、DB2ログまたはジャーナルで検出した変更ごとに、1つの行(または更新がDELETEまたはINSERT操作として保管された場合は2行)をCD表に追加します。複製ソースごとに1つのCD表があります。
    4. 収集プログラムは、コミット済みトランザクションに関するUOWの情報を制御表に保管します。この制御表の各行は、ソース・サーバー内でコミットされた各トランザクションに相当します。UOW情報の表はDB2ソース・サーバーごとに1つずつ持ちます。
    5. 収集プログラムは制御表の登録情報を更新して、複製ソースごとに収集されたコミット済みデータの量 を記録します。
  • 変更情報をターゲット・データベースに反映する
    6. 複製予定のサブスクリプション・セットがある場合、Applyは制御表の登録情報を調べて、複製しなければならない変更があるかどうかを判断します。
    7. Applyは制御表のプルーニング情報を更新して、CD表内のソース表に対する変更情報の同期をとります。プルーニングとは不要な情報を削除するということです。DPropRは、プルーニング情報に変更情報の要・不要を記録し、CD表から不要な情報を削除することによって不要なデータ量 の増大を抑えています。
    8. ApplyはCD表とUOW表をJOINして抽出した結果の変更情報をターゲット表に反映します。これにより、ソースでコミットされた変更だけを反映することを保証します。CD表にはコミットされる前のデータも逐次蓄えています。
  • 変更に関する不要な情報の削除
    9. Applyは、ターゲット・データベースに変更を反映した時点の情報を以ってプルーニング情報を更新します。つまり、プルーニング情報には常に、最新の変更適用状況が記録されます。
    10. 収集プログラムはプルーニング情報に基づき、CD表およびUOW表から不要な変更情報を削除します。

(9)収集トリガーによる差分更新のしくみ
IBM以外のソース表を複製対象ソースとして定義した場合、DJRAはDB2 DataJoinerにより、そのソース表に対して収集トリガーを作成します。ソース表には、DELETE、UPDATE、INSERTの3種類のトリガーが、また、プルーニング情報が記録される表と複製対象の表についての同期情報が記録されている表(以下、登録同期表と記します)に対してはUPDATEトリガーが作成されます。Applyはこれらのトリガーをもとに、ターゲット・データベースに反映する必要がある変更情報を検出/保守します。

次図は非IBMソースからデータを抽出しソース・データベースであるDB2に変更を反映させる例を模式図にしたものです。

 
模式図
模式図

次に、収集トリガーによる差分更新のしくみについて説明します。

  • ソース・データベースからデータを収集する
    1. 複製対象のソースとして定義されているソース表に対してDELETE、UPDATE、またはINSERT操作が実行されると、収集トリガーはCCD表にその変更を記録します。
  • 変更情報をターゲット・データベースに反映する
    2. Applyが開始されると、登録同期表のUPDATEトリガーによって、複製対象の表に対して収集されたコミット済みデータの量 の情報を制御表に記録します。
    3. Applyは制御表からソース・データベースの情報を取得します。
    4. Applyはターゲット・データベースに変更情報を反映する前に、ソースからターゲットにすべてのデータをフルリフレッシュコピーして、両者の同期をとります。
    5. Applyはプルーニング情報を更新して、CCD表内のソース・データベースに対する変更情報の同期をとります。
    6. pplyはDB2DataJoinerのニックネーム名を使用してCCD表を読み、ターゲット・データベースに変更情報を反映します
  • 変更に関する不要な情報の削除
    7. Applyは、ターゲット・データベースに変更情報を反映した時点の情報を以ってプルーニング情報を更新します。(収集プログラムのしくみと同じです)
    8. プルーニング情報に対するUPDATEトリガーによって、ソース・サーバーにあるすべてのCCD表を調べて、複製済みの変更情報の項目を削除します。

3.データ・レプリケーションを理解するために

以下では、データ・レプリケーションを理解する上で重要な項目をいくつかご紹介します。

(1)レプリケーション・ソース
レプリケーション・ソースとは、データのコピー元となるユーザー表または視点です。データを複製するには、その前に複製対象のソースを定義して、Captureが使用する情報を登録しておかなければなりません。レプリケーション・ソースを定義する場合は、複製対象の列を指定し、それに対する更新をUPDATE操作として扱うか、それともDELETEおよびINSERT操作として扱うかを決めます。さらに、次の各点について検討します。

  1. 列の変更前イメージの情報が必要かどうか
    変更後のイメージには、更新後のソース・データベースのデータ値が入っています。変更前のイメージには、更新前のデータ値が入っています。レプリケーション・ソースを定義する場合は、変更後イメージだけ、または変更後イメージと変更前イメージの両方を収集するように指定できます。
    どちらを選ぶかは、データを使用する方法、および使用している表のタイプによって決まります。
    アプリケーションでデータに対する監査またはロールバック機能が求められる場合は、変更前イメージが必要です。
  2. フルリフレッシュコピーか差分コピーか
    フルリフレッシュコピーの場合と差分コピーの場合とでは、Applyによるリプリケーション・ソースからターゲット・データベースへの変更情報の反映方法が異なります。
    フルリフレッシュコピーによる変更反映の場合、Applyは以下のタスクを実行します。
    (1)ターゲット表のすべての行を削除する
    (2)ソース表からすべての行を読む
    (3)ターゲット表に(2)で読み取った行をコピーする
  3. データ・コンフリクト(対立)を検出するレベルの設定
    データ・コンフリクト(対立)とは、Update-Anywhere(両方向レプリケーション)と呼ばれる複製形態においてApply処理の1サイクルの中で、ソース表とターゲット表で同じキーのデータの更新をおこなった場合に発生する現象です。
    Update-Anywhereでは、ターゲット表もRead/Write対象になっており、ターゲット表に対する変更もソース表に反映させることができます。このターゲット表はレプリカ表と記されることもあります。
    データ・コンフリクトの検出とは、同一複製サイクルの中でソース表とターゲット表で同じ行が更新れたかどうかを検出するプロセスです。Applyは標準の検出レベルでは、すでにCD表に取り込まれている行の中でのデータ・コンフリクトを検索します。また、拡張レベルでは、ターゲット表をすべてロックし、データ・コンフリクトの原因となるデータの更新タスクが発生しないようにします。

    次の図ではUpdateAnywhereのしくみを模式化したものです。
     
    UpdateAnywhereのしくみ模式図
    UpdateAnywhereのしくみ模式図

(2)サブスクリプション・セットとサブスクリプション・セット・メンバー
ソース表からデータを複製するには、変更情報を反映させるターゲット表と変更元のソース表を関連付ける必要があります。この情報は、サブスクリプション・セットとサブスクリプション・セット・メンバーを使って定義します。ここで指定する情報はさまざまな制御表に保管されます。サブスクリプションとはApplyが必要とする情報を全て含んだ定義体であり、Applyが行う複製の行為そのものを指すこともあるということは前述しました。1サブスクリプションの単位はセットと呼ばれ、1セット内の同方向の複製が1作業単位で実行されます。1セットには、少なくとも1メンバーあるいは複数メンバーの複製定義が含まれます。1表から1表、あるいは1結合ビューから1表への複製がメンバーの単位となります。
サブスクリプション・セットには、複製のためのサブスクリプションの属性が入っています。サブスクリプション・セットを作成する場合には、以下の属性を定義します。

  • サブスクリプション・セットの名前
  • ソース・サーバーとターゲット・サーバー
  • 適用修飾子(以下、ApplyQualifierと記述・後に詳述します)
  • 複製の開始時とその頻度
  • 一定間隔の複製かイベントドリブンの複製か(あるいは両方使うか)
  • データ・ブロック(大量の変更が予想される場合)


サブスクリプション・セットでは、ターゲット表または視点ごとに1つのサブスクリプション・セット・メンバーを指定する必要があります。サブスクリプション・セット・メンバーを作成する場合は、以下の属性を定義します。

  • ソース表または視点とターゲット表または視点
  • ターゲット表またはターゲット視点の構造
  • 複製する列(副選択列)
  • 複製する行(SQL述部)


サブスクリプション・セットにより、複製中にすべてのサブスクリプション・セット・メンバーがどれも同じように処理されることが保証されます。つまり、変更はすべてのターゲットに適用されるか、まったく適用されないかのどちらかです。サブスクリプション・セット内のサブスクリプション・セット・メンバーすべてに関して反映されたデータは、指定されたターゲット表に対し、単一トランザクションとして変更が反映されます。サブスクリプション・セットにより、セット中のターゲット表がターゲット・サーバーに対して1つのトランザクションで処理されるので、パフォーマンスが最適化されます。サブスクリプション・セットは参照保全も保ちます。

個々のサブスクリプション・セットは1つのApplyによって処理されますが、それぞれのApplyはたくさんのサブスクリプション・セットを処理できます。

(3)ApplyQualifier
ApplyQualifierとは、Applyが処理をするべき1つまたは複数のサブスクリプションのグループを示す識別子です。予め各サブスクリプション・セットは、どのApplyQualifierで実行させるのかを登録しておきます。Apply実行時にApplyQualifierを指定することにより、そのApplyQualifierグループに含まれるサブスクリプション・セットのみを処理することができます。つまり、異なるApplyQualifierを使用すれば、単一ユーザーIDで、複数のターゲット・サーバーに対して、複数のApplyを同時に稼動させることが可能になります。ApplyQualifierは、Applyの作業負荷を定義するコントロール・サーバーでレコードを識別するのに使用されます。

次図はApplyQualifierの使用形態を模式化したものです。同一ユーザーID「UserX」によって異なるターゲット・サーバー群に対して「QualA」「QualB」という異なるApplyQualifierでApplyを実行できます。

 
ApplyQualifierの使用形態を模式図
ApplyQualifierの使用形態を模式図

(4)データ操作
ソース表のサブセットだけを複製したり、簡単な視点を使ってソース表からターゲット表にデータを再構築したり、あるいはもっと複雑なJOINやUNION操作をしたい場合にもDPropRは有効なツールです。

  1. ソース表の複製対象をサブセット化する
    ソース表全体を複製しないで、ソース表から特定の列や行を複製することができます。以下では、このプロセスを、列サブセット複製および行サブセット複製と表記します。
    ソースからすべての列のサブセットだけを複製したい場合は、列サブセット複製を使用します。たとえば、ソース内の一部の列がラージ・オブジェクト(LOB)のように非常に大きい場合や、いくつかの列データ・タイプが目的のターゲット表でサポートされていない場合は、列サブセット複製が適しています。
    ソース表から行の一部だけを複製する場合は、行サブセット複製を使用します。たとえば、複数の地方事務所にデータを複製する場合、その特定の地方事務所に関係のあるレコードだけを複製することができます。行をサブセット化するには、サブスクリプション・セット・メンバーの定義時にWHERE文節を使用します。
  2. ソース表の視点としてターゲット表を活用する
    ターゲット表でのデータ照会を簡易に実行できるようにするために、ソース表にシンプルな視点を作成してターゲット表を再構築することができます。データウェアハウスとしてのデータ利用時に非常に役立ちます。
    たとえば、ソースのデータベースに履歴書表と写真表の2つの表があるとします。人事部は、すべての従業員の履歴書と写 真の入った1つの表を必要としています。この場合、履歴書表と写真表の両方からデータを抽出する1つの視点を作成し、この視点を複製対象のソースとして定義できます。そして、この視点からターゲット表にデータを複製するためのサブスクリプション・セットを作成できます。
  3. ターゲット表のJOINとUNION操作
    既存のソース表のJOINまたはUNION操作の結果をもとにターゲット表の作成および保守ができます。以下のタイプのJOINを使用することができます。
    • 1つあるいは複数の制御表に登録済みのソースと未登録の表あるいは視点とのInner-Join
    • 制御表に登録済みの複製対象のソースのCCD表のInner-Join
      このCCD表はApplyなどによって保守されます。

    また、JOINとUNION操作を使えば、次のような方法でデータを操作できます。

    • 単一のDB2ソース・サーバーでの表のJOIN
    • 複数のソース・サーバーでの表のJOIN
    • 単一のソース・サーバーでの表のUNION
    • 複数のソース・サーバーでの表のUNION。複数サイトUNIONともいいます。

(5)ターゲット表
サブスクリプション・セット・メンバーを定義する場合は、使用するターゲット表のタイプを指定する必要があります。ターゲット表には次のようなタイプがあります。

  • ユーザー・コピー表
  • Point-in-Time(時刻)表
  • CCD表(ステージング表)
  • 集約表
  • レプリカ表

以下で各タイプの表ごとの特徴について説明します。

  1. ユーザー・コピー表
    ユーザー・コピー表は、DPropRによって制御用の列が追加されない読み取り専用コピーです。つまり、ソース表の全てまたは一部の列のみから構成される表です。ターゲット表としては、ごく一般 的なタイプです。
  2. Point-in-Time(時刻)表
    Point-in-Time(時刻)表は、1のユーザー・コピー表にタイム・スタンプ列を追加したものです。タイム・スタンプ列は、初期値にはヌルが入ります。変更情報が収集されると、ソース表で更新が発生した時刻を示す値が追加されます。変更の時刻を記録したい場合は、この表タイプを使用します。
  3. CCD表
    CCD表とは、この表を基にApplyがさらに別のターゲット表に変更データを複製することを可能にするタイプの表です。CCD表には、コミットされたトランザクションからのデータが入ります。また、ターゲット表がINSERT、DELETE、UPDATEのどの操作によって変更されたのかを示す標識も入ります。この表には、データの新しい値と古い値の両方を格納することができます。CCD表はさらに、用途に応じていろいろなタイプに分かれています。
    CCD表を用いると、以下のような方法でデータを収集および操作することができます。
    • リモート・ロケーションへの変更をステージングできる。
      リモート・ロケーションに複数のターゲット表がある場合、ソース表からすべてのターゲット表へ変更情報を反映する代わりに、ソースをいったんCCD表に複製しておき、そのCCD表からそれぞれのリモート・ターゲット表へ複製することができます。CCD表を使用することにより、Apply前のCD表とUOW表のJOINが一度で済みます。CCD表がリモートに存在しても、ターゲット表の近くにあれば、ネットワークの転送コストの軽減につながります。
    • 行の最終的な変更情報だけをターゲット表に反映できる。
      CCD表を使用すると、短期間に同じ行に繰り返し加えられた更新全てをターゲット表に反映しなくてもすむようにでき、ネットワークへの負荷を軽減できます。
    • リモート・ロケーションへの変更をステージングできる。
    • 監査情報を収集できる。
    • 非DB2データベースをソースとする場合に、変更データのソースとして使用できる。
      IMSからの変更データの場合はDPropRNR(Data PROPagator Non Relational)を使用して、非IBMデータベースからの変更データの場合は収集トリガーを使用して、変更データを収集します。
  4. 集約表
    約表は、SQL列関数(SUMやAVGなど)を使用する読み取り専用表で、ソース表の内容全体またはソース表データに加えられた最新の変更に関する要約データを計算します。集約表には時間の経過に伴って行が追加されていきます。集約表には、基礎集約表と変更集約表の2種類があります。
    • 基礎集約表
      ソース表の内容を要約します。基礎集約表は、ソース表の状態を定期的にチェックしたい場合に利用します。たとえば、月ごとの平均顧客数を知りたいとします。ソース表に顧客ごとの行があれば、月ごとにソース表の行数を平均し、結果 を基礎集約表に保管することができます。ただし、基礎集約表には、変化に関する情報は記録されません。平均値は同じでも、その中で生じた変化についての情報を取得することはできません。
    • 変更集約表
      変更集約表は、ソース表そのものではなく、制御表の変更データを処理します。時間の経過に伴う変化(UPDATE、INSERT、およびDELETE操作)の内容を知りたい場合は、変更集約表を利用します。たとえば、毎月新たに獲得した顧客の数(INSERTS)と、失った既存の顧客の数(DELETES)を知りたいとします。この場合、ソース表の行に加えられた変更の数を月ごとに数えて、その数を変更集約表に保管することができます。基礎集約表からは、両月の平均顧客数が同じであったことは分かるものの、顧客の増減状況については分かりません。
  5. レプリカ表
    アプリケーションから直接データ更新ができるのは、レプリカ表とよばれるタイプのターゲット表です。
    レプリカ表に加えられた変更は、それに関連するソース表に反映されます。次に、そのソース表は変更を他のレプリカ表に複製します。レプリカ表はDB2データベースでのみサポートされています。
    Update-anywhereタイプの複製にはレプリカ表を使用してください。

(6)更新適用のスケジュール
DPropRはデータの複製を非同期に行います。
非同期式複製は、ソース表への更新情報を段階的にターゲット表へ送ります。つまり、ソース表に変更が加えられると、その変更は事前に設定された間隔で一時的にステージング表に保管され、後でターゲット表に転送されます。この間隔は、一定の時間単位(秒、分、時間)として指定したり、事前に指定されたイベント(真夜中その他の時刻)として表現したりできます。ターゲット表に変更を加えることができない場合(たとえばターゲット表が停止している場合やネットワーク障害が発生している場合など)、変更情報はソースに変更が加えられた順番で保管され、後でターゲット表に適用されます。非同期式複製には、ネットワーク・リソースの活用効率が優れており、データベースの競合が少ないという利点があります。
変更情報をターゲット表に反映するタイミングには、インターバル・タイミング、イベント・タイミング、(またはその両方の指定も可能)、オンデマンド・タイミング(Windows32ビット・オペレーティング・システムのみ)の3種類が可能です。

  1. インターバル・タイミング
    これは、複製のタイミングを制御する最も簡単な方法です。インターバル・タイミングを使用するには、Applyでターゲット表へのデータ複製を開始する日付と時刻を選択し、データ複製の頻度を示す時間間隔を設定します。Applyが停止すると、その時間間隔が経過するまでプログラムは再開されません。時間間隔は一定の時間(1分から1年まで)を指定することができます。
  2. イベント・タイミング
    これは、インターバル・タイミングよりも精緻に複製操作を制御できます。イベント・タイミングを使用するには、サブスクリプション・セットの定義時にイベントの名前を指定し、そのイベントを処理する時刻を設定します。オプションとして、複製実行期間の終わりの時刻を設定することができます。
    つまり、Applyはこの終了時刻を過ぎてコミットされた変更は複製しません。イベント・タイミングの情報は、ユーザーが、あるいはアプリケーションから指定する必要があります。この情報は制御表の内のサブスクリプション・イベント情報に保管されます。Applyはサブスクリプション・イベント情報を検索し、イベント名、それに関連する時刻、および複製期間終了時刻に関する情報を得ます。
  3. オンデマンド・タイミング
    Windows32ビット・オペレーティング・システムでは、ASNSATコマンドを使用して、オンデマンドのタイミングでデータ複製を行うことができます。このコマンドはApplyを開始させたり、必要に応じてCaptureを開始させることができます。ApplyもCaptureも、複製作業が終了すると、自動的に終了します。

ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=323198
ArticleTitle=DPropRのご紹介
publish-date=11262004