レプリケーションの手引きおよび解説書

複製の計画

この章では、複製環境の設計に必要な情報について説明します。 すなわち、キャパシティー・プランニング、記憶要件、ネットワーク要件、複製内容の決定、監査要件、データのステージング、および移行の計画について説明します。


キャパシティー・プランニング

収集プログラムは一般に他のアプリケーションに影響を与えることはなく、 最小の中央演算処理装置 (CPU) または中央演算処理複合システム (CPC) の能力しか必要としません。 たとえば、収集プログラム (OS/390 版) は、ソース表を更新するアプリケーション・プログラムより低い優先順位でスケジューリングできます。 その場合、収集プログラムは CPU 資源が制約されると遅れることになります。

収集プログラムは CD 表と UOW 表を枝取りする場合に CPU 資源を使用しませんが、その活動を据え置くことによってシステムへの影響を軽減できます。

変更適用プログラムは複製の頻度、つまり、ターゲット・データベースの現行性の要件に応じて、CPU 使用率に影響を与えます。 変更適用プログラムはソース・サーバーからデータを読み、そのデータをターゲット・サーバーにコピーするので、その両方のシステムで CPU 資源を使用します。

一般に DB2 コントロール・センターと DJRA はローカルの CPU 資源をそれほど必要としません。 しかし、複製ソースとサブスクリプション・セットの定義のための SQL を生成する場合、DB2 DataPropagator はソース・サーバーのカタログを徹底的に検索します。 しかも、大規模サイトの場合、この種の検索は CPU またはデータベース・システムに著しい影響を与えることがあります。

推奨事項: 複製管理は、ソースおよびターゲット・データベースがあるシステムへの影響が最小になる時点で計画してください。 ソース・サーバーから戻されるデータ量を最小限に抑えるには、フィルター処理を使用します。


記憶域の計画

DB2 に必要とされる記憶域に加えて、複製では以下のもののための記憶域が必要です。

データベース・ログおよびデータベース・ジャーナルのデータ
データの複製をサポートするために記録される追加データ。

収集プログラム (VSE および VM 版) のアクティブ・ログ・ファイル、および収集プログラム (AS/400 版) の現行レシーバーのサイズ
複製に必要なデータがアーカイブ・ログではなくアクティブ・ログに残っていることを確認する必要があります。

ターゲット表および制御表
複製されるユーザー・データおよび制御表 (変更データ表を含む)。

予備ファイル
変更適用プログラムには、データを保管するための一時的なスペースが必要です。 変更適用プログラム (OS/390 版) は、予備ファイルのためにディスク・スペースではなくメモリーを使用することがあります。 他のオペレーティング・システム環境用の変更適用プログラムは、予備ファイルのためにディスク・スペースを使用します。

予備ファイル用のディスク・スペースが足りない場合、変更適用プログラムは終了します。 変更適用プログラム (OS/390 版) でメモリーを使用することを指定しても、予備ファイル用のメモリーが不足していれば、変更適用プログラムは異常終了します。 その場合は、変更適用プログラムでディスク・スペースを使用することを指定してから、それを再始動してください。 予備ファイルについて詳しくは、予備ファイルを参照してください。

以下の部分で指定されているサイズはすべて目安にすぎません。 実動可能システムを準備して設計するには、障害防止などの要因も考慮に入れなければなりません。 たとえば、発生する可能性のある回線故障停止に備えて、データを保管する期間 (ターゲット表および制御表を参照) を延長する必要があるかもしれません。

記憶域の見積もりが大きすぎるように思える場合は、変更適用プログラムと枝取りの頻度間隔 (サブスクリプションの実行頻度) を再検討してください。 記憶域の使用率、最大限の障害許容度、および CPU オーバーヘッドの間の駆け引きを定期的に検討する必要があります。

データベース・ログおよびデータベース・ジャーナルのデータ

表を複製するには、DATA CAPTURE CHANGES キーワードを使って表を作成 (または変更) する必要があります。 これらのキーワードを使用する利点の 1 つとして、DB2 は UPDATE ステートメントごとに完全な行イメージをログ記録します。 レプリカ表の場合 (随時更新シナリオ)、DB2 は表に更新が加えられるごとに変更前イメージもログ記録します。 ログまたはジャーナルの量が増える別の要因として、DB2 は作業単位 (UOW) 表および変更データ (CD) 表でログ記録を挿入したり削除したりします。

ログおよびジャーナルの量の増加を見積もるのは簡単ではありませんが、一般に、複製に関係するすべての表のために現行ログの量の 3 倍を追加する必要があります。

さらに正確な見積もりを出すには、更新アプリケーションと複製要件についての詳しい知識が必要になります。 たとえば、更新アプリケーションが一般に表の列の 60% を更新する場合、複製要件によっては、ログ・レコードの大きさが、類似の表が複製されない場合に比べて半分以上も増加する可能性があります。 ログの追加量が最大になる複製要件の 1 つとして、変更前イメージと変更後イメージの収集 (随時更新複製シナリオの例が当てはまる) があります。 ログの量を少なくする方法の 1 つとして、複製ソースに対して定義されている列数を少なくすることができます。

ソース・データベースのログ記録に加えて、行が適用されるターゲット・データベースでもログ記録されます。 変更適用プログラムは一時チェックポイントを発行しないので、変更適用プログラムが 1 回の間隔で処理する最大データ量を見積もり、 そのデータ量を格納できるようにログ・スペース (または AS/400 の現行レシーバー用スペース) を調整してください。

収集プログラム (VSE および VM 版) のアクティブ・ログ・ファイル、および収集プログラム (AS/400 版) の現行レシーバーのサイズ

VM および VSE の場合、アクティブ・ログがいっぱいになると DB2 はその内容をアーカイブします。 AS/400 の場合、現行レシーバーがいっぱいになるとシステムは新しいレシーバーに切り替えます。 複製する必要がなくなった古いレシーバーについては、保管するか削除するかを任意に指定できます。 たくさんのトランザクションを扱うシステムの場合、収集プログラムは場合によって遅れることがあります。 ログが小さすぎる場合は、取り込まれる前のログ・レコードをいくつかアーカイブすることができます。 DB2 (VSE および VM 版) で実行される収集プログラム (VSE および VM 版) は、アーカイブ・ログ・レコードを回復できません。 13

DB2 (VSE および VM 版) の場合、ログのサイズが、少なくとも 24 時間のトランザクション・データを扱える大きさであるようにしてください。 DB2 (AS/400 版) の場合、現行レシーバーのサイズが、少なくとも 24 時間分のデータを扱える大きさであるようにしてください。

ターゲット表および制御表

ターゲット表に必要なスペースはソース表 (複数の表も含む) のスペース以下であるのが普通ですが、ターゲット表が非正規化されたり、 その中に変更前イメージ (変更後イメージに加えて) または活動記録データが含まれていると、ソース表のスペースよりもずっと大きくなる場合があります。 ターゲット表に必要なスペースに影響を与えるさらに別の要素として、複製される列数、複製される列のデータ・タイプ、サブスクリプション・セット・メンバーに定義される行サブセット、 複製中に実行されるデータ変換があります。

