Chat now with support
Chat with Support

SharePlex 11.4 - 管理者ガイド

このガイドについて このガイドで使用される表記規則 SharePlexの概要 SharePlexの実行 SharePlexの複数のインスタンスの実行 sp_ctrlでのコマンドの実行 SharePlexパラメータの設定 データレプリケーションの設定 コンテナデータベースとの間のレプリケーションの設定 名前付きキューの設定 分割レプリケーションの設定 変更履歴ターゲットへのレプリケーションの設定 レプリケーション戦略の設定 DDLレプリケーションの設定 エラー処理の設定 データトランスフォーメーションの設定 セキュリティ機能の設定 SharePlexユーザのセキュリティグループへの割り当て 本番システムでのレプリケーションの開始 SharePlexの監視 レプリケーションの問題の防止と解決 非同期データのrepair Captureプロセスの調整 Postプロセスの調整 Oracleフェールオーバー後のレプリケーションのリカバリ アクティブなレプリケーション環境に対する変更 Oracleアプリケーションのパッチまたはアップグレードの適用 ソースまたはターゲットのOracleデータのバックアップ トラブルシューティングのヒント 付録A: ピアツーピア図 付録B: SharePlex環境変数

コンフリクト解決ルーチンの開発

このセクションでは、さまざまなユーザ定義のコンフリクト解決ルーチンについて説明します。

コンフリクトとは

コンフリクトとは、ソース側のテーブルとターゲット側のテーブルが同一ではない、非同期の状態を指します。ターゲット側のテーブルの行に対するSharePlexで作成されたDMLステートメントの実行に失敗した場合は、以下のような理由で非同期コンフリクト状況が発生すると予測できます。

  • Postは複製されたINSERTを適用しますが、同じキーを持つ行が既にターゲットにあります。Postは以下のロジックを適用します。

    • ターゲット行の現在の値がすべてINSERT値と同じ場合、Postは行が同期していると見なし、操作を破棄します。
    • いずれかの値がINSERTの値と異なる場合、Postはこれを非同期状態と見なします。

    注意: INSERTをポストする際に、キー以外の値を考慮しないようにPostを設定することができますOracleからOracleにデータを複製する場合にのみ適用可能。『SharePlexリファレンスガイド』のSP_OPO_SUPPRESSED_OOSパラメーターを参照してください。

  • Postは複製されたUPDATEを適用しますが、UPDATEのキー値と同じキー値を持つ行がターゲットに見付かりません。または、Postは正しい行を見付けますが、その行の値がUPDATEの前の値と一致しません。Postは以下のロジックを適用します。

    • ターゲット行の現在の値がUPDATEの後の値と一致する場合、Postはその行が同期していると見なし、操作を破棄します。
    • ターゲット行の値がUPDATEの前または後の値と一致しない場合、Postはこれを非同期状態と見なします。

    注意: ターゲット行の現在の値がUPDATEの後の値と一致する場合、非同期のメッセージを返すようにPostを設定できますOracleからOracleにデータを複製する場合にのみ適用可能。『SharePlexリファレンスガイド』のSP_OPO_SUPPRESSED_OOSパラメーターを参照してください。

  • DELETEはソースデータで実行されますが、Postはキーを使用してターゲット行を見付けることができません。Postは、DELETEステートメントを作成するときにWHERE句にキー値だけを含めます。ターゲットに行が存在しない場合、Postは操作を破棄します。

OracleからOracleへのユーザ定義コンフリクト解決ルーチン

コンフリクト解決ルーチンを作成するには、コンフリクトが発生したときのSharePlexの動作を指示するPL/SQLプロシージャを記述します。ビジネスルールは企業によって大きく異なるため、あらゆる状況に適用できる標準的なコンフリクト解決ルールや構文を作成することは不可能です。おそらくご自身でルーチンを記述する必要があります。例えば、サイトやシステムの優先順位をプライマリルーチンとし、タイムスタンプをセカンダリルーチンとするなど、複数のプロシージャを記述することをお勧めします。1つのプロシージャが成功するか、利用可能なプロシージャがなくなるまで、SharePlexは順次ルーチンを呼び出します。

SharePlexには、ルーチンの基礎として使用できる以下のツールが用意されています。

