問題判別の手引き


DB2 DataPropagator

DB2 DataPropagator を使用すると、冗長データの複数のコピーを管理できます。 指定されたログ順序番号が表すログ・レコードがどのログ・ファイルに含まれているかを判別するには、 db2flsn (ログ順序番号の検出) コマンドを使用します。

コマンド db2flsn -q input_LSN では、 ログ・ファイル名だけを印刷することを指定します。 エラー・メッセージや警告メッセージは印刷されません。 そのため、状況は戻りコードから判別するしかありません。

有効なエラー・コードは以下のとおりです。

db2flsn を使ったログ・ヘッダー制御ファイルの使用

input_LSN ファイルには、 ログ順序番号の内部 (6 バイト) 16 進値を表す 12 バイトのストリングが入ります。 12 バイトのストリングを完全に埋めるために、先行ゼロが使用される場合があります。

ログ・ヘッダー制御ファイル sqlogctl.lfh は、 現行ディレクトリー内になければなりません。 このファイルはデータベース・ディレクトリーにあるため、 ツールはデータベース・ディレクトリーから実行できます。 つまり、制御ファイルはツールが実行されるディレクトリーにコピーすることができます。

ツールは logfilsiz データベース構成パラメーターを使用します。 DB2 はこのパラメーターの最新の 3 つの値と、 それぞれの logfilsiz の値を使用して作成される最初のログ・ファイルを記録します。 これにより、logfilsiz が変更されても、ツールは正常に作動できます。

指定された LSN の日付が最も早く記録された logfilsiz の値より早くなっている場合、 ツールがこの値を使用すると、警告が戻されます。

このツールは、(DB2 ユニバーサル・データベース バージョン 5.2 より前の) データベース管理プログラムと共に使用することができます。

詳細については、管理 API 解説書 の『sqlurlog (ログの非同期読み取り) API』を参照してください。

db2flsn コマンドおよび db2diag.log ファイルの使用例

db2diag.log ファイルでは、再始動が行われていることに気付くでしょう。

1999-04-06-11.51.31.237000  Instance:DB2   Node:000
PID:254(DB2SYSCS.EXE)   TID:247   Appid:*LOCAL.DB2.990406154954
recovery_manager   sqlpresr   Probe:170   Database:SAMPLE
DIA3909W Crash recovery completed. Next LSN is "0000003E800C".

db2flsn コマンドを使用して、関係のあるログ・ファイルを調べることができます。

D:\DB2\NODE0000\SQL00001>db2flsn 0000003E800C
Given LSN is contained in log file S0000000.LOG

DB2 DataPropagator の拡張機能

DB2 DataPropagator は DB2 ユニバーサル・データベース製品間での BIGINT ソースから BIGINT ターゲットへのコピーをサポートします。 BIGINT をサポートしないターゲット・サーバーの場合、BIGINT 列をコピーすることはできますが、 ターゲット列は DECIMAL として定義されます。

DB2 DataPropagator は DB2 ユニバーサル・データベース OS/390 どうし、DB2 ユニバーサル・データベース製品どうし、 および DB2 ユニバーサル・データベース OS/390 と DB2 ユニバーサル・データベース間でのラージ・オブジェクトのコピーをサポートしています。

LOB の制限および要件

DB2 OS/390 と DB2 UDB の間の LOB のコピー
DB2 コネクト バージョン 6 が必要です。

DB2 ユニバーサル・データベースは LOB アプリケーション・サーバーの役割をサポートしません。
ラージ・オブジェクトをユニバーサル・データベースから DB2 OS/390 にコピーするには、push 技法を使用する必要があります。

LOB 列データは CD 表では取り込まれません。
LOB 列データの変更指示は取り込まれます。 実際の LOB データはソース表から、変更される LOB 列のターゲットに、 変更適用プログラムによって直接コピーされます。 そのため、ユーザー表にはターゲット表と同じ基本キー列が必要です。 ソース表では LOB 変更標識はヌル可能な CHAR(1) 列なので、CD 表では複数の指示列が必要です。 LOB 指示列の値は行の更新の場合に限り重要になります。 LOB 列データが更新操作で変更された場合、標識には U が含まれます。 その他の場合は、ヌルに設定されます。

変更前イメージ・コピーは LOB 列ではサポートされません。

LOB 列は読み取り専用ターゲットにのみコピーされます。
ターゲットのタイプは replica または replica2 であってはなりません。

注:レプリカ とは、更新可能なターゲット表です。 この表を変更すると、変更内容はレプリケーション・ソース表に複製されます。 この表は任意更新シナリオで使用されます。 Replica2 はトランザクションのセマンティクスを持たない任意更新タイプのレプリカです。 レプリカについては、競合はトランザクションごとにではなく、 行ごとに検出されます。

現行値しか使用できないため、ターゲットを圧縮する必要があります。
変更適用プログラムは、 常に最新バージョンの LOB 列をソース表 (CD 表ではない) から直接コピーします。 この列がターゲット表の他の表のバージョンよりも新しくなる場合でもそうします。 同期の変則が起きる可能性があります。 これは、LOB 列の値がソース表からコピーされ、 他の列に適用されている値と比べてかなり新しくなり、矛盾が生じる可能性があるからです。

収集プログラムを使用して LOB の変更を検出するには、 ユーザー表が DATA CAPTURE CHANGES を指定して作成または変更される必要があります。
ユニバーサル・データベースの場合は、CREATE TABLE ステートメントに LOGGED または NOT LOGGED オプションが指定されていると、LOB の変更の取り込みには影響を与えません。 DB2 OS/390 の場合は、CREATE LOB TABLESPACE ステートメントに LOG YES/NO オプションが指定されていると、LOB の変更の取り込みには影響を与えません。 LOB をサポートするために、DB2 OS/390 と DB2 ユニバーサル・データベースは別々の構文を使用します。 DB2 ユニバーサル・データベースでは、 正しいステートメントは CREATE TABLE、 CREATE LOB TABLESPACE、 および CREATE AUXILIARY TABLE です。


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