CD 表と UOW 表もまた、ソース・データベースに必要なディスク・スペースに影響を与えます。 複製制御表に必要なスペースは少ないのが普通ですが、これは各表が必要とするスペースが数行程度だからです。

CD 表は、複製されるデータの量に応じてサイズが大きくなり、やがて収集プログラムによって枝取りされます。 CD 表に必要なスペースを見積もるには、まずデータを保管してから枝取りするまでの任意の期間を決定した後、 収集プログラムで CD 表を枝取りする頻度や、prune コマンドを発行する頻度を指定します。 CD 表に必要な最小サイズを判別するには、次の式を使用します。

最小_CD_サイズ =
  ( (21 バイト) + sum(登録済みの列全部の長さ) ) *
  (ソース表での挿入、更新、および削除の数) *
  (例外要素)

複製済みデータのバイト数を計算する場合は、収集プログラムが CD 表に加えたオーバーヘッド・データとして 21 バイトを含める必要があります。 この式では、データの収集と枝取りの間の間隔においてなされたソース表での挿入、更新、削除の数を判別します。 例外要素としては、変更適用プログラムがデータを複製できなくなるようなネットワーク障害や他の障害などの事情が考えられます。 初期値としては 2 を使用し、その後、複製環境のパフォーマンスに基づいて値を調整します。

例: 適用された行を収集プログラムが 1 日に 1 回 CD 表から枝取りする場合、間隔は 24 時間になります。 CD 表の行が 100 バイトの長さ (これにオーバーヘッドの 21 バイトを加える) で、24 時間の期間内に 100,000 の更新が適用される場合、CD 表に必要な記憶域は約 12 MB です。

CD 表の最大サイズは、そのプラットフォームで DB2 が扱える列の最大数と 1 つの行の最大サイズによって決まります。 表 4 には、CD 表の最大サイズを計算する方法が示されています。 レプリカ表の場合は、列の最大数と行の最大長を 2 で割らなければなりません。 それは、レプリカ表の CD 表には変更前イメージの列が含まれているからです。


表 4. CD 表の最大サイズの計算方法
maxCols は DB2 が 1 つの表につき扱える列の最大数、 値 maxLength は DB2 が扱える行の最大長をそれぞれ示しています。
読み取り専用表の場合 読み取り / 書き込み (レプリカ) ターゲット表の場合
列の数 maxCols - 3 列 (maxCols - 3 列) / 2
行の長さ maxLength - 21 バイト (maxLength - 21 バイト) / 2

UOW 表は、特定の時間間隔内に挿入される行数 (ソース表を更新するトランザクションまたは収集プログラム (AS/400 版) がその間隔内に発行するコミット数) に基づいて拡大および縮小します。 最初は必要サイズを大きく見積もってから、実際に使用されるスペースをモニターして、スペースを回収できるかどうかを見定めてください。 UOW 表の各行のサイズは 79 バイト固定です (例外として DB2 (AS/400 版) の場合は 109 バイト)。 UOW 表に必要なスペースを初めて見積もる場合は、79 バイト (または 109 バイト) に、2 時間以内に適用された更新数を掛けてください。 CD 表に指定した前述の式のような式を使えば、UOW 表に必要なスペースをさらに正確に見積もることができます。 詳しくは、作業単位表を参照してください。

予備ファイル

変更適用プログラムは、予備ファイルと呼ばれる一時ファイルにターゲット表への更新を保管します。 14 ロード入力ファイルは、変更適用プログラムが更新をターゲット表に適用するまで更新を保持します。 変更適用プログラムは、複数のサブスクリプション・セット・メンバーのあるサブスクリプション・セットには複数の予備ファイルを使用します。 つまり、ターゲット表ごとに 1 つの予備ファイルがあります。 変更適用プログラムはオペレーティング・システム環境ごとに予備ファイルをディスク上に保管しますが、変更適用プログラム (OS/390 版) では仮想メモリーで代用できます。 仮想メモリーの制約がない限り、予備ファイルはディスク上ではなく仮想メモリーに保管してください。

予備ファイルのサイズは、個々の複製間隔内の複製用に選択されたデータのサイズと同じです。 予備ファイルのサイズを見積もるには、変更適用プログラム用に計画した頻度間隔 (またはデータ・ブロック間隔; 変更が大量である場合のデータのブロック化を参照) と、 同じ期間内 (または変更のピーク期間内) になされた変更の量を比較します。 予備ファイルの行サイズはターゲット行 のサイズであり、これには DB2 DataPropagator のオーバーヘッド列が含まれます。 この行サイズは DB2 パック内部形式ではなく、拡張された解釈済みの文字形式 (SELECT から取り出された状態) です。 行には、行の長さと、個々の列ストリング上のヌル終了文字も含まれます。

例: 変更量のピークが時間あたり 12,000 件の場合に、変更適用プログラムの頻度が 1 時間間隔で計画されていると、 予備ファイルには 1 時間分の更新件数、つまり 12,000 件を保持しなければなりません。 1 件の更新が 100 バイトのデータを表すとすれば、予備ファイルは約 1.2 MB になります。


ネットワーク計画

ここでは、接続要件について説明し、変更適用プログラム (プッシュまたはプル構成を使用) をどこで実行するかについて述べ、データのブロック化によってパフォーマンスがどのように向上するかを説明します。

コネクティビティー

多くの場合、データ複製には物理的に離れたデータベースが関係しているので、各段階でコネクティビティーを考慮するのは大切なことです。 DB2 コントロール・センターまたは DJRA を実行するワークステーションでは、制御、ソース、およびターゲット・サーバーのデータベースに接続して作業を実行する必要があります。 また、変更適用プログラムは、制御、ソース、およびターゲット・サーバーのデータベースに接続する必要があります。

データベースがネットワークに接続される場合のコネクティビティーは、以下に示すとおり、接続されるプラットフォームによって異なります。

DB2 (OS/390 版) にパスワード検査を使用する場合は、CATALOG DB ステートメントに DCS を追加してデータ通信サービスを使用します。 SNA を使って接続するのであれば、CATALOG APPC NODE ステートメントに SECURITY PGM を追加します。 しかし、TCP/IP を使用する場合、CATALOG TCPIP NODE ステートメントにはそれに相当する機密保護キーワードはありません。

複製の設計で、ソース・データベースとは異なるサーバーでデータのステージングが関係しているなら、さまざまなサーバー間の通信について慎重に考慮する必要があります。 たとえば、 ラップトップ PC 上の Windows 95 で実行する DB2 ユニバーサル・データベースと DB2 (OS/390 版) との不定期複製では、Windows 95 PC から TCP/IP を使ってモデム経由でローカル・サーバー (たとえば DB2 ユニバーサル・データベース エンタープライズ・エディションを使用する AIX サーバー) をダイヤル呼び出しするほうが、 シナリオとしては良好なコネクティビティーを期待できます。 この場合、AIX ワークステーションは DB2 (OS/390 版) に接続され、Windows 95 マシンからの要求に応じることができます。

エミュレーション層、LAN ブリッジ、およびルーター・リンクについては、どれも複製のパフォーマンスに影響を与えるものなので、必ず制限してください。

変更適用プログラムをどこで実行するか: プッシュまたはプルの構成

