Sun Cluster 3.1 Data Service for Oracle ガイド

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

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

エラーの事前設定アクションを変更する
事前設定アクションがないエラーのアクションを指定する

注意 –

Sun Cluster HA for Oracle サーバーの障害モニターをカスタマイズする前に、カスタマイズの影響を考慮してください。特に、アクションを再移動または切り替えから無視またはモニターの中止に変更する場合は、十分に注意してください。エラーが長期間放置されると、エラーによってデータベースに問題が起きる可能性があります。Sun Cluster HA for Oracle サーバーの障害モニターをカスタマイズしたあとでデータベースに問題が起きた場合は、カスタマイズしたアクションを元に戻し、事前設定のアクションを使用してください。事前設定のアクションに戻すことで、カスタマイズが問題の原因かどうかを判断できます。

Sun Cluster HA for Oracle サーバーの障害モニターをカスタマイズするには、次の作業が必要です。

エラーのカスタム動作を定義します。
クラスタ内の全ノードにカスタムアクションファイルを伝達します。
サーバー障害モニターに使用させるカスタムアクションファイルを指定します。

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

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

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

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

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

カスタムアクションファイルは、プレーンテキストファイルです。このファイルに、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`	`Integer`	Oracle が生成する DBMS エラーのエラー番号
`SCAN_LOG`	引用符で囲まれた正規表現	Oracle が Oracle 警告ログファイルに記録するエラーメッセージの文字列
`TIMEOUT_ERROR`	`Integer`	サーバー障害モニターを最後に起動または再起動して以来、検証のタイムアウトが連続して発生した回数

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 エラーに対してサーバー障害モニターが実行するアクションとして、どのようなアクションが事前設定されているかについては、付録 A の表 A–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–1 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–2 DBMS エラーを無視する

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

この例は、DBMS エラー 4030 の事前設定アクションを変更するカスタムアクションファイルのエントリです。このエントリで指定される処理は、次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

記録された警告にテキスト ORA-00600: internal error が含まれている場合、サーバー障害モニターが対応として実行するアクションは再起動です。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
エラーが検出された場合でも、追加のメッセージがリソースのログファイルに出力されることはありません。

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

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

注意 –

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

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

注 –

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

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

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

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

ERROR_TYPE に TIMEOUT_ERROR を設定します。
ERROR に検証タイムアウトの序数を設定します。たとえば、2 回目の連続検証タイムアウトの場合は、2 を設定します。3 回目の連続検証タイムアウトの場合は、3 を設定します。
ACTION に NONE を設定します。

ヒント –

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

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

サーバー障害モニターは、連続する検証タイムアウトの 2 回目から 4 回目までを無視します。
5 回目の連続検証タイムアウトに対して、サーバー障害モニターが実行するアクションは再起動です。
このエントリは、タイムアウト発生時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、タイムアウト発生後も維持されます。
2 回目から 4 回目の連続検証タイムアウトについては、発生時に次の形式のメッセージがリソースのログファイルに出力されます。
Timeout #number has occurred.
5 回目の連続検証タイムアウトが発生すると、次のメッセージがリソースのログファイルに出力されます。
Timeout #5 has occurred. Restarting.

カスタムアクションファイルをクラスタ内の全ノードに伝達する

サーバー障害モニターの動作は、すべてのクラスタノードで一貫している必要があります。したがって、サーバー障害モニターが使用するカスタムアクションファイルも、すべてのクラスタノードで同じにする必要があります。カスタムアクションファイルを作成または変更したあとで、このファイルをすべてのクラスタノードに伝達し、すべてのクラスタノードで同じ内容のファイルが使用されるようにします。全クラスタノードにファイルを伝達するには、次の中からクラスタ構成に最も適した方法を使用します。

すべてのノードが共有するファイルシステムにファイルを配置する
可用性の高いローカルファイルシステムにファイルを配置する
rcp(1) コマンド、rdist(1) コマンドなどのオペレーティングシステムコマンドを使用して、各クラスタノードのローカルファイルシステムにファイルをコピーする

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

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

カスタムアクションファイルを指定すると、ファイルの妥当性が検証されます。ファイルに構文エラーがあると、エラーメッセージが表示されます。カスタムアクションファイルを修正してから、ファイルを再び指定して、ファイルの妥当性を検査してください。

注意 –

変更したカスタムアクションファイルに構文エラーが見つかった場合は、エラーを修正してから、障害モニターを再起動します。障害モニターの再起動時に構文エラーが未修正だった場合は誤ったファイルが読み取られ、最初の構文エラー以後のエントリは無視されます。

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

クラスタノード上で、スーパーユーザーになります。

SUNW.oracle_server リソースの Custom_action_file 拡張プロパティを設定します。

このプロパティをカスタムアクションファイルの絶対パスに設定します。
# scrgadm -c -j server-resource\ -x custom_action_file=filepath
-j server-resource

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

-x custom_action_file= filepath

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