HA for Oracle サーバー障害モニターのカスタマイズ

HA for Oracle サーバー障害モニターをカスタマイズすると、次のようにサーバー障害モニターの動作を変更できます。

エラーに対する事前設定動作をオーバーライドする
動作が事前設定されていないエラーに対する動作を指定する

注意 - 動作を再起動から変更する場合、またはモニターを無視または停止するように切り換える場合は特に、HA for Oracle サーバー障害モニターをカスタマイズする前に、カスタマイズの影響を考慮してください。エラーが長期間修正されない場合、エラーによりデータベースに問題が発生する場合があります。HA for Oracle サーバー障害モニターをカスタマイズしたあとにデータベースに問題が発生した場合は、事前設定動作の使用に戻ってください。事前設定動作に戻ることで、問題がカスタマイズによって発生したものかどうかを確認できます。

HA for Oracle サーバー障害モニターのカスタマイズには、次の作業が伴います。

エラーに対するカスタム動作を定義する
クラスタのすべてのノードにカスタム動作ファイルを伝達する
サーバー障害モニターが使用する必要のあるカスタム動作ファイルを指定する

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

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

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

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

「カスタム動作ファイルの形式」
「DBMS エラーへの対応の変更」
「記録された警告への対応を変更する」
「連続タイムアウト検証の最大数を変更する」

カスタム動作ファイルの形式

カスタム動作ファイルはプレーンテキストファイルです。ファイルには、HA for Oracle サーバー障害モニターのカスタム動作を定義する 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 によって生成された 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 エラーへの対応を変更するには、カスタム動作ファイルにエントリを作成し、キーワードを次のように設定します。

ERROR_TYPE は DBMS_ERROR に設定します。
ERROR は、DBMS エラーのエラー番号に設定します。
ACTION は、必要とする動作に設定します。

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

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

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

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

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

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

例 1-4 DBMS エラーを無視する

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

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

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

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

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

動作が事前設定されている記録された警告は、表 B-2 に一覧表示されています。事前設定動作を変更したり、サーバー障害モニターが対応する新しい警告を定義したりするには、記録された警告への対応を変更します。

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

ERROR_TYPE は SCAN_LOG に設定します。
ERROR は、Oracle が Oracle 警告ログファイルに記録したエラーメッセージの文字列を識別する、引用符で囲まれた正規表現に設定します。
ACTION は、必要とする動作に設定します。

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

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

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

例 1-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 に増やすための、カスタム動作ファイルのエントリを示しています。

例 1-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.
```

クラスタのすべてのノードにカスタム動作ファイルを伝達する

サーバー障害モニターは、すべてのクラスタノードで一貫して動作する必要があります。そのため、サーバー障害モニターが使用するカスタム動作ファイルは、すべてのクラスタノードで同一である必要があります。カスタム動作ファイルを作成または変更したあと、このファイルをすべてのクラスタノードに伝達することによって、確実にファイルがすべてのクラスタノードで同一になります。ファイルをすべてのクラスタノードに伝達するには、クラスタ構成にもっとも適した方法を使用します。

すべてのノードが共有するファイルシステム上のファイルを検出する
高可用性ローカルファイルシステム上でファイルを検出する
rcp コマンドまたは rdist コマンドなどのオペレーティングシステムコマンドを使用して、ファイルを各クラスタノードのローカルファイルシステムにコピーする。

サーバー障害モニターが使用する必要のあるカスタム動作ファイルを指定する

サーバー障害モニターにカスタマイズされた動作を適用するには、障害モニターが使用する必要のあるカスタム動作ファイルを指定する必要があります。カスタマイズされた動作は、サーバー障害モニターがカスタム動作ファイルを読み取ったときに、サーバー障害モニターに適用されます。サーバー障害モニターは、ファイルが指定されたときにカスタム動作ファイルを読み取ります。

カスタム動作ファイルを指定すると、ファイルも検証されます。ファイルに構文エラーが含まれている場合は、エラーメッセージが表示されます。そのため、カスタム動作ファイルを変更したあと、ファイルを再度指定して、ファイルを検証します。

注意 - 変更されたカスタム動作ファイルに構文エラーが検出された場合は、障害モニターを再起動する前にエラーを修正してください。障害モニターが再起動したときに構文エラーが修正されないままの場合、障害モニターはエラーのあるファイルを読み取り、最初の構文エラーのあとに出現するエントリを無視します。

サーバー障害モニターが使用する必要のあるカスタム動作ファイルの指定方法

クラスタノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。
SUNW.oracle_server リソースの Custom_action_file 拡張プロパティーを設定します。
このプロパティーをカスタム動作ファイルの絶対パスに設定します。
```
# clresource set -p custom_action_file=filepath server-resource
```
-p custom_action_file= filepath

カスタム動作ファイルの絶対パスを指定します。

server-resource

SUNW.oracle_server リソースを指定します。

ナビゲーションリンクをスキップ
印刷ビューの終了
	Oracle Solaris Cluster Data Service for Oracle ガイド Oracle Solaris Cluster 4.0 (日本語)