変更適用プログラムはソース・サーバーまたはターゲット・サーバーで実行できます。 変更適用プログラムがソース・サーバーで実行される場合、プッシュ構成 になります。すなわち、変更適用プログラムはソース・サーバーからターゲット・サーバーに更新をプッシュします。 変更適用プログラムがターゲット・サーバーで実行される場合、プル構成 になります。すなわち、変更適用プログラムはソース・サーバーからターゲット・サーバーに更新をプルします。

変更適用プログラムは上記のいずれかまたは両方の構成で同時に実行できます。つまり、一部のサブスクリプション・セットの更新をプッシュし、他のサブスクリプション・セットの更新をプルすることができます。

ターゲット表が IBM 以外のデータベースにある場合、変更適用プログラムは DB2 DataJoiner データベース (DB2 DataJoiner は IBM 以外のデータベースに接続されている) に接続し、DB2 DataJoiner のニックネームを使ってターゲット表に変更を適用します。 その場合、変更適用プログラムは DB2 DataJoiner ソース・サーバーからターゲット・サーバーに更新をプッシュしたり、DB2 DataJoiner ソース・サーバーからターゲット・サーバーに更新をプルしたりします。 変更適用プログラムは、IBM 以外のサーバーから直接プッシュまたはプルできません。

図 16 に、プッシュ構成とプル構成の違いを示します。

図 16. プッシュ構成とプル構成の比較


プッシュ構成とプル構成の比較

プッシュ構成では、変更適用プログラムはローカル・ソース・サーバー (または IBM 以外のソースの場合は DB2 DataJoiner ソース・サーバー) に接続してデータを取り出します。 次にリモート・ターゲット・サーバーに接続し、ターゲット表に変更をプッシュします。 変更適用プログラムは行ごとに更新をプッシュします。DB2 のブロック取り出し機能を使ってネットワーク効率を高めることはできません。

プル構成では、 変更適用プログラムはリモート・ソース・サーバー (または IBM 以外のソースの場合は DB2 DataJoiner ソース・サーバー) に接続してデータを取り出します。 DB2 はブロック取り出し機能を使って、ネットワーク経由で効率よくデータを取り出すことができます。 すべてのデータを取り出した後、変更適用プログラムはローカル・ターゲット・サーバーに接続して、ターゲット表に変更を適用します。

一般に、プル構成のほうがプッシュ構成よりもパフォーマンスは優れています。プル構成のほうが、ネットワークを効率よく使用できるからです。 しかし、次に示す状況では、プッシュ構成を選ぶほうがよいかもしれません。

プッシュ構成やプル構成は、変更適用プログラムをどこで実行するかを決めるだけでセットアップできます。 DB2 DataPropagator、DB2 コントロール・センター、および DJRA は、どちらの構成も認識します。

変更が大量である場合のデータのブロック化

1 回の変更適用サイクルで大量の変更ブロックを複製する複製サブスクリプションは、予備ファイルまたはログ (ターゲット・データベースの場合) でのオーバーフローの原因となります。 たとえば、変更適用プログラムをバッチ処理するシナリオでは、複製を必要とする待機状態のトランザクションのバックログが大量に生成される可能性があります。 また、ネットワークの停止が長引くと、大量のデータ・ブロックが CD 表に蓄積され、予備ファイルがオーバーフローする可能性があります。

DB2 コントロール・センターの「サブスクリプション・タイミング (Subscription Timing)」ノートブックの「データ・ブロック (Data Blocking)」ページを使用するか、 DJRA の「空のサブスクリプション・セットの作成 (Create Empty Subscription Sets)」ウィンドウの「ブロック化因数 (Blocking factor)」フィールドを使用すると、 変更適用プログラムがサブスクリプション・サイクルで何分間分の変更データを複製できるかを指定できます。 指定する分の値によって、データ・ブロックのサイズが決まります。 15 この値は、 サブスクリプション・セット表の MAX_SYNCH_MINUTES 列に保管されます。 変更データの累積がデータ・ブロックのサイズより大きい場合、 変更適用プログラムは 1 つのサブスクリプション・サイクルを複数のミニサイクルに変換して、バックログを管理可能な量にまで少なくします。 また、失敗したミニサイクルを取り出し、使用可能なシステム資源に合わせてデータ・ブロックのサイズを小さくします。 ミニサイクル中に複製が失敗した場合、 変更適用プログラムは最後に成功したミニサイクルからサブスクリプション・セットを取り出します。 図 17 に、変更されたデータが変更のサブセットに分割される仕組みを示します。

図 17. データのブロック化. ネットワークのトラフィック量を少なくするには、データ・ブロック値を指定します。


データのブロック化によって大きい応答セットが小さいセグメントに分割されることを示す図

デフォルトでは、変更適用プログラムはデータのブロック化を使用しません。つまり、収集されて使用可能なコミット済みデータすべてをコピーします。 データのブロック化値を設定する場合、設定する分値が小さければ、 間隔内に生じるサブスクリプション・セットのトランザクションをすべてコピーし、予備ファイルやログのオーバーフローを防ぐことができます。 AS/400 の場合、間隔内に複製されるデータの総量が 4 MB を超えないようにしてください。

制約事項:


複製する内容を決定する

複製の計画の一部として、ターゲット・サイトでデータを使用する方法を考慮しなければなりません。 多くの場合、ソース・データは、意思決定支援やデータウェアハウジングのために、サブセット化するか変換または拡張する必要があります。 ここでは、そのような要件を、 DB2 コントロール・センターまたは DJRA の使用によって簡単に満たされるものと、制御表の直接操作を必要とするものに分類します。

コントロール・センターおよび DJRA は、次のようなデータ操作をサポートします。

以下の部分では、コントロール・センターまたは DJRA を使って実行できるデータ操作について説明します。 この章では、ラージ・オブジェクト (LOB) の複製、変更前イメージの列名に関する制限、およびデータ・タイプの制約についても説明します。

列および行のサブセット化

IBM レプリケーションは、ソース表の列 (縦) と行 (横) の両方のサブセット化をサポートします。 これは、ソース表のすべての列および行ではなく、列および行のうちのサブセットだけをターゲット表に複製するように指定できることを意味します。

列サブセット化
複製のシナリオによっては、すべての列をターゲット表に複製したいわけではない場合があります。 また、ターゲット表に定義したすべてのデータ・タイプをターゲット表がサポートできない場合もあります。 ソース表より列数が少ない列サブセットを定義できます。 列のサブセット化は、レプリカ表を除くすべての表について使用可能です。

次のいずれかの機会に列のサブセット化を定義できます。

推奨事項: 複製ソースを定義する場合は、すべての 列を選択してください (つまりどの列もサブセット化しません)。 サブスクリプション・セットを定義する場合は列サブセットを作成します。 複製ソースではなくサブスクリプション・セットで列サブセットを定義すれば、 サブスクリプション要件が変わる場合でも複製ソースを再定義する必要がなくなります。

行サブセット化
複製のシナリオによっては、異なるデータをソース表からいくつかのターゲット表に複製したい場合があるかもしれません。 一定の条件 (WHERE 文節) と一致する行、たとえば、部門 "J35" 用のすべての行が入った行サブセットを定義することができます。

