サーバとインスタンスの関係は固定的ではなく、どのサーバでなんという名前のインスタンスが起動しているかは決まっていないということですねぇ。今回は障害発生により、フェイルオーバーした時に発生するサービス停止時間(データベースに接続できない時間)がどのくらいになるかを確認します。いわゆるダウンタイムです。今回もサーバ(ノード1側)をシャットダウンします。oel55sv02------------------------------------------------------------今回も無事フェイルオーバーできました。行った検証と同様に新規接続の状態を確認してみた結果、以下のようになりました。前回の検証結果を踏まえて今回はホスト名を追加しています。インスタンス名だけではどちらのノードに接続しているのか判断できないということが分かったので。Oracleの初期化またはシャットダウン中です。新規接続ができない状態でした。秒程度かかっていることが確認できています。時刻的には、この間はまだ接続できている状態ですね。停止しているはずですが。続いて、ノード2側のクラスタ関連のログを見てみます。いうことは残り時間と同じ時間分前にさかのぼれば、ハートビートの失敗が始まった時刻と考えられます。20:06:23.148つまり、ほぼノード1がダウンした直後からハートビートが失敗し始めていますね。実はノード2(oel55sv02)の時刻が2秒ほど進んでいました。)にノード1の切り離しが始まっています。替え処理の開始が記録されていました。変更しているということでしょう。上記はクラスタの挙動をいくつかのログでトレースした結果です。データベースの様子をノード2側のアラートログからみてみます。サービス名の登録が行われています。データベースがオープンした直後に接続したということですね。データベースにアクセスできない時間帯でした。この時間の内訳の大半は以下のようになっています。リソースの登録や、各種リソース(仮想IPやリスナ)の起動が行われているようです。'ora.LISTENER_SCAN1.lsnr'('oel55sv02')の起動が成功しました以下は、DBの起動とサービス登録。サービス切替のタイミングなどで一時的に接続できなくなるものの切替先のインスタンスをあらかじめ起動しておくため比較的短時間で接続先を切り替えることができるためです。切替先のノードにデータベースが立ち上がっていないため、データベースが起動するまでの時間がまるまるサービス停止時間になってしまいます。導入を検討する必要があるかもしれません。分間の停止が与えるビジネスインパクト次第ということでしょう。次回は別のパターンで障害をシミュレートしてみます。reserved.トップページ企業概要プライバシーポリシ。