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

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

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

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

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

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

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

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

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

---

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

---

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

1. クラスタノード上で、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。
2. 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 リソースを指定します。