サブスクリプションの定義時に、拡張サブスクリプション・オプションを使用して WHERE 文節を定義します。 すべてのターゲット表タイプで、行サブセット化がサポートされます。

ターゲット表の基本キー値が更新されたり、更新される論理区分列が表 (または視点) に入っていたりする場合、 複製ソースを定義する際に複製論理区分化キー・サポートを指定しなければなりません。 複製論理区分化キー・サポートを指定すると、UPDATE は、DELETE の後に INSERT が実行されるものとして実行されます。 詳しくは、複製論理区分化キーのサポートを使用できるようにするを参照してください。

視点を使用した結合の複製

結合視点は多くの要件を満たします。その要件には、コピーされたデータをより簡単に照会できるようにするために、データウェアハウスのシナリオでコピーを非正規化 (再構成) するためのものと、 経路指定問題 (分散コンピューティングのシナリオでデータベース区分化問題と呼ばれることがある) を扱うためのものが含まれます。 16 視点は、512 バイト (サブスクリプション・ターゲット・メンバーの PREDICATES 列の容量) を超える行サブセットの述部を指定しなければならない場合にも役立ちます。 したがって、サブスクリプション・セット定義の一部としてではなく、視点を使ってサブセット述部を管理するという選択が可能になります。

コントロール・センターを使って結合視点を複製ソースとして定義するには、 まず複製ソースとして結合に関係するすべての表を定義します (表のサブスクリプションを定義する必要はありません)。 また、DJRA を使って結合視点を複製ソースとして定義する場合は、 既存の視点を使用するか、複製ソースとして定義されていない表を含んでいる結合視点を定義します。 視点を複製ソースとして定義するにはコントロール・センターまたは DJRA を使用します (視点を複製ソースとして定義するを参照)。 結合に定義した複製ソースに CD または CCD 表がある場合、コントロール・センターまたは DJRA はその複製ソースの CD 表から CD 視点を作成します。

IBM レプリケーションは、次に示すタイプの視点定義をサポートします。

ヒント: 定義する視点に 2 つ以上の表が複製ソースとして含まれている場合は、 さらに結合内のソース表の 1 つに CCD 表を定義してください。 この CCD 表は、圧縮された完全でない (完全であってもよい) 表でなければならず、 さらにターゲット・サーバー上になければなりません。 ソース表を 2 つ以上含んでいる視点には「二重削除」が生じやすいという問題があり、 DB2 DataPropagator はこれを複製できません。

たとえば、定義する視点に CUSTOMERS 表と CONTRACTS 表が含まれており、 同じ複製サイクルで CUSTOMERS 表から 1 つの行を削除すると同時に (視点の結合点から) それに対応する行を CONTRACTS 表からも削除した場合、 二重削除が生じます。 ここで問題となるのは、結合の 2 つのソース表から削除されているためその行は視点に (基本視点と CD 表視点のどちらにも) 表示されず、 その結果としてこの二重削除は複製できません。

結合内のいずれかのソース表に、圧縮された完全でない CCD 表を定義すればこの問題を解決できます。 それは、この CCD 表の IBMSNAP_OPERATION 列を使用すれば削除を検出できるからです。 さらに、サブスクリプション・サイクルの後に実行するサブスクリプション・セットの定義に、 SQL ステートメントを追加することもできます。 この SQL ステートメントは、 CCD 表内の IBMSNAP_OPERATION が "D" と等しくなるターゲット表からすべての行を除去します。

変更前イメージおよび変更後イメージの複製

変更前イメージと変更後イメージは両方とも、複製ソースおよびサブスクリプションで定義できます。 変更前イメージ列とは、更新される前の列のコピーのことです。また、変更後イメージ列とは、更新された後の列のコピーのことです。 DB2 は、表に加えられた変更ごとに、その表の変更前イメージ列と変更後イメージ列の両方を記録します。 変更前イメージの複製作業は、レプリカを標準または拡張対立検出で定義する場合に、 随時更新シナリオで必要とされます。 この場合に変更前イメージは、拒否されたトランザクションの自動補正に必要な情報を提供します。 さらに、変更前イメージの複製作業は監査のときにも役立ちます。

次に示すとおり、変更前イメージおよび変更後イメージには、 ターゲット表に対して実行するアクションに応じて異なる値を指定できます。

アクション
列値

全最新表示
すべての変更前イメージは NULL 値になります。

挿入
変更前イメージ列は NULL 値になります。

更新
変更前の列値は変更前イメージ列に収集され、変更後の値は変更後イメージ列に入れられます。

論理区分化キー・サポートを使用可能にすると、削除された列には変更前イメージ列が表示され、挿入された列には変更後イメージ列が表示されます。 詳しくは、複製論理区分化キーのサポートを使用できるようにするを参照してください。

削除
変更前イメージ列と変更後イメージ列の両方に、変更前イメージ値が入れられます。

変更前イメージは基礎集約表タイプでは無効です (算出列には変更前イメージがありません)。 その他のすべてのターゲット表タイプでは、変更前イメージ列を利用することができます。

制約事項: 列に変更前イメージが定義されている場合、 DB2 DataPropagator では列名が 17 文字に制限されます。 DB2 DataPropagator はターゲット表に変更前イメージの列識別子 (通常は X) を追加し、各列名は必ず固有名にする必要があるので、 複製する表の列名にもっと長い列名を使用することはできません。 複製するつもりがない表にはさらに長い列名を使用できますが、その表を将来複製する可能性がある場合は 17 文字の名前を使用することを検討してください。 DB2 (OS/390 版) の表であれば 18 文字の列名を使用できますが、DB2 DataPropagator は 18 番目の文字をターゲット表の変更前イメージ列識別子と置き換えます。 それで、列名の最初の 17 文字は固有名になるようにする必要があります。

列の名前変更

時刻ターゲット表とユーザー・コピー・ターゲット表のタイプでは、列の名前を変更できます。 その他の表タイプでは、列を名前変更するために視点を定義しなければなりません。

算出列の作成

SQL を使えば、既存のソース列から新しい列を取り出すことができます。 集約ターゲット表タイプでは、COUNT や SUM といった総計関数を使って新しい列を定義できます。 その他の表タイプでは、SQL 式を使って新しい列を定義できます。

算出列は、複製ソースが使用する表を作成するときにユーザー定義関数を参照して作成することもできます。

ストアード・プロシージャーを使用した複製前後の実行時処理

変更適用プログラムがサブスクリプションを処理する前または後に実行できる SQL ステートメントまたはストアード・プロシージャーを使用して、実行時処理ステートメントを定義することができます。 そのようなステートメントは、CCD 表の整理やサブスクリプションが処理される順序の制御に役立ちます。 実行時処理ステートメントは、サブスクリプションの処理前にソース・サーバーにおいて、またはサブスクリプションの処理後にソース・サーバーとターゲット・サーバーにおいて実行できます。 たとえば、データを取り出す前、またはターゲット表にデータを複製した後、あるいはその両方の場合に SQL ステートメントを実行することができます。