重要!
  • このドキュメントには、支援のためにガイドライン、例、テンプレートが含まれていますが、これをお客様の実際のルーチンとしては使用しないでください。
  • 意図したとおりに動作することを確認し、あるルーチンが別のルーチンを打ち消さないことを確認するために、本番稼働環境に投入する前にコンフリクト解決ルーチンをテストしてください。
  • デフォルトでは、SharePlexは同期外の状態では停止しません。失敗したコンフリクト解決の試みが解決されない場合、データベースはますます同期を外れる可能性があります。sp_ctrlshow logコマンドを使用して、イベントログを頻繁にチェックし、同期外の警告を監視します。show logおよびその他のSharePlexコマンドの詳細については、『SharePlexリファレンスガイド』を参照してください。
  • コンフリクト解決ロジックは時折更新されるため、これらの説明を補強する、またはこれらの説明よりも優先される追加情報については、ご使用バージョンのSharePlexのリリースノートやドキュメントを参照してください。
SharePlexの汎用インターフェイスを使用してルーチンを記述する方法

SharePlexには、記述したプロシージャルーチンとの間で情報を受け渡しするために使用できる汎用のコンフリクト解決PL/SQLパッケージがあります。

注: カスタムルーチンは、OracleからOracleのソースターゲットの組み合わせにのみ対応しています。

始める前に以下のガイドラインをご確認ください。

  • 一般的なコンフリクト解決とトランスフォーメーションの両方に同じPL/SQLパッケージが使用されます名前はsp_crテーブルには、一般的なコンフリクト解決かトランスフォーメーションのいずれかを使用しますが、両方を使用することはできません。変換されたテーブルはSharePlexでcompareすることができず、コンフリクトの解決は成功しません。両方が使われている場合、SharePlexはトランスフォーメーションルーチンのみを呼び出します。該当する場合、同じ設定内の異なるテーブルに対して一般的なコンフリクト解決とトランスフォーメーションを使用することができます。詳細については、データトランスフォーメーションの設定を参照してください。
  • コンフリクトの解決はDDLの変更には使用できません。
  • PL/SQLを使用してコンフリクト解決のためにアクセスするテーブルには、オブジェクトの所有者からSharePlexに暗黙的に付与された権限が必要です。
  • コンフリクト解決では、LONG列やLOB列の変更をサポートしていません。

注:SharePlexインストールおよびセットアップガイド』のSharePlexのコンフリクト解決デモを実行した場合は、デモに使用したデータベースにインストールされているod_employee_genルーチンを表示することで、一般的なコンフリクト解決ルーチンのサンプルを表示することができます。

プロシージャインターフェイス

このテンプレートに従ってプロシージャを作成してください。

(table_info in outsplex.sp_cr.row_typ, col_values insplex.sp_cr.col_def_tabtyp)

ここで:

  • splexSharePlexのスキーマです。
  • sp_crはPL/SQLレコードおよびテーブルの構造を含むパッケージの名前です。
  • row_typは、in/out変数を渡すPL/SQLレコードの名前ですパッケージの定義」を参照
  • col_def_typeは、列情報を保存するPL/SQLテーブルの名前ですcol_def_typeテーブル」を参照
パッケージの定義

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 
); 
IN変数

行の操作によってコンフリクトが発生するたびに、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のエラー番号。

OUT変数

これらの変数は、プロシージャに成功したか失敗したかに基づいてSharePlexのアクションを指示します。

変数 説明
status

プロシージャが成功したかどうかを定義します。このパラメーターには値を指定する必要があります。

  • 0の値は、正常に実行されたことを意味します。この動作は、プロシージャの使用目的がコンフリクト解決かトランスフォーメーションかによって異なります。

    トランスフォーメーション: PostはSQLを書き込みません。トランスフォーメーションに成功すると、SharePlexはイベントログにエラーメッセージを書き込まず、postキューにある次のレプリケートされた操作を読み込むことで処理を続行します。

  • コンフリクト解決: 0の値は、SQLステートメントを続行するようにSharePlexに指示します。コンフリクト解決に成功すると、SharePlexはイベントログにログエントリを書き込みません。
  • 1の値は、プロシージャが失敗したことを意味します。この場合、SharePlexが取るアクションは、アクション変数として指定したものによって異なります。
  • トランスフォーメーションのみ7の値は実行に失敗したことを意味し、Postプロセスの停止を指示します。
