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 エラーに対応してサーバー障害モニターが実行するアクションは、表 1で一覧表示されているように、事前に設定されています。 DBMS エラーに対する応答を変更する必要があるかどうか決定するには、データベースに対する DBMS エラーの影響を考慮して、事前設定アクションが適切かどうかを判断します。例として、次のサブセクションを参照してください。

「影響が重大であるエラーに対する応答」
「影響が軽度のエラーを無視する」

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

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

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

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

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

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

例 4 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 つとしては、オペレーティングシステムに対してメモリー不足していたことが挙げられます。このエラーが 2 つ以上のセッションに影響を及ぼす場合、データベースの再起動が適切な場合があります。しかしながら、これらのセッションはさらにプライベートメモリーを必要としないため、このエラーはほかのセッションに影響を与えない可能性があります。この場合、サーバー障害モニターでエラーを無視するよう指定することを考慮します。

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

例 5 DBMS エラーの無視

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

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

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

記録された警告に対する応答の変更

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

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

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

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

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

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

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

例 6 記録された警告に対する応答の変更

{
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 に増やすための、カスタムアクションファイルのエントリを示しています。

例 7 連続タイムアウトプローブの最大数の変更

{
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(1) コマンドまたたは rdist(1) コマンドなどのオペレーティングシステムコマンドを使用して、ファイルを各クラスタノードまたはゾーンのローカルファイルシステムにコピーする

サーバー障害モニターが使用する必要のあるカスタムアクションファイルを指定する

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

カスタムアクションファイルを指定すると、ファイルも検査されます。ファイルが構文エラーを含む場合、エラーメッセージが表示されます。そのため、カスタムアクションファイルを修正したあと、ファイルを再度指定して、ファイルを検査します。

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

サーバー障害モニターが使用するべきカスタムアクションファイルを指定する

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

カスタムアクションファイルの絶対パスを指定します。

サーバーリソース

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

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

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