ストアード・プロシージャーは、パラメーターなしの SQL CALL ステートメントを使用します。 プロシージャー名の長さは 18 文字以下でなければなりません (AS/400 の場合は、最大 128 文字です)。 ソース表が IBM 以外のデータベースにある場合、DB2 DataJoiner は SQL ステートメントを処理します。 各タイプの実行時プロシージャーは単一トランザクションとして一緒に実行されます。 さらに、それぞれのステートメントごとに受け入れ可能 SQLSTATE を定義することもできます。

SQL の事前および事後処理ステートメントは DB2 プラットフォームに応じて、ストアード・プロシージャーの呼び出しなど、その他の処理を実行することができます。

ラージ・オブジェクトの複製

DB2 ユニバーサル・データベースはラージ・オブジェクト (LOB) のデータ・タイプをサポートします。 このデータ・タイプには、2 進 LOB (BLOB)、文字 LOB (CLOB)、2 バイト文字 LOB (DBCLOB) が含まれます。 ここでは、ここに示したタイプの LOB データをすべて取り上げます。

収集プログラムは LOB 記述子を読み、LOB 列のデータが変更された場合に複製の必要があるかどうかを判別しますが、CD 表には LOB データをコピーしません。 LOB 列が変更されると、収集プログラムは CD 表に標識を設定します。 変更適用プログラムはこの標識を読み取ると、次に LOB 列全体 (LOB 列の変更部分だけではない) をソース表からターゲット表に直接コピーします。

収集プログラムが LOB データの変更を検出できるようにするには、ソース表を作成 (または変更) するときに DATA CAPTURE CHANGES キーワードを含める必要があります。

LOB 列には最大 2 GB のデータを入れることができるので、変更適用プログラムには十分なネットワーク帯域幅を指定できるようにしてください。 同じように、ターゲット表にも LOB データが入るだけのディスク・スペースを指定しなければなりません。

制約事項:

DATALINK 値の複製

リモート・ネットワークを介して大きなファイル (マルチメディア・データなど) にアクセスするのは、 非効率的で費用がかかります。 これらのファイルが不変であるか、変更される回数がごくわずかである場合、 リモート・サイトに複製することによってこれらのファイルに短時間でアクセスできるだけでなく、 ネットワーク・トラフィックも軽減できます。 DB2 ユニバーサル・データベースには DATALINK データ・タイプが用意されており、 これを使うことによってデータベースにこのような種類のファイルに対するアクセス、 保全性、回復などを制御させることができます。 DB2 ユニバーサル・データベースは、OS/390 を除くすべてのプラットフォームで DATALINK 値をサポートしています。

DB2 は DATALINK 列を複製すると同時に、 ASNDLCOPY ユーザー出口ルーチンを使ってその DATALINK 列が参照している外部ファイルを複製します。 このルーチンはそれぞれのソース・リンク参照をターゲット・リンク参照に変換した後、 該当する外部ファイルをソース・システムからターゲット・システムにコピーします。 sqllib/samples/repl ディレクトリーには、 ファイルの転送に FTP やファイル・コピー用デーモン (ASNDLCOPYD.SMP) を使用できる サンプルのルーチン (ASNDLCOPY.SMP) があります。 AS/400 の場合、サンプル・プログラムはライブラリー QDPR 内のファイル QCSRC、QCBLLESRC、および QRPGLESRC にあります。 ASNDLCOPY 出口ルーチンの使用および ASNDLCOPYD ファイル・コピー・デーモンの使用を参照してください。

外部ファイルは非常に大きい場合があるため、 変更適用プログラムと、これらのファイルをコピーするのに使うファイル転送方式の両方にとって十分なネットワーク帯域幅を確保してください。 同じように、ターゲット・システムにもこれらのファイルが入るだけのディスク・スペースを確保しなければなりません。

推奨事項:

制約事項:

キー更新の制約事項

複製の対象が圧縮されたターゲット表 (ユーザー・コピー表、 時刻指定表、圧縮された CCD 表、レプリカ表など) である場合は、 構文 SET KEYCOL=KEYCOL + n を更新で使わないでください。 キーの更新をこの形式で行うと、データの複製が正しく実行されません。 サブスクリプション・セット内のキーとして、ソース表内の別の列を使用してください。 代わりになるキーがソース表内に存在しない場合でも、 以下に示す方法でデータを正しく複製できます。

  1. ソース表内に新しい列を作成します。
  2. 既存の行に、新しい列にある固有の値を割り当てます。
  3. その表を複製ソースとして定義します。
  4. 新しいキー列を、圧縮されたターゲット表のサブスクリプション・セットに組み込みます。
  5. 行がソース表に挿入される時点で、新しい列に固有のキー値を割り当てます。

複製における一般的な制約事項

DB2 DataPropagator には現在のところ、 特定のオペレーティング・システム環境とデータ・タイプにおいていくつかの制約事項があります。 主な制約は、次のとおりです。


非 IBM ソース用の収集トリガー

収集トリガーは、IBM 以外のデータベースからの複製に使用します。 収集トリガーはソース表からの変更データを収集し、それらを複製で使用可能にします。 収集トリガーは、収集プログラムが DB2 に対して行う作業と同じ作業を実行しますが方法が異なります。 収集トリガーは DJRA により生成されます。

ソース表を複製ソースとして定義した場合、DJRA は DB2 DataJoiner により IBM 以外のソース・データベースに収集トリガーを作成します。 収集トリガーはソース・データに対するコミット済み変更を収集し、収集した変更を整合した変更データ (CCD) 表と呼ばれるステージング表に入れます。 DB2 DataJoiner には CCD 表のニックネームがあり、 変更を複製するプログラム (変更適用プログラムなど) はこのニックネームにアクセスできます。 CCD 表の詳細については、データのステージングを参照してください。

各ソース表には、DELETE、UPDATE、および INSERT という 3 つのトリガーがあります。

収集トリガーがデータ変更を収集する方法

収集トリガーは、CCD 表、登録制御表、枝取り制御表、および登録同期化制御表を操作します。

DJRA は、実行すると次の処理を行う SQL を生成します (複製ソースとして表を定義した場合)。

定義済みソースで削除、更新、または挿入操作が生じると、収集トリガーはその変更を CCD 表に記録します。 変更情報を取り出すときに、収集トリガーは CCD 表に挿入する変更前列および変更後列のデータも取得することができます。

ターゲット表の基本キー値が更新されたり、更新される論理区分列が表 (または視点) に入っていたりする場合、 複製ソースを定義する際に複製論理区分化キー・サポートを指定しなければなりません。 複製論理区分化キー・サポートを指定すると、UPDATE は、DELETE の後に INSERT が実行されるものとして実行されます。 詳しくは、複製論理区分化キーのサポートを使用できるようにするを参照してください。

その後で、変更適用プログラムは CCD 表を読み取り (DB2 DataJoiner ニックネーム経由)、ターゲット・サーバーに変更をコピーし、ターゲット表に変更を適用します。

図 18 は、収集トリガー、ソース表、登録制御表、および CCD 表の関連を示しています。

図 18. ソース・サーバーでの収集トリガー. 収集トリガーはソースの変更をモニターし、変更データを収集し、変更データを CCD 表に書き込みます。


ソース・サーバーでの収集トリガー

収集トリガーと既存トリガー

DJRA が収集トリガーを作成して、それを IBM 以外のデータベースに置くとき、次のような状況が生じるかもしれません。

