test

Sun Cluster Data Service for Oracle ガイド (Solaris OS 版)

エラーのカスタム動作の定義

Sun Cluster HA for Oracle サーバーの障害モニターは、次のタイプのエラーを検出します。

各エラータイプにカスタム動作を定義するには、カスタムアクションファイルを作成します。

カスタムアクションファイルのフォーマット

カスタムアクションファイルは、プレーンテキストファイルです。このファイルに、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"]
}

キーワードと値のペアの間とエントリの間で空白を使用してファイルをフォーマットできます。

カスタムアクションファイルのキーワードの意味と指定できる値は、次のとおりです。

ERROR_TYPE

サーバー障害モニターが検出したエラーのタイプ。このキーワードに対して指定できる値は、次のとおりです。

DBMS_ERROR

DBMS エラーであることを指定します。

SCAN_LOG

エラーが警告ログファイルに記録される警告であることを指定します。

TIMEOUT_ERROR

タイムアウトであることを指定します。

ERROR_TYPE キーワードは省略可能です。このキーワードを省略した場合は、DBMS エラーとみなされます。

ERROR

エラーを特定します。データ型と error-spec の意味は、次の表に示すように、ERROR_TYPE キーワードの値によって決まります。

ERROR_TYPE

データ型 

意味 

DBMS_ERROR

整数 

Oracle が生成する DBMS エラーのエラー番号 

SCAN_LOG

引用符で囲まれた正規表現 

Oracle が Oracle 警告ログファイルに記録するエラーメッセージの文字列 

TIMEOUT_ERROR

整数 

サーバー障害モニターを最後に起動または再起動して以来、検証のタイムアウトが連続して発生した回数 

ERROR キーワードは、指定する必要があります。このキーワードを省略した場合、カスタムアクションファイルのエントリは無視されます。

ACTION

エラーに対してサーバー障害モニターが実行するアクションを指定します。このキーワードに対して指定できる値は、次のとおりです。

NONE

サーバー障害モニターはエラーを無視します。

STOP

サーバー障害モニターは停止します。

RESTART

サーバー障害モニターは、SUNW.oracle_server リソースの Restart_type 拡張プロパティの値によって指定されたエンティティを停止して再起動します。

SWITCH

サーバー障害モニターは、データベースサーバーリソースグループを別のノードに切り替えます。

ACTION キーワードは省略可能です。このキーワードを省略した場合、サーバー障害モニターはエラーを無視します。

CONNECTION_STATE

エラー検出時の、データベースとサーバー障害モニター間の接続状態を指定します。エントリが適用されるのは、エラー検出時に接続が指定した状態になっていた場合だけです。このキーワードに対して指定できる値は、次のとおりです。

*

接続の状態に関係なく、常にエントリが適用されます。

co

エントリは、サーバー障害モニターがデータベース接続を試行中の場合に限り、適用されます。

on

エントリは、サーバー障害モニターがオンラインの場合に限り、適用されます。データベースに接続している場合、サーバー障害モニターはオンラインです。

di

エントリは、サーバー障害モニターがデータベースから切り離されている場合に限り、適用されます。

CONNECTION_STATE キーワードは省略可能です。このキーワードを省略した場合は、接続の状態に関係なく、常にエントリが適用されます。

NEW_STATE

エラーの検出後、データベースとサーバー障害モニター間で維持する必要がある接続状態を指定します。このキーワードに対して指定できる値は、次のとおりです。

*

接続の状態を現状維持する必要があることを指定します。

co

サーバー障害モニターはデータベースを切断し、ただちにデータベースに再接続する必要があります。

di

サーバー障害モニターはデータベースを切り離す必要があります。サーバー障害モニターは、次回、データベースを検証するときに再接続します。

NEW_STATE キーワードは省略可能です。このキーワードを省略した場合、データベースの接続状態はエラー検出後も変化しません。

MESSAGE

エラーが検出されたときに、リソースのログファイルに出力する追加のメッセージを指定します。メッセージは二重引用符で囲む必要があります。このメッセージは、エラーに対して定義された標準メッセージに追加されます。

MESSAGE キーワードは省略可能です。このキーワードを省略すると、エラーが検出された場合でも、追加のメッセージはリソースのログファイルに出力されません。

DBMS エラーへの対応の変更

サーバー障害モニターが各 DBMS エラーに応じて実行するアクションは、表 B–1 に示すように事前に設定されています。DBMS エラーへの対応を変更すべきかどうかを判断するときは、データベースに対する DBMS エラーの影響を検討して、事前設定されたアクションで不都合があるかどうかを考慮します。以下の各項を参考にしてください。

DBMS エラーへの対応を変更する場合は、カスタムアクションファイルにエントリを作成し、次のようにキーワードを設定します。

影響が大きいエラーに対応する

サーバー障害モニターが無視するエラーによって複数のセッションに影響が出る場合は、サービスの損失を防止するアクションをサーバー障害モニターで実行します。

