Oracle ARK(LifeKeeper for Linux)の処理概要について

“Oracle ARK(LifeKeeper for Linux)の処理概要について

Oracle ARKが提供する監視機能と起動処理、停止処理、リカバリ処理についてご説明します。

※Oracle ARK 6.3.1にてリスナーが保護可能となりました。以下のページも合わせてご参照ください。

Oracle ARK 6.3.1(以降)へのアップグレードについて

対象製品
・LifeKeeper For Linux v7.0 (Steeleye-lkORA -7.0.0-1)

下記にて Oracle リソースと Listener リソースそれぞれの動作処理をご案内します。

Oracle リソース

監視処理
Oracleリソースでは、以下の項目を監視しています。

(1) ora_pmon プロセスおよび ora_lgwr プロセスが存在するかどうかを ps コマンドで確認します。

(2) sqlplusを通じて以下のSQLを発行して確認をします。

SELECT * from dba_data_files;

障害と判定された場合、ローカルリカバリ機能により同じサーバ上でOracleの再立ち上げを試行します。
ローカルリカバリに失敗した場合は、待機系への切替処理に移行します。

※Oracle リソースの階層下にリスナーリソースが定義されていない場合、lsnrctlコマンドを使用してリスナーの状態も確認しています。
ただし、リスナーが起動していないと判定された場合、再立ち上げを試行し失敗したとしても切替処理には移行せず、次回の監視スクリプト時に再度「障害 検出」→「再立ち上げ」を試行することになります(リスナーの障害は切替処理の対象とはなっておりません)。

起動処理
Oracleリソースを起動時に、以下の処理が実行されます。

(1) ora_pmon プロセスが存在するかどうかを ps コマンドで確認します。

(2) sqlplusを通じて以下のSQLを発行して確認をします。

SELECT * from dba_data_files;

(3) sqlplus を通じてsysdbaとしてOracleに接続し、[startup]を発行して起動処理を実行します。

(4) Oracleが起動したかどうかを判定します。起動に成功した場合は起動処理は終了します。

(5) 処理(4)の判定において起動処理に失敗したと判定した場合、同様にsqlplusを通じて[startup force]を発行し、
起動処理を実行します。ここで起動に失敗した場合は、リソースの起動処理に失敗して処理が終了します。

※Oracle リソースの階層下にリスナーリソースが定義されていない場合、Oracleの起動に成功した時点でリスナーも同様に起動されます。

停止処理
Oracleリソースを停止時に、以下の処理が実行されます。

(1) ora_pmon プロセスが存在するかどうかを ps コマンドで確認します。

(2) sqlplusを通じてsysdbaとしてOracleに接続し、[shutdown immediate]を発行して、停止処理を実行します。
停止に成功した場合は、停止処理は終了します。

(3) 処理(2)の判定において停止処理に失敗したと判定した場合、同様にsqlplusを通じてsysdbaとしてOracleに接続し
[shutdown abort]を発行して、停止処理を実行します。ここで停止に失敗した場合、リソースの
停止処理に失敗して処理は終了します。

※Oracle リソースの階層下にリスナーリソースが定義されていない場合、Oracleの停止に成功した時点でリスナーも同様に停止されます。

リカバリ処理
Oracleリソースをリカバリ時に、以下の処理が実行されます。

(1) ora_pmon プロセスが存在するかどうかを ps コマンドで確認します。

(2) sqlplusを通じて以下のSQLを発行して確認をします。

SELECT * from dba_data_files;

(3) 起動していた場合、sqlplusを通じてsysdbaとしてOracleに接続し、[shutdown abort] を発行して
停止処理を実行します。

(4) sqlplus を通じてsysdbaとしてOracleに接続し、[startup]を発行して起動処理を実行します。

(5) 処理 (4) の判定において 起動処理に失敗したと判定した場合、同様にsqlplusを通じて [startup force] を
発行して起動処理を実行します。

(6) sqlplusを通じて以下のSQLを発行して確認をします。

SELECT * from dba_data_files;

(7) 処理 (6) の判定において、起動が確認できない場合は、リカバリ処理に失敗したと
判断して処理を終了します。

Listener リソース

監視処理
Listenerリースでは、以下の項目を監視しています。

(1) [lsnrctl status] を発行して、リスナーの状態を確認します。

(2) 処理 (1) の判定においてリスナーの起動を確認した場合は、監視処理を終了。
リスナーの起動が確認できない場合は、障害と判断してローカルリカバリ処理を実施。

※ Listener Protection Level が Minimal Control となっている場合は、ローカル
リカバリ処理は行われません。

起動処理
Listenerリソースを起動時に、以下の処理が実行されます。

(1) [lsnrctl status] を発行して、リスナーの状態を確認します。

(2) 処理 (1) の判定においてリスナーの起動を確認した場合は、起動処理を終了。
リスナーの起動が確認できない場合は、[lsnrctl start] を発行して、起動処理を実行します。

(3) 処理 (2) の判定においてリスナーの起動が確認できない場合は、Listener の起動に
失敗したと判断して処理を終了します。

停止処理
Listenerリソースを停止時に、以下の処理が実行されます。

(1) [lsnrctl status] を発行して、リスナーの状態を確認します。

(2) 処理 (1) の判定においてリスナーの停止を確認した場合は、停止処理を終了。
リスナーの停止が確認できない場合は、[lsnrctl stop] を発行して、起動処理を実行します。

(3) 処理 (2) の判定においてリスナーの停止が確認できない場合は、Listener の停止に
失敗したと判断して処理を終了します。

※ Listener Protection Level が FULL 以外となっている場合は、リスナーの
停止処理は行われません

リカバリ処理
Listener リソースでは、リカバリ処理時に以下の処理が実行されます。

(1) [lsnrctl status] を発行して、リスナーの状態を確認します。

(2) [lsnrctl start] を発行して、起動処理を実行します。

(3) 処理 (2) の判定においてリスナーの起動が確認できない場合は、Listener の起動に
失敗したと判断して処理を終了します。

掲載日: 2010年1月29日

<改定履歴>

 [2011年8月12日 改定]”

return top