action

希望するSharePlexのアクションを定義します。これは、プロシージャの使用目的がトランスフォーメーションかコンフリクト解決かによって異なります。

トランスフォーメーション: このパラメーターには0の値を指定する必要があります。これは、SQLステートメントをポストしないようにSharePlexに指示します。トランスフォーメーションルーチンは、トランスフォーメーションの結果をターゲット側のテーブルや別のテーブルにポストします。このアクションの結果は、レポート変数に指定した内容によって異なります。

コンフリクト解決: コンフリクト解決プロシージャに失敗した場合に取るべきアクションを指定します。このパラメーターには値を指定する必要があります。

  • 0の値は、SQLステートメントをポストしないようにSharePlexに指示します。このアクションの結果は、reporting変数に指定した内容によって異なります。

    さらに、コンフリクト解決ファイルに記載されている次のコンフリクト解決プロシージャがあれば、それを試すようにSharePlexに指示します。

  • 値1は、SharePlexの内部で使用するために予約されています。使用しないでください。
  • 2の値は、コンフリクト解決ファイルに記載されている次のコンフリクト解決プロシージャが存在すれば、それを試すようにSharePlexに指示します。
レポート作成機能

不成功に終わったプロシージャの結果をSharePlexがどのように報告するかを決定します。このパラメーターには値を指定する必要があります。

  • 0の値は、SID_errlog.sqlログにエラーを報告したり、失敗したSQLステートメントを書き込んだりしないようにSharePlexに指示します。
  • 値1と2は、SharePlexの内部で使用するために予約されています。使用しないでください。
  • 3の値は、失敗したSQLステートメントをSID_errlog.sqlログに書き込み、イベントログにエラーを報告するようにSharePlexに指示します。

col_def_typeテーブル

SharePlexは、レプリケートされた操作ごとにcol_def_tabtyp PL/SQLテーブルを作成します。 このテーブルには列情報が保存されます。これは、プロシージャの使用目的がトランスフォーメーションかコンフリクト解決かによって異なります。

  • トランスフォーメーション: 行を操作するたびに、SharePlexは列情報をcol_def_typeに書き込みます。
  • コンフリクトの解決: 行の操作でコンフリクトが発生するたびに、SharePlexは列情報をcol_def_tabtypに書き込みます。

すべてのフィールドは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
col_def_tabtypの説明
説明
column_name 例えばemp_last_nameなど、ソース側のテーブルからレプリケートされた列の名前をプロシージャに伝えます。この値では大文字と小文字を区別しません。
data type 例えばVARCHAR2など、レプリケートされた列のデータのデータ型をプロシージャに伝えます。この値は常に大文字です。
is_key 列がキー列であるかどうかをプロシージャに伝えます。キー列の場合、SharePlexTRUEの値を渡します。列がキーの一部でない場合、SharePlexFALSEの値を渡します。
is_changed

列の値が変更されたかどうかをプロシージャに伝えます。変更された場合、SharePlexTRUEの値を渡します。列が変更されない場合、SharePlexFALSEの値を渡します。

  • INSERTの場合、NULL以外の値でis_changedTRUEになります。どの列もデータベースに存在しないためです。NULLの値が挿入された場合、is_changedFALSEになります。
  • UPDATEの場合、キー列以外ではis_changedTRUEになります。キー列の場合、is_changedは通常FALSEですが、SharePlexは変更されたキー列の値を渡します。

    コンフリクト解決のみ: ターゲットシステム上でキー値も変更された場合、SharePlexは正しい行を見付けることができず、コンフリクト解決に失敗する可能性があります。

  • DELETEの場合、is_changedは常にFALSEになります。これは、SharePlexがDELETEステートメントのキー値のみをレプリケートするからです。
old_value

レプリケートされた列の、ソースシステムで変更される前の古い値をプロシージャに伝えます。INSERTでは、この列はNULLです。これは、INSERTを実行する前にターゲットデータベースに行が存在しなかったためです。

コンフリクト解決のみ: これは、UPDATEとDELETEの同期チェックの一環としてSharePlexがソース列とターゲット列を比較したときの基準となるプリイメージです。SharePlexによって渡された古い値が、ターゲット行から得られたcurrent_valueの値と一致しない場合、コンフリクトが発生します。

