UPDATE文におけるレコードの特定について (4369458)

UPDATE文におけるレコードの特定について

本記事ではソースで行われたDMLのうちUPDATE文についてSharePlexのターゲットに複製され、ターゲットのデータベースに投稿される際のレコードの特定方法について説明します。
 

デフォルトの挙動について
SharePlexではソースにおけるUPDATE文の複製においてターゲットデータベースのテーブルのレコードの特定にWHERE句にて「キーの値」（キーとなる列）と「変更された列の変更前の値」（プレイメージ）を使用します。

具体例
1.次のようなテーブル TBLP1 を複製しているとします。

TBLP1

ID(主キー)	NAME(キーなし)	PHONE
10	admin	9923456
11	spuser	8133334
15	adadmin	2512345

2.ソースで以下のUpdate文をコミットする時、
UPDATE TBLP1 SET PHONE=8823456 where ID=10;
SharePlexはターゲットへ次のデータを含めたメッセージを送ります。
・キーとなる列の値（ID=10）
・変更対象列の変更前（現在）の値

3.ターゲットでは次のようなUPDATE文が構成されて発行されます。
UPDATE TBLP1 SET PHONE=8823456 where ID=10 and PHONE=9923456;
 

注意: あくまでもターゲットのUpdateにつくwhere句の条件となるカラムは「キーとなる列の値」と「変更された列の変更前の値」（プレイメージ）であるため、ソースで UPDATE TBLP1 SET PHONE=8823456 where NAME='admin' のようなSQLを発行してもターゲットで投稿されるSQLのWhere句にNAME='admin'は含まれず、上の例と同様の文になります。

4. この動作によって、もしターゲットのテーブルに対して（独自に変更された等の理由で）UPDATEを行おうとしている ID=10かつPHONE=9923456の行が見つからない状況の場合、PostプロセスはOut-Of-Syncを検出します。

このプレイメージの抽出または使用を行わないように出来るパラメータが存在します。

どちらかのパラメータを2に設定すると、レコードの特定に使用する情報をキー列のみにする（プレイメージを送信しない・使用しない）ことができます。
（ ターゲットでは UPDATE TBLP1 SET PHONE=8823456 where ID=10 のように指定が行われて、PHONE=9923456を探さない）

SP_OCT_REDUCED_KEY  (デフォルト: 1,  即時反映, ソースで動作するCaptureに作用)

2 に設定した場合、このパラメータは、キー値と、（UPDATE の場合）この操作でターゲットに変更された列の操作後の値を送信するように Capture に指示します。この設定は最小限のデータをネットワーク上に送信するとともに、データの post 時にキー値のみを Post で使用できるようにするので、パフォーマンスが改善されます。

SharePlex 10.2 - Reference Guide (quest.com)
SharePlex 8.6.6 - リファレンス・ガイド (quest.com)

SP_OPO_REDUCED_KEY  (デフォルト: 0, 要再起動, ターゲットで動作するPostに作用)

2 に設定すると、キー列のみを使用して WHERE 句を作成するように Post に指示します。この設定は、post のパフォーマンスを最大限に高めるときに使用できます。この設定では変更された列の前後の比較が省略されるため、SharePlex 以外にターゲットデータを変更できるプロセスやユーザーがいないことに注意してください。また、compare コマンドを使用して、通常の整合性検証を実行することをお勧めします。

SharePlex 10.2 - Reference Guide (quest.com)
SharePlex 8.6.6 - リファレンス・ガイド (quest.com)

What does this parameter do? (SP_OCT_REDUCED_KEY) (4331124)
How to speed up the posting of UPDATEs on target? (4301287)
プレイメージを検索しなくなるのでPostの速度が改善します。


また、テーブルに キー値として使用されるカラムが存在しない場合には、SharePlex はSP_*_REDUCED_KEYの値にかかわらず、テーブルのすべてのカラム（LONG/LOBを除く）を使用してターゲットでの変更対象のレコード（行）を検索します。プレイメージも探します。更新対象のレコードをうまく見つけられなければ独自に変更されているものとしてOut-Of-Syncを検出します。


「キー」について

本記事でのキーは行を特定するために使用される一意性を持つ単一あるいは複数からなるカラム（の値）を意味します。
SharePlex 10.2 - Installation and Setup for Oracle Source - Ensure row uniqueness
SharePlex 8.6.6 - インストール・ガイド - 行の一意性の保証

 

行の一意性の保証
  SharePlex では、ターゲット上で変更する行がソース行と一致する正しい行であることを保証できる必要があります。これは、キーとインデックスを使用して 1 対 1 の関係を保証することで実現できます。
キーの役割
 SharePlex は複製するすべてのソーステーブルおよびターゲットテーブル、特に大きなテーブルや LONG 列を含むテーブルに対してプライマリキーまたは一意のキーが存在する場合に、最も速く動作します。使用するキーを選択するとき、SharePlex は最適なキー列を次の優先順位で使用します。

レプリケーション中のテーブルのキーについてはソースでの show config の出力にてテーブルおよびそのキーカラムを確認できます。
sp_ctrl＞ show config

Tables Replicating with Key: （キーをもつテーブル。KEY:一意キーを構成するカラム）
  "APPDBUSER"."DFF_A"   KEY: COL1
  "APPDBUSER"."DFF_KK"   KEY: COL1
  "APPDBUSER"."DFF_PKN"   KEY: COL1

Tables Replicating with no key: （一つもキーカラムを持たないテーブル）
  "APPDBUSER"."DFF_NKT"


ユニーク性のあるカラムを一切持たないテーブルに対して、1つまたは複数の列の組み合わせで実質的にユニーク性を担保できる場合、手動でキーとして定義することが可能です。（そのカラムが本当にユニークかどうかはソースDBに依存します。パフォーマンスについてはターゲット側DB次第です。）
SharePlex 10.2 - Installation and Setup for Oracle Source (quest.com) Define a unique key
SharePlex 8.6.6 - インストール・ガイド (quest.com) 一意のキーの定義

例:
SQL> create table DFF_NONKT(COL1 varchar2(2),COL2 NUMBER,COL3... COL4... COL5... ); 
-- このテーブルのどのカラムにも設定上のユニーク設定（PK,UK, 制約, 索引等）は無いため、通常はターゲットで全カラムを使用した検索が行われる。
-- UPDATE NONKT SET COL3=999 where COL1='x' and COL2=20 and COL3=998 and COL4=  ... and COL5=...

このテーブルに対して Configで次のように記述すると一意性のキーとしてCOL1とCOL2が採用されます。
appdbuser.DFF_NONKT !key(COL1,COL2)    appc.DFF_NONKT         targetsys@o.orcltgt

上の内容を含む新しいConfigでActivateすると DFF_NONKT のキーについてCOL1,COL2が追加されています。
sp_ctrl> show config

Tables Replicating with Key:
  "APPDBUSER"."DFF_A"   KEY: COL1
  "APPDBUSER"."DFF_KK"   KEY: COL1
  "APPDBUSER"."DFF_PKN"   KEY: COL1
  "APPDBUSER"."DFF_NONKT"   KEY: COL1,COL2   # COL1,COL2が一意性のキーとして使用される

UPDATE文複製時の行の特定にCOL1,COL2と変更対象列の値（プレイメージ）のみが使用されるようになる
UPDATE NONKT SET COL3=999 where COL1='x' and COL2=20 and COL3=998

 

詳細に動作確認するには特定テーブルへのデバッグが必要ですがPostが直近に発行したSQLの概要(DMLの種類、使用したカラム)についてはターゲットでの show sqlにて確認できます。