推奨事項: DJRA の収集トリガーと既存トリガーの間で対立が予想される場合は、 両方のトリガーの内容を 1 つのトリガーにまとめます。 表イベントごとに、既存の業務トリガーを、DJRA で生成された収集トリガー・スクリプトの終わりに追加してください。


データのステージング

複製時には通常、ソース表への変更が収集され、変更された行が CD 表に挿入され、 関連しているトランザクション情報が UOW 表に挿入されます。 CD 表は UOW 表と結合され、どの変更がコミットされてターゲット表に複製できるようになっているかを判別します。 この結合された出力結果は CCD 表に保管することができ、 変更されたデータ情報をそこから読み出すことも可能です。 CCD 表に入れることができるのはコミット済み変更に限られます。 CCD 表を使用することで、複数のサブスクリプション・セット (とそのメンバー) がその情報を参照するたびに、 CD 表と UOW 表を結合するときのオーバーヘッドがサブスクリプション・サイクルごとに生じないようにします。 18

CCD 表には、CD 表と UOW 表の結合を不要にすること以外にもいくつかの用途があります。 複製環境をセットアップするときは、その複製環境に適した CCD 表のタイプを選ぶことができます。 CCD 表を使用する必要があるかどうかを知りたい場合は、 この節で説明している CCD 表の属性と CCD 表の標準的な使い方を参照してください。

CCD 表の属性

CCD 表を使用したい場合は、それをどこに置くか、また何の変更データをそれに入れるかを決める必要があります。

ローカル CCD 表とリモート CCD 表の比較

ローカル CCD 表はソース・データベースにあります。 リモート CCD 表はソース・データベースから離れている場所、 つまり変更適用プログラムがアクセスできるネットワーク内の他のデータベースにあります。 リモートのターゲットが多数ある場合は、リモート CCD 表をソース表として使用することで、 ソースからのネットワーク・トラフィックを軽減できます。

完全 CCD 表と不完全 CCD 表の比較

完全 CCD 表 には、 ソース表または視点からのソース視点と述部に適合するすべての 行が入っています。 変更適用プログラムは完全 CCD 表を全最新表示のソースとして、 あるいは変更を他のターゲット表に複製するときに使用します。

不完全 CCD 表 には、ソース表に対して行われた変更だけが入れられます。 したがって、不完全 CCD 表は最初は空の状態で、ソース表が変更されるたびに中身が増えていきます。 不完全 CCD 表を最初に作成した時点、あるいは収集プログラムのコールド・スタートが行われた時点では、 変更適用プログラムは不完全 CCD 表の最新表示を、ソース表のすべての行では行いません。 19 変更適用プログラムはソース表に対する変更は記録しますが、元の行の複製は行いません。 また、不完全 CCD 表を使って他のターゲット表を最新表示することはできません。

圧縮 CCD 表と非圧縮 CCD 表の比較

圧縮 CCD 表 には、列の最新値しか入れることができません。 たとえばソース表で、ある行が 5 回変更された場合、 圧縮 CCD 表にはそのソース表に対する 5 回の変更すべての結果を示す 1 つの行が入れられます。 圧縮 CCD 表には変更が統合されるため、 ステージ化された複製を行うときのネットワーク・トラフィックが減少します。 非圧縮 CCD 表 には、 複製ソースの行に対する変更ごとに 1 つの行が入れられます。 この場合、ソース表で 1 つの行が 5 回変更されると、 非圧縮 CCD 表には 5 つの行 (1 回の変更につき 1 つの行) が入れられます。 つまり、各行の変更に対する活動記録が示されています。 非圧縮 CCD 表は、監査に役立てることができます。

固有索引の定義: 圧縮 CCD 表は行ごとに固有のキー値を指定する必要がありますが、 非圧縮 CCD 表は複数の行に同じキー値を指定することができます。 キーの固有性には違いがあるため、 圧縮 CCD 表には固有索引を必ず 定義してください。 反対に、非圧縮 CCD 表には固有索引を定義しないでください

CCD 表の基本タイプ

表 5 には、CCD 表のタイプが、 指定可能な属性の組み合わせごとにまとめられています。

表 5. CCD 表の基本タイプ
CCD 表には、ローカルまたはリモート、完全または不完全、 圧縮または非圧縮といったタイプがあり、これらを組み合わせることも可能です。
場所 完全 圧縮 説明
ローカル はい はい ソース・データベースに置かれており、 複製ソースと同じデータが入れられる CCD 表。
いいえ ソース・データベースに置かれており、 変更に関する完全な活動記録 (複製ソースからの元データを含む) が入れられる CCD 表。
いいえ はい ソース・データベースに置かれており、 最新の変更データのみが入れられる CCD 表。
いいえ ソース・データベースに置かれており、 すべての変更データのみが入れられる CCD 表。
リモート はい はい 変更適用プログラムがアクセスできるデータベース (ソース・データベースを除く) に置かれており、 ユーザー表と同じデータが入れられる CCD 表。
いいえ 変更適用プログラムがアクセスできるデータベース (ソース・データベースを除く) に置かれており、 変更に関する完全な活動記録 (複製ソースの元データを含む) が入れられる CCD 表。
いいえ はい 変更適用プログラムがアクセスできるデータベース (ソース・データベースを除く) に置かれており、 最新の変更データのみが入れられる CCD 表。
いいえ 変更適用プログラムがアクセスできるデータベース (ソース・データベースを除く) に置かれており、 すべての変更データのみが入れられる CCD 表。

CCD 表を複製ソースとして使用する

CCD 表は、他のターゲット表に対して複製のソースとして使用できます。 20

内部および外部 CCD 表

複製環境によっては、完全 CCD 表を複製ソースとして登録することが可能です (外部 CCD 表)。 あるいは、複製において暗黙的にソースとして使われるように CCD 表を 設定することもできます (内部 CCD 表)。

外部 CCD 表

外部 CCD 表に全最新表示を実行する場合、変更適用プログラムは、この外部 CCD 表を複製ソースとして使用するすべてのターゲット表上で全最新表示を実行します。 このプロセスのことをカスケード全最新表示 と呼びます。 1 つの複製ソースには、複数の外部 CCD 表を定義できます。 外部 CCD 表には属性を自由に設定できます (ローカルまたはリモート、完全または不完全、圧縮または非圧縮)。 ただし、外部 CCD 表を使ってデータをステージ化する場合は、 変更適用プログラムがその表を使って全最新表示と変更複製の両方を行うため、 必ず完全 CCD 表を使用してください。

内部 CCD 表

内部 CCD 表は、変更のステージングに役立てることができます。 変更適用プログラムは全最新表示するときには元のソース表を、 また変更を複製するときは内部 CCD を (変更が複製されるたびに CD 表と UOW 表を結合させる代わりに) 使用します。 21

内部 CCD 表は、ソース表に対するコミット済み変更用のローカル・キャッシュとして使用します。 変更適用プログラムは、CD 表からではなく、内部 CCD 表 (存在する場合) から変更を複製します。

内部 CCD 表は、それを特に複製ソースとして定義しなくても、 複製における暗黙的なソースとして使用できます。 サブスクリプション・セット・メンバーを追加する場合、 表の属性が以下に示すものであれば、内部 CCD 表が必要であることを指定できます。

