アクティベートにて複製先のルートが変更される場合のロック獲得について説明します。
複製対象のテーブルオブジェクトに対して、アクティベートで複製先のルートを変更した場合（キューを分ける等）にはルート変更の対象となるすべてのテーブルについてロック（獲得・解放）が行われる仕組みになっています。
以下に具体例を挙げて説明します。
1. test1 スキーマに以下のようにテーブルを作成します。
create table sptest1 (col varchar2(10) );
create table sptest2 (col varchar2(10) );
create table sptest3 (col varchar2(10) );
create table sptest4 (col varchar2(10) );
create table sptest5 (col varchar2(10) );
create table sptest6 (col varchar2(10) );
2. コンフィグファイルを設定します。
コンフィグ名はtest1configであるとします。
datasource:o.orcl
expand test1.% test1.% rhel6tgt@o.orcl2
3. アクティベートします。
sp_ctrl> activate config test1config
この時の対象のPostキュー名はデフォルトでソースホスト名が与えられます。
4. コンフィグファイルをコピーします。
sp_ctrl> copy config test1config to test2config
5. test2configにて、test1.%の複製用Postキューが 名前付きPostキューとなるように queue01 を指定します。
sp_ctrl> edit config test2config
datasource:o.orcl
expand test1.% test1.% rhel6tgt:queue01@o.orcl2
6. アクティベートします。
sp_ctrl> activate config test2config
このとき、複製先のルートを変更するため test1 スキーマ内の全てのテーブルに対してロックを同時に獲得します。
今回の例ではsptest1からsptest6までの全てのテーブルに対して同時にロックを獲得します。
複数テーブルに対して同時にロック獲得されることを避けたい場合は、以下のように移動するテーブルだけ名前付きPostキューへ変更してください。
datasource:o.orcl
expand test1.% not (sptest1) test1.% rhel6tgt@o.orcl2
expand test1.sptest1 test1.sptest1 rhel6tgt:queue01@o.orcl2
上述のConfigによるアクティベートであれば、ルーティング移動を伴う sptest1テーブルについてのみロックが行われます。
徐々にsptest2,sptest3と名前付きPostキューへ移行してアクティベートすることで複数テーブルまとめてのロックが回避できます。
しかしながら、アクティベーションによる複製対象テーブルの追加・変更設定においては、どこかではロックが必要となりますのでロックされることが許容できる期間を設けて実施することをお勧めします。
