Oracle RAC 用サポート 障害モニターのチューニング

Oracle RAC 用サポート データサービスの障害モニタリングは、次のリソースの障害モニターが行います。

• スケーラブルなデバイスグループのリソース

• スケーラブルなファイルシステムマウントポイントのリソース

• Oracle 9i RAC サーバーのリソース

• Oracle 9i RAC リスナーのリソース

各障害モニターには、次の表に示すリソースタイプを持つリソースがあります。

表 5-4 Oracle RAC 用サポート 障害モニターのリソースタイプ

障害モニターの動作は、このリソースのシステムプロパティーと拡張プロパティーによって制御されます。事前に設定された障害モニターの動作は、これらのプロパティーのデフォルト値に基づいています。現在の動作は、ほとんどの Oracle Solaris Cluster システムに適しているはずです。したがって、事前に設定されたこの動作を変更する場合「のみ」、Oracle RAC 用サポート 障害モニターを調整してください。

Oracle RAC 用サポート 障害モニターの調整には、次のような作業があります。

• 障害モニターの検証間隔を設定する。

• 障害モニターの検証タイムアウトを設定する。

• 継続的な障害とみなす基準を定義する。

• リソースのフェイルオーバー動作を指定する

詳細は、『Oracle Solaris Cluster Data Services Planning and Administration Guide』の「Tuning Fault Monitors for Oracle Solaris Cluster Data Services」を参照してください。 これらの作業を行うのに必要な Oracle RAC 用サポート 障害モニターについては、次の副節を参照してください。

• 「スケーラブルなデバイスグループの障害モニターの操作」

• 「スケーラブルなファイルシステムマウントポイントの障害モニターの操作」

• 「Oracle 9i RAC サーバー障害モニターの操作」

• 「Oracle 9i RAC リスナー障害モニターの操作」

• 「DBMS タイムアウトのトラブルシューティング用にコアファイルを取得」

スケーラブルなデバイスグループの障害モニターの操作

デフォルトでは、障害モニターは、リソースが表すデバイスグループ内のすべての論理ボリュームを監視します。 デバイスグループ内の論理ボリュームのサブセットのみを監視する必要がある場合は、LogicalDeviceList 拡張プロパティーを設定します。

デバイスグループのステータスは、監視される個々の論理ボリュームのステータスから導き出されます。監視されているすべての論理ボリュームが健全な場合、そのデバイスグループは健全です。監視されている論理ボリュームが 1 つでも障害状態の場合、そのデバイスグループは障害状態となります。デバイスグループが障害状態であることがわかると、グループを表すリソースの監視が停止され、リソースが無効な状態に置かれます。

個々の論理ボリュームのステータスを取得するには、そのボリュームのボリュームマネージャーに照会します。Solaris Volume Manager for Sun Cluster のボリュームのステータスを照会から判断できない場合、障害モニターはファイルの入出力 (I/O) 操作を実行して、そのステータスを判断します。

ユーザーランドクラスタメンバーシップの再構成によって I/O エラーが発生した場合、ユーザーランドクラスタメンバーシップモニター (Userland Cluster Membership Monitor、UCMM) の再構成中は、障害モニターによるデバイスグループリソースの監視が中断されます。

スケーラブルなファイルシステムマウントポイントの障害モニターの操作

障害モニターは、マウントされたファイルシステムが使用可能かどうかを判断するため、ファイルシステム上でテストファイルを開いたり、読み込んだり、書き込んだりするなどの I/O 操作を実行します。I/O 操作がタイムアウト期間内に完了しない場合、障害モニターはエラーを報告します。I/O 操作のタイムアウトを指定するには、IOTimeout 拡張プロパティーを設定します。

エラーに対する応答は、ファイルシステムの種類によって次のように異なります。

• ファイルシステムが 認定された NAS デバイス上の NFS ファイルシステムである場合、応答は次のようになります。

  • リソースの監視は現在のノードで停止されます。

  • リソースは現在のノードで無効な状態になり、ノードからファイルシステムがマウント解除されます。

• ファイルシステムが Sun QFS 共有ファイルシステム である場合、応答は次のようになります。

  • エラーが発生したノードがメタデータサーバーリソースをホストしている場合、メタデータサーバーリソースは別のノードにフェイルオーバーされます。

  • ファイルシステムはマウント解除されません。

  フェイルオーバーの試みが失敗した場合、ファイルシステムはマウント解除されたままで、警告が表示されます。

Oracle 9i RAC サーバー障害モニターの操作

Oracle 9i RAC サーバーの障害モニターは、サーバーへのリクエストを使用して、サーバーの状態をクエリします。

サーバー障害モニターは、pmfadm を介して起動され、モニターの可用性を高めます。何らかの理由でモニターが終了すると、手順モニター機能 (PMF) がモニターを自動的に再起動します。

サーバー障害モニターは、次の要素から構成されます。

• 主要障害モニター手順

• データベースクライアント障害プローブ

このセクションには、サーバー障害モニターに関する次の情報が含まれています。

• 「主要障害モニターの操作」

• 「データベースクライアント障害プローブの操作」

• 「データベーストランザクション障害に対応する、サーバー障害モニターによるアクション」

• 「サーバー障害モニターによる記録された警告のスキャン」

主要障害モニターの操作

