Sun Cluster HA for Oracle サーバーの障害モニターは、次のタイプのエラーを検出します。
サーバー障害モニターによるデータベースの検証中に発生する DBMS エラー
Oracle が警告ログファイルに記録するエラー
Probe_timeout 拡張プロパティの設定時間内に応答を得られなかったために発生するタイムアウト
各エラータイプにカスタム動作を定義するには、カスタムアクションファイルを作成します。
カスタムアクションファイルは、プレーンテキストファイルです。このファイルに、Sun Cluster HA for Oracle サーバー障害モニターのカスタム動作を定義したエントリを 1 つ以上登録します。エントリごとに、個々の DBMS エラー、個々のタイムアウトエラー、または複数の記録対象警告に対応するカスタム動作を定義します。カスタムアクションファイルに指定できるエントリの最大数は 1024 です。
カスタムアクションファイルの各エントリを使用して、エラーの事前設定アクションを変更するか、アクションが事前設定されていないエラーに対してアクションを指定します。カスタムアクションファイルには、変更する事前設定アクションまたはアクションが事前設定されていないエラーに対応するエントリだけを指定します。変更不要なアクションに対応するエントリは作成 しないでください。
カスタムアクションファイルのエントリは、セミコロンで区切ったキーワードと値のペアです。1 つのエントリを中括弧で囲みます。
カスタムアクションファイルのエントリの書式は、次のとおりです。
{ [ERROR_TYPE=DBMS_ERROR|SCAN_LOG|TIMEOUT_ERROR;] ERROR=error-spec; [ACTION=SWITCH|RESTART|STOP|NONE;] [CONNECTION_STATE=co|di|on|*;] [NEW_STATE=co|di|on|*;] [MESSAGE="message-string"] }
キーワードと値のペアの間とエントリの間で空白を使用してファイルをフォーマットできます。
カスタムアクションファイルのキーワードの意味と指定できる値は、次のとおりです。
サーバー障害モニターが検出したエラーのタイプ。このキーワードに対して指定できる値は、次のとおりです。
DBMS エラーであることを指定します。
エラーが警告ログファイルに記録される警告であることを指定します。
タイムアウトであることを指定します。
ERROR_TYPE キーワードは省略可能です。このキーワードを省略した場合は、DBMS エラーとみなされます。
エラーを特定します。データ型と error-spec の意味は、次の表に示すように、ERROR_TYPE キーワードの値によって決まります。
ERROR_TYPE |
データ型 |
意味 |
---|---|---|
DBMS_ERROR |
整数 |
Oracle が生成する DBMS エラーのエラー番号 |
SCAN_LOG |
引用符で囲まれた正規表現 |
Oracle が Oracle 警告ログファイルに記録するエラーメッセージの文字列 |
TIMEOUT_ERROR |
整数 |
サーバー障害モニターを最後に起動または再起動して以来、検証のタイムアウトが連続して発生した回数 |
ERROR キーワードは、指定する必要があります。このキーワードを省略した場合、カスタムアクションファイルのエントリは無視されます。
エラーに対してサーバー障害モニターが実行するアクションを指定します。このキーワードに対して指定できる値は、次のとおりです。
サーバー障害モニターはエラーを無視します。
サーバー障害モニターは停止します。
サーバー障害モニターは、SUNW.oracle_server リソースの Restart_type 拡張プロパティの値によって指定されたエンティティを停止して再起動します。
サーバー障害モニターは、データベースサーバーリソースグループを別のノードに切り替えます。
ACTION キーワードは省略可能です。このキーワードを省略した場合、サーバー障害モニターはエラーを無視します。
エラー検出時の、データベースとサーバー障害モニター間の接続状態を指定します。エントリが適用されるのは、エラー検出時に接続が指定した状態になっていた場合だけです。このキーワードに対して指定できる値は、次のとおりです。
接続の状態に関係なく、常にエントリが適用されます。
エントリは、サーバー障害モニターがデータベース接続を試行中の場合に限り、適用されます。
エントリは、サーバー障害モニターがオンラインの場合に限り、適用されます。データベースに接続している場合、サーバー障害モニターはオンラインです。
エントリは、サーバー障害モニターがデータベースから切り離されている場合に限り、適用されます。
CONNECTION_STATE キーワードは省略可能です。このキーワードを省略した場合は、接続の状態に関係なく、常にエントリが適用されます。
エラーの検出後、データベースとサーバー障害モニター間で維持する必要がある接続状態を指定します。このキーワードに対して指定できる値は、次のとおりです。
接続の状態を現状維持する必要があることを指定します。
サーバー障害モニターはデータベースを切断し、ただちにデータベースに再接続する必要があります。
サーバー障害モニターはデータベースを切り離す必要があります。サーバー障害モニターは、次回、データベースを検証するときに再接続します。
NEW_STATE キーワードは省略可能です。このキーワードを省略した場合、データベースの接続状態はエラー検出後も変化しません。
エラーが検出されたときに、リソースのログファイルに出力する追加のメッセージを指定します。メッセージは二重引用符で囲む必要があります。このメッセージは、エラーに対して定義された標準メッセージに追加されます。
MESSAGE キーワードは省略可能です。このキーワードを省略すると、エラーが検出された場合でも、追加のメッセージはリソースのログファイルに出力されません。
サーバー障害モニターが各 DBMS エラーに応じて実行するアクションは、表 B–1 に示すように事前に設定されています。DBMS エラーへの対応を変更すべきかどうかを判断するときは、データベースに対する DBMS エラーの影響を検討して、事前設定されたアクションで不都合があるかどうかを考慮します。以下の各項を参考にしてください。
DBMS エラーへの対応を変更する場合は、カスタムアクションファイルにエントリを作成し、次のようにキーワードを設定します。
ERROR_TYPE に DBMS_ERROR を設定します。
ERROR に DBMS エラーのエラー番号を設定します。
ACTION に必要なアクションを設定します。
サーバー障害モニターが無視するエラーによって複数のセッションに影響が出る場合は、サービスの損失を防止するアクションをサーバー障害モニターで実行します。
たとえば、Oracle エラー 4031 にはアクションが事前設定されていません。このエラーは、unable to allocate num-bytes bytes of shared memory というエラーです。ただし、この Oracle エラーは、共有大域領域 (SGA) がメモリー不足である、ひどく断片化されている、またはその両方の状況に陥っていることを意味します。このエラーの影響を受けるセッションが 1 つだけであれば、無視しても問題ありません。しかし、このエラーが複数のセッションに影響を与える場合は、サーバー障害モニターによるデータベースの再起動を考慮してください。
次に、DBMS エラーへの対応を再起動に変更するカスタムアクションファイルのエントリの例を示します。
{ ERROR_TYPE=DBMS_ERROR; ERROR=4031; ACTION=restart; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE="Insufficient memory in shared pool."; }
この例は、DBMS エラー 4031 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。
DBMS エラー 4031 への対応としてサーバー障害モニターが実行するアクションは、再起動です。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
このエラーが検出されると、次のメッセージがリソースのログファイルに出力されます。
Insufficient memory in shared pool. |
サーバー障害モニターが対応するエラーの影響が小さい場合、エラーを無視するほうがエラーに対応するより問題が小さいことがあります。
たとえば、Oracle エラー 4030: out of process memory when trying to allocate num-bytes bytes に対応する事前設定アクションは再起動です。この Oracle エラーは、サーバー障害モニターが専用ヒープメモリーを割り当てられなかったことを意味します。このエラーが発生する原因の 1 つは、オペレーティングシステムで利用できるメモリーが不足しているということです。複数のセッションがこのエラーの影響を受ける場合は、データベースの再起動が適切です。ただし、専用メモリーの追加を必要とするセッションがなければ、このエラーが他のセッションに影響を与えることはありません。この場合は、サーバー障害モニターにエラーを無視させることを考慮してください。
次に、DBMS エラー無視するカスタムアクションファイルのエントリの例を示します。
{ ERROR_TYPE=DBMS_ERROR; ERROR=4030; ACTION=none; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE=""; }
この例は、DBMS エラー 4030 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。
サーバー障害モニターは、DBMS エラー 4030 を無視します。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
エラーが検出された場合でも、追加のメッセージがリソースのログファイルに出力されることはありません。
Oracle ソフトウェアは、Alert_log_file 拡張プロパティに指定されたファイルに警告を記録します。サーバー障害モニターはこのファイルを走査し、アクションが定義されている警告に対してアクションを実行します。
記録対象警告のうち、アクションが事前設定されているものについては、付録 A の表 B–2 を参照してください。記録対象警告への対応を変更することで、事前設定アクションを変更するか、サーバー障害モニターが対応する新しい警告を定義します。
記録対象警告への対応を変更する場合は、カスタムアクションファイルにエントリを作成し、次のようにキーワードを設定します。
ERROR_TYPE に SCAN_LOG を設定します。
ERROR に、Oracle が Oracle 警告ログファイルに記録したエラーメッセージの文字列を特定する正規表現を設定します。
ACTION に必要なアクションを設定します。
サーバー障害モニターは、カスタムアクションファイルのエントリを指定された順に処理します。記録対象警告と最初に一致したエントリだけが処理されます。それ以後のエントリは一致しても無視されます。正規表現を使用して複数の記録対象警告に対するアクションを指定する場合は、固有性の強いエントリを汎用性の強いエントリの前に指定してください。汎用性の強いエントリを先に指定すると、固有性の強いエントリが無視される場合があります。
カスタムアクションファイルで、たとえば、正規表現 ORA-65 および ORA-6 で指定されたエラーに、それぞれ異なるアクションを定義するとします。正規表現 ORA-65 を含むエントリが無視されないようにするには、このエントリを正規表現 ORA-6 を含むエントリの前に指定する必要があります。
次に、記録対象警告への対応を変更するカスタムアクションファイルのエントリの例を示します。
{ ERROR_TYPE=SCAN_LOG; ERROR="ORA-00600: internal error"; ACTION=RESTART; }
この例は、内部エラーに関する記録対象警告 への事前設定アクションを変更するカスタムアクションファイルのエントリです。このエントリで指定される処理は、次のとおりです。
記録された警告にテキスト ORA-00600: internal error が含まれる場合、サーバー障害モニターが対応として実行するアクションは再起動です。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
エラーが検出された場合でも、追加のメッセージがリソースのログファイルに出力されることはありません。
デフォルトでは、サーバー障害モニターは検証タイムアウトが 2 回続くと、データベースを再起動します。データベースの負荷が小さい場合、連続 2 回の検証タイムアウトはデータベースの停止を意味するものと解決できます。ただし、負荷が大きいときは、データベースが正常に動作していても、サーバー障害モニターの検証がタイムアウトすることがあります。サーバー障害モニターがデータベースを不必要に再起動しないようにするには、連続検証タイムアウトの最大回数を増やします。
連続検証タイムアウトの最大回数を増やすと、データベースの停止を検出するためにかかる時間が長くなります。
連続検証タイムアウトの最大許容回数を変更するには、2 回目以降の検証タイムアウトごとに、カスタムアクションファイルにエントリを 1 つずつ作成します。
最初の検証タイムアウトについては、対応するエントリを作成する必要はありません。最初の検証タイムアウトに対してサーバー障害モニターが実行するアクションは、事前に設定されています。
許容される最後の検証タイムアウトについては、キーワードを次のように設定してエントリを作成します。
ERROR_TYPE に TIMEOUT_ERROR を設定します。
ERROR に、連続検証タイムアウトの最大許容回数を設定します。
ACTION に RESTART を設定します。
2 回目以降の検証タイムアウトのそれぞれに、次のようにキーワードを設定してエントリを 1 つずつ作成します。
ERROR_TYPE に TIMEOUT_ERROR を設定します。
ERROR に検証タイムアウトの序数を設定します。たとえば、2 回目の連続検証タイムアウトについては、このキーワードを 2 に設定します。3 回目の連続検証タイムアウトについては、このキーワードを 3 に設定します。
ACTION に NONE を設定します。
デバッグしやすくするには、検証タイムアウトの序数を示すメッセージを指定します。
次に、検証タイムアウトの最大連続回数を 5 回に増やすカスタムアクションファイルのエントリの例を示します。
{ ERROR_TYPE=TIMEOUT; ERROR=2; ACTION=NONE; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE="Timeout #2 has occurred."; } { ERROR_TYPE=TIMEOUT; ERROR=3; ACTION=NONE; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE="Timeout #3 has occurred."; } { ERROR_TYPE=TIMEOUT; ERROR=4; ACTION=NONE; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE="Timeout #4 has occurred."; } { ERROR_TYPE=TIMEOUT; ERROR=5; ACTION=RESTART; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE="Timeout #5 has occurred. Restarting."; }
この例は、検証タイムアウトの最大連続回数を 5 回に増やすカスタムアクションファイルのエントリです。これらのエントリで指定される処理は、次のとおりです。
サーバー障害モニターは、連続する検証タイムアウトの 2 回目から 4 回目までを無視します。
5 回目の連続検証タイムアウトに対して、サーバー障害モニターが実行するアクションは再起動です。
このエントリは、タイムアウト発生時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、タイムアウト発生後も維持されます。
2 回目から 4 回目の連続検証タイムアウトについては、発生時に次の形式のメッセージがリソースのログファイルに出力されます。
Timeout #number has occurred. |
5 回目の連続検証タイムアウトが発生すると、次のメッセージがリソースのログファイルに出力されます。
Timeout #5 has occurred. Restarting. |