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 拡張プロパティーを設定します。

デバイスグループのステータスは、モニターされる個々の論理ボリュームのステータスから導出されます。モニター対象のすべての論理ボリュームが健全であれば、そのデバイスグループは健全です。いずれかのモニター対象の論理ボリュームに障害がある場合、そのデバイスグループには障害があります。デバイスグループに障害があることが見つかると、そのグループを表すリソースのモニタリングが停止され、そのリソースは無効状態に変更されます。

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

ユーザーランドクラスタメンバーシップの再構成によって I/O エラーが発生する場合、ユーザーランドクラスタメンバーシップモニター (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% 未満で、20MB 未満の場合、検証機能は 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) のマニュアルページを参照してください。