RAC One Node の検証 その３
＜RAC One Node の検証 その３＞
ペンネーム : ダーリン
前回は RAC One Node の Omotion という機能を使ってインスタン
スをノード間で移動させて見ました。
その間、一時的に、2 ノード RAC の状態になることが確認できま
した。また、Omotion 自体は 2 分以上かかりましたが、その間完
全にデータベースに接続できないというわけではありません。
Omotion 中に（データベースからみてクライアント側からの）新規
接続時のエラーは、移行先のインスタンスが起動した直後の微妙な
タイミングで発生しそうです。
今回の検証環境においては少なくとも 30 秒から 40 秒程度は「微
妙なタイミング」がありそうです。
ただし、前回の検証のようにリトライさせれば正常に接続できるの
で、このあたりはアプリケーション側で考慮しておけば特に大きな
問題にはならないでしょう。
上記のとおり、Omotion 中には接続時エラーが発生する可能性があ
ることを確認しましたが、処理中の既存セッションがブツブツと切
断されるわけではありません。ではすでに接続されているセッショ
ンはどうでしょうか
今回はそのあたりを検証していきます。
「既存セッションはいつまで生き残るのか」
今回はセッションはそのままでテーブルに時刻を INSERT しながら
どのタイミングまで時刻データを INSERT し続けることができるか
確認し見ます。
では、テスト用の INSERT スクリプト(後述)を実行しながら、Omotion
を実行しましょう。
では、再び ！！
$ Omotion
入力データは前回と同様なので省略します。
（ただし oel55sv02 側から oel55sv01 側への移動という点だけご注意を）
で、INSERT したデータはどうなったかというと…..
SQL> select idate , cnt , csid , to_char(trunc(dtime/60),'FM999') || ':' || to_char(mod(dtime,60),'FM00') dtime from ora3_test order by idate; IDATE CNT CSID DTIME -------- ----- ------- ----- 22:10:44 1 RON_2 0:00 <<< Omotion 開始 22:10:49 2 RON_2 0:05 22:10:54 3 RON_2 0:10 22:10:59 4 RON_2 0:15 22:11:04 5 RON_2 0:20 <<< 移行後インスタンス起動開始 : : 22:11:44 13 RON_2 1:00 22:11:49 14 RON_2 1:05 <<< 移行後インスタンス起動終了 22:11:54 15 RON_2 1:10 22:11:59 16 RON_2 1:15 22:12:04 17 RON_2 1:20 22:12:09 18 RON_2 1:25 22:12:14 19 RON_2 1:30 <<< サービス設定変更 22:12:19 20 RON_2 1:35 22:12:24 21 RON_2 1:40 <<< 移行前の接続 SID 22:12:33 1 RON_1 1:49 <<< 移行後の接続 SID 22:12:38 2 RON_1 1:54 22:12:43 3 RON_1 1:59 22:12:48 4 RON_1 2:04 <<< 移行前インスタンス停止 22:12:53 5 RON_1 2:09 22:12:58 6 RON_1 2:14 22:13:03 7 RON_1 2:19 :
IDATE INSERT 時刻 CNT 接続した状態での INSERT の累計回数。再接続でクリア CSID 接続先の SID DTIME スクリプト開始後からの経過時間
上記より、Omotion 開始から 1 分 40 秒程度は移行前のインスタ
ンスに接続していることが確認できます。 新しいインスタンスが
起動してしばらくはそのままの状態で処理しているようです。
ところで右のカラムは接続先の SID ですが、22:12:24 で一旦切断
した後 22:12:33 に新しいインスタンスからデータが INSERT でき
ていることがわかります。この間 10 秒かかっていません。
接続したままの状態から再接続が行われた場合は接続できない時間
は非常に短いようです。
新しいインスタンスが起動した直後よりは、しばらく後の方が接続
時の安定性がよいのかもしれません。コネクション・プーリングな
どを行っている環境では、この恩恵が得られるかもしれませんね。
さて、今回も Omotion 開始から、コンソールにプロンプトが戻る
まで 2 分 40 秒程度かかりました。
2 分 40 秒の根拠は何なのでしょうか。
これまで見てきたように Omotion ではアクティブ側とスタンバイ
側で Oracle のインスタンスが起動したり停止したりします。
ということであれば DB インスタンスのアラートログを覗けば何か
情報があるかもしれません。
さてと、、、
oel55sv01 サーバ ( RON_1 側 )(alert_RON_1.log) ---------------------------------------------------------- Mon Jul 19 22:11:04 2010 Starting ORACLE instance (normal) : Mon Jul 19 22:11:14 2010 MARK started with pid=28, OS id=5004 NOTE: MARK has subscribed Reconfiguration started (old inc 0, new inc 100) List of instances: 1 2 (myinst: 1) Set master node info : Reconfiguration complete : Mon Jul 19 22:11:25 2010 Successful mount of redo thread 1, with mount id 1565376430 Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE) : Mon Jul 19 22:11:29 2010 Completed: ALTER DATABASE MOUNT ALTER DATABASE OPEN : Mon Jul 19 22:12:13 2010 ALTER SYSTEM SET service_names='srvRON1' SCOPE=MEMORY SID='RON_1'; ----------------------------------------------------------
まずは、新らしく起動する移行先インスタンスの起動処理が先行し
ています。
22:11:04 インスタンス起動開始 22:11:14 マスターブロック管理情報などのリコンフィグレーション 22:11:25 初期化パラメータのクラスタデータベースの設定 (CLUSTER_DATABASE=TRUE) 22:11:29 データベース・オープン 22:12:13 サービス設定 oel55sv02 サーバ ( RON_2 側 )(alert_RON_2.log) ---------------------------------------------------------- Mon Jul 19 22:11:14 2010 Reconfiguration started (old inc 98, new inc 100) List of instances: 1 2 (myinst: 2) : Reconfiguration complete : Mon Jul 19 22:12:10 2010 ALTER SYSTEM SET service_names='' SCOPE=MEMORY SID='RON_2'; Mon Jul 19 22:12:23 2010 Shutting down instance (transactional) Stopping background process SMCO Shutting down instance: further logons disabled Mon Jul 19 22:12:25 2010 Stopping background process CJQ0 Stopping background process QMNC Stopping background process MMNL Stopping background process MMON All transactions complete. Performing immediate shutdown : ALTER DATABASE CLOSE NORMAL Mon Jul 19 22:12:38 2010 Shutting down archive processes : Mon Jul 19 22:12:39 2010 Completed: ALTER DATABASE CLOSE NORMAL ALTER DATABASE DISMOUNT Completed: ALTER DATABASE DISMOUNT : Mon Jul 19 22:12:49 2010 Instance shutdown complete ----------------------------------------------------------
続いて、移行元インスタンスの停止です。
22:11:14 リコンフィグレーション 22:12:10 サービス設定無効化 22:12:23 インスタンス停止処理開始 22:12:25 全トランザクション終了/データベース・クローズ開始 22:12:39 データベース・クローズ/ディスマウント 22:12:49 インスタンス停止
データベースインスタンスの起動停止処理で 1 分 40 秒程度はか
かっているようです。
しかしここでひとつ気になる情報を見つけてしまいました。
移行元のアラートログに以下の一文が。
------------------------------------------------ Shutting down instance (transactional) ------------------------------------------------
これは「トランザクションの終了を待ちますよ。」という意味です。
ということは、トランザクションの状態によっては Omotion の時
間が延びる可能性があります。
次回ももう少し Omotion を調べてみます。
==
補足1「INSERT スクリプト」
-------------------------------
#/bin/sh
CNT=0
#
sqlplus ora3/ora3@ron <<_EOF_
truncate table ora3_test;
truncate table ora3_start;
insert into ora3_start (sdate) values (sysdate);
commit;
exit
_EOF_
#
while [ ${CNT} -lt 2 ];
do
sqlplus ora3/ora3@ron <<_EOF_
DECLARE
v_start_date date := NULL;
v_count number := 0;
v_instance_name varchar2(5) := NULL;
BEGIN
select sdate into v_start_date from ora3_start;
LOOP
v_count := v_count + 1;
insert into ora3_test (idate,cnt,csid,dtime)
values ( sysdate
, v_count
, sys_context('userenv','instance_name')
, (sysdate - v_start_date)*60*60*24);
commit;
DBMS_LOCK.SLEEP(5);
END LOOP;
END;
/
exit
_EOF_
echo "Exit at:" `date '+%Y/%m%d %H%M%S'`
CNT=`expr ${CNT} + 1`
sleep 1
done
exit
-------------------------------
補足2「テストテーブル」
------------------------------- create table ora3_start (sdate date); create table ora3_test (idate date,cnt number,csid char(10)); -------------------------------