エラーに対するカスタム動作を定義する

言語:

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

サーバー障害モニターによるデータベースの検証中に発生する DBMS エラー
Oracle Database が警告ログファイルに記録する警告
Probe_timeout 拡張プロパティーに設定された時間内に応答がなかったために生じたタイムアウト

これらのタイプのエラーに対するカスタムアクションを定義するには、カスタムアクションファイルを作成します。このセクションには、カスタムアクションファイルに関する次の情報が含まれます。

カスタムアクションファイルの形式

カスタムアクションファイルはプレーンテキストファイルです。ファイルには、HA for Oracle Database サーバー障害モニターのカスタム動作を定義する 1 つ以上のエントリが含まれます。各エントリは、1 つの DBMS エラー、1 つのタイムアウトエラー、または複数の記録された警告に対するカスタム動作を定義します。カスタムアクションファイルには、最大 1024 のエントリが許可されます。

注 - カスタムアクションファイルの各エントリは、エラーに対する事前設定アクションをオーバーライドしたり、事前設定されたアクションがないエラーに対するアクションを指定したりします。オーバーライドする事前設定アクションまたはアクションが事前設定されていないエラーに対してのみ、カスタムアクションファイルにエントリを作成します。変更しないアクションに対して、エントリを作成しないでください。

カスタムアクションファイルのエントリは、セミコロンで区切られた一連のキーワードと値のペアで構成されます。各エントリは中カッコで囲まれています。

カスタムアクションファイルのエントリの形式は、次のとおりです。

{
[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 Database により生成される DBMS エラーのエラー番号
`SCAN_LOG`	引用符で囲んだ正規表現	Oracle Database が Oracle Database 警告ログファイルに記録したエラーメッセージの文字列
`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 エラーに対応してサーバー障害モニターが実行するアクションは、表 4 に一覧表示されているように、事前に設定されています。DBMS エラーへの対応を変更する必要があるかどうかを判定するには、データベースに対する DBMS エラーの影響を考慮して、事前設定アクションが適切かどうかを判断します。例として、次のサブセクションを参照してください。

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

ERROR_TYPE は DBMS_ERROR に設定します。
ERROR は、DBMS エラーのエラー番号に設定します。
ACTION は、必要とするアクションに設定します。

影響が重大であるエラーに対応する

サーバー障害モニターが無視するエラーが複数のセッションに影響を及ぼす場合、サービスの損失を防ぐために、サーバー障害モニターによるアクションが必要になる場合があります。

たとえば、「Oracle Database エラー 4031: 共有メモリーの num-bytes バイトを割り当てできません」に対して、事前設定されたアクションはありません。ただし、この Oracle Database エラーは、共有グローバル領域 (SGA) のメモリーが不足しているか、ひどく断片化している、あるいは両方の状態が当てはまることを示しています。このエラーが 1 つのセッションのみに影響する場合、エラーを無視することが適切な場合あります。ただし、このエラーが複数のセッションに影響を及ぼす場合、サーバー障害モニターがデータベースを再起動するように指定することを考慮してください。

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

使用例 3 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 Database エラー 4030: num-bytes バイトを割り当てようとしてプロセスメモリーが不足しました」に対する事前設定アクションは再起動です。この Oracle Database エラーは、サーバー障害モニターがプライベートヒープメモリーを割り当てられなかったことを示します。このエラーの考えられる原因の 1 つは、オペレーティングシステムに使用できるメモリーが不足していることです。このエラーが複数のセッションに影響を及ぼす場合は、データベースの再起動が適切な場合があります。しかし、これらのセッションがさらにプライベートメモリーを必要とすることはないため、このエラーはほかのセッションには影響を与えない可能性があります。この場合は、サーバー障害モニターがエラーを無視するよう指定することを考慮してください。

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

使用例 4 DBMS エラーを無視する

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

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

サーバー障害モニターは、DBMS エラー 4030 を無視します。
このエントリは、エラーの検出時に、データベースとサーバー障害モニター間の接続状態にかかわらず適用されます。
データベースおよびサーバー障害モニター間の接続の状態は、エラーが検出されたあとも変更されずに維持される必要があります。
エラーが検出されたとき、追加メッセージがリソースのログファイルに出力されません。

記録された警告への対応を変更する

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

アクションが事前設定されている記録される警告は、表 5に示されています。事前設定アクションを変更したり、サーバー障害モニターが対応する新しい警告を定義したりするには、記録された警告への対応を変更します。

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

ERROR_TYPE は SCAN_LOG に設定します。
ERROR を、Oracle Database が Oracle Database 警告ログファイルに記録したエラーメッセージ内の文字列を識別する引用正規表現に設定します。
ACTION は、必要とするアクションに設定します。

サーバー障害モニターは、エントリが発生した順序で、カスタムアクションファイルのエントリを処理します。記録された警告と一致する最初のエントリのみが処理されます。後続の一致するエントリは無視されます。複数の記録された警告に対するアクションを指定するために正規表現を使用している場合は、より一般的なエントリの前に、より具体的なエントリが出現するようにしてください。一般的なエントリのあとに出現する具体的なエントリは、無視されることがあります。

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

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

使用例 5 記録された警告への対応を変更する

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

この例は、内部エラーに関する記録された警告に対する事前設定アクションをオーバーライドする、カスタムアクションファイルのエントリを示しています。このエントリは、次の動作を指定します。

テキスト ORA-00600: internal error を含む警告ログに応答して、サーバー障害モニターが実行するアクションは再起動です。
このエントリは、エラーの検出時に、データベースとサーバー障害モニター間の接続状態にかかわらず適用されます。
データベースおよびサーバー障害モニター間の接続の状態は、エラーが検出されたあとも変更されずに維持される必要があります。
エラーが検出されたとき、追加メッセージがリソースのログファイルに出力されません。

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

デフォルトでは、サーバー障害モニターは、2 回目の連続タイムアウト検証のあとにデータベースを再起動します。データベースの負荷が軽い場合、2 回目の連続タイムアウト検証は、データベースがハングアップしたことを示すには十分です。ただし、負荷が重い間は、サーバー障害モニター検証はデータベースが正しく機能している場合でもタイムアウトになることがあります。サーバー障害モニターが不必要にデータベースを再起動するのを防ぐには、連続タイムアウト検証の最大数を増やします。

注意 - 連続タイムアウト検証の最大数を増やすと、データベースがハングアップしたことを検出するために必要な時間が長くなります。

連続タイムアウト検証の最大許容数を変更するには、最初のタイムアウト検証以外の許可されている連続タイムアウト検証ごとに、カスタムアクションファイルに 1 つのエントリを作成します。

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

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

ERROR_TYPE を TIMEOUT_ERROR に設定します。
ERROR を、連続タイムアウト検証の最大許容数に設定します。
ACTION を RESTART に設定します。

最初のタイムアウト検証を除く、残りの連続タイムアウト検証ごとにエントリを作成し、キーワードを次のように設定します。

ERROR_TYPE を TIMEOUT_ERROR に設定します。
ERROR をタイムアウト検証のシーケンス番号に設定します。たとえば、2 回目の連続タイムアウト検証では、このキーワードを 2 に設定します。3 回目の連続タイムアウト検証では、このキーワードを 3 に設定します。
ACTION を NONE に設定します。

ヒント - デバッグを容易にするため、タイムアウト検証のシーケンス番号を示すメッセージを指定します。

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

使用例 6 連続タイムアウト検証の最大数を変更する

{
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.
```