複数層ステージングで CCD 表を複製ソースとして使用する

以下に示すリストには CCD 表のすべてのタイプが明記されており、 それらのタイプがステージング・データに適しているかどうかを解説しています。

完全圧縮 CCD 表

このタイプの CCD 表は複製ソースとして定義することができ、 以下に示す方法で使用します。

通常は、この表はソースでローカルに作成する代わりにターゲットに近い場所に作成することによって、 変更複製と全最新表示のときのネットワーク・トラフィックを節約するようにします。 さらに、ソース表の 1 つの行に対して複数の更新をかけると、 1 つの行がすべてのターゲット表に複製されることになります。

完全非圧縮 CCD 表

このタイプの CCD 表は、複製ソースとしても内部 CCD 表としても定義しないでください。

それぞれの変更をすべて保管することで消費されるスペースの関係上、 このタイプの CCD 表は複製ステージング表としては使用しないでください。

この表には最初に、行が全部揃った状態で入れられます。 その後は、行の変更が行われるたびにそれがすべて付加されます。 情報は上書きされることも、失われることもありません。 このタイプの CCD 表は、その CCD 表を初期化した後にはいつでも、 時間的要素 (たとえば、前の火曜日以降、1 か月前、 昨日など) が関係する照会を処理しなければならないアプリケーションで使用できます。 さらに、完全に揃った行を必要とするアプリケーションの監査にも使用できます。 (監査を行うそれ以外の方法については、データ使用量の監査で説明しています。)

不完全圧縮 CCD 表

このタイプの CCD 表は、複製ソースの内部 CCD 表として定義できます。 これを内部 CCD 表として定義することにより、 元のソースへは全最新表示のときにだけアクセスし、 更新のときは CCD 表を使用することになります。 この方法では CD 表と UOW 表の結合は 1 回しか行われず、 それによって CCD 表にデータが入れられた後は、 変更の複製はすべてのターゲットに対して CCD 表から行われるため、 結合のためのオーバーヘッドを生じることがなく効率的です。 なお、CCD 表は不完全であるため、全最新表示は元のソース表から行う必要があります。 このタイプの表は、CD 表からの変更データを圧縮するときにも役立ちます。 圧縮を実行すると各行の最後の変更以外のすべての変更が除去されるため、 リモート・サイトへ複製する行の数、およびターゲット表に対する SQL 操作の数が減少します。

不完全非圧縮 CCD 表

ほとんどの場合、このタイプの CCD 表は複製ソースとして定義しないでください。 このタイプの表は、すべて揃っている行は不要で、 比較的新しく変更された行だけを必要とするアプリケーションの監査に使用します。

リモートのターゲット自体が非圧縮である場合は、 CCD 表を複製ソースの内部 CCD として定義できます。 この場合、リモートのターゲットが多数あるときは、 CD 表を繰り返し UOW 表と結合させることを回避することにはメリットがあります。 ただし、それはこのメリットが CCD 表の保管と保守を行うコストよりも重要な場合に限られます。

複数のターゲットで内部 CCD 表を使用する

内部 CCD 表をターゲットとして定義した場合、 ソース表に関連付けられている他のすべてのターゲット表の変更は、 元のソース表ではなくその内部 CCD 表から複製されるようになります。 そのため、対象となる可能性のあるすべてのターゲット表を計画するときには、 内部 CCD 表を正しく定義することが重要です。 内部 CCD 表にはソース表のすべての列を組み込んでおらず、 ターゲット表にはそれらの列がすべて組み込まれている場合、複製は失敗します。 同様に、内部 CCD 表を保守するのに使っている CD 表にはソース表のすべての列を組み込んでおらず、 ターゲット表にはすべての列が組み込まれている場合、やはり複製は失敗します。

内部 CCD 表では、UOW 表の列の追加はサポートされません。 そのため、(UOW 列がある) ターゲット CCD 表を複製ソースとして定義すると、 内部 CCD 表は定義できません。 UOW 列を含んでいるターゲット CCD 表をすでに定義している場合は、 内部 CCD 表は使用しないでください。

内部 CCD 表で列サブセット化を使用したい場合は、 以前に定義したすべてのターゲット表を検討し、 該当する列がすべてソース表からその内部 CCD 表の定義に組み込まれていることを確認してください。 内部 CCD 表にサブスクリプション・セットを定義した後に、 このソースから別のいずれかのサブスクリプション・セットを定義した場合、 その別のサブスクリプション・セットは内部 CCD 表にある列に限定されます。

非関係データまたは非 IBM データがある CCD 表の使用

CCD 表は、別のデータベース管理システム (Oracle など) のアプリケーション・プログラム やツールによって収集された変更を複製するのに使うことができます。 Oracle の表に対してトリガーを実行すると、 変更を Oracle CCD 表に入れることにより、収集プログラムをシミュレートします。 さらに、非 IBM ソースに対する収集トリガーは、 変更を複製するのに内部 CCD セットアップを使用します。 この使用法については、DB2 以外の分散データ・ストアからデータを取り出すにある例を参照してください。

同様に、他のツール (IMS DataPropagator) によって収集した変更は、 サブスクリプション・セット用のソースとして定義できます。 アプリケーション・プログラムでは、完全 CCD 表を作成し、保守しなければなりません。 なお、その CCD 表は外部 CCD 表とみなされます。 この CCD 表は必ず外部表になりますが、圧縮でも非圧縮でも可能です。 たとえば、IMS DataPropagator は IMS DB セグメントへの変更を収集し、その CCD 表を更新します。 この CCD 表を複製ソースとして定義した後、 元の更新が発生した場所に関係なくこの CCD 表を使ってサブスクリプション・セットを定義します。 この使用法については、リモート・サイトへの IMS データの配布にある例を参照してください。

CD 表および CCD 表の枝取り

収集プログラムは、変更適用プログラムによって枝取り制御表に挿入された情報に基づいて CD 表を枝取りできます。 収集プログラムで CD 表を枝取りするかどうかは、PRUNE または NOPRUNE パラメーターを使って制御します。 また、チューニング・パラメーター制御表を変更することによって、枝取りを実行するタイミングと整理間隔を設定する方法を制御することができます。

CCD 表によっては (特に非圧縮 CCD 表)、サイズが大きくなり続けるものがあります。 これらの表は自動的に枝取りされないため、手作業でそれらを枝取りするか、 アプリケーション・プログラムを使用する必要があります。 CCD 表のタイプによっては、表を枝取りせずにアーカイブし、新しい表を定義することもできます。

ソース表が非 IBM 表である場合、収集トリガーは、変更適用プログラムが枝取り制御表に書き込む同期点に基づいて CCD 表を整理します。


データ使用量の監査

監査とは、時刻と更新ユーザー ID を使ってデータを比較したり、変更を識別したりして、その前後のデータ使用に関する活動記録を追跡することです。

IBM レプリケーションは、次のようにして監査をサポートします。

変更前イメージおよび変更後イメージ
複製ソースを定義するときに、更新された行の変更前イメージ列をターゲット表に含めることができます。 監査やアプリケーション・ロールバック機能を必要とする業界では、 変更前イメージと変更後イメージのコピーのセットが役立ちます。