主要障害モニターは、データベースがオンラインで、トランザクション中にエラーが返されない場合、操作が成功したと見なします。

データベースクライアント障害プローブの操作

データベースクライアント障害プローブは、次の操作を実行します。

1. アーカイブされた再実行ログの区分のモニター「アーカイブされた再実行ログの区分をモニターする操作」を参照してください。

2. 区分が健全である場合、データベースが操作可能かどうかを決定します。「データベースが操作可能かどうかを決定する操作」を参照してください。

プローブは、リソースプロパティ Probe_timeout で設定されているタイムアウト値を使用して、Oracle のプローブを成功させるために割り当てる時間を決定します。

アーカイブされた再実行ログの区分をモニターする操作

データベースクライアント障害プローブは、動的パフォーマンス表示 v$archive_dest をクエリーし、アーカイブされた再実行ログのすべての可能な送信先を決定します。すべてのアクティブな送信先に対して、プローブは送信先が健全で、アーカイブされた再実行ログを保存するための十分な空き容量があるかどうかを決定します。

• 送信先が健全である場合、プローブは送信先のファイルシステムの空き容量を決定します。空き容量がファイルシステム容量の 10% 未満で、20 M バイト未満の場合、プローブは syslog にメッセージを出力します。

• 送信先が ERROR 状態の場合、プローブは syslog にメッセージを出力し、データベースが操作可能かどうかを判定するために操作を無効にします。操作は、エラー状態がクリアされるまで無効のままです。

データベースが操作可能かどうかを決定する操作

アーカイブされた再実行ログ用の区分が健全な場合、データベースクライアント障害プローブは動的パフォーマンス表示 v$sysstat をクエリーし、データベースパフォーマンス統計を取得します。これらの統計が変更されている場合、データベースが操作されていることを示します。連続したクエリー間で統計が変化しなかった場合、障害プローブはデータベーストランザクションを実行し、データベースが運用されているかを判定します。これらのトランザクションには、ユーザー表スペースでの、表の作成、更新およびドロップが関係しています。

データベースクライアント障害プローブは、Oracle ユーザーとしてすべてのトランザクションを実行します。このユーザーの ID は、「DBA グループと DBA ユーザーアカウントを作成する」に従ってノードまたはゾーンを準備する段階で指定します。

データベーストランザクション障害に対応する、サーバー障害モニターによるアクション

データベーストランザクションに失敗した場合、サーバー障害モニターは障害の原因になったエラーによって決定されるアクションを実行します。サーバー障害モニターが実行するアクションを変更するには、「Oracle 9i RAC サーバー 障害モニターのカスタマイズ」に従って、サーバー障害モニターをカスタマイズしてください。

アクションで外部プログラムの実行が必要な場合、そのプログラムはバックグラウンドで別のプロセスとして実行されます。

可能なアクションは、次のとおりです。

• 無視。サーバー障害モニターはエラーを無視します。

• モニター停止。データベースをシャッドダウンせずに、サーバー障害モニターが停止されます。

• 再起動。サーバー障害モニターは Oracle 9i RAC サーバーリソースを停止して再起動します。

サーバー障害モニターによる記録された警告のスキャン

Oracle ソフトウェアは、警告を警告ログファイルに記録します。このファイルの絶対パスは、SUNW.scalable_rac_server リソースの alert_log_file 拡張プロパティーにより指定されます。サーバー障害モニターは、次のタイミングで新しい警告があるかどうか、警告ログファイルをスキャンします。

• サーバー障害モニターが起動されたとき

• サーバー障害モニターがサーバーの健全性をクエリーするたび

サーバー障害モニターが検出する警告ログに対するアクションが定義されている場合、サーバー障害モニターは警告に対してアクションを実行します。

記録された警告用の事前設定アクションは、表 B-2 に一覧表示されています。 サーバー障害モニターが実行するアクションを変更するには、「Oracle 9i RAC サーバー 障害モニターのカスタマイズ」に従って、サーバー障害モニターをカスタマイズしてください。

Oracle 9i RAC リスナー障害モニターの操作

Oracle 9i RAC リスナー障害モニターは、Oracle リスナーの状態を確認します。

リスナーが実行されている場合、Oracle 9i RAC リスナー障害モニターはプローブが成功したと見なします。 障害モニターがエラーを検出すると、リスナーは再起動されます。

リスナープローブは、pmfadm を介して起動することで、プローブの可用性を高めます。プローブが終了した場合、PMF は自動的にプローブを再起動します。

プローブ中にリスナーに問題が生じた場合、プローブはリスナーの再起動を試みます。リソースプロパティ retry_count に設定されている値は、プローブが再起動を試みる最大回数を決定します。 最大試行回数に達してもプローブが成功しないと、プローブで障害モニターが停止します。

DBMS タイムアウトのトラブルシューティング用にコアファイルを取得

不明な DBMS タイムアウトのトラブルシューティングを容易にするために、障害モニターを有効にして、プローブタイムアウトが生じたときにコアファイルを作成することができます。コアファイルの内容は、障害モニター手順に関連します。障害モニターは、/ ディレクトリにコアファイルを作成します。障害モニターがコアファイルを作成できるためには、coreadm コマンドを使用して set-id コアダンプを有効にします。詳細は、coreadm(1M) のマニュアルページを参照してください。