このセクションでは、さまざまなユーザ定義のコンフリクト解決ルーチンについて説明します。
コンフリクトとは、ソース側のテーブルとターゲット側のテーブルが同一ではない、非同期の状態を指します。ターゲット側のテーブルの行に対するSharePlexで作成されたDMLステートメントの実行に失敗した場合は、以下のような理由で非同期(コンフリクト)状況が発生すると予測できます。
Postは複製されたINSERTを適用しますが、同じキーを持つ行が既にターゲットにあります。Postは以下のロジックを適用します。
注意: INSERTをポストする際に、キー以外の値を考慮しないようにPostを設定することができます(OracleからOracleにデータを複製する場合にのみ適用可能)。『SharePlexリファレンスガイド』のSP_OPO_SUPPRESSED_OOSパラメーターを参照してください。
Postは複製されたUPDATEを適用しますが、UPDATEのキー値と同じキー値を持つ行がターゲットに見付かりません。または、Postは正しい行を見付けますが、その行の値がUPDATEの前の値と一致しません。Postは以下のロジックを適用します。
注意: ターゲット行の現在の値がUPDATEの後の値と一致する場合、非同期のメッセージを返すようにPostを設定できます(OracleからOracleにデータを複製する場合にのみ適用可能)。『SharePlexリファレンスガイド』のSP_OPO_SUPPRESSED_OOSパラメーターを参照してください。
コンフリクト解決ルーチンを作成するには、コンフリクトが発生したときのSharePlexの動作を指示するPL/SQLプロシージャを記述します。ビジネスルールは企業によって大きく異なるため、あらゆる状況に適用できる標準的なコンフリクト解決ルールや構文を作成することは不可能です。おそらくご自身でルーチンを記述する必要があります。例えば、サイトやシステムの優先順位をプライマリルーチンとし、タイムスタンプをセカンダリルーチンとするなど、複数のプロシージャを記述することをお勧めします。1つのプロシージャが成功するか、利用可能なプロシージャがなくなるまで、SharePlexは順次ルーチンを呼び出します。
SharePlexには、ルーチンの基礎として使用できる以下のツールが用意されています。
重要!
|
SharePlexには、記述したプロシージャルーチンとの間で情報を受け渡しするために使用できる汎用のコンフリクト解決PL/SQLパッケージがあります。
注: カスタムルーチンは、OracleからOracleのソースターゲットの組み合わせにのみ対応しています。
始める前に以下のガイドラインをご確認ください。
注: 『SharePlexインストールおよびセットアップガイド』のSharePlexのコンフリクト解決デモを実行した場合は、デモに使用したデータベースにインストールされているod_employee_genルーチンを表示することで、一般的なコンフリクト解決ルーチンのサンプルを表示することができます。
このテンプレートに従ってプロシージャを作成してください。
(table_info in outsplex.sp_cr.row_typ, col_values insplex.sp_cr.col_def_tabtyp) |
ここで:
SharePlexは、SharePlexのデータベーススキーマのsp_crという名前を持つパブリックパッケージのPL/SQLレコードとテーブルの構造を定義します。 このパッケージでは以下のパラメーターを使用します。
CREATE or REPLACE PACKAGE sp_cr AS
TYPE row_typ IS RECORD
src_host VARCHAR2(32),
src_ora_sid VARCHAR2(32),
src_ora_time VARCHAR2(20),
source_rowid VARCHAR2(20),
target_rowid VARCHAR2(20),
statement_type VARCHAR2(6),
source_table VARCHAR2(78),
target_table VARCHAR2(78),
oracle_err NUMBER,
status NUMBER,
action NUMBER,
reporting NUMBER
);
行の操作によってコンフリクトが発生するたびに、SharePlexはこのメタデータ情報をプロシージャに渡します。
変数 | 説明 |
---|---|
src_host |
(操作が実行された)ソースシステムの名前。文字と小文字は区別され、例えばSysAのように、ソースシステムと同じ大文字と小文字を使用して渡されます。ターゲットシステム上で名前付きpostキューが使用されている場合、この変数は、例えばpostq1などのpostキューの名前で構成されます。 注: 最大文字数は32文字です。32文字を超えるホスト名は32文字に切り詰められます。 |
src_ora_sid | ソースデータベースのORACLE_SID。大文字と小文字は区別され、oratabファイルまたはV$PARAMETERテーブルと同じ大文字と小文字を使用して渡されます。 |
src_ora_time | ソースREDOログ内の変更レコードのタイムスタンプ。 |
source_rowid | ソース行の行ID。例えば'123456'のように、一重引用符で囲まれたリテラルとして渡されます。 |
target_rowid | ターゲットデータベースの対応する行の行ID。SharePlexは、ターゲットデータベースに問い合わせることで行IDを取得します。例えば'123456'のように、一重引用符で囲まれたリテラルとして渡されます。PRIMARYキーを使用して行が見付からない場合、値はNULLとなります。 |
statement_type | 操作がINSERT、UPDATE、DELETEステートメントのどれであるかを示すI、U、Dのいずれかの文字。 |
source_table | owner.tableで表すソース側のテーブルの所有者と名前。この値では大文字と小文字を区別します。これは、データベースでのテーブルの命名方法と同じです。例えば"scott". "emp"のように、二重引用符で囲んで渡します。 |
target_table | owner.tableで表すターゲット側のテーブルの所有者と名前。この値では大文字と小文字を区別します。これは、データベースでのテーブルの命名方法と同じです。例えば"scott". "emp"のように、二重引用符で囲んで渡します。 |
oracle_err |
これは、プロシージャの使用目的がコンフリクト解決かトランスフォーメーションかによって異なります。 トランスフォーメーション: SharePlexは0の値をこの変数に渡します。この変数はコンフリクトの解決のみに使用されます。 コンフリクト解決: コンフリクトの原因となったOracleのエラー番号。 |
これらの変数は、プロシージャに成功したか失敗したかに基づいてSharePlexのアクションを指示します。
変数 | 説明 |
---|---|
status |
プロシージャが成功したかどうかを定義します。このパラメーターには値を指定する必要があります。
|
action |
希望するSharePlexのアクションを定義します。これは、プロシージャの使用目的がトランスフォーメーションかコンフリクト解決かによって異なります。 トランスフォーメーション: このパラメーターには0の値を指定する必要があります。これは、SQLステートメントをポストしないようにSharePlexに指示します。トランスフォーメーションルーチンは、トランスフォーメーションの結果をターゲット側のテーブルや別のテーブルにポストします。このアクションの結果は、レポート変数に指定した内容によって異なります。 コンフリクト解決: コンフリクト解決プロシージャに失敗した場合に取るべきアクションを指定します。このパラメーターには値を指定する必要があります。
|
レポート作成機能 |
不成功に終わったプロシージャの結果をSharePlexがどのように報告するかを決定します。このパラメーターには値を指定する必要があります。
|
SharePlexは、レプリケートされた操作ごとにcol_def_tabtyp PL/SQLテーブルを作成します。 このテーブルには列情報が保存されます。これは、プロシージャの使用目的がトランスフォーメーションかコンフリクト解決かによって異なります。
すべてのフィールドはSharePlexによってルーチンに渡されますが、SharePlexが行を見付けられない場合は、すべてのフィールドに値があるとは限りません。
以下はcol_def_tabtypテーブルに入力するために使用するデータ型です。
type col_def_typ is record
(column_name user_tab_columns.column_name%type
,data type user_tab_columns.data type%type
,is_key boolean
,is_changed boolean
,old_value varchar2(32764)
,new_value varchar2(32764)
,current_value varchar2(32764)
);
type col_def_tabtyp is table of col_def_typ
列 | 説明 |
---|---|
column_name | 例えばemp_last_nameなど、ソース側のテーブルからレプリケートされた列の名前をプロシージャに伝えます。この値では大文字と小文字を区別しません。 |
data type | 例えばVARCHAR2など、レプリケートされた列のデータのデータ型をプロシージャに伝えます。この値は常に大文字です。 |
is_key | 列がキー列であるかどうかをプロシージャに伝えます。キー列の場合、SharePlexはTRUEの値を渡します。列がキーの一部でない場合、SharePlexはFALSEの値を渡します。 |
is_changed |
列の値が変更されたかどうかをプロシージャに伝えます。変更された場合、SharePlexはTRUEの値を渡します。列が変更されない場合、SharePlexはFALSEの値を渡します。
|
old_value |
レプリケートされた列の、ソースシステムで変更される前の古い値をプロシージャに伝えます。INSERTでは、この列はNULLです。これは、INSERTを実行する前にターゲットデータベースに行が存在しなかったためです。 コンフリクト解決のみ: これは、UPDATEとDELETEの同期チェックの一環としてSharePlexがソース列とターゲット列を比較したときの基準となるプリイメージです。SharePlexによって渡された古い値が、ターゲット行から得られたcurrent_valueの値と一致しない場合、コンフリクトが発生します。 |
new_value | ソースシステムで変更された、レプリケートされた列の新しい値をプロシージャに伝えます。 |
current_value | ターゲット側のテーブルの列の現在の値をプロシージャに伝えます。SharePlexがターゲット行を見付けられない場合、値はNULLになります。 |
以下の表は、各操作で起こりうる結果を示しています。
column_name | is_changed | old_value | new_value | current_value1 | is_key |
---|---|---|---|---|---|
C1 | TRUE | NULL | bind | NULL | FALSE |
C2 | TRUE | NULL | bind | NULL | TRUE |
C3 | FALSE | NULL | NULL | NULL | TRUE | FALSE |
1 INSERTが失敗するのは、同じPRIMARYキーを持つ行が既にターゲットデータベースに存在するためです。SharePlexはINSERTの現在の値を返しません。
column_name | is_changed | old_value | new_value | current_value1, 2 | is_key |
---|---|---|---|---|---|
C1 | TRUE | bind | bind | NULL | target_value | FALSE |
C2 | FALSE | bind | NULL | NULL | target_value | TRUE |
C3 | TRUE | bind | bind | NULL | target_value | TRUE |
1(コンフリクト解決)UPDATEが失敗するのは、SharePlexがPRIMARYキーとプリイメージを使用して行を見付けることができないためです。行が見付からない場合、SharePlexはPRIMARYキーのみを使用して行を検索します。SharePlexが行を見付けた場合、変更された列だけでなくキー列の現在の値も返します。SharePlexがPRIMARYキーを使用しただけでは行を見付けられない場合、SharePlexはNULLを返します。
2(トランスフォーメーション)UPDATEの場合、SharePlexはPRIMARYキーとプリイメージを使用して行を検索することはできません。これはトランスフォーメーションによりプリイメージが異なるためです。別の方法として、PRIMARYキーだけを使用して行を検索することもできます。見付かった場合、SharePlexは変更された列だけでなくキー列の現在の値も返します。PRIMARYキーだけでは行を特定できない場合、current_valueはNULLになります。
column_name | is_changed | old_value | new_value | current_value1 | is_key |
---|---|---|---|---|---|
C1 | FALSE | bind | NULL | NULL | TRUE |
1 DELETEが失敗するのは、SharePlexがPRIMARYキーを使用して行を見付けることができなかったためです。したがって、SharePlexはNULLを返します。
コンフリクト解決プロシージャを作成したら、コンフリクト解決ファイルを構成します。このファイルは、どのプロシージャをどのオブジェクトや操作のタイプに、どの順番で使用するかをSharePlexに指示します。
空白のconflict_resolution.SIDファイルでは、SIDはターゲットインスタンスのORACLE_SIDです。これは、SharePlexのインストール時にSharePlexの変数データディレクトリのdataサブディレクトリに含まれていたものです。ターゲットシステム上のファイルを使用します。
このファイルがない場合は、ASCIIテキストエディタでASCII形式のファイルを作成することができます。名前はconflict_resolution.SIDでなければなりません。ここで、SIDはターゲットインスタンスのORACLE_SIDです。
注: SIDでは大文字と小文字を区別します。
重要: conflict_resolutionSIDファイルは、アクティブな設定ごとに1つだけでなければなりません。
以下のテンプレートを使用して、プロシージャを1つ以上のオブジェクトおよび操作のタイプにリンクします。
owner.object | {i | u | d | iud} | owner.procedure |
ここで:
scott.sal | IUD | scott.sal_cr |
like:scott.%\_corp\_emp | IUD | scott.emp_cr1 |
like:scott.%\_corp\_emp | IUD | scott.emp_cr2 |
like:scott% | IUD | scott.emp_cr3 |
scott.cust | U | scott.sal_cr |
仕組み:
レプリケーションの設定のすべてのテーブルでSharePlexの準備されたルーチンを使用するには、所有者とオブジェクト名を指定する代わりに!DEFAULTパラメーターを使用します。
カスタムルーチンは、SharePlexの準備されたルーチンよりも優先されます。準備されたルーチンは、カスタムルーチンが失敗した場合にのみ使用されます。これは、!DEFAULTに関連するルーチンのファイル内での順序にかかわらず当てはまります。
!DEFAULTパラメーターでは大文字と小文字を区別します。すべて大文字で入力しなければなりません。
以下の例では、!UpdateUsingKeyOnlyプロシージャが、james.table1を含むすべてのテーブルのUPDATEとDELETEに使用されていますが、james.table1にリストされているユーザ定義プロシージャが優先されます。
!DEFAULT | U | !UpdateUsingKeyOnly |
!DEFAULT | D | !UpdateUsingKeyOnly |
james.table1 | U | james.procedure_upd |
james.table1 | I | james.procedure_ins |
james.table1 | D | james.procedure_del |
コンフリクト解決ファイルはレプリケーション中にいつでも変更し、テーブルやプロシージャを追加したり削除したりできます。コンフリクト解決ファイルを変更したら、Postプロセスを一旦停止し、再度開始します。
SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。詳細については、「Oracleデータベースの解決済みコンフリクトに関する情報のロギングページを参照してください。
コンフリクト解決ルーチンを作成するには、コンフリクトが発生したときのSharePlexの動作を指示するPL/PGSQLプロシージャを記述します。ビジネスルールは企業によって大きく異なるため、あらゆる状況に適用できる標準的なコンフリクト解決ルールや構文を作成することは不可能です。おそらくご自身でルーチンを記述する必要があります。例えば、サイトやシステムの優先順位をプライマリルーチンとし、タイムスタンプをセカンダリルーチンとするなど、複数のプロシージャを記述することをお勧めします。1つのプロシージャが成功するか、利用可能なプロシージャがなくなるまで、SharePlexは順次ルーチンを呼び出します。
SharePlexには、ルーチンの基礎として使用できる以下のツールが用意されています。
重要
|
SharePlexには、記述したプロシージャルーチンとの間で情報を受け渡しするために使用できる汎用のコンフリクト解決インターフェイスがあります。
注: カスタムルーチンは、OracleからPostgreSQLおよびPostgreSQLからPostgreSQLのソースとターゲットの組み合わせにのみ対応しています。
始める前に以下のガイドラインをご確認ください。
このテンプレートに従ってプロシージャを作成してください。
(table_info sp_cr.row_typ, col_values sp_cr.col_def_typ[], INOUT status INTEGER, INOUT action INTEGER, INOUT reporting INTEGER) |
ここで:
SharePlexは、SharePlexのデータベースのsp_crという名前を持つスキーマのPL/PGSQLレコードとテーブルの構造を定義します。
このスキーマでは以下のパラメーターを使用します。
CREATE SCHEMA IF NOT EXISTS sp_cr;
CREATE TYPE sp_cr.row_typ AS
(src_host VARCHAR(32),
src_db VARCHAR(32),
src_time VARCHAR(20),
statement_type VARCHAR(6),
source_table VARCHAR(128),
target_table VARCHAR(128),
native_error INTEGER,
sql_state VARCHAR(10)
);
行の操作によってコンフリクトが発生するたびに、SharePlexはこのメタデータ情報をプロシージャに渡します。
変数 | 説明 |
---|---|
src_host | (操作が実行された)ソースシステムの名前。文字と小文字は区別され、例えばSysAのように、ソースシステムと同じ大文字と小文字を使用して渡されます。ターゲットシステム上で名前付きpostキューが使用されている場合、この変数は、例えばpostq1などのpostキューの名前で構成されます。注: 最大文字数は32文字です。32文字を超えるホスト名は32文字に切り詰められます。 |
src_db | ソースのデータベース名。 |
src_time | Captureプロセスが変更レコードを受け取ったときのタイムスタンプ。 |
statement_type | 操作がINSERT、UPDATE、DELETEステートメントのどれであるかを示すI、U、Dのいずれかの文字。 |
source_table | owner.tableで表すソース側のテーブルの所有者と名前。この値では大文字と小文字を区別します。これは、データベースでのテーブルの命名方法と同じです。 |
target_table | owner.tableで表すターゲット側のテーブルの所有者と名前。この値では大文字と小文字を区別します。これは、データベースでのテーブルの命名方法と同じです。 |
native_error |
このフィールドは、競合するDMLのためにODBC APIによって生成されます。* |
sql_state | このフィールドは、競合するDMLのためにODBC APIによって生成されます。* |
注: *UpdateおよびDelete操作の場合、行が見付からないと、ネイティブエラーは100に設定され、SQL_stateは'00000'に設定されます。
これらの変数は、プロシージャに成功したか失敗したかに基づいてSharePlexのアクションを指示します。
変数 | 説明 |
---|---|
status |
プロシージャが成功したかどうかを定義します。このパラメーターには値を指定する必要があります。
|
action |
希望するSharePlexのアクションを定義します。これは、プロシージャの使用目的がコンフリクト解決かどうかによって異なります。 コンフリクト解決: コンフリクト解決プロシージャに失敗した場合に取るべきアクションを指定します。このパラメーターには値を指定する必要があります。
|
レポート作成機能 |
不成功に終わったプロシージャの結果をSharePlexがどのように報告するかを決定します。このパラメーターには値を指定する必要があります。
|
SharePlexは、レプリケートされた操作ごとにcol_def_typ型を作成します。 この型には列情報が保存されます。
すべてのフィールドはSharePlexによってルーチンに渡されますが、SharePlexが行を見付けられない場合は、すべてのフィールドに値があるとは限りません。
以下はcol_def_typテーブルに入力するために使用するデータ型です。
type col_def_typ is record
(column_name user_tab_columns.column_name%type
,data type user_tab_columns.data type%type
CREATE TYPE sp_cr.col_def_typ AS
(column_name VARCHAR,
datatype VARCHAR,
is_key BOOLEAN,
is_changed BOOLEAN,
old_value VARCHAR ,
new_value VARCHAR
);
type col_def_tabtyp is table of col_def_typ
列 | 説明 |
---|---|
column_name | 例えばemp_last_nameなど、ソース側のテーブルからレプリケートされた列の名前をプロシージャに伝えます。この値では大文字と小文字を区別しません。 |
data type | 例えばVARCHARなど、レプリケートされた列のデータのデータ型をプロシージャに伝えます。この値は常に大文字です。 |
is_key | 列がキー列であるかどうかをプロシージャに伝えます。キー列の場合、SharePlexはTRUEの値を渡します。列がキーの一部でない場合、SharePlexはFALSEの値を渡します。 |
is_changed |
列の値が変更されたかどうかをプロシージャに伝えます。変更された場合、SharePlexはTRUEの値を渡します。列が変更されない場合、SharePlexはFALSEの値を渡します。
|
old_value |
レプリケートされた列の、ソースシステムで変更される前の古い値をプロシージャに伝えます。INSERTでは、この列はNULLです。これは、INSERTを実行する前にターゲットデータベースに行が存在しなかったためです。 コンフリクト解決のみ: これは、UPDATEとDELETEの同期チェックの一環としてSharePlexがソース列とターゲット列を比較したときの基準となるプリイメージです。SharePlexによって渡された古い値が、ターゲット行から得られたcurrent_valueの値と一致しない場合、コンフリクトが発生します。 |
new_value | ソースシステムで変更された、レプリケートされた列の新しい値をプロシージャに伝えます。 |
以下の表は、各操作で起こりうる結果を示しています。
INSERT操作
column_name | is_changed | old_value | new_value | is_key |
---|---|---|---|---|
C1 | TRUE | NULL | bind | FALSE |
C2 | TRUE | NULL | bind | TRUE |
C3 | FALSE | NULL | NULL | TRUE | FALSE |
UPDATE操作
column_name | is_changed | old_value | new_value | is_key |
---|---|---|---|---|
C1 | TRUE | bind | bind | FALSE |
C2 | FALSE | bind | NULL | TRUE |
C3 | TRUE | bind | bind | TRUE |
DELETE操作
column_name | is_changed | old_value | new_value | is_key |
---|---|---|---|---|
C1 | FALSE | bind | NULL | TRUE |
コンフリクト解決プロシージャを作成したら、コンフリクト解決ファイルを構成します。このファイルは、どのプロシージャをどのオブジェクトや操作のタイプに、どの順番で使用するかをSharePlexに指示します。
空白のconflict_resolution.testdb。ここで、testdbはDB名です。これは、SharePlexのインストール時にSharePlexの変数データディレクトリのdataサブディレクトリに含まれていたものです。ターゲットシステム上のファイルを使用します。
このファイルがない場合は、ASCIIテキストエディタでASCII形式のファイルを作成することができます。名前はconflict_resolution.DBにする必要があります。ここで、DBはデータベース名です。
重要: conflict_resolutionDBファイルは、アクティブな設定ごとに1つだけでなければなりません。
以下のテンプレートを使用して、プロシージャを1つ以上のオブジェクトおよび操作のタイプにリンクします。
SchemaName.tableName | IUD | schema.procedure |
ここで:
scott.sal | IUD | scott.sal_cr |
scott.cust | IUD | scott.cust_cr |
!DEFAULT | IUD | scott.sal_cr5 |
仕組み:
レプリケーション設定内のすべてのテーブルでSharePlexの準備されたルーチンを使用するには、スキーマとオブジェクト名を指定する代わりに!DEFAULTパラメーターを使用します。
カスタムルーチンは、SharePlexの準備されたルーチンよりも優先されます。準備されたルーチンは、カスタムルーチンが失敗した場合にのみ使用されます。これは、!DEFAULTに関連するルーチンのファイル内での順序にかかわらず当てはまります。
!DEFAULTパラメーターでは大文字と小文字を区別します。すべて大文字で入力しなければなりません。
!DEFAULT | IUD | proc0 |
schema.table1 | IUD | proc1 |
james.table1 | IUD | proc2 |
james.table1 | IUD | proc3 |
コンフリクト解決ファイルはレプリケーション中にいつでも変更し、テーブルやプロシージャを追加したり削除したりできます。コンフリクト解決ファイルを変更したら、Postプロセスを一旦停止し、再度開始します。
SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。詳細については、「PostgreSQLデータベースの解決済みコンフリクトに関する情報のロギングページを参照してください。
コンフリクト解決ルーチンを作成するには、コンフリクトが発生したときのSharePlexの動作を指示するPL/SQLプロシージャを記述します。ビジネスルールは企業によって大きく異なるため、あらゆる状況に適用できる標準的なコンフリクト解決ルールや構文を作成することは不可能です。おそらくご自身でルーチンを記述する必要があります。例えば、サイトやシステムの優先順位をプライマリルーチンとし、タイムスタンプをセカンダリルーチンとするなど、複数のプロシージャを記述することをお勧めします。1つのプロシージャが成功するか、利用可能なプロシージャがなくなるまで、SharePlexは順次ルーチンを呼び出します。
SharePlexには、ルーチンの基礎として使用できる以下のツールが用意されています。
重要
|
SharePlexには、記述したプロシージャルーチンとの間で情報を受け渡しするために使用できる汎用のコンフリクト解決PL/SQLパッケージがあります。
始める前に、PL/SQLを使用してコンフリクト解決のためにアクセスするテーブルには、オブジェクトの所有者からSharePlexに暗黙的に付与された権限が必要であることに注意してください。その他のガイドラインについては、Oracleでは「Oracle用のルーチンを記述する方法」のセクションを、PostgreSQLでは「ルーチンを記述する方法」のセクションを参照してください。
注: 『SharePlexインストールおよびセットアップガイド』のSharePlexのコンフリクト解決デモを実行した場合は、デモに使用したデータベースにインストールされているod_employee_genルーチンを表示することで、一般的なコンフリクト解決ルーチンのサンプルを見ることができます。
Oracleのプロシージャインターフェイスについては、「Oracleのプロシージャインターフェイス」を参照してください。
PostgreSQLのプロシージャインターフェイスについては、「PostgreSQLのプロシージャインターフェイス」を参照してください。
コンフリクト解決プロシージャを作成したら、コンフリクト解決ファイルを構成します。このファイルは、どのプロシージャをどのオブジェクトや操作のタイプに、どの順番で使用するかをSharePlexに指示します。
空白のconflict_resolution.oraA。ここで、oraAはOracleDBのsidです。これは、SharePlexのインストール時にSharePlexの変数データディレクトリのdataサブディレクトリに含まれていたものです。ターゲットシステム上のファイルを使用します。
このファイルがない場合は、ASCIIテキストエディタでASCII形式のファイルを作成することができます。conflict_resolution.oraAという名前でなければなりません。ここで、oraAはOracleDBのsidです。
重要: conflict_resolution.sidファイルは、アクティブな設定にごとに1つのみです。
以下のテンプレートを使用して、プロシージャを1つ以上のオブジェクトおよび操作のタイプにリンクします。
SchemaName.tableName | IUD | schema.procedure |
ここで:
コンフリクト解決ファイルの例
scott.sal | IUD | scott.sal_cr |
scott.cust | IUD | scott.cust_cr |
!DEFAULT | IUD | scott.sal_cr5 |
仕組み:
レプリケーション設定内のすべてのテーブルでSharePlexの準備されたルーチンを使用するには、スキーマとオブジェクト名を指定する代わりに!DEFAULTパラメーターを使用します。
カスタムルーチンは、SharePlexの準備されたルーチンよりも優先されます。準備されたルーチンは、カスタムルーチンが失敗した場合にのみ使用されます。これは、!DEFAULTに関連するルーチンのファイル内での順序にかかわらず当てはまります。
!DEFAULTパラメーターでは大文字と小文字を区別します。すべて大文字で入力しなければなりません。
!DEFAULT | IUD | proc0 |
schema.table1 | IUD | proc1 |
james.table1 | IUD | proc2 |
james.table1 | IUD | proc3 |
コンフリクト解決ファイルはレプリケーション中にいつでも変更し、テーブルやプロシージャを追加したり削除したりできます。コンフリクト解決ファイルを変更したら、Postプロセスを一旦停止し、再度開始します。
SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。詳細については、「Oracleデータベースの解決済みコンフリクトに関する情報のロギングページを参照してください。
© ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center