new_value ソースシステムで変更された、レプリケートされた列の新しい値をプロシージャに伝えます。
current_value ターゲット側のテーブルの列の現在の値をプロシージャに伝えます。SharePlexがターゲット行を見付けられない場合、値はNULLになります。
col_def_tabtypテーブルのエントリの例操作のタイプ別

以下の表は、各操作で起こりうる結果を示しています。

INSERT操作
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の現在の値を返しません。

UPDATE操作
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キーを使用しただけでは行を見付けられない場合、SharePlexNULLを返します。

2トランスフォーメーションUPDATEの場合、SharePlexはPRIMARYキーとプリイメージを使用して行を検索することはできません。これはトランスフォーメーションによりプリイメージが異なるためです。別の方法として、PRIMARYキーだけを使用して行を検索することもできます。見付かった場合、SharePlexは変更された列だけでなくキー列の現在の値も返します。PRIMARYキーだけでは行を特定できない場合、current_valueはNULLになります。

DELETE操作
column_name is_changed old_value new_value current_value1 is_key
C1 FALSE bind NULL NULL TRUE

1 DELETEが失敗するのは、SharePlexがPRIMARYキーを使用して行を見付けることができなかったためです。したがって、SharePlexはNULLを返します。

conflict_resolution.SIDでのルーチンのリスト

コンフリクト解決プロシージャを作成したら、コンフリクト解決ファイルを構成します。このファイルは、どのプロシージャをどのオブジェクトや操作のタイプに、どの順番で使用するかを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

ここで:

  • owner.objectターゲットオブジェクトの所有者と名前またはワイルドカードエントリです構文規則ページを参照
  • i| u | dは、指定されたプロシージャで解決されるコンフリクトの原因となる操作のタイプです。例えばidiudのように、一部またはすべての操作のタイプを指定することができます。大文字でも小文字でも構いません。
  • owner.procedureは、指定されたオブジェクトと操作のタイプを扱うコンフリクト解決プロシージャの所有者と名前です。
構文規則
  • オブジェクトの指定、操作のタイプの指定、プロシージャの指定の間には、少なくとも1つのスペースを空けなければなりません。
  • LIKE演算子とSQLワイルドカード%を使用すると、検索文字列を使用して複数のオブジェクトを指定できます例を参照
  • アンダースコア_を使用して1文字のワイルドカードを表すことができます。アンダースコア文字を含むテーブル名emp_salなどの場合、SharePlexはバックスラッシュ\を拡張文字として認識し、アンダースコアがワイルドカードではなくリテラルであることを示します例: like:scott.%\_corp\_emp。LIKE演算子を使用しない場合、オブジェクト名にアンダースコアが含まれていても、バックスラッシュ拡張文字は必要ありません。
  • コンフリクト解決ファイルにプロシージャをリストする順番によって使用の優先順位が決まります降順。テーブル固有のプロシージャをリストした場合、SharePlexは、ワイルドカードのオブジェクト名で指定されたプロシージャの前にそのプロシージャを使用します。
  • ファイルのいずれかの場所にコメント行を入れます。コメント行の先頭にはポンド記号#を付けます。
コンフリクト解決ファイルの例
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

仕組み:

  • scott.sal_crルーチンは、scott.sal_cr1プロシージャがscott.salテーブルに使用される前にこのテーブルに使用されます。
  • scott.emp_cr1プロシージャは、scott.emp_cr2プロシージャの前に、検索条件を満たすすべてのテーブルに対して使用されます。
  • scott.custでは、UPDATEのためにプロシージャが呼び出された後、すべての操作に対して他のルーチンが使用されます。
コンフリクト解決ファイルでSharePlexの準備されたルーチンを指定する方法

レプリケーションの設定のすべてのテーブルで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プロセスを一旦停止し、再度開始します。

Oracleデータベースの解決されたコンフリクトに関する情報のロギング

SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。詳細については、「Oracleデータベースの解決済みコンフリクトに関する情報のロギングページを参照してください。

ユーザ定義のコンフリクト解決ルーチン(PostgreSQLまたはPostgreSQL Database as a ServiceからPostgreSQLへ)

ユーザ定義のコンフリクト解決ルーチンPostgreSQLまたはPostgreSQL Database as a ServiceからPostgreSQLへ