活動記録の保守

非圧縮 CCD 表は、UPDATE、INSERT、または DELETE 操作のたびに 1 つの行を保持するので、ソース表で実行された操作の活動記録を保守することができます。 UPDATE 操作を INSERT および DELETE 操作 (区分化キー列用) として収集する場合、 CCD 表は、DELETE と INSERT にそれぞれ 1 つの行、UPDATE にそれぞれ 2 つの行を指定します。

重要: 変更データの活動記録を正確なものにしておきたい場合は、 収集プログラムのコールド・スタートは行わないでください。 収集プログラムをシャットダウンした後で変更適用プログラムが変更を複製できないと、 ギャップが生じることがあります。 ソース表とターゲット表の間のギャップの解決を参照してください。

不完全な非圧縮 CCD 表は、ソース表への更新に関する部分的な活動記録を保管したり、 データベース使用の監査証跡を保守したりするために使用します。 監査機能を向上させるには、UOW 表からの付加的な列を含めます。 22

ソース表に対する変更の活動記録を完全なものにしておくには、 完全な、圧縮されていない CCD 表を使ってください。

詳細については、CCD 表の属性を参照してください。

トランザクション識別
監査では、CD 表と UOW 表のいくつかの列を使用できます。 UOW 表ではソース・サーバーで変更された行のおよそのコミット時刻が見つかり、CD 表では操作タイプ (INSERT、UPDATE、および DELETE) が見つかります。 この情報を保持しておく必要がある場合は、 DJRA を使って UOW 列を含んでいる不完全 CCD 表を定義し、 それらの CCD 表を複製することができます。 通常、収集プログラムは CD 表と UOW 表の枝取りを行いますが、 CCD 表の枝取りは行いません。

ユーザー指向の識別がさらに必要であれば、UOW 表で、DB2 (OS/390 版) の相関 ID に関する列、 基本許可 ID、または AS/400 のジョブ名およびユーザー・プロファイルを使用することができます。


移行の計画

AS/400 での移行:

DPropR/400 のバージョン 1 はバージョン 7 と同時に実行することができません。 現在バージョン 1 を使用しているか、バージョン 1 の複製構成要素をバージョン 5 の DPropR/400 環境で使用する場合は、 以下のいずれかを行う必要があります。

DPropR/400 の V5 から V7 への移行には、特別な移行作業は必要ありません。

すべての複製管理作業では DJRA を使用する必要があります。 ただし、DJRA および DB2 コントロール・センターは両方とも、 複製ソースとサブスクリプション・セットを定義する基本複製管理機能を装備しています。

OS/2、UNIX、Windows での移行:

DB2 ユニバーサル・データベース (Windows 版、OS/2 版、UNIX 版) のバージョン 5 からは、 複製構成要素は自動的に DB2 と同時にインストールされます (つまり、オプションではありません)。 DB2 UDB バージョン 7 をインストールした後に、次のようなことはできません。

DB2 UDB の V6 から V7 への移行には、複製のための特別な移行作業は必要ありません。

重要: バージョン 1 とバージョン 6 またはバージョン 7との間における 複製構成要素の相互操作性はサポートされていません。 そのため、バージョン 1 からバージョン 5 への移行作業は、 DB2 UDB バージョン 6 またはバージョン 7の導入前に行わなくてはなりません。 手順については、DB2 DataPropagator の Web サイト (www.ibm.com/software/data/dpropr/) の 「Library」ページから入手できる Migration Guide を参照してください。

バージョン 5 の収集および変更適用プログラムの構成要素は、 バージョン 6 またはバージョン 7 の収集および変更適用プログラムの構成要素と一緒に実行できます。 すべてのサーバーを同時に移行する必要はありません。

さらに、

DB2 UDB は、DB2 ユニバーサル・データベース サテライト・エディションのイネーブラー・コマンド ASNSAT をサポートします。 しかし、既存の複製環境で DB2 ユニバーサル・データベース サテライト・エディションの SYNCH コマンドを使用することはできません。 SYNCH コマンドは、中央制御サーバーが制御する中央管理に依存しているからです。 中央制御サーバーは、SYNCH コマンドを使用しないで管理される既存の複製環境を認識しません。

DB2 ユニバーサル・データベース サテライト・エディションについて詳しくは、 DB2 ユニバーサル・データベース サテライト管理 手引きおよび解説書 を参照してください。

OS/390 での移行:

バージョン 1 とバージョン 6 またはバージョン 7 との間における 複製構成要素の相互操作性はサポートされていません。 そのため、バージョン 1 からバージョン 5 への移行作業は、 DB2 (OS/390 版) バージョン 6 またはバージョン 7 の導入前に行わなくてはなりません。 手順については、DB2 DataPropagator の Web サイト (www.ibm.com/software/data/dpropr/) の 「Library」ページから入手できる Migration Guide を参照してください。

DB2 (OS/390 版) の V6 から V7 への移行には、複製のための特別な移行作業は必要ありません。

バージョン 5 の収集および変更適用プログラムの構成要素は、 バージョン 6 またはバージョン 7 の収集および変更適用プログラムの構成要素と一緒に実行できます。 すべてのサーバーを同時に移行する必要はありません。


脚注:

13
DB2 (MVS/ESA 版) V4 以降および DB2 ユニバーサル・データベース V5 以降で実行される 収集プログラム (OS/390 版) は、アーカイブ・ログ・レコードを回復できます。

14
ASNLOAD ユーティリティーを使用する場合は、ロード予備ファイルではなくロード入力ファイルになります。

15
DATALINK 列がある表がサブスクリプション・セットに含まれている場合、 この値には ASNDLCOPY 出口ルーチンに渡すファイルの数も指定できます。

16
たとえば、銀行会計の更新をどこに送るかを知りたい場合に、該当顧客はその銀行のどの支店と取り引きしているかを調べるため、会計表と顧客表を結合しなければならないことがあります。 通常、支店番号などの地理的詳細がデータベースのどこにも重複して保管されないよう、実働データベースは正規化されます。

17
単純な内部結合に使用する CCD 表は完全圧縮である必要があります。データのステージングを参照。

18
随時更新複製では CCD 表は使われません。

19
収集プログラムをコールド・スタートしている途中でソース表に対する変更が行われた場合、 それらの変更は不完全 CCD 表には取り込まれません。 そのような変更が不完全 CCD 表に確実に複製されるようにするには、 収集プログラムをコールド・スタートする時点で、ソース表に対するすべての活動を停止する必要があります。

20
非 IBM データベースでは CCD 表をターゲットとして定義できますが、ソースとしては定義できません。 さらに、CCD ターゲットが非 IBM データベース内にある場合は、 それを内部 CCD 表または外部 CCD 表のいずれにすることもできません。

21
内部 CCD 表を定義すると、その表は、レプリカを持つサブスクリプション・セット をターゲットとして処理する場合に変更適用プログラムによって無視されます。

22
ターゲット CCD 表を複製ソースに定義した後で内部 CCD 表を定義したい場合は、 内部 CCD 表が UOW 表の列の追加をサポートしない点に注意してください。 UOW 列を含んでいるターゲット CCD 表をすでに定義している場合は、 内部 CCD 表は使用しないでください。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]