ナビゲーションリンクをスキップ
印刷ビューの終了
| Oracle Solaris Cluster Data Service for Oracle Real Application Clusters ガイド Oracle Solaris Cluster 3.3 3/13 (日本語)

検索範囲:

- このドキュメント
- ライブラリ全体

## Oracle 9i RAC サーバー 障害モニターのカスタマイズ

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

- エラーに対する事前設定動作をオーバーライドする

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

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

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

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

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

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

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

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

- サーバー障害モニターによるデータベースの検証中に発生する DBMS エラー

- Oracle が警告ログファイルに記録する警告

- `Probe_timeout` 拡張プロパティーに設定された時間内に応答がなかったために生じたタイムアウト

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

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

- 「DBMS エラーへの対応の変更」

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

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

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

カスタム動作ファイルはプレーンテキストファイルです。ファイルには、Oracle 9i RAC サーバー障害モニターのカスタム動作を定義する 1 つ以上のエントリが含まれます。各エントリは、1 つの DBMS エラー、1 つのタイムアウトエラー、または複数の記録された警告に対するカスタム動作を定義します。カスタム動作ファイルには、最大 1024 のエントリが許可されます。

注 - カスタム動作ファイルの各エントリは、エラーに対する事前設定動作をオーバーライドしたり、事前設定された動作がないエラーに対する動作を指定したりします。オーバーライドする事前設定動作または動作が事前設定されていないエラーに対してのみ、カスタム動作ファイルにエントリを作成します。変更しない動作に対して、エントリを作成しないでください。

カスタム動作ファイルのエントリは、セミコロンで区切られた一連のキーワードと値のペアで構成されます。各エントリは中カッコで囲まれています。

カスタム動作ファイルのエントリの形式は、次のとおりです。

    {
    [ERROR_TYPE=DBMS_ERROR|SCAN_LOG|TIMEOUT_ERROR;]
    ERROR=error-spec;
    [ACTION=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`

    サーバー障害モニターが Oracle 9i RAC サーバーリソースを停止して再起動することを示します。

  `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 エラーへの対応を再起動に変更するための、カスタム動作ファイルのエントリを示しています。

例 5-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 エラーを無視するためのカスタム動作ファイルのエントリを示しています。

例 5-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` を含むエントリの前に出現するようにしてください。

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

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

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

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

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

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

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

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

1. クラスタノードで、スーパーユーザーになるか、`solaris.cluster.modify` RBAC の承認を提供する役割になります。
2. `SUNW.scalable_rac_server` リソースの `Custom_action_file` 拡張プロパティーを設定します。

   このプロパティーをカスタム動作ファイルの絶対パスに設定します。

       # clresource set -p custom_action_file=filepath server-resource

   `-p` `custom_action_file=` filepath

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

   server-resource

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

Copyright © 2000, 2013, Oracle and/or its affiliates. All rights reserved. 著作権について |