コンフリクト解決ルーチンを作成するには、コンフリクトが発生したときのSharePlexの動作を指示するPL/PGSQLプロシージャを記述します。ビジネスルールは企業によって大きく異なるため、あらゆる状況に適用できる標準的なコンフリクト解決ルールや構文を作成することは不可能です。おそらくご自身でルーチンを記述する必要があります。例えば、サイトやシステムの優先順位をプライマリルーチンとし、タイムスタンプをセカンダリルーチンとするなど、複数のプロシージャを記述することをお勧めします。1つのプロシージャが成功するか、利用可能なプロシージャがなくなるまで、SharePlexは順次ルーチンを呼び出します。

SharePlexには、ルーチンの基礎として使用できる以下のツールが用意されています。

重要

  • このドキュメントには、支援のためにガイドライン、例、テンプレートが含まれていますが、これをお客様の実際のルーチンとしては使用しないでください。

  • 意図したとおりに動作することを確認し、あるルーチンが別のルーチンを打ち消さないことを確認するために、本番稼働環境に投入する前にコンフリクト解決ルーチンをテストしてください。

  • デフォルトでは、SharePlexは同期外の状態では停止しません。失敗したコンフリクト解決の試みが解決されない場合、データベースはますます同期を外れる可能性があります。sp_ctrlshow logコマンドを使用して、イベントログを頻繁にチェックし、同期外の警告を監視します。show logおよびその他のSharePlexコマンドの詳細については、『SharePlexリファレンスガイド』を参照してください。

  • コンフリクト解決ロジックは時折更新されるため、これらの説明を補強する、またはこれらの説明よりも優先される追加情報については、ご使用バージョンのSharePlexのリリースノートやドキュメントを参照してください。

SharePlexの汎用インターフェイスを使用してルーチンを記述する方法

SharePlexには、記述したプロシージャルーチンとの間で情報を受け渡しするために使用できる汎用のコンフリクト解決インターフェイスがあります。

注: カスタムルーチンは、OracleからPostgreSQLおよびPostgreSQLからPostgreSQLのソースとターゲットの組み合わせにのみ対応しています。

始める前に以下のガイドラインをご確認ください。

  • コンフリクトの解決はDDLの変更には使用できません。
  • PL/PGSQLプロシージャを使用してコンフリクト解決のためにアクセスするテーブルには、オブジェクトのスキーマからSharePlexに暗黙的に付与された権限が必要です。
  • カスタムコンフリクト解決は、CHAR > 2000、VARCHAR > 4000、または長さのないもの、TEXT、BYTEAなどの大きなデータ型をサポートしていません。
プロシージャインターフェイス

このテンプレートに従ってプロシージャを作成してください。

(table_info sp_cr.row_typ, col_values sp_cr.col_def_typ[], INOUT status INTEGER, INOUT action INTEGER, INOUT reporting INTEGER)

ここで:

  • sp_crはPL/PGSQLレコードおよびテーブルの構造を含むスキーマの名前です。
  • row_typは、in変数を渡すPL/PGSQLレコードの名前ですスキーマの定義」を参照
  • col_def_typは、列情報を保存するPL/PGSQLテーブルの名前ですcol_def_typ型を参照
スキーマの定義

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)
); 
IN Variables

行の操作によってコンフリクトが発生するたびに、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'に設定されます。

OUT変数

これらの変数は、プロシージャに成功したか失敗したかに基づいてSharePlexのアクションを指示します。

変数 説明
status

プロシージャが成功したかどうかを定義します。このパラメーターには値を指定する必要があります。

  • 0の値は、正常に実行されたことを意味します。この動作は、プロシージャの使用目的がコンフリクト解決かどうかによって異なります。

  • コンフリクト解決: 0の値は、SQLステートメントを続行するようにSharePlexに指示します。コンフリクト解決に成功すると、SharePlexはイベントログにログエントリを書き込みません。
  • 1の値は、プロシージャが失敗したことを意味します。この場合、SharePlexが取るアクションは、アクション変数として指定したものによって異なります。
action

希望するSharePlexのアクションを定義します。これは、プロシージャの使用目的がコンフリクト解決かどうかによって異なります。