たとえば、Oracle エラー 4031 にはアクションが事前設定されていません。このエラーは、unable to allocate num-bytes bytes of shared memory というエラーです。ただし、この Oracle エラーは、共有大域領域 (SGA) がメモリー不足である、ひどく断片化されている、またはその両方の状況に陥っていることを意味します。このエラーの影響を受けるセッションが 1 つだけであれば、無視しても問題ありません。しかし、このエラーが複数のセッションに影響を与える場合は、サーバー障害モニターによるデータベースの再起動を考慮してください。

次に、DBMS エラーへの対応を再起動に変更するカスタムアクションファイルのエントリの例を示します。

例 1–1 DBMS エラーへの対応を再起動に変更する

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4031; 
ACTION=restart;
CONNECTION_STATE=*; 
NEW_STATE=*;
MESSAGE="Insufficient memory in shared pool.";
}

この例は、DBMS エラー 4031 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。

影響が小さいエラーを無視する

サーバー障害モニターが対応するエラーの影響が小さい場合、エラーを無視するほうがエラーに対応するより問題が小さいことがあります。

たとえば、Oracle エラー 4030: out of process memory when trying to allocate num-bytes bytes に対応する事前設定アクションは再起動です。この Oracle エラーは、サーバー障害モニターが専用ヒープメモリーを割り当てられなかったことを意味します。このエラーが発生する原因の 1 つは、オペレーティングシステムで利用できるメモリーが不足しているということです。複数のセッションがこのエラーの影響を受ける場合は、データベースの再起動が適切です。ただし、専用メモリーの追加を必要とするセッションがなければ、このエラーが他のセッションに影響を与えることはありません。この場合は、サーバー障害モニターにエラーを無視させることを考慮してください。

次に、DBMS エラー無視するカスタムアクションファイルのエントリの例を示します。

例 1–2 DBMS エラーを無視する

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4030;
ACTION=none;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="";
}

この例は、DBMS エラー 4030 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。

記録対象警告への対応を変更する

Oracle ソフトウェアは、Alert_log_file 拡張プロパティに指定されたファイルに警告を記録します。サーバー障害モニターはこのファイルを走査し、アクションが定義されている警告に対してアクションを実行します。

記録対象警告のうち、アクションが事前設定されているものについては、付録 A の表 B–2 を参照してください。記録対象警告への対応を変更することで、事前設定アクションを変更するか、サーバー障害モニターが対応する新しい警告を定義します。

記録対象警告への対応を変更する場合は、カスタムアクションファイルにエントリを作成し、次のようにキーワードを設定します。

サーバー障害モニターは、カスタムアクションファイルのエントリを指定された順に処理します。記録対象警告と最初に一致したエントリだけが処理されます。それ以後のエントリは一致しても無視されます。正規表現を使用して複数の記録対象警告に対するアクションを指定する場合は、固有性の強いエントリを汎用性の強いエントリの前に指定してください。汎用性の強いエントリを先に指定すると、固有性の強いエントリが無視される場合があります。

カスタムアクションファイルで、たとえば、正規表現 ORA-65 および ORA-6 で指定されたエラーに、それぞれ異なるアクションを定義するとします。正規表現 ORA-65 を含むエントリが無視されないようにするには、このエントリを正規表現 ORA-6 を含むエントリの前に指定する必要があります。

次に、記録対象警告への対応を変更するカスタムアクションファイルのエントリの例を示します。

例 1–3 記録対象警告への対応を変更する

{
ERROR_TYPE=SCAN_LOG;
ERROR="ORA-00600: internal error";
ACTION=RESTART;
}

この例は、内部エラーに関する記録対象警告 への事前設定アクションを変更するカスタムアクションファイルのエントリです。このエントリで指定される処理は、次のとおりです。

連続タイムアウトの最大検証回数を変更する

デフォルトでは、サーバー障害モニターは検証タイムアウトが 2 回続くと、データベースを再起動します。データベースの負荷が小さい場合、連続 2 回の検証タイムアウトはデータベースの停止を意味するものと解決できます。ただし、負荷が大きいときは、データベースが正常に動作していても、サーバー障害モニターの検証がタイムアウトすることがあります。サーバー障害モニターがデータベースを不必要に再起動しないようにするには、連続検証タイムアウトの最大回数を増やします。

注意 – 注意 –

連続検証タイムアウトの最大回数を増やすと、データベースの停止を検出するためにかかる時間が長くなります。

連続検証タイムアウトの最大許容回数を変更するには、2 回目以降の検証タイムアウトごとに、カスタムアクションファイルにエントリを 1 つずつ作成します。

注 –

最初の検証タイムアウトについては、対応するエントリを作成する必要はありません。最初の検証タイムアウトに対してサーバー障害モニターが実行するアクションは、事前に設定されています。

許容される最後の検証タイムアウトについては、キーワードを次のように設定してエントリを作成します。

2 回目以降の検証タイムアウトのそれぞれに、次のようにキーワードを設定してエントリを 1 つずつ作成します。

ヒント –

デバッグしやすくするには、検証タイムアウトの序数を示すメッセージを指定します。

次に、検証タイムアウトの最大連続回数を 5 回に増やすカスタムアクションファイルのエントリの例を示します。

例 1–4 連続タイムアウトの最大検証回数を変更する

{
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 回に増やすカスタムアクションファイルのエントリです。これらのエントリで指定される処理は、次のとおりです。