この章では、収集および変更適用プログラムの一般的な操作方法について説明します。 特定のオペレーティング・システム環境におけるいずれかのプログラムの操作 (たとえば開始、停止、またはスケジューリング) に関する情報は、 操作を参照してください。 この章では、定期的なデータベースの保守、複製のモニター、 およびギャップの処理についても説明します。
ここでは、収集プログラムを開始する前に知っておくべきこと、 収集プログラムのウォームおよびコールド・スタートを実行するとき、 イベントを使って収集プログラムを停止する方法について説明します。
収集プログラムを開始する前に、次のようなインストール後作業を確実に完了してください。
複製ソースとサブスクリプションを定義すると、以下の制御表が制御サーバーに作成されます。
また、「SQL ファイルの実行 (RUN SQL Files)」ウィンドウで DPCNTL.* ファイルを実行して、 これらの制御表を手動で作成することもできます。
収集プログラムを開始または再始動するとき、キーワード (COLD、WARM、または WARMNS)のどれかを含めることができます。 収集プログラムを初めて開始している場合、収集プログラムをコールド・スタートするためには COLD または WARM のいずれかを指定します。 シャットダウンされた後または障害が発生した後に収集プログラムを再始動している場合、 収集プログラムをウォーム・スタートするためには WARM または WARMNS のいずれかを指定します。 以下において、コールド・スタートとウォーム・スタートについて説明します。 それには、収集プログラムがウォーム・スタートを処理する方法、 自動コールド・スタートに切り替える時、およびウォーム・スタートを強制することにより、 自動コールド・スタートが発生しないようにする方法が含まれています。
収集プログラムをコールド・スタートすると、CD 表と UOW 表からすべての行が削除され、 データベース・ログの終了を読み取ることが始まります。 収集プログラムを開始するとき COLD キーワードを含めることにより、コールド・スタートを指定します。 ウォーム・スタートは、特定の状況ではコールド・スタートになる場合もあります。 自動コールド・スタートをご覧ください。
コールド・スタートの後で、変更適用プログラムはターゲット表の全最新表示を実行します。 変更適用プログラムを開始するときに LOADX キーワードを指定して、 全最新表示のパフォーマンスを向上させるか、 または DJRA を使ったターゲット表のオフライン・ロードで説明されている手法を使用することができます。
収集プログラムを停止する場合、またはプログラムに障害が発生する場合、 収集プログラムはウォーム・スタート制御表に情報を書き込んで、 ウォーム・スタートできるようにします。 収集プログラムがウォーム・スタート情報を保管できない場合があります。 たとえば、オペレーターが収集プログラムを取り消したり、DB2 を停止したりすることがあります。 そのような場合、収集プログラムは CD、UOW、または登録表にある情報を使用して、 停止した時刻に再同期し、ウォーム・スタートできるようにします。
WARM または WARMNS キーワードを指定して収集プログラムを再始動すると、 プログラムはウォーム・スタート表 (あるいは CD、UOW、または登録表) でロックし、 ウォーム・スタートできるかどうか、またはコールド・スタートする必要があるかどうかを判別します。 十分なウォーム・スタート情報がある場合、収集プログラムはウォーム・スタートを行いますが、 そうでない場合には、コールド・スタートを試行します。 自動コールド・スタートを参照してください。
ウォーム・スタートが成功すると、収集プログラムはウォーム・スタート表の古い行を削除します。
収集プログラムは、ウォーム・スタートできない場合、コールド・スタートを試行します。 ただし、WARMNS キーワードを指定すると、収集プログラムはコールド・スタートを行いません。 次のような場合に、収集プログラムは自動的にコールド・スタートに切り替わります。
収集プログラムを初めて起動したときは、ウォーム・スタートが失敗したことを示す ASN0102W というメッセージが表示されます。 収集プログラムは、コールド・スタートに切り替わります。 初めて収集プログラムを起動するときは、このメッセージを無視できます。
上記のような場合はいずれも、収集プログラムは通知メッセージを出してコールド・スタートを実行します。 また、収集プログラムがデータベース・ログの新しい位置にジャンプするため、 このコールド・スタートでは変更データの収集順序にギャップが生じます。
収集プログラムがコールド・スタートを試行することを回避するには、 収集プログラムの起動時に WARMNS キーワードを指定します。 ウォーム・スタートができない場合、収集プログラムはコールド・スタートを行わずに終了します。 この方法で収集プログラムが終了すると、制御表が損なわれることはありません。 再起動する前に、収集プログラムが終了する原因になった問題を訂正しなければなりません。 問題を訂正しないと、収集プログラムは開始されるたびに終了するかまたはコールド・スタートを実行し続けます。
収集プログラムを開始するのが初めての場合、 あるいは収集および変更適用プログラムを両方とも停止した後で収集プログラムを開始する場合は、 以下のステップを実行してください。
複製ソースの定義および 複製サブスクリプション・セットの定義を参照してください。
収集プログラムが実行されていることを示す初期化メッセージが表示されるのを待ちます。 変更適用プログラムが開始して全最新表示を完了するまで、 収集プログラムは変更を収集しません。
変更適用プログラムは、 すべてのサブスクリプション・セット・メンバーの全最新表示を実行します。 全最新表示が終了すると、 変更適用プログラムはソース表に対する変更の収集を開始します。
ここでは、変更適用プログラムを開始する前に知っておく必要のあること、 および順方向回復で変更適用プログラムを使用する方法について説明します。 特定のオペレーティング・システム環境における変更適用プログラムの操作 (たとえば開始、停止、またはスケジューリング) に関する情報は、 操作を参照してください。
変更適用プログラムを開始する前に、次のことを確認してください。
変更適用プログラム (OS/390 版) パッケージを作成する BIND プログラムについては、変更適用プログラムの資料を参照してください。 変更適用プログラムは、ソースおよびターゲット・データベースの両方にバインドしなければなりません。
Windows および OS/2 用の変更適用プログラム・パッケージを作成するバインド・プログラムの詳細については、 オプション: 変更適用プログラム (Windows 版および OS/2 版) の手動での構成を参照してください。
UNIX プラットフォーム用の変更適用プログラム・パッケージを作成するためのバインド・プログラムの詳細については、オプション: 変更適用プログラム (UNIX 版) の手動での構成を参照してください。
リモート・システムで作業する DataPropagator Relational (AS/400 用) で必要なパッケージを作成する CRTDPRPKG コマンドに関する情報は、リモート・システムで使用するためのパッケージの作成を参照してください。
Sybase または Microsoft SQL Server のいずれかへの DBLIB 接続を使って変更適用プログラムを実行すると、 低速のネットワークにおいて、全体のパフォーマンスを大幅に向上させることができます。 DB2 DataPropagator は、複製データをバッファーに保持し、 個々の更新を送信するのではなく、各バッファーをネットワーク送信します。 バッファーのサイズは、 create server option ステートメントで設定します。 この利点を活用するには、次の指示に従ってください。
SELECT PKGNAME FROM SYSCAT.PACKAGES WHERE PKGNAME LIKE 'ASN%'
パッケージ名はリリースごと、またサービス更新ごとに変わりますが、 この照会はご使用のサービス・レベルに固有の名前を取り出します。
ASN6A001+ ASN6B001+ ASN6C001+ ASN6F001+ ASN6I001+ ASN6M001+ ASN6P001
create server option apply_packet_size for server type sybase setting 16384; create server option apply_buffer_size for server type sybase setting 16384;
Microsoft SQL Server 用のサーバー・オプションの例を示します。
create server option apply_packet_size for server type mssqlserver setting 16384; create server option apply_buffer_size for server type mssqlserver setting 16384;
パケットおよびバッファー・サイズは、 Sybase または Microsoft SQL Server の最大設定値以下の任意の値に指定し、 必要に応じて調整することができます。
DJX_ASYNC_APPLY=TRUE
データベースで実施する定期的な保守に加えて、 複製の実行には、以下に示す保守を実施する必要があります。
CD 表および UOW 表を頻繁に使用する場合、1 週間に 1 回程度それらを再編成する必要があります。 DB2 (OS/390 版) バージョン 5 以上の場合には、PREFORMAT キーワードを指定します。表スペースを事前フォーマットすると、収集プログラムが挿入処理を行うスピードがアップします。表スペースを圧縮されている場合には、KEEPDICTIONARY キーワードも指定する必要があります。
サブスクリプション述部は非常に選択的で、トランザクション更新の大部分をフィルターできるため、 ターゲット表を再編成する頻度に関する一般的な規則はありません。 ただし、ターゲット表は、少なくともソース表を再編成するのと同じぐらいの頻度で再編成する必要があります。
各サブスクリプション・サイクルの終了時に、変更適用プログラムは変更適用追跡制御表に行を挿入します。 この表が大きくなりすぎるのを避けるには、こうした行を定期的に削除する必要があります。 変更適用プログラムは、この表に書き込みはしても読み取りは行わないため、 いつでも好きなときにこうした行を削除することができます。 この表に書き込まれるサブスクリプション統計およびエラー診断は後で活用できるものであり、複製モニターによって使用されます。 この表のボリュームを管理する簡単な方法は、SQL ステートメントをサブスクリプション・セットに追加することです。 たとえば、以下のようにします。
DELETE FROM ASN.IBMSNAP_APPLYTRAIL WHERE LASTRUN < (CURRENT TIMESTAMP - 7 DAYS);
収集プログラムと変更適用プログラムはいずれも、CCD 表の枝取りを自動的には行いません。 また、これらの表を枝取りするコマンドはありません。 圧縮された CCD 表は適度に更新され、絶え間なく増大することはありません。 圧縮されていない CCD 表には、保存するのによい履歴が含まれています。
圧縮された、完全でない内部 CCD 表 (十分な更新活動記録付き) は、 完全な CCD 表のサイズに近づく場合があります。 最新の変更だけがその表から検索されるため、この表を増大させる値はありません。 この表からすでに複製されたトランザクションを枝取りするには、 SQL ステートメントを内部 CCD サブスクリプションに追加します。たとえば、
DELETE FROM my.internal_ccd WHERE IBMSNAP_COMMITSEQ <= (SELECT MIN(SYNCHPOINT) FROM ASN.IBMSNAP_PRUNCNTL);
このステートメントは、内部 CCD 表に関連付けられたソースを参照するサブスクリプションではなく、 活動状態が最小のサブスクリプションに基づいて表を枝取りするため、 ステートメントを変更してより積極的な枝取りを行うことができます。
以下の操作可能プロシージャーでは、通常 DB2 スペースまたはカタログを排他使用する必要があります。
REORG
BIND PACKAGE
BIND PLAN
GRANT
REVOKE
これらの操作可能プロシージャーは、収集および変更適用プログラムが発行する動的 SQL (カタログ表を暗黙的にロック) またはプログラムがアクセスする表スペースとうまく共存できないため、 ユーティリティー (および他の類似の操作可能プロシージャー) を実行するときには、収集および変更適用プログラムを両方とも停止して、競合が生じるのを避ける必要があります。
複製モニター (DJRA に含まれる) を使用して、複製ネットワークの作動状況を示すレポートを、 定期的に生成することができます。
複製モニターを開始するには、メイン DJRA ウィンドウで、 「複製のモニター (Monitor Replication)」をクリックします。 「複製管理のスケジューラー (Replication Administration Scheduler)」ウィンドウで、 モニターを定期的に実行するか、または一度だけ実行するようにスケジュールを指定することができます。
場合によっては、ソース表の変更データを収集する際にギャップが生じることがあります。 たとえば、収集プログラムを遮断してからコールド・スタートした場合、CD 表のすべての列が削除されます。 この場合、収集プログラムが収集を実行しないまま更新されることがあります。 さらに、CD 表の中にあったすべての更新は、コールド・スタートで、 変更適用プログラムが複製する前に 削除されてしまった可能性があります。
ギャップが存在する場合、ターゲット表が不完全 CCD 表でなければ変更適用プログラムは全最新表示を試行します。 変更適用プログラムが全最新表示を実行できない場合は、データの保全性が失われる可能性があります。 不完全 CCD 表の場合、以下のステップを使用すると、 収集プログラムをコールド・スタートする結果として生じる可能性のあるデータ保全性の損失を回避できます。
複製を開始した後、その構成を変更することができます。それには、 複製ソースまたはサブスクリプションの変更、ソースまたはサブスクリプションの削除、 サブスクリプションの非活動化、およびサブスクリプションの複製が含まれます。
DB2 コントロール・センターまたは DJRA のいずれかを使って、既存の複製ソースを表示することができます。 コントロール・センターで、「表は随時更新用に使用されます (Table will be used for update anywhere)」チェック・ボックスを選択して、 複製ソースで定義した対立検出レベルを変更することができます。 複製ソースを正常に定義し終わったら、 もう他のどのフィールドも制御も変更に使えなくなります。 DJRA を使うと、複製で使用できる列セットを変更できます。 30
複製ソースの定義の変更を計画している場合には、 収集プログラムの REINIT コマンドを使用します。 収集プログラムを停止または中断してからウォーム・スタートまたは再初期設定して、 変更後の複製ソースの変更の収集を開始することもできます。 ご使用のオペレーティング・システム環境に応じた収集プログラムに関する情報は、 操作を参照してください。
複製ソースがもう必要なくなったら、DB2 コントロール・センターまたは DJRA からオブジェクトを除去し、 制御表からその制御情報を除去することができます。
重要:
コントロール・センターおよび DJRA は、DB2 複製ソースの表スペースが空の場合、それを除去します。 DJRA は、IBM 以外のデータベースのコンテナー (表スペース、データベース・スペース、 またはセグメント) は除去しません。 コントロール・センターの場合、「ツール設定 (Tools Settings)」ノートブック内の「複製 (Replication)」ページでこの設定を変更すると、表スペースが除去されないようにすることができます。
DB2 コントロール・センターまたは DJRA を使って、 サブスクリプション・セットの活動状況を制御することができます。 この機能が便利なのは、サブスクリプション・セットを除去しないで一時的に非活動化したい場合です。 サブスクリプション・セットを非活動化すると、変更適用プログラムは、 現在の処理サイクルを完了させてから、サブスクリプション・セットの処理を停止します。 コントロール・センターでは、サブスクリプション・セットを非活動化すると、 サブスクリプション・セットのアイコンはグレーアウトされます。
DB2 コントロール・センターを使用すると、サブスクリプション・セットを別のサーバーに複製することができます。 複製では、様々な変更適用修飾子が使われて、 既存のサブスクリプション・セットの正確なコピーが別のターゲット・サーバー上に作成されます。 このコピーには、サブスクリプション情報だけが含まれます。 複写表、表スペース、または索引定義は含まれません。 一度に 1 つ以上のサブスクリプション・セットを複製できます。 コントロール・センターは、制御サーバーの制御表を更新します。
複製環境全体を別のシステムにコピーすることについて詳しくは、 別のシステムへの複製構成のコピーを参照してください。
DB2 コントロール・センターを使用して、サブスクリプション・セットの値のサブセット (主に、ターゲット表の構造に影響を与えないもの) を変更することができます。 「サブスクリプションの変更 (Change Subscription)」ウィンドウおよびサブウィンドウで、 次に示す値を変更できます。
DJRA を使って既存のサブスクリプション・セット・メンバーを表示または変更するには、 「ターゲット表へのメンバーのリストまたは列の追加 (List Members or Add a Column to Target Tables)」ボタンをクリックします。 必要な情報 (ソース・サーバー名およびソース表名など) をウィンドウ内に書き込んでから、 ソース列名 (または SQL 式) およびターゲット表名を任意で書き込み、 ターゲット表に新しい列または算出欄を追加します。 31
サブスクリプション・セットの定義を除去すると、それに関連した情報が制御表から削除され、 オプションでターゲット・サーバーのターゲット表が削除されます。 IBM 以外のターゲット表の場合、 DJRA を使用してサブスクリプション・セットを削除する際に、 ニックネームと対応するターゲット表を除去するかどうか選択することができます。
DB2 コントロール・センターを使って、目次の画面区画で、 削除したい 1 つ以上の複製サブスクリプションのオブジェクトを選択してから、 ポップアップ・メニューで「除去 (Remove)」を選択します。 DJRA を使って、まずサブスクリプション・セットのメンバーをすべて消去してから、 空になったサブスクリプション・セットを除去することができます。