コンフリクト解決: コンフリクト解決プロシージャに失敗した場合に取るべきアクションを指定します。このパラメーターには値を指定する必要があります。

  • 0の値は、SQLステートメントをポストしないようにSharePlexに指示します。このアクションの結果は、reporting変数に指定した内容によって異なります。

    さらに、コンフリクト解決ファイルに記載されている次のコンフリクト解決プロシージャがあれば、それを試すようにSharePlexに指示します。

  • 値1は、SharePlexの内部で使用するために予約されています。使用しないでください。
  • 2の値は、コンフリクト解決ファイルに記載されている次のコンフリクト解決プロシージャが存在すれば、それを試すようにSharePlexに指示します。
レポート作成機能

不成功に終わったプロシージャの結果をSharePlexがどのように報告するかを決定します。このパラメーターには値を指定する必要があります。

  • 0の値は、database_errlog.sqlログにエラーを報告したり、失敗したSQLステートメントを書き込んだりしないようにSharePlexに指示します。
  • 値1と2は、SharePlexの内部で使用するために予約されています。使用しないでください。
  • 3の値は、失敗したSQLステートメントをdatabase_errlog.sqlログに書き込み、イベントログにエラーを報告するようにSharePlexに指示します。

col_def_typ型

SharePlexは、レプリケートされた操作ごとにcol_def_typ型を作成します。 この型には列情報が保存されます。

  • コンフリクトの解決: 行の操作でコンフリクトが発生するたびに、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

col_def_typの説明
説明
column_name 例えばemp_last_nameなど、ソース側のテーブルからレプリケートされた列の名前をプロシージャに伝えます。この値では大文字と小文字を区別しません。
data type 例えばVARCHARなど、レプリケートされた列のデータのデータ型をプロシージャに伝えます。この値は常に大文字です。
is_key 列がキー列であるかどうかをプロシージャに伝えます。キー列の場合、SharePlexTRUEの値を渡します。列がキーの一部でない場合、SharePlexFALSEの値を渡します。
is_changed

列の値が変更されたかどうかをプロシージャに伝えます。変更された場合、SharePlexTRUEの値を渡します。列が変更されない場合、SharePlexFALSEの値を渡します。

  • INSERTの場合、NULL以外の値でis_changedTRUEになります。どの列もデータベースに存在しないためです。NULLの値が挿入された場合、is_changedFALSEになります。
  • UPDATEの場合、キー列以外ではis_changedTRUEになります。キー列の場合、is_changedは通常FALSEですが、SharePlexは変更されたキー列の値を渡します。

    コンフリクト解決のみ: ターゲットシステム上でキー値も変更された場合、SharePlexは正しい行を見付けることができず、コンフリクト解決に失敗する可能性があります。

  • DELETEの場合、is_changedは常にFALSEになります。これは、SharePlexがDELETEステートメントのキー値のみをレプリケートするからです。
old_value

レプリケートされた列の、ソースシステムで変更される前の古い値をプロシージャに伝えます。INSERTでは、この列はNULLです。これは、INSERTを実行する前にターゲットデータベースに行が存在しなかったためです。

コンフリクト解決のみ: これは、UPDATEとDELETEの同期チェックの一環としてSharePlexがソース列とターゲット列を比較したときの基準となるプリイメージです。SharePlexによって渡された古い値が、ターゲット行から得られたcurrent_valueの値と一致しない場合、コンフリクトが発生します。

new_value ソースシステムで変更された、レプリケートされた列の新しい値をプロシージャに伝えます。
col_def_typテーブルのエントリの例操作のタイプ別

以下の表は、各操作で起こりうる結果を示しています。

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
conflict_resolution.dbnameでのルーチンのリスト

コンフリクト解決プロシージャを作成したら、コンフリクト解決ファイルを構成します。このファイルは、どのプロシージャをどのオブジェクトや操作のタイプに、どの順番で使用するかをSharePlexに指示します。

コンフリクト解決ファイルの場所

空白のconflict_resolution.testdb。ここで、testdbはDB名です。これは、SharePlexのインストール時にSharePlexの変数データディレクトリのdataサブディレクトリに含まれていたものです。ターゲットシステム上のファイルを使用します。

このファイルがない場合は、ASCIIテキストエディタでASCII形式のファイルを作成することができます。名前はconflict_resolution.DBにする必要があります。ここで、DBはデータベース名です。

重要: conflict_resolutionDBファイルは、アクティブな設定ごとに1つだけでなければなりません。

