RAC One Node の検証 その3

<RAC One Node の検証 その3>
ペンネーム : ダーリン

前回は 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 &lt;&lt;_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 &lt;&lt;_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));
-------------------------------