ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris Cluster Data Service for Oracle ガイド Oracle Solaris Cluster 3.3 3/13 (日本語) |
HA for Oracle のインストールと構成のプロセスの概要
Solaris Volume Managerを使用した Oracle データベースアクセスの構成方法
Veritas Volume Manager を使用した Oracle データベースアクセスの構成方法
Oracle ASM を使用した Oracle データベースアクセスの構成方法
クラスタ SCAN リスナー用の Oracle Grid Infrastructure の構成方法
Oracle Database ソフトウェアをインストールする方法
Oracle Database カーネルパラメータを設定する方法
Oracle Database のインストールおよび構成の確認
Oracle Database のインストールを確認する方法
HA for Oracle を登録および構成する方法 (clsetup)
Oracle Grid Infrastructure なしで HA for Oracle を登録および構成する方法 (CLI)
スタンドアロンサーバー用 Oracle Grid Infrastructure ありで HA for Oracle を登録および構成する方法 (CLI)
クラスター用 Oracle Grid Infrastructure ありで HA for Oracle を登録および構成する方法 (CLI)
アーカイブされた再実行ログ用のパーティションをモニターする操作
データベーストランザクション障害に対応する、サーバー障害モニターによるアクション
DBMS タイムアウトのトラブルシューティング用にコアファイルを取得
SUNW.oracle_listener リソースタイプのアップグレード
SUNW.oracle_server リソースタイプのアップグレード
Oracle Data Guard インスタンスの役割の変更
Oracle Data Guard インスタンスの役割の変更方法
B. DBMS のエラーおよび記録される警告についての事前設定アクション
HA for Oracle サーバー 障害モニターをカスタマイズすると、サーバー障害モニターの動作を次のように変更できます。
エラーに対する事前設定アクションをオーバーライドする
アクションが事前設定されていないエラーに対するアクションを指定する
次のセクションでは、HA for Oracle サーバー 障害モニターをカスタマイズするために実行するアクティビティーについて説明します。
HA for Oracle サーバー 障害モニターは、次のタイプのエラーを検出します。
サーバー障害モニターによるデータベースの検証中に発生する DBMS エラー
Oracle が警告ログファイルに記録する警告
Probe_timeout 拡張プロパティーに設定された時間内に応答がなかったために生じたタイムアウト
これらのタイプのエラーに対するカスタムアクションを定義するには、カスタムアクションファイルを作成します。このセクションには、カスタムアクションファイルに関する次の情報が含まれます。
カスタムアクションファイルは、標準テキストファイルです。ファイルには、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"] }
区切られたキーワードと値のペアの間、およびファイルの書式を設定するエントリの間には、空白を使用することもできます。
カスタムアクションファイル内のキーワードの意味と許可される値は、次のとおりです。
サーバー障害モニターが検出したエラーのタイプを示します。このキーワードには、次の値が許可されます。
エラーが DBMS エラーであることを指定します。
エラーが警告ログファイルにログに記録されている警告であることを指定します。
エラーがタイムアウトであることを指定します。
ERROR_TYPE キーワードはオプションです。このキーワードを省略すると、エラーは DBMS エラーと見なされます。
エラーを識別します。error-spec のデータタイプと意味は、次の表に示されているように、ERROR_TYPE キーワードの値によって決定されます。
|
ERROR キーワードを指定する必要があります。このキーワードを省略すると、カスタムアクションファイルのエントリは無視されます。
サーバー障害モニターがエラーに対応して実行するアクションを指定します。このキーワードには、次の値が許可されます。
サーバー障害モニターがエラーを無視することを指定します。
サーバー障害モニターが停止することを指定します。
サーバー障害モニターが SUNW.oracle_server リソースの Restart_type 拡張プロパティーの値によって指定されたエンティティーを停止および再起動することを指定します。
サーバー障害モニターがデータベースサーバーリソースグループを別のノードまたはゾーンに切り換えることを指定します。
ACTION キーワードはオプションです。このキーワードを省略すると、サーバー障害モニターはエラーを無視します。
エラー検出時のデータベースとサーバー障害モニター間の必須接続状態を指定します。エラー検出時に接続がこの必須状態にあるときにのみ、エントリが適用されます。このキーワードには、次の値が許可されます。
接続の状態に関係なく、エントリが常に適用されることを指定します。
サーバー障害モニターがデータベースへの接続を試みている場合にのみ、エントリが適用されることを指定します。
サーバー障害モニターがオンラインの場合にのみ、エントリが適用されることを指定します。サーバー障害モニターは、データベースに接続されている場合はオンラインです。
サーバー障害モニターがデータベースに接続解除している場合にのみ、エントリが適用されることを指定します。
CONNECTION_STATE キーワードはオプションです。このキーワードを省略すると、接続の状態に関係なく、エントリは常に適用されます。
エラーが検出されたあとにサーバー障害モニターが到達する必要がある、データベースおよびサーバー障害モニター間の接続の状態を指定します。このキーワードには、次の値が許可されます。
接続の状態が変更されずに維持される必要があることを指定します。
サーバー障害モニターがデータベースから接続解除し、ただちにデータベースに再接続する必要があることを指定します。
サーバー障害モニターがデータベースから接続解除する必要があることを指定します。サーバー障害モニターは、次回データベースを検証するときに再接続します。
NEW_STATE キーワードはオプションです。このキーワードを省略すると、エラーが検出されたあと、データベース接続の状態は変更されずに維持されます。
エラーが検出されたときにリソースのログファイルに出力される追加メッセージを指定します。メッセージは二重引用符で囲む必要があります。このメッセージは、エラーに対して定義されている標準メッセージに追加されます。
MESSAGE キーワードはオプションです。このキーワードを省略すると、エラーが検出されたときにリソースのログファイルに追加メッセージは出力されません。
各 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) コマンドなどのオペレーティングシステムコマンドを使用して、クラスタの各ノードまたはゾーンのローカルファイルシステムにファイルをコピーする
カスタマイズしたアクションをサーバー障害モニターに適用するには、障害モニターが使用するカスタムアクションファイルを指定する必要があります。カスタマイズしたアクションがサーバー障害モニターに適用されるのは、サーバー障害モニターがカスタムアクションファイルを読み取るときです。サーバー障害モニターがカスタムアクションファイルを読み取るのは、ファイルの指定時です。
カスタムアクションファイルを指定すると、ファイルも検証されます。ファイルに構文エラーが含まれている場合は、エラーメッセージが表示されます。そのため、カスタムアクションファイルを変更したあと、ファイルを再度指定して、ファイルを検証します。
注意 - 変更されたカスタムアクションファイルに構文エラーが検出された場合は、障害モニターを再起動する前にエラーを修正してください。障害モニターが再起動したときに構文エラーが修正されないままの場合、障害モニターはエラーのあるファイルを読み取り、最初の構文エラーのあとに出現するエントリを無視します。 |
このプロパティーをカスタムアクションファイルの絶対パスに設定します。
# clresource set -p custom_action_file=filepath server-resource
カスタムアクションファイルの絶対パスを指定します。
SUNW.oracle_server リソースを指定します。