コンフリクト解決ファイルのエントリの作成方法

以下のテンプレートを使用して、プロシージャを1つ以上のオブジェクトおよび操作のタイプにリンクします。

SchemaName.tableName IUD schema.procedure

ここで:

  • IUDは、指定されたプロシージャで解決されるコンフリクトの原因となる操作のタイプです。
  • schema.procedureは、指定されたオブジェクトと操作のタイプを扱うコンフリクト解決プロシージャのスキーマと名前です。
構文規則
  • オブジェクトの指定、操作のタイプの指定、プロシージャの指定の間には、少なくとも1つのスペースを空けなければなりません。
  • コンフリクト解決ファイルにプロシージャをリストする順番によって使用の優先順位が決まります降順。テーブル固有のプロシージャをリストした場合、SharePlexは、ワイルドカードのオブジェクト名で指定されたプロシージャの前にそのプロシージャを使用します。
コンフリクト解決ファイルの例
scott.sal IUD scott.sal_cr
scott.cust IUD scott.cust_cr
!DEFAULT IUD scott.sal_cr5

仕組み:

  • scott.sal_crルーチンは、scott.sal_cr5プロシージャがscott.salテーブルに使用される前にこのテーブルに使用されます。
  • scott.custでは、IUDのためにscott.cust_crプロシージャが呼び出された後に、すべての操作に対してデフォルトのルーチンが使用されます。
コンフリクト解決ファイルでSharePlexの準備されたルーチンを指定する方法

レプリケーション設定内のすべてのテーブルでSharePlexの準備されたルーチンを使用するには、スキーマとオブジェクト名を指定する代わりに!DEFAULTパラメーターを使用します。

カスタムルーチンは、SharePlexの準備されたルーチンよりも優先されます。準備されたルーチンは、カスタムルーチンが失敗した場合にのみ使用されます。これは、!DEFAULTに関連するルーチンのファイル内での順序にかかわらず当てはまります。

!DEFAULTパラメーターでは大文字と小文字を区別します。すべて大文字で入力しなければなりません。

!DEFAULT IUD proc0
schema.table1 IUD proc1
james.table1 IUD proc2
james.table1 IUD proc3
レプリケーションがアクティブな状態でコンフリクト解決ファイルを変更する方法

コンフリクト解決ファイルはレプリケーション中にいつでも変更し、テーブルやプロシージャを追加したり削除したりできます。コンフリクト解決ファイルを変更したら、Postプロセスを一旦停止し、再度開始します。

PostgreSQLデータベースの解決済みコンフリクトに関する情報のロギング

SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。詳細については、「PostgreSQLデータベースの解決済みコンフリクトに関する情報のロギングページを参照してください。

ユーザ定義のコンフリクト解決ルーチン(PostgreSQLまたはPostgreSQL Database as a ServiceからOracleへ)

ユーザ定義のコンフリクト解決ルーチンPostgreSQLまたはPostgreSQL Database as a ServiceからOracleへ

コンフリクト解決ルーチンを作成するには、コンフリクトが発生したときのSharePlexの動作を指示するPL/SQLプロシージャを記述します。ビジネスルールは企業によって大きく異なるため、あらゆる状況に適用できる標準的なコンフリクト解決ルールや構文を作成することは不可能です。おそらくご自身でルーチンを記述する必要があります。例えば、サイトやシステムの優先順位をプライマリルーチンとし、タイムスタンプをセカンダリルーチンとするなど、複数のプロシージャを記述することをお勧めします。1つのプロシージャが成功するか、利用可能なプロシージャがなくなるまで、SharePlexは順次ルーチンを呼び出します。

SharePlexには、ルーチンの基礎として使用できる以下のツールが用意されています。

重要
  • このドキュメントには、支援のためにガイドライン、例、テンプレートが含まれていますが、これをお客様の実際のルーチンとしては使用しないでください。
  • 意図したとおりに動作することを確認し、あるルーチンが別のルーチンを打ち消さないことを確認するために、本番稼働環境に投入する前にコンフリクト解決ルーチンをテストしてください。
  • デフォルトでは、SharePlexは同期外の状態では停止しません。失敗したコンフリクト解決の試みが解決されない場合、データベースはますます同期を外れる可能性があります。sp_ctrlshow logコマンドを使用して、イベントログを頻繁にチェックし、同期外の警告を監視します。show logおよびその他のSharePlexコマンドの詳細については、『SharePlexリファレンスガイド』を参照してください。
  • コンフリクト解決ロジックは時折更新されるため、これらの説明を補強する、またはこれらの説明よりも優先される追加情報については、ご使用バージョンのSharePlexのリリースノートやドキュメントを参照してください。
