はじめに
Oracle Autonomous Database(以下ADB)には、ソースの更新内容をクローンに反映するリフレッシュという機能を持つ、リフレッシュ可能クローンがあります。
これはOracle Multitenantの一機能でもありますが、今回はAutonomous Databaseのリフレッシュ可能クローンに限定します。
リフレッシュ可能クローンのクローン作成時・リフレッシュ時にトランザクションを発生させ、その前後の静止点のずれがどのくらいか計測してみました。
事前準備
Autonomous Transaction Processing(ATP)インスタンス ATPtestを作成します。
ATPtest に接続し、以下のSQL文で検証に使用する表sampleとシーケンスserialを作成した時点から検証を開始します。
create table sample(ID number primary key, time timestamp);
create sequence serial maxvalue 10000;
クローン作成時の静止点
以下のシェルスクリプトを作成します。
1秒ごとに1行sample表にIDとSYSTIMESTAMPを追加します。
#!/bin/bash
sql_flg=/tmp/sql.flg
touch $sql_flg
(
while [ -a ${sql_flg} ]
do
echo "insert into sample values(serial.nextval, systimestamp);"
echo "commit;"
sleep 1
done
echo "exit"
)|sqlplus -s admin/Welcome12345#@ATPtest_tp
exit
このスクリプトを実行している状態、つまりソースDB側にトランザクションが発生している状態で、OCIコンソール画面からリフレッシュ可能クローンの作成を行います。
その際、作成されたクローン側はどの時点のデータが最新になっているのか確認します。
ADBの詳細画面から、[他のアクション]→[クローンの作成]をクリックします。
[クローン・タイプの選択]でリフレッシュ可能クローンを選択します。
check.shを実行している状態で、上記の手順でコンソール画面からリフレッシュ可能クローンの作成を行います。
作成後、クローン側の作業リクエストを確認すると、1:59:14に作成開始、2:03:11に終了しています。
クローン側のsample表の最新レコードを参照します。
select * from sample where id = (select max(id) from sample);
最新のレコードは1:59:31にINSERTされたレコードです。
このことから、クローン作成開始から数秒後のトランザクションまではクローン側に反映される、ということが分かりました。
クローン作成時は、データブロックのコピーと合わせて、複製元から複製先にREDOを転送、適用することで同期しながらクローンします。
REDOを転送、適用しながら複製するのである程度同期を保ったままコピーされますが、複製元にトランザクションが常に発生する限り、最終的には若干ずれることになります。
リフレッシュ時の静止点
続いて今度は、リフレッシュ（ソースとクローンを同期する）時に指定したタイムスタンプと実際のデータのずれを計測します。
引き続きcheck.shを実行しておき、コンソールからリフレッシュで以下のようにタイムスタンプを指定し、リフレッシュをします。
2:40:34を指定してリフレッシュします。
リフレッシュ後、先ほどと同様にクローン側のsample表の最新レコードを参照します。
2:40:33のレコードが最新でした。
このことから、『リフレッシュ時に指定したタイムスタンプは正確にソースと同期する』ことが確認できました。
なお、リフレッシュ自体はREDOログをクローン側に転送・同期を行います。
指定するタイムスタンプが現在の時刻に近すぎると、このような表示になりリフレッシュできません。
最小で過去1分からリフレッシュできるようになるので、注意してください。
リフレッシュ可能クローンは、簡単に本番環境と同じ状態でテスト環境が作れるだけでなく、指定した静止点でバックアップとしてインスタンスを複製できますので、ぜひご活用ください。