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

検索範囲:

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

## HA for Oracle 障害モニターの調整

HA for Oracle データサービスの障害のモニタリングは、次の障害モニターによって行われます。

- Oracle サーバー障害モニター

- Oracle リスナー障害モニター

注 - Oracle Database version 11g release 2 または 12c で、クラスタ用 Oracle Grid Infrastructure の単一クライアントアクセス名 (SCAN) リスナーを使用している場合、Oracle Solaris Cluster ソフトウェアによる SCAN リスナーの障害モニタリングは行われません。

各障害モニターは、次の表に示すリソースタイプを持つリソースに含まれています。

表 1-4 HA for Oracle 障害モニターのリソースタイプ

障害モニター | リソースタイプ
--- | ---
Oracle サーバー | `SUNW.oracle_server`
Oracle リスナー | `SUNW.oracle_listener`

これらのリソースのシステムプロパティーと拡張プロパティーが、障害モニターの動作を制御します。これらのプロパティーのデフォルト値が、事前設定された障害モニターの動作を決定します。事前設定された動作は、ほとんどの Oracle Solaris Cluster のインストールに適しているはずです。したがって、HA for Oracle 障害モニターを調整するのは、事前設定されたこの動作を変更する必要がある場合のみにしてください。

HA for Oracle 障害モニターを調整するには、次のタスクを実行します。

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

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

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

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

詳細については、『Oracle Solaris Cluster Data Services Planning and Administration Guide』の「Tuning Fault Monitors for Oracle Solaris Cluster Data Services」を参照してください。これらのタスクを行うために必要な HA for Oracle 障害モニターについての情報は、以降のサブセクションで説明します。

HA for Oracle を登録および構成する際に、HA for Oracle 障害モニターを調整します。詳細については、「HA for Oracle の登録と構成」を参照してください。

### Oracle サーバー障害モニターの操作

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

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

サーバー障害モニターは、次のプロセスで構成されます。

- 主要な障害モニタープロセス

- データベースクライアント障害検証

このセクションでは、サーバー障害モニターに関する次の情報について説明します。

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

- 「データベースクライアント障害検証の操作」

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

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

#### 主要障害モニターの操作

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

#### データベースクライアント障害検証の操作

データベースクライアント障害検証は、次の操作を行います。

1. アーカイブされた再実行ログ用のパーティションのモニタリング。「アーカイブされた再実行ログ用のパーティションをモニターする操作」を参照してください。

2. パーティションに問題がない場合は、データベースが稼働しているかの確認。「データベースが操作可能かどうかを判定する操作」を参照してください。

検証機能は、リソースプロパティー `Probe_timeout` で設定されているタイムアウト値を使用して、Oracle を正常に検証するために割り当てる時間を決定します。

##### アーカイブされた再実行ログ用のパーティションをモニターする操作

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

- 送信先が健全である場合、検証は送信先のファイルシステムの空き容量を決定します。空き容量がファイルシステムの容量の 10% 未満で、20MB 未満の場合、検証機能は `syslog` にメッセージを出力します。

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

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

アーカイブされた再実行ログのパーティションが健全な場合、データベースクライアント障害検証は動的パフォーマンスビュー `V$sysstat` をクエリーして、データベースパフォーマンス統計情報を取得します。これらの統計の変化は、データベースが稼働していることを意味します。連続したクエリー間でこれらの統計が変化していない場合、障害検証機能はデータベーストランザクションを実行して、データベースが操作可能かどうかを判定します。これらのトランザクションには、ユーザー表スペースの表の作成、更新、および削除を伴います。

データベースクライアント障害検証機能は、Oracle ユーザーとしてすべてのトランザクションを実行します。このユーザーの ID は、「ノードの準備方法」で説明しているように、ノードまたはゾーンの準備中に指定されます。

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

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

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

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

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

- モニター停止。データベースを停止せずに、サーバー障害モニターが停止されます。

- 再起動。サーバー障害モニターは、`Restart_type` 拡張プロパティーの値によって指定されたエンティティーを停止および再起動します。

  - `Restart_type` 拡張プロパティーが `RESOURCE_RESTART` に設定されている場合、サーバー障害モニターはデータベースサーバーリソースを再起動します。デフォルトでは、サーバー障害モニターはデータベースサーバーリソースを再起動します。

  - `Restart_type` 拡張プロパティーが `RESOURCE_GROUP_RESTART` に設定されている場合、サーバー障害モニターはデータベースサーバーリソースグループを再起動します。

  注 - 再起動を試みる回数は、`Retry_interval` リソースプロパティーが指定する時間内に、`Retry_count` リソースプロパティーの値を超えることがあります。このような場合、サーバー障害モニターは、別のノードまたはゾーンへのリソースグループの切り換えを試みます。

- 切り換え。サーバー障害モニターは、データベースサーバーリソースグループを別のノードまたはゾーンに切り換えます。使用可能なノードまたはゾーンがない場合、リソースグループを切り換える試みは失敗します。リソースグループを切り換える試みが失敗すると、データベースサーバーは再起動されます。

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

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

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

- サーバー障害モニターがサーバーの健全性をクエリーするとき

サーバー障害モニターが記録された警告を検出し、その警告に対処方法が定義されている場合、サーバー障害モニターは警告に対応する対処方法を実行します。

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

### Oracle リスナー障害モニターの操作

Oracle リスナー障害モニターは、Oracle リスナーのステータスを確認します。

リスナーが実行中の場合、Oracle リスナー障害モニターは検証が成功したと見なします。障害モニターがエラーを検出すると、リスナーが再起動されます。

注 - リスナーリソースは、リスナーパスワードを設定するメカニズムを提供していません。Oracle リスナーセキュリティが有効の場合、リスナー障害モニターによる検証が Oracle エラー TNS-01169 を返すことがあります。リスナーは応答が可能なため、リスナー障害モニターは検証が成功したと見なします。このアクションのためにリスナーが検出されないままになるという障害が生じることはありません。リスナーの障害は、別のエラーを返すか、検証のタイムアウトの原因になります。

リスナー検証は、`pmfadm` を介して起動することで、検証の可用性を高めます。検証が強制終了した場合、PMF は自動的に検証機能を再起動します。

検証中にリスナーで問題が発生した場合、検証機能によってリスナーの再起動が試行されます。検証機能による再起動の試行最大回数は、`retry_count` リソースプロパティーに設定した値によって決定されます。最大回数まで起動を試みても、まだ検証が成功しない場合、検証機能は障害モニターを停止し、リソースグループの切り換えを行いません。

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

不明な DBMS タイムアウトのトラブルシューティングを容易にするために、障害モニターを有効にして、検証タイムアウトが発生したときにコアファイルを作成できます。コアファイルの内容は、障害モニターのプロセスに関するものです。障害モニターは、`/` ディレクトリにコアファイルを作成します。障害モニターでコアファイルを作成できるようにするには、`coreadm` コマンドを使用して `set-id` コアダンプを有効にします。

    # coreadm -g /var/cores/%f.%n.%p.core -e global -e process \
    -e global-setid -e proc-setid -e log

詳細については、`coreadm`(1M) のマニュアルページを参照してください。

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