ここでは、複製をセットアップして開始するステップについて説明します。 各オペレーティング・システムでの収集プログラムと変更適用プログラムの操作に関する細かい情報は含まれていません。 詳細については、操作を参照してください。
複製環境をセットアップするには、以下に示す一般的な手順に従ってください。
管理者は、DB2 コントロール・センターまたは DB2 DataJoiner 複製管理 (DJRA) を使用して、複製のソースおよびターゲットの定義、ターゲット更新のスケジュールの設定、 ターゲット・データへの拡張の指定、および複製を開始するトリガーの定義を行います。 ソース表とターゲット表が DB2 ユニバーサル・データベースのデータベース (任意のオペレーティング・システム環境) にある場合のみ、 DB2 コントロール・センターを使用して複製を管理することができます。しかし、DJRA は、 ソース表とターゲット表が DB2 ユニバーサル・データベースのデータベース (任意のオペレーティング・システム環境) にあるか、 サポート対象になっている IBM 以外のデータベースにある場合に複製管理に使用できます。
この章に説明のある管理タスクは、収集プログラムと変更適用プログラムの両方で使われ、 更新データを取り込んだ後、それを正しい形式と適切な間隔でターゲット表に複製します。
複製環境をセットアップする際には、DB2 コントロール・センターを使用して、 ソースおよびターゲット表定義と制御表を管理することができます。 複製オブジェクトを管理するには、以下のハイレベルなステップを使用します。
制御表を作成し、複製ソースおよびターゲットを定義した後、 データの複製を開始するには、収集および変更適用プログラムを構成および実行することが必要です。
コントロール・センターを介して、複製ソースおよびターゲットにアクセスすることができます。 コントロール・センターには、 複製環境のセットアップおよび保守に使用するオブジェクトを編成するコンテナーとして、 次の 3 つがあります。
それぞれのオブジェクトには、そのオブジェクトで実行できるアクションが入ったメニューもあります。
コントロール・センターから DB2 (MVS/ESA 版)、DB2 (VSE 版)、DB2 (VM 版)、または DB2 (AS/400 版) サーバーに接続する場合、 リモート・データベースへのコネクティビティーの構成、リモート・データベースのカタログ、 およびカタログへのパッケージのバインドを行う必要があります。
データベースをバインドするには、次のようにします。
DB2 CONNECT TO dbname USER userid USING password DB2 BIND @DDCSxxx.LST ISOLATION CS BLOCKING ALL SQLERROR CONTINUE
ここで、CS はカーソル固定分離レベルを指定し、xxx は MVS、VSE、VM、 または AS/400 のいずれかのプラットフォーム名を指定します。
ユーザー ID とパスワードが、 コントロール・センター・ワークステーションでのローカル・ログオン ID およびパスワードと異なる場合には、 リモート・データベース・オブジェクトのポップアップ・メニューから、 「接続 (Connect)」メニュー項目を使用して、 データベース・サーバーに明示的に接続する必要があります。
「ツール設定 (Tools Settings)」ノートブックには、DB2 ユニバーサル・データベースの管理ツールについてのデフォルト・プリファレンスが入っています。 図 19 で示されているように、 ノートブックの「複製 (Replication)」ページで複製のデフォルト値を設定することができます。 このデフォルト値は、コントロール・センターが管理するすべての複製活動で使われます。
図 19. 「ツール設定 (Tools Setting)」ノートブックの「複製 (Replication)」ページ. このページを使って、複製のデフォルトのプリファレンスを指定します。
![]() |
CD 表名、索引名、表スペース名は、複製ソースやサブスクリプション・セットを定義するときにカスタマイズできます。 これらの名前を変更するには、テンプレート・ファイル DPREPL.DFT を編集します。 このファイルはコントロール・センターの作業ディレクトリー (\sqllib\bin または \sqllib\java) にあります。 構文および例については、そのファイルの指示を参照してください。
このファイルを使用する場合は、 「ツールの設定 (Tools Settings)」ノートブックの「複製 (Replication)」ページでそのことを指定します。 図 19 を参照してください。
DB2 DataJoiner 複製管理 (DJRA) ツールを使用して複製管理作業を実行すると、 DJRA はソース、ターゲット、または制御サーバーに接続して、 そのサーバーに制御情報およびターゲット表を作成および更新します (実行するオペレーションによって異なります)。 DJRA があるクライアント・ワークステーションは、 DJRA によって管理されているすべてのソース、ターゲット、 および制御サーバーに接続する許可を与えられ、接続できる状態でなければなりません。
DJRA は、ソースおよびターゲット表定義を定義および管理するためのオブジェクトやアクションを提供します。 DB2 DataJoiner と併用した場合、DJRA は以下のものを作成します。
変更適用プログラムは DB2 DataJoiner ニックネームを読み取るかニックネームに書き込むため、 IBM 以外のデータベースに明示的に接続する必要はありません。
ソース・データベースが DB2 データベースの場合、そのデータベース用の収集プログラムは変更データを収集するため、収集トリガーと DB2 DataJoiner は関係ありません。 ターゲット・データベースが DB2 データベースの場合、変更適用プログラムは変更データを直接 DB2 ターゲット・データベースに書き込むため、DB2 DataJoiner は関係ありません。
DJRA は、DB2 DataJoiner、収集プログラム、収集トリガー、および変更適用プログラムとともに、さまざまなソースからさまざまなターゲットに関係データを複製します。 DJRA がソースまたはターゲットとしてサポートしているデータベースは以下のとおりです。
DB2 ソース、ターゲット、または制御サーバーの場合、 DB2 DataJoiner の分散データベース接続サービス (DDCS) または DB2 コネクト製品を使って接続できます。 IBM 以外のソースおよびターゲットの場合、DJRA は DB2 DataJoiner を使用して IBM 以外のサーバーに接続します。
DJRA では、制御表、複製ソース、サブスクリプション・セット、 および SQL の実行または編集を処理する領域ごとに分類されたユーザー・インターフェースが準備されています。 (図 20 を参照してください)。
このインターフェースを使用して、以下の管理作業を実行することができます。
上にリストした管理作業の大部分は、論理をカスタマイズすることもできます。
![]() |
DB2 UDB を Windows システム上にインストールすると、 DB2 セットアップ・プログラムは DJRA セットアップ・プログラム (djra.exe) を \sqllib\djra ディレクトリーにコピーします。 DJRA は DB2 DataJoiner V2 にも同梱されています。 それで、DataJoiner を Windows NT 上にインストールするときに、 DJRA をインストールするよう指定することもできます。 さらに、DJRA を Web アドレス 24 からダウンロードすることも可能です。 DJRA をインストールする時点でオブジェクト REXX がまだインストールされていない場合は、 DJRA によってオブジェクト REXX のインストールが実行されます。 すでにインストールされていれば、DJRA は既存のものを使用します。
DJRA の稼働環境は以下のとおりです。
DJRA をインストールする方法:
以下のプリファレンスを設定することができます。
プリファレンスを設定するには、DJRA 基本ウィンドウのメニューから「ファイル」->「プリファレンス (Preference)」を選択します。 プリファレンスは、いつでも変更することができます。
「プリファレンス (Preference)」ノートブックの「接続 (Connection)」ページでは、システムで現在カタログされているデータベースのリストが表示されます。
制限: 複製環境で Microsoft SQL Server を使用しているなら、別名ユーザー ID は使用しないでください。 Microsoft SQL Server は別名ユーザー ID を拒否するからです。
DJRA のステージング表、索引、述部などは、 以下に示すウィンドウから該当する「論理の編集 (Edit Logic)」ボタンを選択すればカスタマイズできます。
推奨事項: ソース表が非 IBM 表である場合は、 CCD 表の所有者を変更しないでください。
さらに、「複製ソースとして複数の表を定義 (Define Multiple Tables as Replication Sources)」ウィンドウ にある「論理の編集 (Edit Logic)」ボタンを選択することもできます。 この場合は、CD_TABLE (または CCD_TABLE) パラメーター値の末尾に 3 桁の番号を追加してください。 DJRA はこの番号を自動的に増やしていくことで、それぞれの表の名前が一意になるようにします。
デフォルト・ディレクトリー (C:\) を変更することにより、 表スペースを作成する場所を指定できます。 ディレクトリー名の後ろには必ず円記号 (\) を追加してください。
「作成表論理の編集 (Edit Create Table Logic)」ボタン を選択し、ターゲット表を作成する表スペースまたはセグメントを指定します。
デフォルト・ディレクトリー (C:\) を変更することにより、 表スペースを作成する場所を指定できます。 ディレクトリー名の後ろには必ず円記号 (\) を追加してください。
さらに、 「複数のメンバーをサブスクリプション・セットに追加 (Add Multiple Members to Subscription Sets)」ウィンドウの「述部論理の編集 (Edit Predicate Logic)」や「作成表論理の編集 (Edit Create Table Logic)」ボタンを選択することもできます。
通常、複製制御表は、次に示す方法のいずれかで作成されます。
個々のデータベース・プラットフォームで実行する SQL の調整法に関する詳細は、 ファイル内のコメントを参照してください。 次のような定義では、DPCNTL ファイルをカスタマイズする必要があります。
このオプションを使用する場合、既存の制御表を除去してから表をカスタマイズしない限り、 複製制御表のカスタマイズを行うことはできません。 OS/390、VSE/ESA、または VM/ESA で実行する場合、 複製制御表をカスタマイズしなければなりません。
カスタマイズ制御表を作成するときは、DPCNTL ファイルの CREATE TABLE ステートメントをカスタマイズする必要があります。 各オペレーティング・システム環境別の DPCNTL ファイルは、 sqllib\samples\repl\ ディレクトリーにあります。 ファイル名は次のとおりです。
カスタマイズ制御表の作成後、それを除去する必要が生じる場合、 DPNCNTL ファイルの DROP TABLE ステートメントをカスタマイズする必要があります。 各オペレーティング・システム環境別の DPNCNTL ファイルは、 sqllib\samples\repl6\ ディレクトリーにあります。 ファイル名は次のとおりです。
制御表を作成または除去するために SQL をカスタマイズするには、次のようにします。
db2 -tf dpcntl.platform_name db2 -tf dpncntl.platform_name
複製に含まれる DB2 (および DataJoiner) システムごとに、 制御表を作成する必要があります。 25 このステップを完了すると、DJRA は登録表、枝取り制御表、および登録同期制御表を、 データベース・ソースに配置します (IBM 以外のソースの場合には、これら DB2 DataJoiner 内の表に応じたニックネームを作成します)。
DJRA の 1 次ウィンドウから、「複製制御表の作成 (Create Replication Control Tables)」をクリックします。 制御表を作成するために完成させるフィールドは、以下のとおりです。
制御表を、リモート・サーバーのデータベースではなく DataJoiner のデータベースに作成したい場合、(なし) を指定します。
これ以外のプラットフォームでは、 デフォルトの表スペース名は TSnnnnnn (nnnnnn は固有の識別子) になっています。
プロシージャーが正常に終了したら、 「ファイル (File)」->「保管 (Save)」の順に選択してファイルを保管します。 これで、必要な場合には複製 SQL ファイルのカスタマイズおよび実行にリストされているガイドラインに基づき、 生成された SQL を編集できるようになりました。 準備ができていれば、 「ファイル (File)」->「実行 (Run)」の順に選択して SQL を実行します。 SQL を実行する前に、生成された SQL を保管する必要があります。 SQL を生成および実行して、複製ソースまたはサブスクリプション・セットを作成する前に、 制御表を生成するよう SQL を実行する必要があります。
DB2 コントロール・センターから、オプション選択によって、複製タスクをただちに実行することも、 または、生成した SQL ファイルを保管して後から実行することもできます。 DJRA からは、メイン・ウィンドウから SQL ファイルを実行または編集することができます。 SQL ファイルは、大規模な複製アクション (サブスクリプション・セットの定義など) 用にカスタマイズすることも、コントロール・センターまたは DJRA のいずれかでサポートされる、 実装法を超えたアプリケーション用にカスタマイズすることもできます。
SQL ファイルを保管またはカスタマイズして、以下のことを行うことができます。
大規模な複製サブスクリプションの定義を SQL ファイルに保存しておけば、 必要なときにその定義を再実行できます。
生成済みの SQL を編集するときは、DJRA が SQL に挿入した特殊マーカーを変更しないように注意してください。 たとえば、:ENDOFTRIGGER: または :ENDOFPROCEDURE: は、DJRA を正常に実行するのに必要なコメントの一部です。 トリガー作成ブロックを変更すると、SQL が正しくなくなり、実行するとエラーが生じることがあります。 ファイルの終わりに行を追加する場合は、必ずそのファイルの末尾に改行 (CRLF) を追加しておいてください。
DJRA の「SQL の実行 (Run SQL)」押しボタンは、DJRA で生成された SQL に対して使用するためのものです。 DJRA 以外で生成された SQL に対して DJRA を使って実行すると失敗することがあります。 同じように、DJRA で生成された SQL を DB2 コマンド行で実行すると失敗することがあります。
推奨: DJRA で生成された SQL は DJRA から実行してください。
DB2 DataPropagator は表主導型であるため、すべての複製オブジェクトの機密保護は、 データベースの機密保護に依存しています。 複製ソースとサブスクリプション・セットを定義するデータベース管理者は、 それらの機密保護も定義します。 さらに、収集プログラムには、ソース・データベースにアクセスする権限がなければなりません。 また、変更適用プログラムには、制御、ソース、およびターゲット・データベースにアクセスする権限がなければなりません。
複製ソースおよびサブスクリプション・セットを定義すると、DB2 コントロール・センターと DJRA は数多くの表を作成します。 オペレーティング・システムによっては、表スペースと DB スペースを作成する場合もあります。 このようなアクションではすべて、高レベルのデータベース特権が必要です。 そのため、複製の管理者として働き、また各ソース・データベースにおいて、 オブジェクトの作成、プランのバインド、および生成した SQL を実行するためのユーザー ID を最低 1 つは設ける計画をたてる必要があります。
収集プログラムを実行するユーザー ID は、DB2 システム・カタログにアクセスできなければなりません。 また、複製制御表にアクセスおよび更新でき、収集プログラム・パッケージに対する実行特権を持っていなければなりません。 収集プログラムを実行するユーザー ID は、管理者ユーザー ID と同じものですが、 これは要件ではありません。
OS/390 の場合、収集プログラムを実行するユーザー ID は、SYSADM 権限か、 または次に示す権限のいずれかを持っていなければなりません。
VM および VSE の場合、収集プログラムを実行するユーザー ID は DBA 権限を持っていなければなりません。 他のすべてのオペレーティング・システムの場合、収集プログラムを実行するユーザー ID は DBADM 権限か SYSADM 権限のいずれかを持っていなければなりません。
変更適用プログラムを実行するユーザー ID は、ソース、制御、およびターゲット・サーバーと、 コントロール・センターか DJRA がインストールされているワークステーションで有効なログオン ID でなければなりません。 変更適用プログラムを実行するユーザー ID は、ソース表にアクセスできなければなりません。 また、すべての複製制御表にアクセスおよび更新でき、ターゲット表を更新できなければなりません。 またこのユーザー ID は、変更適用プログラム・パッケージに対する実行特権も持っていなければなりません。 変更適用プログラムを実行するユーザー ID は、管理者ユーザー ID と同じものですが、 これは要件ではありません。 正しい許可があれば、任意のユーザー ID でどの変更適用プログラム・インスタンスでも実行できます。
変更適用プログラムには、ソースまたはターゲット・サーバーに接続するためのパスワード・ファイルが必要なことがあります。 変更適用プログラムの許可要件についての詳細は、操作にあるご使用のオペレーティング・システムに該当する『収集プログラムおよび変更適用プログラム』の章を参照してください。
DB2 コントロール・センター を使って複製ソースを定義するには:
ソース・データベースの「表 (Tables)」フォルダーをクリックして、 すべての表を表示します。 表オブジェクトの上で右クリックして、ポップアップ・メニューを表示し、 「複製ソースとして定義 (Define as replication source)」を選択します。
複製ソースを定義するには、 「クィック (Quick)」または「カスタム (Custom)」選択項目を使用します。 「クィック (Quick)」は、 デフォルト値を使って複製ソースを定義するのに使います。 「カスタム (Custom)」は、 デフォルト値をカスタマイズするのに使います。たとえば、 特定の列が取り込まれないよう指定するときに使います。
ソースを定義すると、 「複製ソース (Replication Sources)」フォルダー内にオブジェクトが作成されます。 これでソース表を、サブスクリプション・セットに定義できます。
DJRA を使って複製ソースを定義するには:
「複製ソースとして 1 つの表を定義 (Define One Table as a Replication Source)」、 または「複製ソースとして複数の表を定義 (Define Multiple Tables as Replication Sources)」をクリックして、 ソース・サーバー、ソース表名、およびソース列などの必要な情報を書き込みます。
収集トリガーについては、非 IBM ソース用の収集トリガーを参照してください。 複製ソースとサブスクリプション・セットの定義に関するデータ制約の詳細については、 複製における一般的な制約事項を参照してください。
収集プログラムは、reinit コマンドを発行するか、 収集プログラムを停止して再始動するかのいずれかを行わない限り、新しい DB2 の複製ソースを識別しません。 収集プログラムは、複製ソースに応じてサブスクリプション・セットが作成され、 サブスクリプション・セット・メンバーが全最新表示されない限り、 複製ソースの取り込みの更新を始めません。
DB2 コントロール・センター を使って随時更新用の複製ソースを定義するには:
カスタム複製ソースを定義してから、次のようにします。
重要: ソース表とレプリカの間の矛盾した更新は検出されません。 このオプションは、随時更新複製ではお勧めしません。
このオプションを選択すると、DB2 コントロール・センターは、すべての列で「ソースとして定義 (Define as Source)」および 「変更前イメージの取り込み (Capture before image)」チェック・ボックスも選択します。
変更適用プログラムが不定期接続の環境 (asnsat コマンド、 または COPYONCE キーワードを使って開始) で実行するときに、 拡張対立検出を指定しても、変更適用プログラムは標準対立検出を使用します。
DJRA を使って随時更新用の複製ソースを定義するには:
複製ソースとして表を定義するときに対立検出レベル (上記で説明済み) を選択し、 サブスクリプション・セットにメンバーを追加するときにレプリカのターゲット構造を選択します。
随時更新を使用する場合:
対立のリスクと、拒否された矛盾するトランザクションのコストを削減するには、 次に示す条件のもとで随時更新複製を使用します。
随時更新複製の場合、次のときに更新の対立が生じます。
変更適用プログラムは、サブスクリプション・サイクルのときに、すでに発生した更新の対立を検出します。 ソース表は、1 次表とみなされます。 つまりこの表は、レプリカ表から更新を受け取ることができますが、 対立があった場合、ソース行が受け入れられ、レプリカ表の矛盾したトランザクションは拒否されます。 変更適用プログラムは、CD 表内のキー値とソースおよびターゲット表とを比較して、行の直接の対立を検出します。 対立を検出する場合、プログラムは UOW 表で拒否されたというマークをレプリカのトランザクションに付け、 レプリカのトランザクションをロールバックします。
変更適用プログラムは、読み取り従属関係を検出することはできません。 たとえば、後で (DELETE ステートメントによって、またはロールバック・トランザクションによって) 除去されることになる情報をアプリケーションが読み取る場合、 変更適用プログラムは従属関係を検出することはできません。
DB2 DataPropagator では、対立検出をして、検出なし、標準検出、 および拡張検出の 3 つのレベルが提供されています。 どのレベルにも数値が付いていて、登録制御表の CONFLICT_LEVEL 列に保管されます。 喪失または拒否されたトランザクションの許容度とパフォーマンス要件に基づいて、 どのタイプの検出を使用するかを決定しなければなりません。 対立検出のレベルおよびそれらを指定する方法に関する詳細は、 随時更新複製の複製ソースの定義を参照してください。
制約事項: 対立検出レベルを個々の複製ソースに設定した場合でも、 変更適用プログラムはサブスクリプション・セットのすべてのメンバーのレベルとして、 サブスクリプション・セット・メンバーの対立検出レベルのうち最も高いものを使用します。
UOW 表で提供される拒否コードを使うと、拒否されたトランザクション別に CD データ表内の変更前と変更後の行値を識別できます。 ASNDONE 出口ルーチンは、各サブスクリプション・サイクルの最後で実行するため、 ルーチンにコードを追加して、拒否されたトランザクションを処理することができます。 ASNDONE 出口ルーチンについて詳しくは、ASNDONE 出口ルーチンの使用を参照してください。 あるいは、拒否されたトランザクションの変更データ行と UOW 制御表は、 通常の枝取りを免除されている (ただし、RETENTION_LIMIT 枝取りは受ける) ため、 UOW 表を走査するプログラムを使って、拒否されたトランザクションをバッチ処理することができます。
他の表の視点となる複製ソースを定義できます。 視点に含まれる各複製ソース表を定義し終わったら、次に視点複製ソースを作成できます。 そうすると、その視点複製ソースは、ターゲット表への複製で使用できるようになります。
DB2 コントロール・センターを使って、既存の視点を複製ソースとして定義することはできません。DJRA を使用してください。 新規の視点であれば、DB2 コントロール・センター を使ってそれを複製ソースとして定義できます。
DB2 コントロール・センターを使って視点を定義するには:
USERID.VIEW_NAME AS SELECT A.COL1, A.COL2, B.COL6, B.COL5
CREATE VIEW という語を入力しないでください。 ステートメントのこの部分は、処理時に自動的に入力されます。
TABLEA A, TABLEB B
FROM という語を入力しないでください。 ステートメントのこの部分は、処理時に自動的に入力されます。
A.COL1=B.COL1
WHERE という語を入力しないでください。 ステートメントのこの部分は、処理時に自動的に入力されます。
DJRA を使って視点を複製ソースとして定義するには:
「複製ソースとして DB2 の視点を定義 (Define DB2 Views as Replication Sources)」をクリックして、 必要な情報 (ソース・サーバー、ソース視点の修飾子、およびソース視点名など) を書き込みます。 DJRA を使って結合を複製ソースとして定義することはできませんが、 結合の視点を定義した上で、DJRA を使ってその視点を複製ソースとして定義することは可能です。
収集プログラムは通常、ソース表に加えられた更新を UPDATE ステートメントとして取り込みます。 ただし次の条件のもとでは、 収集プログラムに更新を DELETE および INSERT ステートメントとして取り込むように指示しなければなりません (つまり論理区分化キー・サポートを使用可能にしなければなりません)。
ターゲット表の基本キーの値は、 新しいキー値を反映するソース・サーバーに取り込まれた変更から取られるため、 これらの値を使用して既存のターゲット表の行 (まだ存在していない) を検出することはできません。 UPDATE を DELETE および INSERT ペアに変換すると、 ターゲット表はソース・サーバー上で加えられた変更を反映するようになります。
この場合、述部に含まれる列を基本キー列にする必要はありません。 サブスクリプション・セットが、特定の列値 (たとえば、WHERE DEPT = 'J35') に基づく述部で定義され、 その列を変更すると (たとえば、DEPT='FFK' に変更)、取り込まれた変更は述部としての基準を満たしていないため、 複製では選択されません。 つまり、新しい FFK 部門は、サブスクリプションが部門 J35 に基づいているため複製されません。 UPDATE を DELETE および INSERT ペアに変換すると、 ターゲット表列は確実に削除されます。
論理区分化キー・サポートを使用可能にすると、 論理区分化キーのソース列が変更されて複写されるとき、1 つのノードからもう 1 つのノードへとターゲット行を確実に移動します。 古いノードで DELETE を、新しいノードで INSERT を実行すると移動します。
更新は、DB2 ソースと非 DB2 ソースの両方に対する、更新または削除 / 挿入のペアとして収集できます。
デフォルトでは、ソースまたはターゲット表の基本キーを更新すると、 収集プログラムは更新用に変更済みの行を取り込みます。 その後、変更適用プログラムが、新しいキー値を使って、ターゲット表上の行の更新を試みます。 この新しいキー値はターゲット表内に見つからないので、変更適用プログラムはこの更新を挿入に変換します。 この場合、古いキー値をもつ古い行は表内に残ります。これは不要な行です。 複製論理区分化キー・サポートを使用可能にすると、収集プログラムは、 変更を別個の DELETE および INSERT ステートメントとして取り込みます。 古い行を削除して、新しい行を挿入してください。
DATALINK 列が ON UNLINK DELETE として定義されている場合、 DELETE と INSERT のペアが同じトランザクション内で処理されるため、 このリンク解除は無視されます。 外部ファイルは削除されませんが、更新は行われます。
取り込んだそれぞれの UPDATE は、すべての列 (キー列だけでなく非キー列も) の CD 表内の 2 つの行に変換されます。 この取り込んだデータの増加に合わせて CD 表のスペース割り振りを調節する必要があるかもしれません。
DB2 コントロール・センターを使ってソース表を定義する場合、「複製ソースとして定義 (Define as Replication Source)」ウィンドウで、 「削除および挿入として取り込まれた区分化キー列の変更データ (Changed data for partitioned key columns captured as delete and insert)」チェック・ボックスを選択して、 収集プログラムが DELETE および INSERT ステートメントとして更新を取り込むよう指定します。
DJRA を使ってソース表を定義する場合、「複製ソースとして 1 つの表を定義 (Define One Table as a Replication Source)」ウィンドウか、 または「複製ソースとして複数の表を定義 (Define Multiple Tables as Replication Sources)」ウィンドウで、 「削除 / 挿入のペアとして更新 (Updates as delete/insert pairs)」ラジオ・ボタンを選択します。
推奨事項: CCD 表の定義には DJRA を使ってください。 DB2 コントロール・センター は CCD 表の作成は行うものの、それらを定義することはできません。
DJRA を使って CCD 表を定義するには、 「サブスクリプション・セットにメンバーを追加 (Add Member to a Subscription Set)」ウィンドウ の「ターゲットの構造 (Target structure)」として「CCD」を選択した後、 「セットアップ (Setup)」押しボタンをクリックします。 「ターゲット・サーバーのステージング (CCD) 表特性の選択 (Staging (CCD) table property selection for target server)」ウィンドウ から、任意の CCD 表のタイプを選択します。 このウィンドウでは、CCD 表のすべての有効な組み合わせから選択するよう指示されます。
不完全 CCD 表の場合、UOW 表の 1 つまたは複数の列を含めることができます。 これらの列は監査のときに役立てることができ、変更適用修飾子、許可 ID、UOW ID、 その他のものがそこに入れられます。
CCD 表を使って複製をステージングする (たとえば、3 層の複製環境にする) 予定であれば、 以下に示す手順に従ってください。
そのサブスクリプション・セットを所有する変更適用プログラムは、 そのサブスクリプション・セットの定義に基づいて CCD 表にデータを入れます。
DJRA の「ターゲット・サーバーのステージング (CCD) 表特性の選択 (Staging (CCD) table property selection for target server)」ウィンドウから完全 CCD 表を 1 つ選択した後、 「外部複製ソースとして登録 (Register as external replication source)」チェック・ボックスを選択します。 詳細については、複製ソースの定義を参照してください。
この新しいセットは、CCD 表からターゲット表に変更を適用する変更適用プログラムになります。 変更適用修飾子は通常、CCD にデータを入れるのに使った修飾子とは別のものを使用しますが、 同一のものを使用することも可能です。
複製サブスクリプション・セットの定義を参照してください。
使用する CCD 表のタイプにより、以下のようにソース表を選択します。
制約事項: 内部 CCD 表を登録するには、 ソース・サーバーとターゲット・サーバーが併置されている必要があります。 登録できる内部 CCD の数は、それぞれのソース表に 1 つだけです。
CCD 表について詳しくは、データのステージングを参照してください。
DB2 コントロール・センターを使って、複製サブスクリプション・セットを定義するには、次のようにします。
変更適用プログラムがターゲット表を作成して、その表に DATALINK 列を入れるよう指定した場合、 これらの列のリンク制御のレベルはデフォルト (なし) になります。 これらの列のリンク制御のレベルを変更したい場合は、 生成された SQL を編集してその CREATE TABLE ステートメントを修正し、 リンク制御のレベルを新たに指定します。 その後、変更した SQL を実行してください。
DJRA を使って複製サブスクリプション・セットを定義するには:
サブスクリプション・セットにメンバーを追加するときに、 ターゲット表でどの基本キーを使用するかを指定できます。 DJRA がターゲット基本キーをソース基本キーとソース表の索引から生成するよう指定したり、 キーの特定の列を指定したり、あるいはソース基本キーを指定することが可能です。
IBM 以外のソース・サーバー用にサブスクリプション・セットを作成した後で、変更適用プログラムはその非 IBM サーバーに関連した DB2 DataJoiner データベースに接続し、 非 IBM ソース・サーバーにある登録制御表およびステージング表の情報に (ニックネーム経由で) アクセスします (図 21 を参照)。
図 21. 活動中の DB2 DataJoiner. ソース表が IBM 以外の表 (太線) の場合、DB2 DataJoiner ニックネームは非 IBM ソース・サーバーへのアクセスと、 非 IBM ソース表への変更に対するアクセス (ステージング表経由) を 変更適用プログラムに与えます。ソース表が DB2 表 (細線) の場合、DB2 DataJoiner ニックネームは IBM 以外のターゲット表へのアクセスを変更適用プログラムに与えます。
![]() |
イベントによって変更適用プログラムを起動するよう定義している場合、イベント表にデータを挿入する必要があります。 この作業についての詳細は、イベント・タイミングを参照してください。 ターゲット表へのデータの複製を開始するには、ソース・サーバーで収集プログラムを開始した後、 「コントロール・センターのサブスクリプション情報 (Control Center Subscription Information)」ウィンドウ (または、「サブスクリプション・セットに複数のメンバーを追加 (Add Multiple Members to Subscription Sets)」ウィンドウ) で指定した制御サーバーの名前を使用して変更適用プログラムを開始します。
DB2 コントロール・センターを使って随時更新複製のサブスクリプション・セットを定義するには、 サブスクリプション・セットを定義してから次のようにします。
矛盾が生じないよう、この基本キーをソース表の基本キーと同じにします。 ターゲット表の基本キー列として変更前イメージを使用しないでください。
重要: 既存のターゲット表の場合、 基本キー列を選択する必要があります。
DJRA を使って随時更新複製の複製サブスクリプションを定義するには、 サブスクリプション・セットにメンバーを追加するときに、レプリカのターゲット構造を選択します。
ユーザー・コピーのデフォルト・ターゲット・タイプを使いたくない場合には、 ターゲット表タイプを指定することができます。
DB2 コントロール・センターを使ってターゲット表タイプを指定するには:
DJRA を使ってターゲット表のタイプを指定するには:
「サブスクリプション・セットへのメンバーの追加 (Add a Member to Subscription Sets)」または 「サブスクリプション・セットへの複数のメンバーの追加 (Add Multiple Members to Subscription Sets)」をクリックします。 サブスクリプション・セット・メンバーに必須の情報を入力します。 「表の構造 (Table structure)」ドロップダウン・リストから、 ターゲット表のタイプを指定することができます。 使用可能なタイプには、DB2 コントロール・センターで説明されたものと同じタイプに加えて CCD 表のタイプに応じた選択項目も含まれます。
アプリケーションによっては、 ソース表内に存在するすべての行または列がターゲット表に必要であるとは限りません。 コントロール・センター または DJRA を使って、 ターゲット表がソース表の列または行サブセットになるように定義することができます。 サブセット化について詳しくは、列および行のサブセット化を参照してください。
制約事項: レプリカ・ターゲット表には、 ソース表と同じ列が入っていなければなりません。 つまり、この表をサブセット化したり、列を追加したり、列の名前を変更したりすることはできません。
DB2 コントロール・センターを使ってターゲット表列を定義するには:
ある列をターゲット表の基本キー列と指定したい場合、 列名の次の「基本キー (Primary Key)」チェック・ボックスを選択します。
重要: ユーザー・コピー、時刻、レプリカ、 または圧縮ステージング表のいずれかのターゲット表タイプを使用する場合には、 1 つ以上の列を基本キーの一部として選択する必要があります。 基本キー用の列を選択しない場合、DB2 はソース表の基本キー定義を使用します。 しかし、ソース表に基本キー定義がない場合は、変更適用プログラムはエラー・メッセージを発行します。
列の名前を変更したい場合、編集したい列の名前を選択し、既存の列名を上書きします。 列名は最大 17 文字で、通常識別子または区切り識別子にすることができます。
ターゲット表の列定義を変更したい場合、「変更 (Change)」をクリックして、「列変更 (Change Column)」ウィンドウをオープンします。 このウィンドウで、次のことを行うことができます。
式は最大 254 文字で、任意の有効な SQL 式にすることができます。 この式には、通常識別子または区切り識別子を含めることができます。 この式に使用される列は、ソース表の有効な変更後イメージ列でなければなりません。 これらの列名は、「使用可能な列 (Available columns)」ボックスにリストされます。
有効な SQL 式については、DB2 SQL 解説書 を参照してください。 SQL 式が無効であると、サブスクリプションが変更適用プログラムで処理されるときに SQL エラーが発生します。
ターゲット表から列を除去したい場合は、 列名の次の「サブスクリプション (Subscribe)」チェック・ボックスをクリアします。
ターゲット表について新しい算出列を作成するかまたは集約を使用したい場合は、次のようにします。
DJRA を使ってターゲット表の列を定義するには:
「サブスクリプション・セットへのメンバーの追加 (Add a Member to Subscription Sets)」ウィンドウで、 「選択した列 (Selected columns)」ラジオ・ボタンをクリックします。 それから、ターゲット表に複製したい列を選択します。
DB2 コントロール・センターを使ってターゲット表行を定義するには:
どの行をターゲット表にコピーするかを指定するには、 「WHERE」フィールドに SQL 述部を入力します。 この述部には、通常識別子または区切り識別子を含めることができます。 WHERE 文節についての詳細は、DB2 SQL 解説書 を参照してください。
行の述部の制約:
次に示す例には、ターゲット表の行をフィルターするために使用できる WHERE 文節が含まれます。 これらの例は一般的であり、モデルとして使用するためのものです。
特定の値 (たとえば、管理職にある社員を表す MGR) をもつ行だけをコピーするには、次のような WHERE 文節を使用します。
EMPLOYEE = 'MGR'
ある範囲の値 (たとえば従業員番号 5000〜7000) の行をターゲット表にコピーするには、次のような WHERE 文節を使用します。
EMPID BETWEEN 5000 AND 7000
集約をサポートするには、WHERE 文節を次のように使用します。
1=1
DJRA を使ってターゲット表の行を定義するには:
「サブスクリプション・セットへのメンバーの追加 (Add a Member to Subscription Sets)」ウィンドウの 「WHERE 文節 (Where clause)」フィールドに WHERE 文節を追加します。
DB2 DataPropagator を使うと、以前に定義した DB2 表を、 サブスクリプション・セットでのターゲット表として使用できます。 つまり、サブスクリプション・セットのメンバーが DB2 コントロール・センターまたは DJRA の外部で定義されているターゲット表になるように定義することができます。 このタイプのターゲット表を、ユーザー定義のターゲット表と呼びます。
制約事項:
ユーザー定義のターゲット表を使用したサブスクリプションを定義するには、次のようにします。
DB2 コントロール・センターの「サブスクリプションの定義 (Define Subscription)」ウィンドウで、 以下のようにします。
代わりの表タイプを選択したい場合、ターゲット表タイプの選択を参照してください。 ユーザー定義のターゲット表に合致するようにターゲット表列を変更したい場合、 行のサブセット化や集約式の使用を行いたい場合には、ターゲット表の構造の定義: 列および行を参照してください。
DJRA は既存のターゲット表を許容し、 そのターゲット表内の列がサブスクリプション・セットのメンバー用に定義された列と合致するかどうか検査します。
DB2 DataPropagator は、サブスクリプション定義とユーザー定義のターゲット表との間に矛盾があるかどうかを検査しません。 以下のことを行う必要があります。
変更適用プログラムがソース表からターゲット表にデータをコピーする前または後に実行する SQL ステートメントまたはストアード・プロシージャーを定義できます。 たとえば、古い項目を削除して、1 日ごとに適用追跡制御表を枝取りすることができます。
DB2 コントロール・センターを使って、 サブスクリプション・セット用の SQL ステートメントまたはストアード・プロシージャーを定義するには、 次のようにします。
「SQL」ウィンドウは、複製サブスクリプションの処理前または処理後のいずれかに、 ターゲットまたはソース・サーバーで実行依頼される SQL ステートメントまたはストアード・プロシージャーを、 追加または除去するために使用します。 ステートメントは、リスト内の順序どおりに処理されます。
有効な 5 バイトの SQLSTATE 値を「SQLSTATE」フィールドに入力してから、 「追加 (Add)」をクリックします。 この値は、「SQLSTATE 許容値 (Acceptable SQLSTATE values)」ボックスに追加されます。 10 個までの値を入力できます。
DJRA を使ってサブスクリプションの SQL ステートメントまたはストアード・プロシージャーを指定するには:
「ステートメント番号 (Statement number)」スピン・ボックス からステートメント番号を選択した後、「有効な SQLSTATE 値 (Acceptable SQLSTATE values)」フィールドに 5 バイトからなる有効な SQLSTATE 値を入力します。
System/390 データ共用環境に複製を実装することができます。 データ共用環境では、ソース・データ共用グループにつき 1 つの収集プログラムか、 またはターゲット・データ共用グループにつき 1 つ以上の変更適用プログラムを実行します。
収集プログラムは、サポートしているすべてのバージョンの DB2 (OS/390 版) のデータ共用ログを読み取ることができます。 つまり、データ共用環境では、たとえば、別のバージョンへの移行時で、1 つの収集プログラムがトランザクション整合データの取り込みを継続する場合に、 別の DB2 バージョンを実行することができるということです。 しかし、こうしたバージョンが混在する環境を、複製または DB2 のいずれかで長期間使用することはお勧めできません。 DB2 のバージョンが混在する環境でのデータ共用については、DB2 (OS/390 版) 管理の手引き を参照してください。
DB2 DataPropagator が、何分間分の変更データをサブスクリプション・サイクルに移すことができるかを指定するには、 DB2 コントロール・センターでは、「サブスクリプション・タイミング (Subscription Timing)」ノートブックの「データ・ブロック (Data Blocking)」ページを使用します。 また、DJRA では、「空のサブスクリプション・セットの作成 (Create Empty Subscription Sets)」ウィンドウの「ブロック化因数 (Blocking factor)」を設定します。 指定する分の値によって、データ・ブロックのサイズが決まります。 この値の決定方法についての詳細は、変更が大量である場合のデータのブロック化を参照してください。
DB2 DataPropagator は、この値をサブスクリプション・セット制御表の MAX_SYNCH_MINUTES 列に保管します。 この値を変更するには、以下に示す SQL ステートメントを実行します。
UPDATE ASN.IBMSNAP_SUBS_SET SET MAX_SYNCH_MINUTES=new_val WHERE APPLY_QUAL=ApplyQual AND SET_NAME=name AND WHOS_ON_FIRST=val
new_val は新しいブロック化因数値、 ApplyQual は現行の変更適用修飾子、 name は現行のサブスクリプション・セットの名前、 そして val は F または S のいずれかです。
ターゲット表をどの程度最新のものにしておきたいですか? ターゲット表を使用するアプリケーション・プログラムを混乱させずに、 どの程度古い表を許容できますか? こうした質問に対する答えは、データの現行性の要件を示しています。 どのくらいの頻度で変更適用プログラムがサブスクリプションを処理するのか、 その結果データの現行性を制御することになるのかを制御することができます。 変更適用プログラムの間隔 (または相対時間) のスケジュールを設定したり、 変更適用プログラムがサブスクリプション・セットの処理を開始するのに使用するイベント・トリガーを定義したりすることができます。
DB2 コントロール・センターでは、「サブスクリプション・タイミング (Subscription Timing)」ノートブックを使ってサブスクリプション・タイミングを定義します。また、DJRA では、 「空のサブスクリプション・セットの作成 (Create Empty Subscription Sets)」ウィンドウの 「サブスクリプション・セットのタイミング (Subscription set timing)」フィールドを使用します。 時間に基づくスケジューリングまたはイベント・ベースのスケジューリングを使用してタイミングを制御したり、 これらのタイミング・オプションを一緒に使うことができます。 たとえば、ある 1 日の間隔を設定する一方で、 あるイベントによってサブスクリプション・サイクルを起動するよう指定することもできます。 随時更新複製の場合、ソースからレプリカへの複製およびレプリカからソースへの複製に応じて、 別々のタイミングを指定することもできます。
推奨事項: 試験環境から実稼働環境へと移動する際、 中性能のタイミング値 (2 時間など) を設定して、そこから必要に応じて頻度を上げたり、 または下げたりしてシステムを調整します。
サブスクリプションのタイミングを制御する最も単純な方法は、間隔タイミングを使用することです。 特定の開始時間、日付、および間隔を決定します。 間隔は、特定の値 (1 分〜1 年) または連続した値にすることができますが、 時間間隔はおおよその値になります。 変更適用プログラムは、作業負荷とリソースの可用性に基づいて、 可能な限りすみやかにサブスクリプション・セットを開始します。 連続したタイミングを指定すると、変更適用プログラムは可能な限り頻繁にデータを複製します。
ある間隔を選択しても、複製の頻度が正確にその間隔になるとは限りません。 間隔を指定する前に、その間隔内でサブスクリプション・セットにあるすべての表を最新表示できるかどうかを判別します。 また、それぞれの間隔ごとに変更適用プログラムが選択すると思われるデータ量を判別してから、 そのデータをコピーするのに必要な時間を概算します。
DB2 コントロール・センター、DJRA を使用して、またはサブスクリプション・セットの制御表に対して SQL ステートメントを実行することにより、間隔の設定および変更を行うことができます。
イベント・タイミングを使ってデータをコピーするには、DB2 コントロール・センターまたは DJRA でサブスクリプション・セットを定義するときにイベント名を指定します。 イベント名のタイム・スタンプを指定したサブスクリプションのイベント表を (アプリケーション・プログラムまたは DB2 コマンド・センターを使って) 移入する必要もあります。 変更適用プログラムがイベントを検出すると、複製 (変更データ収集または全最新表示のいずれか) を開始します。
サブスクリプション・イベント表には、表 6 で示されているように、3 つの列があります。
EVENT_NAME | EVENT_TIME | END_OF_PERIOD |
---|---|---|
END_OF_DAY | 2000-05-01-17.00.00.000000 | 2000-05-01-15.00.00.000000 |
EVENT_NAME は、サブスクリプション・セットの定義時に指定するイベントです。 EVENT_TIME は、変更適用プログラムがサブスクリプション・セットの処理を開始する時刻を示すタイム・スタンプです。 END_OF_PERIOD は、該当時刻より後の更新が後の日付まで据え置かれることを指定するオプション値です。 EVENT_TIME は、制御サーバーのクロックにより設定されますが、END_OF_PERIOD はソース・サーバーのクロックにより設定されます。 2 つのサーバーが別の時間帯にある場合、この区別は重要です。
表 6 によると、END_OF_DAY という名前のイベントの場合、タイム・スタンプ値 (2000-05-01-17.00.00.000000) は、変更適用プログラムが複製サブスクリプションの処理を開始する時刻です。END_OF_PERIOD のタイム・スタンプ値 (2000-05-01-17.00.00.000000) は、 更新が複写されなかった後、次の日のサイクルで複写される時刻です。 つまり、イベントは 3 時前に作成されたすべての未解決の更新を複写して、それに続くすべての更新を延期します。
ご使用のアプリケーション・プログラムは、イベントをサブスクリプション・イベントに通知し、 アプリケーション・プログラムをサブスクリプションの活動に結び付けます。 CURRENT TIMESTAMP に 1 分加算した値を使って EVENT_TIME に項目を通知すると、 EVENT_NAME に指定したイベントが起動します。 このイベントに結び付けられたサブスクリプション・セットはすべて、 1 分で実行するのに適したものとなります。 イベントは、翌週、翌年、または毎週土曜日のように、前もって通知することができます。 変更適用プログラムが実行されている場合、変更適用プログラムは指定されたおおよその時刻に処理を開始します。 変更適用プログラムは、指定された時刻に停止しており、後で再始動されると、 サブスクリプション・イベント表をチェックして、 通知されたイベントのサブスクリプション・セットの処理を開始します。
変更適用プログラムがサブスクリプション・セットを処理した最新の時点 (サブスクリプション・セットの制御表の LASTRUN 列にある値で指定) より前に発生するイベントは、 期限切れのイベントとみなされて無視されます。 そのため、変更適用プログラムが実行中である場合は、 期限切れのイベントを通知することを避けるため、 時間的にわずかに先のイベントを通知しなければなりません。
サブスクリプション・セットのタイミングは、 サブスクリプション・セット表の値を変更することにより、 収集プログラムと変更適用プログラムの両方が実行中のときに変更できます。 たとえば間隔値を変更するときは、以下に示す SQL ステートメントを実行します。
UPDATE ASN.IBMSNAP_SUBS_SET SET INTERVAL_MINUTES=new_val WHERE APPLY_QUAL=ApplyQual AND SET_NAME=name AND WHOS_ON_FIRST=val
new_val は新しい間隔値、 ApplyQual は現行の変更適用修飾子、 name は現行のサブスクリプション・セットの名前、 そして val は F または S のいずれかです。
間隔のタイミングの代わりにイベントのタイミングを使用するようサブスクリプション・セットを変更するには、 以下に示す SQL ステートメントを実行します。
UPDATE ASN.IBMSNAP_SUBS_SET SET REFRESH_TIMING='E', EVENT_NAME='END_OF_DAY' WHERE APPLY_QUAL=ApplyQual AND SET_NAME=name INSERT INTO ASN.IBMSNAP_SUBS_EVENT (EVENT_NAME, EVENT_TIME) VALUES ('END_OF_DAY', 'timestamp')
new_val は新しい間隔値、 ApplyQual は現行の変更適用修飾子、 name は現行のサブスクリプション・セットの名前、 val は F または S のいずれか、 そして timestamp は変更適用プログラムがサブスクリプション・セットの処理を開始する時刻のタイム・スタンプです。 END_OF_DAY というイベントがすでにあれば上記の INSERT ステートメントは不要ですが、 EVENT_TIME は変更しなければならない場合があります。
上記の制御表について詳しくは、サブスクリプション・セット表、および サブスクリプション・イベント表を参照してください。
サブスクリプション・セットを計画および定義するときには、 以下に示す規則と制約に注意する必要があります。
独自の CCD 表を保守したい場合には、登録制御表にある 3 つの列 (CCD_OLD_SYNCHPOINT、SYNCHPOINT、および SYNCHTIME) を更新しなければなりません。
CCD 表の全最新表示の前に、CCD_OLD_SYNCHPOINT を NULL に設定します。
CCD の全最新表示の後で、CCD_OLD_SYNCHPOINT を SYNCHPOINT の以前の値よりも大きな値に設定します。 SYNCHPOINT に前の値がない (これが初期ロードであるため) 場合は、CCD_OLD_SYNCHPOINT を X'00000000000000000000' に設定してください。
CCD 表への新しい変更をコミットしたらすぐ、CCD 表の SYNCHPOINT を MAX(IBMSNAP_COMMITSEQ) に設定します。 また、同じように SYNCHTIME の設定も行います。
DJRA は、表またはデータベースのオフライン・ロードの作成処理を支援します。 以下の手順では、外部 CCD 表のロードに必要な追加の制御情報は保守しません。 それで、こうした表の場合、手動手順を使用する必要があります。
DJRA を使用してオフライン・ロードを実行するには以下のようにします。
あるシステム (たとえば、試験システム) で表、複製ソース、またはサブスクリプション・セットを定義して、 複製環境を別のシステム (たとえば、実働システム) にコピーする必要がある場合には、DJRA プロモート機能を使用します。 これらの機能は、表、複製ソース、またはサブスクリプション・セットをリバース・エンジニアリングして、 適切なデータ定義言語 (DDL) およびデータ操作言語 (DML) 付きのスクリプト・ファイルを作成します。 表 7 で、3 つのプロモート機能を示します。
たとえば、プロモート機能を使用して、 リモート DB2 パーソナル・エディションのターゲット・データベース用のサブスクリプション・セットを定義します。 試験環境でモデルになるターゲット・システムを定義した後、 DB2 パーソナル・エディション用のサブスクリプション・セットのスクリプトを作成できます (または使用する変更適用修飾子の変更などを行うことができます)。 こうしないと、中央制御点からはサポートされません。
プロモート機能 | 説明 |
---|---|
プロモート登録 | この機能は、ソースの表および視点をソース・サーバーからプロモートします。 |
プロモート表 | この機能は、表、表スペース、および索引をプロモートします。
表に定義した制約はプロモートしません。
この機能は、DB2 UDB V5 およびそれ以降のバージョンで完全にサポートされています。 ただし、IBM 共通サーバーの場合、表はプロモートできますが、表スペースはプロモートできません。 |
プロモート・サブスクリプション | この機能は、サブスクリプション (サブスクリプション・セット、
サブスクリプション・セット・メンバー、サブスクリプション列、サブスクリプション枝取り制御、
およびサブスクリプション・ステートメント) をプロモートします。
この機能を使用すると、既存のサブスクリプション・セットから、
新しいサブスクリプション・セットを作成することができます。
DJRA の「サブスクリプションのプロモート (Promote Subscriptions)」ウィンドウで、 以下に示すフィールドのいずれかで新しい値を設定することにより、 サブスクリプションを (プロモートする前に) 変更することができます。 「変更適用修飾子 (Apply Qualifier)」、 「セット名 (Set Name)」、 「ソース・サーバー (Source server)」、 「ソース別名 (Source alias)」、 「ターゲット・サーバー (Target server)」、 「ターゲット別名 (Target alias)」、 「制御サーバー (Control server)」、 および「制御別名 (Control alias)」。 |
ここでは、収集プログラムの一般的な設定について説明します。 収集プログラムのセットアップに関する特定の情報については、 (操作にある) ご使用のオペレーティング・システム環境に応じた該当する章を参照してください。
収集プログラムのパフォーマンスを制御するために、 以下のチューニング・パラメーターをチューニング・パラメーター表に指定することができます。
AS/400 の場合、RGZPFM コマンドを使って表を再編成することにより、 表のサイズを小さくしておくことができます。
推奨事項: 収集プログラムが不必要に自ら遮断することがないよう、 遅延限度の範囲内で高い値を設定します。
データベースにアーカイブ・ログがないか、 またはサポートしていない場合に、収集プログラムが自ら遮断したときは、 収集プログラムのコールド・スタートを実行しなければなりません。
変更適用プログラムが収集プログラムと同時に実行されない 場合、 DB2 タイムアウト間隔より高いコミット間隔を設定してはいけません。
AS/400 の場合、この値には別の意味があります。この値は、 アプリケーション・プログラムがソース表を更新する時間と、 それに対応する CD 表の更新がディスクに書き込まれる時間との間の秒数です。 コミット間隔の範囲は、30〜600 秒にすることができます (デフォルトは 180 です)。 この値が小さすぎると、システム全体のパフォーマンスが低下する場合があります。
AS/400 の場合、STRDPRCAP コマンドの CLNUPITV キーワードの待機時間サブパラメーターの値を指定することにより、 この値を変更することができます。 CLNUPITV キーワードのクリーンアップの開始サブパラメーターに対して *NO を指定すると、 枝取り間隔値は無視されます。
AS/400 で収集プログラムを毎日始動する場合、*NO を指定すると枝取りを延期することができます (たとえば週末に延期)。 週中には、STDPRCAP コマンドに対して CLNUPITV (*DPRVSN *NO) を使用することができます。 週末には、CLNUPITV (*DPRVSN *IMMED) を使用することができます (これがデフォルトです)。
重要: CD 表の枝取りを手操作で行うときは、 最新の行を削除しないようにしてください。 表の中に少なくとも 1 つの行が必ずあるようにしてください。
チューニング・パラメーターを指定するには、以下のタスクのどちらかを行います。
UPDATE TABLE ASN.IBMSNAP_CCPPARMS SET RETENTION_LIMIT=number_of_minutes, LAG_LIMIT=number_of_minutes, COMMIT_INTERVAL=number_of_seconds, PRUNE_INTERVAL=number_of_seconds
収集プログラムを実行しているときに、 値を変更してチューニング・パラメーターを最新表示する必要が生じた場合、 表の値を変更した後で reinit コマンドを入力します。 AS/400 の場合、INZDPRCAP コマンドを入力します。 INZDPRCAP コマンドについて詳しくは、収集プログラム (AS/400 版) の再初期設定を参照してください。
チューニング・パラメーター表の構造については、表の構造を参照してください。
以下のアクションは、収集プログラムが実行中に終了してしまう原因になります。 以下のタスクのいずれかを実行したい場合は、収集プログラムを停止してください。
収集プログラムには、他に以下のような制約事項があります。
ここでは、変更適用プログラムの一般的な設定について説明します。 変更適用プログラムのセットアップに関する特定の情報については、 (操作にある) ご使用のオペレーティング・システム環境に応じた該当する章を参照してください。
変更適用プログラムは、ターゲット表の全最新表示を実行するときは、 そのつど ASNLOAD プログラムを呼び出すことができます。 LOADX パラメーターを指定して、変更適用プログラムがこのルーチンを呼び出すようにします。
ASNLOAD ルーチンは、変更適用プログラムに付けて提供されたままのものを使用できますが、 変更することもできます。 出荷されたままのものの場合、このルーチンは、DB2 エクスポート (EXPORT) ユーティリティーを使ってソース表からデータをエクスポートし、 DB2 ロード (LOAD) ユーティリティーを使ってターゲット表を全最新表示します。 すべての IBM またはベンダーのユーティリティーを呼び出すために ASNLOAD ルーチンを修正することもできます。 この出口ルーチンを修正する方法について詳しくは、\sqllib\samples\repl ディレクトリーにあるサンプル・プログラム (ASNLOAD.SMP) の Prolog に関する項をご覧ください。
参照整合性制約をもった表を全最新表示するときに、 参照保全検査をバイパスするには、ASNLOAD ルーチンを使用しなければなりません。
ソース・サーバーのパスワードが保護されている場合、 パスワード・ファイルを提供するように ASNLOAD ルーチンを変更する必要があります。 ただし、DB2 ユニバーサル・データベース サテライト・エディションによってパスワードが管理されている場合、ASNLOAD ルーチンはパスワード・ファイルを必要としません。 IBM 提供のルーチンを使用することができます。
ソース表に DATALINK 列が含まれていると、変更適用プログラムは ASNDLCOPY 出口ルーチンを呼び出しません。 全最新表示のときに外部ファイル (DATALINK 値によって参照されている) をコピーさせるには、 これらの列に対して ASNDLCOPY ルーチンを呼び出すように ASNLOAD ルーチンを修正しなければなりません。
AS/400 環境における ASNLOAD の使用について詳しくは、ASNLOAD 出口ルーチン (AS/400 用) を使ったターゲット表の最新表示を参照してください。
ASNLOAD ルーチンを実行すると、以下のファイルが生成されます。
このファイルは、ソースからエクスポートされたデータを含みます。
このファイルは、EXPORT API が発行したエラー・メッセージ、警告メッセージ、または通知メッセージを含みます。
このファイルは、LOAD API が発行したエラー・メッセージ、警告メッセージ、または通知メッセージを含みます。
ASNLOAD ルーチンを実行すると、以下のファイルが生成されます。
このファイルは、ソースからエクスポートされたデータを含みます。
このファイルは、EXPORT API が発行したエラー・メッセージ、警告メッセージ、または通知メッセージを含みます。
このファイルは、LOAD API が発行したエラー・メッセージ、警告メッセージ、または通知メッセージを含みます。
変更適用プログラムが ASNLOAD を呼び出している時にエラーが発生した場合か、 またはルーチンが非ゼロの戻りコードを戻した場合、変更適用プログラムはメッセージを出し、 そのサブスクリプションの処理を停止して、次のサブスクリプションを処理します。
ASNLOAD ルーチンを使って行えるのは、時刻指定表とユーザー・コピー表の最新表示だけです。 ターゲット表に対する ASNLOAD ルーチンの制約事項には、以下に示すものがあります。
変更適用プログラムは、サブスクリプション処理が成功または失敗のどちらであるかに関係なく、 その処理後にオプションとして ASNDONE 出口ルーチンを呼び出すことができます。 必要に応じて、このルーチンを変更することができます。 たとえば、このルーチンは、UOW 表を検査して、拒否されたトランザクションを検出したら、 メッセージの発行やアラートの生成などの事後アクションを始動することができます。この出口ルーチンの別の使用法は、障害が発生した (状況 = -1) サブスクリプション・セットを非活動化して、その障害が修正されるまで変更適用プログラムが再試行しないようにすることです。
この出口ルーチンを修正する方法について詳しくは、\sqllib\samples\repl ディレクトリーにあるサンプル・プログラム (ASNDONE.SMP) の prolog 部分をご覧ください。AS/400 の場合、以下の表で、このルーチンのソース・コードを検出できる場所を示します。
コンパイラー言語 | ライブラリー名 | ソース・ファイル名 | メンバー名 |
---|---|---|---|
C | QDPR | QCSRC | ASNDONE |
COBOL | QDPR | QCBLLESRC | ASNDONE |
RPG | QDPR | QRPGLESRC | ASNDONE |
AS/400 環境における ASNDONE 出口ルーチンの使用について詳しくは、ASNDONE 出口ルーチン (AS/400 用) の使用を参照してください。
ASNDONE 出口ルーチンを使用するには、以下のようにします。
変更適用プログラムが ASNDONE 出口ルーチンに渡すパラメーターは、以下のとおりです。
サブスクリプション・セットに DATALINK 列が含まれていると、 変更適用プログラムはサブスクリプション・セット・メンバーに対する処理を行っているときに ASNDLCOPY 出口ルーチンを呼び出し、 外部ファイルをコピーします。 このルーチンは必要に応じて修正できます (たとえば、ファイル転送プロトコルを変更するときなど)。
制約事項: ターゲット表が CCD 表である場合、 変更適用プログラムは ASNDLCOPY ルーチンを呼び出しません。 さらに、全最新表示のときに外部ファイル (DATALINK 値によって参照されている) をコピーさせるには、 これらの列に対して ASNDLCOPY ルーチンを呼び出すように ASNLOAD ルーチンを修正しなければなりません。
この出口ルーチンのセットアップと修正を行う方法については、 \sqllib\samples\repl ディレクトリー にあるサンプル・プログラム (ASNDLCOPY.SMP) の prolog 部分をご覧ください。 AS/400 の場合、サンプル・プログラムはライブラリー QDPR のソース・ファイル QCSRC のメンバー ASNDLCOPY の中にあります。
ASNDLCOPY 出口ルーチンを使用するには:
ASNDLCOPY ルーチンが完了した時点で、このルーチンは変更適用プログラムに戻りコードを返します。 ゼロ以外の戻りコードは、1 つまたは複数のファイルで複製が失敗したことを 変更適用プログラムに知らせます。 このような場合、変更適用プログラムはメッセージを出し、 そのサブスクリプションをスキップして次のサブスクリプションを処理します。 ゼロの戻りコードは、複製が正常に行われたことを変更適用プログラムに知らせます。
変更適用プログラムは ASNDONE 出口ルーチンを、 正常に処理されたかエラーが発生したかに関係なく、サブスクリプションの処理が完了した後に呼び出します。 そのため、ASNDLCOPY ルーチンが外部ファイルの複製に失敗した場合は、 ASNDONE 出口ルーチンを使って必要なクリーンアップを任意に実行できます。
ASNDLCOPY ルーチンは、ログ・ファイルとトレース・ファイル (トレースが有効になっている場合) の 2 つのファイルを作成します。 このログ・ファイルの名前は以下のとおりです。
ASNDLApplyQualSetNameSrcSrvrTgtSrvr.LOG
ApplyQual は変更適用修飾子、 SetName はサブスクリプション・セットの名前、 SrcSrvr はソース・サーバーの名前、 そして TgtSrvr はターゲット・サーバーの名前です。 ログ・ファイルには、ASNDLCOPY ルーチンが生成するすべてのメッセージが入れられます。 トレース・ファイルの名前は以下のとおりです。
ASNDLApplyQualSetNameSrcSrvrTgtSrvr.TRC
トレース・ファイルには、ASNDLCOPY ルーチンが生成するトレース情報がすべて入れられます。
変更適用プログラムが ASNDLCOPY 出口ルーチンに渡すパラメーターは、以下のとおりです。
入力データ・ファイルには、ソース表から収集したリンク参照先のリストが入れられます。 このファイルの形式は次のとおりです。
length source_link_reference new_link_indicator
フィールドは以下のとおりです。
入力行の終わりを示すには、改行文字を使用します。
サンプルの入力ファイル:
35 HTTP://S1.CDE.COM/data/yy/file1.avi Y 35 HTTP://S2.CDE.COM/data/qq/file2.avi N
結果ファイルには、ターゲット・システムに対して有効な、変換済みのリンク参照が含まれています。 このファイルの形式は次のとおりです。
length target_link_reference
length はターゲットのリンク参照の長さ、 target_link_reference はターゲット・リンクへの参照 (URL 形式) です。 ソース・ファイルが複製不可である場合、ASNDLCOPY ルーチンは結果ファイルの length を 0 に、 また target_link_reference をブランクに設定し、 ターゲット・ファイルの中でリンクが確立されないようにします。
サンプルの結果ファイル:
35 HTTP://T1.XYZ.COM/data/yy/file1.avi 35 HTTP://T2.XYZ.COM/data/zz/file2.avi
トレース・オプションは yes または no のいずれかにより、 トレース機能を使うかどうかを指定します。
ASNDLCOPY ルーチンには、ASNDLUSER と ASNDLSRVMAP という 2 つの構成ファイルが必要です。 ASNDLUSER ファイルにはサーバーのアドレス (URL 形式)、入力ポート番号、 出力ポート番号、ログイン用のユーザー ID、およびパスワードが収められます。 その最初のポート番号は、ASNDLCOPY ルーチンがファイルの取り出しを行うために接続する、 ソースの FTP またはファイル・コピー・デーモンのポート番号です。 また 2 番目のポート番号は、ファイルの送信に使用する、 ターゲットの FTP またはファイル・コピー・デーモンのポート番号です。 これら 2 つのポート番号は同一でも構いません。
サンプルの ASNDLUSER ファイル:
S1.CDE.COM 21 21 userA xxyyzz T1.XYZ.COM 21 24 userB xkxkxk
ASNDLSRVMAP ファイルにはリンク参照のサーバー・マッピング、 および任意指定のディレクトリー・パスのマップが収められます。 ディレクトリー・パスのマップを指定していない場合、 あるいはパスのマッピングが見つからない場合は、同一のパス名が使われます。
サンプルの ASNDLSRVMAP ファイル:
HTTP://S1.CDE.COM HTTP://T1.XYZ.COM HTTP://S2.CDE.COM HTTP://T2.XYZ.COM /data/qq /data/zz
特定の項目のすべてのフィールドは、同じ行になければなりません。
ASNDLCOPYD ファイル・コピー・デーモンは、ASNDLCOPY 出口ルーチンが使用するファイルを抽出します。 これは標準の FTP デーモンと似ていますが、DATALINK 複製のために以下に示す機能が用意されています。
推奨事項: ASNDLCOPYD ファイル・コピー・デーモンは、 「読み取り許可 DB (read permission DB)」属性が定義されている DATALINK 列を複製するときに使用します。 標準の FTP ではスーパーユーザーのアクセス権が必要になりますが、 ASNDLCOPYD デーモンではそのようなアクセス権は必須ではありません。
ASNDLCOPYD ファイル・コピー・デーモンは、特定ユーザーだけのログインを許可するよう構成できます。 また各ユーザーに対して、ディレクトリーのサブセットへのアクセスを許可することができます。 このプログラムのセットアップと修正を行う方法については、 \sqllib\samples\repl ディレクトリー にあるサンプル・プログラム (ASNDLCOPYD.SMP) の prolog 部分をご覧ください。 AS/400 の場合、サンプル・プログラムはライブラリー QDPR のソース・ファイル QCSRC のメンバー ASNDLCOPYD の中にあります。 ユーザー・ログインの追加や変更が必要な場合は、ASNDLCOPYD_CMD ツールを使ってください。
以下に示すパラメーターをファイル・コピー・デーモンに渡します。
ASNDLCOPYD ファイル・コピー・デーモンを使用するには:
ASNDLCOPYD デーモンの実行には root (管理者) 権限が必要です。
ASNDLCOPYD ファイル・コピー・デーモンは、ASNDLCOPYD プログラムが生成するすべての メッセージのためのログ・ファイルを作成します。 このログ・ファイルの名前は ASNDLCOPYDYYYYMMDDHHMMSS.LOG (YYYYMMDDHHMMSS は、 デーモンの実行開始時刻) になります。
DB2 DataJoiner のインストールは、 DB2 DataJoiner 計画、インストールおよび構成の手引き で説明されている手順に従って行います。 DataJoiner のインストール時には、変更適用プログラムが自動的にインストールされます。 DataJoiner のインストール後は、以下に示す手順に従ってください。
AIX の場合、変更適用ユーザー ID とは DataJoiner に対するローカル・クライアントのことです。
DJRA が DataJoiner (AIX 版) にアクセスする場合、DJRA ワークステーションから DB2CODEPAGE 環境変数を設定します。 設定する値は、使用する国別コードによって違います。 たとえば、国別コードが US の場合は、次のように設定します。
それぞれの 非 IBM 複製ソース・サーバーに対して 1 つの DataJoiner データベースを作成する必要があります。 1 つの DataJoiner データベースで、複数の非 IBM 複製ターゲット・サーバーをサポートすることができます。 ここでセットアップする DataJoiner データベースは 1 つの DataJoiner インスタンス内に存在しています。 ソースまたはターゲットへのアクセスを必要とする DataJoiner データベースごとに、サーバーとユーザーのマッピングを定義しなければなりません。
IBM 以外のソースについては、CREATE DATABASE コマンドで COLLATE USING パラメーターを使用します。 IDENTITY を使用してください。
Windows NT の場合、DataJoiner インスタンスと DB2 セキュリティー・サービスは自動開始できます。
詳細については、 DB2 DataJoiner 計画、インストールおよび構成の手引き を参照してください。