サーバー障害モニターが各 DBMS エラーに応じて実行するアクションは、表 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 エラーへの対応を再起動に変更するカスタムアクションファイルのエントリの例を示します。
{ 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 エラー無視するカスタムアクションファイルのエントリの例を示します。
{ ERROR_TYPE=DBMS_ERROR; ERROR=4030; ACTION=none; CONNECTION_STATE=*; NEW_STATE=*; MESSAGE=""; }
この例は、DBMS エラー 4030 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。
サーバー障害モニターは、DBMS エラー 4030 を無視します。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
エラーが検出された場合でも、追加のメッセージがリソースのログファイルに出力されることはありません。