SharePlexの汎用インターフェイスを使用してルーチンを記述する方法

SharePlexには、記述したプロシージャルーチンとの間で情報を受け渡しするために使用できる汎用のコンフリクト解決PL/SQLパッケージがあります。

始める前に、PL/SQLを使用してコンフリクト解決のためにアクセスするテーブルには、オブジェクトの所有者からSharePlexに暗黙的に付与された権限が必要であることに注意してください。その他のガイドラインについては、Oracleでは「Oracle用のルーチンを記述する方法」のセクションを、PostgreSQLでは「ルーチンを記述する方法」のセクションを参照してください。

注:SharePlexインストールおよびセットアップガイド』のSharePlexのコンフリクト解決デモを実行した場合は、デモに使用したデータベースにインストールされているod_employee_genルーチンを表示することで、一般的なコンフリクト解決ルーチンのサンプルを見ることができます。

プロシージャインターフェイス

Oracleのプロシージャインターフェイスについては、「Oracleのプロシージャインターフェイス」を参照してください。

PostgreSQLのプロシージャインターフェイスについては、「PostgreSQLのプロシージャインターフェイス」を参照してください。

conflict_resolution.sidでのルーチンのリスト

コンフリクト解決プロシージャを作成したら、コンフリクト解決ファイルを構成します。このファイルは、どのプロシージャをどのオブジェクトや操作のタイプに、どの順番で使用するかを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

ここで:

  • IUDは、指定されたプロシージャで解決されるコンフリクトの原因となる操作のタイプです。
  • schema.procedureは、指定されたオブジェクトと操作のタイプを扱うコンフリクト解決プロシージャのスキーマと名前です。
構文規則
  • オブジェクトの指定、操作のタイプの指定、プロシージャの指定の間には、少なくとも1つのスペースを空けなければなりません。
  • コンフリクト解決ファイルにプロシージャをリストする順番によって使用の優先順位が決まります降順。テーブル固有のプロシージャをリストした場合、SharePlexは、ワイルドカードのオブジェクト名で指定されたプロシージャの前にそのプロシージャを使用します。

コンフリクト解決ファイルの例

scott.sal IUD scott.sal_cr
scott.cust IUD scott.cust_cr
!DEFAULT IUD scott.sal_cr5

仕組み:

  • scott.sal_crルーチンは、scott.sal_cr5プロシージャがscott.salテーブルに使用される前にこのテーブルに使用されます。
  • scott.custでは、IUDのためにscott.cust_crプロシージャが呼び出された後に、すべての操作に対してデフォルトのルーチンが使用されます。
コンフリクト解決ファイルでSharePlexの準備されたルーチンを指定する方法

レプリケーション設定内のすべてのテーブルでSharePlexの準備されたルーチンを使用するには、スキーマとオブジェクト名を指定する代わりに!DEFAULTパラメーターを使用します。

カスタムルーチンは、SharePlexの準備されたルーチンよりも優先されます。準備されたルーチンは、カスタムルーチンが失敗した場合にのみ使用されます。これは、!DEFAULTに関連するルーチンのファイル内での順序にかかわらず当てはまります。

!DEFAULTパラメーターでは大文字と小文字を区別します。すべて大文字で入力しなければなりません。

!DEFAULT IUD proc0
schema.table1 IUD proc1
james.table1 IUD proc2
james.table1 IUD proc3
レプリケーションがアクティブな状態でコンフリクト解決ファイルを変更する方法

コンフリクト解決ファイルはレプリケーション中にいつでも変更し、テーブルやプロシージャを追加したり削除したりできます。コンフリクト解決ファイルを変更したら、Postプロセスを一旦停止し、再度開始します。

Oracleデータベースの解決されたコンフリクトに関する情報のロギング

SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。詳細については、「Oracleデータベースの解決済みコンフリクトに関する情報のロギングページを参照してください。

 

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating