10 クラスタの監視およびトラブルシューティング

自律型ヘルス・フレームワークを使用してクラスタを監視およびトラブルシューティングできます。

• 自律型ヘルス・フレームワーク
  自律型ヘルス・フレームワークは、収集されたデータを分析し、クラスタまたはOracle RACデータベースの状態に影響を及ぼす前に問題を事前に特定できるツールの集合です。
• Enterprise Managerを使用したOracle Clusterwareの監視
  Enterprise Managerを使用して、Oracle Clusterwareを監視できます。
• Oracle RAC環境における構成の問題のトラブルシューティング
  クラスタ・レディ・サービス・コントロール(CRSCTL)・コマンドのcheckを使用すると、複数のOracle Clusterwareコンポーネントのステータスを同時に判別できます。

関連項目:

• Oracle Real Application Clustersコンポーネントの問題における診断の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

• Oracle Clusterwareコンポーネントの問題の診断方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください

10.1 自律型ヘルス・フレームワーク

自律型ヘルス・フレームワークは、収集されたデータを分析し、クラスタまたはOracle RACデータベースの状態に影響を及ぼす前に問題を事前に特定できるツールの集合です。

自律型ヘルス・フレームワークを構成するツールの大多数は、すでにOracle Database 12c リリース1で使用可能です。Oracle Database 12c リリース2では、いくつかのツールの出力がグリッド・インフラストラクチャ管理リポジトリで統合され、リアルタイムで分析されて本番クラスタでの問題の発現を示す可能性があるパターンを検出します。

• クラスタ検証ユーティリティ(CVU)
  クラスタ検証ユーティリティ(CVU)は、構成における様々な問題の診断を支援できます。自律型ヘルス・フレームワークの一部として、CVUはスケジュール・ベースで自律的に稼働することで次のようなチェックを定期的に実行できます。
• ORAchk
  自律型ヘルス・フレームワークの一部として、ORAchkはデーモン・モードで稼働するように構成されます。ORAchkは、既知の問題がないか様々な製品を事前にスキャンし、それらの問題について自律的にレポートします。
• クラスタ状態モニター
  クラスタ状態モニターは、Oracle Grid Infrastructureに統合されています。クラスタ状態モニターは、パフォーマンスを向上させ、CPU使用のオーバーヘッドを削減するために、オペレーティング・システムAPIを使用してオペレーティング・システム統計を収集します。
• Cluster Health Advisor
  Cluster Health Advisorデーモンは、Oracle Real Application Clusters (Oracle RAC)、Oracle RAC One Nodeデータベース、ホストのオペレーティング・システムおよびハードウェア・リソースからデータを収集し、データベースまたはホストのパフォーマンス問題を検出した後に根本原因と処置を分析して示します。
• トレース・ファイル・アナライザ・コレクタ
  トレース・ファイル・アナライザは、診断情報の収集を一元管理して自動化します。
• ハング・マネージャ
  ハング・マネージャは、ハングしたデータベース・セッションを確実に検出して、適時に解決できます。
• データベース・サーバーのメモリー不足の管理
  Memory Guardは、サーバー上のメモリー不足をリアルタイムで検出し、新しいセッションを他のサーバーにリダイレクトして、メモリーが不足しているサーバー上のすべての使用可能メモリーが使用されることを防止します。
• Oracle Database Quality of Service Management
  Oracle Database Quality of Service (QoS) Managementは、システム全体のワークロード・リクエストを監視する自動化されたポリシーベースの製品です。

10.1.1 クラスタ検証ユーティリティ(CVU)

クラスタ検証ユーティリティ(CVU)は、構成における様々な問題の診断を支援できます。自律型ヘルス・フレームワークの一部として、CVUはスケジュール・ベースで自律的に稼働することで次のようなチェックを定期的に実行できます。

クラスタ検証ユーティリティ(CVU)は、インストール、パッチ更新またはその他のシステム変更に備えてシステム・チェックを行います。CVUを使用すると、必要なシステム構成やインストール前の手順を確実に行えるようになり、Oracle Grid InfrastructureやOracle Real Application Clusters (Oracle RAC)のインストール、更新またはパッチ操作を正常に完了できます。

Oracle Universal InstallerはCVUに完全に統合されており、CVUの多くの前提条件チェックは自動化されます。Oracle Universal Installerを実行すると、すべての前提条件チェックとこれに関連付けられたfixupスクリプトが実行されます。

• ノード・アプリケーションの存在の検証
  CVUのcomp nodeappコマンドを使用して、すべてのノード上でのノード・アプリケーション、つまり仮想IP (VIP)、Oracle Notification Services (ONS)およびグローバル・サービス・デーモン(GSD)の存在を確認します。
• Oracle Clusterwareコンポーネントの整合性の検証
  CVUのcomp crsコマンドを使用して、すべてのOracle Clusterwareコンポーネントの存在を確認します。
• Oracle Cluster Registryの整合性の検証
  CVUのcomp ocrコマンドを使用して、Oracle Clusterwareレジストリの整合性を検証します。
• クラスタ全体の整合性の検証
  CVUのcomp cluコマンドを使用して、クラスタ内のすべてのノードにクラスタ構成の同一ビューがあるかチェックします。
• インターコネクトの設定のチェック
  CVUのcomp nodereachまたはcomp nodeconコマンドを使用して、インターコネクトの設定をチェックします。
• トレースの有効化
  トレースを有効にしないかぎり、CVUはトレース・ファイルを生成しません。

関連項目:

Oracle Clusterware管理およびデプロイメント・ガイド

10.1.1.1 ノード・アプリケーションの存在の検証

CVUのcomp nodeappコマンドを使用して、すべてのノード上でのノード・アプリケーション、つまり仮想IP (VIP)、Oracle Notification Services (ONS)、およびGlobal Service Daemon (GSD)の存在を確認します。

ノード・アプリケーションの存在を確認するには、次の手順を実行します。

1. コマンド・ウィンドウで、Oracle Clusterwareソフトウェア・インストールを所有するユーザーとしてオペレーティング・システムにログインします。
2. 次の構文でCVUのcomp nodeappコマンドを使用します。

   cluvfy comp nodeapp [ -n node_list] [-verbose]
   

   node_listはチェックするノードを表します。

3. cluvfyコマンドが特定のノードのUNKNOWNの値を戻す場合、CVUではチェックに成功したか失敗したかは判別できません。
   次のどの理由で失敗したかを判別します。

   • ノードが停止している。

   • CRS_home/binディレクトリまたはOracle_home/binディレクトリにCVUが必要とする実行可能ファイルが存在しない。

   • CVUを実行したユーザー・アカウントに対して、ノード上の一般的なオペレーティング・システム実行可能ファイルを実行する権限が付与されていない。

   • オペレーティング・システム・パッチまたは必要なパッケージがノードに適用されていない。

   • そのノードのカーネル・パラメータが正しく構成されていないため、チェックの実行に必要なオペレーティング・システム・リソースをCVUが取得できない。

関連項目:

• Oracle RAC環境における構成の問題のトラブルシューティング

• クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

10.1.1.2 Oracle Clusterwareコンポーネントの整合性の検証

CVUのcomp crsコマンドを使用して、すべてのOracle Clusterwareコンポーネントの存在を確認します。

Oracle Clusterwareコンポーネントの整合性を検証するには、次の手順を実行します。

1. コマンド・ウィンドウで、Oracle Clusterwareソフトウェア・インストールを所有するユーザーとしてオペレーティング・システムにログインします。
2. 次の構文でCVUのcomp crsコマンドを使用します。

   cluvfy comp crs [ -n node_list] [-verbose]
   

   node_listはチェックするノードを表します。

関連項目:

• クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

10.1.1.3 Oracle Cluster Registryの整合性の検証

CVUのcomp ocrコマンドを使用して、Oracle Clusterwareレジストリの整合性を検証します。

Oracle Clusterwareレジストリの整合性を検証するには、次の手順を実行します。

1. コマンド・ウィンドウで、Oracle Clusterwareソフトウェア・インストールを所有するユーザーとしてオペレーティング・システムにログインします。
2. 次の構文でCVUのcomp ocrコマンドを使用します。

   cluvfy comp ocr [ -n node_list] [-verbose]
   

   node_listはチェックするノードを表します。

関連項目:

• クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

10.1.1.4 クラスタ全体の整合性の検証

CVUのcomp cluコマンドを使用して、クラスタ内のすべてのノードにクラスタ構成の同一ビューがあるかチェックします。

クラスタの整合性を検証するには、次の手順を実行します。

1. コマンド・ウィンドウで、Oracle Clusterwareソフトウェア・インストールを所有するユーザーとしてオペレーティング・システムにログインします。
2. 次の構文でCVUのcomp cluコマンドを使用します。

   cluvfy comp clu [-verbose]
   

関連項目:

• クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

• Oracle RACデータベースのインストールの検証

10.1.1.5 インターコネクトの設定のチェック

CVUのcomp nodereachまたはcomp nodeconコマンドを使用して、インターコネクトの設定をチェックします。

キャッシュ・フュージョンは、高速インターコネクトを使用してデータ・ブロックを別のインスタンスのバッファ・キャッシュに送ることにより、Oracle RACのパフォーマンスを強化します。最大限のパフォーマンスを得るために、高速インターコネクトは帯域幅が最も高いプライベート・ネットワークである必要があります。

ネットワーク接続の検証では、CVUコマンドラインでインタフェースを指定しない場合、すべての使用可能なネットワーク・インタフェースが検出されます。

相互接続の設定をチェックするには、次の手順を実行します。

1. コマンド・ウィンドウで、Oracle Clusterwareソフトウェア・インストールを所有するユーザーとしてオペレーティング・システムにログインします。
2. node_listで指定したクラスタ・ノードのアクセス可能性を検証するには、次のようなコンポーネント検証コマンドnodereachを使用します。srcnodeで指定するとローカル・ノードまたは別のクラスタ・ノードで検証できます。

   cluvfy comp nodereach -n node_list [ -srcnode node ] [-verbose]
   

3. node_listに指定したノード間の接続性を、ローカル・ノードまたは任意の他のクラスタ・ノードから使用可能なネットワーク・インタフェースを介して検証するには、次の例に示すようにcomp nodeconコマンドを使用します。

   cluvfy comp nodecon -n node_list -verbose
   

   前述の例で示されるように、nodeconコマンドを発行すると、CVUは次のタスクを実行するように指示されます。

   • 指定したクラスタ・ノード上で使用可能なすべてのネットワーク・インタフェースの検出

   • インタフェースに対応したIPアドレスおよびサブネットの確認

   • VIPとしての使用に適したインタフェースのリストおよびプライベート・インターコネクトのインタフェースのリストの取得

   • これらのインタフェースを介したすべてのノード間の接続性の検証

   冗長モードでnodeconコマンドを実行して、インタフェース、IPアドレスおよびサブネット間のマッピングが識別できます。

4. 特定のネットワーク・インタフェースを介したノード間の接続性を検証するには、-iオプションのあるcomp nodeconコマンドを使用して、interface_list引数によってチェックされるインタフェースを指定します。

   cluvfy comp nodecon -n node_list -i interface_list [-verbose]
   

   たとえば、次のコマンドを実行して、特定のネットワーク・インタフェースeth0を介してracnode1、racnode2およびracnode3ノード間の接続性を検証できます。

   cluvfy comp nodecon -n racnode1,racnode2,racnode3 -i eth0 -verbose
   

関連項目:

• 「ネットワークの構成」

• クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

10.1.1.6 トレースの有効化

トレースを有効にしないかぎり、CVUはトレース・ファイルを生成しません。

デフォルトではCVUトレース・ファイルはORACLE_BASE/crsdata/host_name/cvuディレクトリに作成されます。ログ・ファイルは自動的にローテーションされ、最新のログ・ファイルの名前はcvutrace.log.0になります。必要に応じて不要なログ・ファイルを削除またはアーカイブしてディスク領域を解放する必要があります。

CVUを使用したトレースを有効にするには、次の手順を実行します。

1. コマンド・ウィンドウで、rootユーザーとしてオペレーティング・システムにログインします。
2. 環境変数SRVM_TRACEをtrueに設定します。

   # set SRVM_TRACE=true; export SRVM_TRACE
   

3. コマンドを実行してトレースします。

関連項目:

トレースの有効化の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

10.1.2 ORAchk

自律型ヘルス・フレームワークの一部として、ORAchkはデーモン・モードで稼働するように構成されます。ORAchkは、既知の問題がないか様々な製品を事前にスキャンし、それらの問題について自律的にレポートします。

ORAchkは、広く使用されているRACcheckツールにかわるもので、ユーザーがレポートした上位の問題の優先順位付けに基づいて適用範囲が拡張されています。ORAchkは、調査および分析の一元管理のために、結果をコレクション・マネージャ・リポジトリにアップロードするように構成できます。

ORAchkを最大限に活用するために、ORAchkを(パスワードまたはSUDOによって)rootユーザーとして実行することをお薦めします。

• Oracle ORAchkの概要
  Oracle ORAchkは、ソフトウェア・コンポーネントおよびハードウェア・コンポーネントのOracleスタック用の軽量で非侵入型のヘルス・チェック・フレームワークです。
• ORAchkの実行
  ORAchkは、定期的に実行するようにスケジュールすることも、必要に応じて実行することもできます。
• ORAchkのHTMLレポート出力
  Oracle ORAchkでは、結果および推奨事項が含まれる詳細なHTMLレポートが生成されます。

10.1.2.1 Oracle ORAchkの概要

Oracle ORAchkは、ソフトウェア・コンポーネントおよびハードウェア・コンポーネントのOracleスタック用の軽量で非侵入型のヘルス・チェック・フレームワークです。

Oracle ORAchkは、バリュー・アドオンとして既存のサポート契約に規定されます。Oracle ORAchkの実行に追加の料金またはライセンスは必要ありません。

ORAchkの機能

• 業務に影響する前にリスクを特定して事前に通知することを自動化します。

• Oracleカスタマ・ベースで繰り返し発生する重大な問題に基づいてヘルス・チェックを実行します。

• オラクル社に何も送信する必要なしに、ご使用の環境で稼働します。

• 電子メールのヘルス・チェック・レポートをスケジュールできます。

• 結果を他の選択したツールと統合します。

Oracle ORAchkの有効範囲は新しいリリースで拡大します。現在の有効範囲は次のとおりです。

Oracle Database

• 単一インスタンスのOracle Database

• Oracle Grid InfrastructureおよびOracle RAC

• 最大可用性アーキテクチャ(MAA)の検証

• アップグレード対応の検証

• Oracle GoldenGate

• アプリケーション・コンティニュイティ

Enterprise Manager Cloud Control (12cのみ)

• 管理リポジトリ

• 管理エージェント

• Oracle Management Service (OMS) (リリース12.1.0.1以降、Linuxのみ)

Oracle Hardware Systems

• Oracle Solaris

• Oracle Solaris Cluster

• Oracle MiddlewareおよびOracle ApplicationsのOracle Systemsの構成

• Oracle ZFS Storage Appliance

• Oracle Virtual Networking

10.1.2.2 ORAchkの実行

ORAchkは、定期的に実行するようにスケジュールすることも、必要に応じて実行することもできます。

デーモン・プロセスを使用して、一定の間隔で繰り返すヘルス・チェックをスケジュールすることをお薦めします。

次の目的を満たすようにデーモンを構成します。

• 一定の間隔で繰り返すヘルス・チェックをスケジュールする。

• ヘルス・チェックの実行が完了したら、前回の実行からの相違点をわかりやすく表示した電子メール通知を送信する。

• 事前に定義した期間の経過後に、収集結果をパージする。

• 失効パスワードをチェックして電子メール通知を送信する。

• 自動化されたヘルス・チェックの実行について複数のプロファイルを格納する。

• デーモンが稼働しているサーバーまたはノードの再起動時に自動的に再起動する。

次のシナリオでは、ヘルス・チェックをオンデマンドで実行することをお薦めします。

• アップグレード前またはアップグレード後

• サブネット間でのマシンの移動

• ハードウェアの障害または修復

• 問題のトラブルシューティング

• 稼働テストに追加する場合

1. ヘルス・チェックをオンデマンドで実行する場合は、他のユーザーが起動したデーモン・プロセスを使用しないでください。デーモンを起動したのと同じディレクトリ内で、オンデマンドのヘルス・チェックを実行します。

   $ ./orachk
2. ヘルス・チェックをスケジュールする場合は、次のようにします。
   1. -setオプションを使用してデーモンのプロパティを設定します。

      少なくとも、AUTORUN_SCHEDULEとNOTIFICATION_EMAILを設定します。

      たとえば、毎日曜日午前3時に実行し、結果を[e-mail]に電子メール送信するようにツールを設定するには、次のコマンドを実行します。

      $ ./orachk –set “AUTORUN_SCHEDULE=3 * * 0 ;NOTIFICATION_EMAIL=[e-mail]”

   2. 「自動化されたデーモン・モード操作」の説明に従ってヘルス・チェック・デーモンを構成します。
   3. root (推奨)か、Oracle DatabaseまたはOracle Grid Infrastructureのホーム所有者としてデーモンを起動します。

      $ ./orachk –d start

   4. 起動時にプロンプト表示された質問に回答します。

Oracle ORAchkでは、結果および推奨事項が含まれる詳細なHTMLレポートが生成されます。

最初の電子メール通知の後に実行されるヘルス・チェックにおいて、デーモンは、現在の実行と直近の実行の差分レポートをNOTIFICATION_EMAILリストに指定されたすべてのユーザーに電子メール送信します。

電子メール通知のメッセージには、次の情報が含まれます。

• 前回と比較したこの実行のシステム・ヘルス・スコア。

• 実行されたチェック数のサマリーと前回との差。

• 最新レポートの結果(添付ファイル)。

• 前回レポート結果(添付ファイル)。

• 差分レポート(添付ファイル)。

関連項目:

ORAchkの使用および構成の詳細は、『Oracle Autonomous Health Frameworkユーザーズ・ガイド』を参照してください。

10.1.2.3 ORAchkのHTMLレポート出力

Oracle ORAchkでは、結果および推奨事項が含まれる詳細なHTMLレポートが生成されます。

ヘルス・チェックのHTMLレポートには、次の情報が含まれます。

• おおよそのヘルス・スコア。

• 実行のサマリー。

• 結果に簡単にアクセスできる目次。

• 結果と、問題を解決するための推奨事項。

システム・ヘルス・スコアとサマリー

Oracle ORAchkでは、合格または不合格のチェック数に基づいてシステム・ヘルス・スコアが概算されます。実行のサマリーには、次の情報が表示されます。

• クラスタ名

• オペレーティング・システムおよびソフトウェアのバージョン

• EMエージェントのホーム・ディレクトリ

• クラスタ情報 - ノード数、データベース・サーバー数、ストレージ・サーバー数およびIBスイッチ数

• ORAchkのバージョン

• コレクション・ファイルの名前

• ORAchk実行の期間

• ORAchkを起動したユーザー

• ORAchkの実行日

HTMLレポートの目次と機能

目次には、HTMLレポート内の各主要セクションへのリンクがあります。

レポート機能を使用すると、次の操作が可能です。

• ステータスに基づいたチェックのフィルタ処理。

• リージョンの選択。

• すべてのチェックの展開/折畳み。

• チェックIDの表示。

• レポートからの結果の削除。

• 印刷可能なビューの取得。

HTMLレポートの結果

レポートの結果は、Oracle Stackコンポーネントごとにグループ分けされます。結果には、次の情報が含まれます。

• チェックのステータス(FAIL、WARNING、INFOまたはPASS)。

• チェックのタイプ。

• チェックのメッセージ。

• チェックの実行場所。

• さらに結果および推奨事項の詳細を開くためのリンク。

いずれの結果についても、「View」をクリックすると結果および推奨事項を表示でき、次のような情報が含まれます。

• 問題を解決するためのソリューション。

• 適用できる推奨事項。

• 問題が当てはまらない場所。

• 関連ドキュメントまたはMy Oracle Supportノートへのリンク。

• 推奨事項が基づいているデータの例

Maximum Availability Architecture (MAA) Scorecard

「Maximum Availability Architecture (MAA) Scorecard」は、「Findings」グループの後に表示されます。

MAAスコアカードは、最大可用性アーキテクチャの一連のベスト・プラクティスです。最新でないソフトウェアがないかチェックされたインストール済のソフトウェア・バージョン、互換性のない機能の使用など、最大可用性に関する結果も表示されます。

Findings needing further review

ヘルス・チェックに部分的なビューしかなく、関係があるかどうか判別するためにユーザーの確認を必要とする問題が、「Findings needing further review」セクションに表示されます。

Platinum Certification

「Platinum Certification」セクションには、Oracle Platinum Servicesのコンプライアンス・ステータス項目のリストが表示されます。既存のPlatinumの顧客の場合、これはレビューです。Oracle Platinumにまだ参加していない顧客の場合は、Oracle Platinumに参加する準備が整っていることを示します。

Clusterwide Linux Operating system Health Check (VMPScan)

VMPScanレポートのサマリーがレポートの「Clusterwide Linux Operating system Health Check (VMPScan)」セクションに表示されます。

完全なVMPScanレポートもcollection/reports and collection/outfiles/vmpscanディレクトリ内で入手できます。

File Attribute Changes

「File Attribute Changes」セクションは、–fileattrオプションを指定してOracle ORAchkを実行した場合のみレポートに表示されます。

Skipped Checks

なんらかの理由で実行できずにスキップされたチェックが「Skipped Checks」セクションに表示されます。

Component Elapsed Times

「Component Elapsed Times」では、各種コンポーネントのチェックに要した時間の内訳がわかります。

これは、パフォーマンス問題を診断する際に使用すると便利です。

Top 10 Time Consuming Checks

「Top 10 Time Consuming Checks」セクションには、実行されたチェックのうち最も遅い上位10チェックが表示されます。

これは、パフォーマンス問題を診断する際に使用すると便利です。

10.1.3 クラスタ状態モニター

クラスタ状態モニターは、Oracle Grid Infrastructureに統合されています。クラスタ状態モニターは、パフォーマンスを向上させ、CPU使用のオーバーヘッドを削減するために、オペレーティング・システムAPIを使用してオペレーティング・システム統計を収集します。

クラスタ状態モニターは、メモリーおよびスワップ領域の使用量、プロセス数、IO使用量、ネットワーク関連データなど、オペレーティング・システム統計(システム・メトリック)を収集します。クラスタ状態モニターの情報収集はリアルタイムで(通常は1秒に1回)行われます。クラスタ状態モニターは、実行可能なかぎり多くのシステム・メトリックおよびデータを収集しますが、これはツールによるリソース消費の許容レベルによって制限されます。

クラスタ状態モニターでは、ノードの再起動、インスタンスの削除、サーバーのハング、重大なパフォーマンスの低下、システム・メトリックおよびデータを必要とするその他の問題など、多種多様な問題をトラブルシューティングするためのシステム・メトリックおよびデータを提供します。データを常に監視することで、ユーザーはクラスタ状態モニターを使用して、問題によって望ましくない停止が引き起こされる前に、潜在的な問題領域(CPUロード、メモリー制約、スピン中のプロセスなど)を検出できます。

クラスタ状態モニターによって収集された情報は、グリッド・インフラストラクチャ管理リポジトリ(GIMR)に格納されます。GIMRは、診断データおよびパフォーマンス・データ用の一元管理されたインフラストラクチャ・データベースで、Gridホームにあります。これは、単一インスタンスのマルチテナント・データベースで、プラガブル・データベース(PDB)が1つ含まれます。パーティショニングが(データ・ライフサイクル管理用に)組み込まれています。GIMRクライアントには、クラスタ状態モニター、高速ホーム・プロビジョニング、Enterprise Manager Cloud Controlおよびトレース・ファイル・アナライザがあります。クラスタ状態モニターは、オペレーティング・システムのメトリック・データをすべてGIMRに格納します。高速ホーム・プロビジョニングは、サービスの提供先となる各データベース・ホームに関するメタデータの維持にGIMRを使用します。Enterprise Manager Cloud Controlおよびトレース・ファイル・アナライザは、GIMRからデータ(主にクラスタ状態モニターのデータ)を取得します。

diagcollection.plまたはoclumonを使用して、クラスタ状態モニターによって収集された情報を確認できます。

• diagcollection.pl: gridユーザーとして、コマンドGrid_home/bin/diagcollection.pl --collect --chmosを使用すると、リポジトリ内の収集された全データについて出力が生成されます。大量のデータが存在する可能性があるため、この操作は長時間かかることがあります。問合せを目的の期間に限定することをお薦めします。

  Grid_home/bin/diagcollection.pl --collect --crshome Grid_home 
    --chmos --incidenttime start_time --incidentduration 05:00

  前述のコマンドは、incidenttimeで指定した時間から5時間分を網羅したレポートを生成します。incidenttimeの形式は、MM/DD/YYYYHH:MN:SSとする必要があります(MMは月、DDは日付、YYYYは年、HHは24時間形式の時間、MNは分、SSは秒です)。たとえば、インシデント時刻を2016年6月1日の午後10時15分にする場合、インシデント時刻は06/01/201622:15:00となります。incidenttimeおよびincidentdurationを変更して、取得するデータの量を増やすこともできます。

• oclumon: なんらかの理由でdiagcollection.plが失敗した場合は、かわりにコマンドoclumon dumpnodeview -allnodes -v -last "11:59:59" > output-filenameを使用できます。このコマンドは、最大過去12時間のリポジトリからレポートを生成できます。-last値を変更して、取得するデータ量を増減できます。

10.1.4 Cluster Health Advisor

Cluster Health Advisorデーモンは、Oracle Real Application Clusters (Oracle RAC)、Oracle RAC One Nodeデータベース、ホストのオペレーティング・システムおよびハードウェア・リソースからデータを収集し、データベースまたはホストのパフォーマンス問題を検出した後に根本原因と処置を分析して示します。

ユーザーは、予測分析データ・セットの作成元となるデータを生成するために、測定プロセスを開始できます。すると、異常な状態が発生して進行中であるかどうかを、根本原因、詳細および修正処理とともに調べるために、この基本運用モデルが5秒おきに評価されます。このデータ・エビデンスは、Oracle Enterprise Manager Cloud Controlにレポートするために、グリッド・インフラストラクチャ管理リポジトリ・データベースで保持されます。

Cluster Health Advisorデーモンでは、システム管理者およびデータベース管理者に、Oracle RACデータベースとクラスタ・ノードに関する保留中のパフォーマンスの問題、根本原因および修正処理について早期に警告します。この高度な事前診断機能により、可用性およびパフォーマンスの管理が向上します。

Oracle RACシステムのオンライン状態を追跡するため、Cluster Health Advisorは、システムの測定値(稼働中システムの動作状態のサンプルとして取得)を分析し、設定された正常なベース・ライン内に測定値が収まっているのかどうか、あるいは異常に変動して許容限度を超えているかどうかを検出します。Cluster Health Advisorが測定値のいずれかで異常を検出した場合、インシデント診断エンジンを起動して根本的な問題を同定し、インシデントの詳細を生成します。分析サイクルは、新しくサンプリングされた一連の測定値で定期的に繰り返し、システムのヘルス・ステータスを経時的に追跡します。

Cluster Health Advisorの結果を表示するには、次のものを使用できます: グラフィカル・インタフェースとコマンドライン・インタフェースがあります。グラフィカル・インタフェースには次のものがあります。

• グラフィカル・インタフェース

  • Enterprise Manager Cloud Control

  • Cluster Health Advisorの分析を表すことに特化されたスタンドアロンのコンソール

• コマンドライン・インタフェース - CHACTL

例10-1 CHACTLを使用したCluster Health Advisorの結果の確認

CHACTLを使用してCluster Health Advisorの結果を確認する例を次に示します。

$ chactl query diagnosis –start start_time -end end_time 
10:05:15      	Database A	    Disk Failure   (instance1) [detected]
				                      Storage Bandwidth Saturation (instance 1) [detected]
10:05:30        Database A     Disk Failure (instance 1)  [cleared]
                               Storage Bandwidth Saturation (instance 2) [detected]
                               Storage Bandwidth Saturation (instance 1) [cleared]
		           Database B      Storage Bandwidth Saturation (instance 1 )
		           Host A		       Disk Failure

10.1.5 トレース・ファイル・アナライザ・コレクタ

トレース・ファイル・アナライザは、診断情報の収集を一元管理して自動化します。

• トレース・ファイル・アナライザ・コレクタ(tafctl)について
  トレース・ファイル・アナライザ・コレクタ(TFA)は、Oracle Grid Infrastructureシステム、Oracle RACシステムおよび単一インスタンスのOracle Databaseシステムでの診断データの収集を簡素化する診断収集ユーティリティです。
• tfactlコマンドの概要
  tfactlは、トレース・ファイル・アナライザ・コレクタ(TFA)ユーティリティを管理するためのコマンドライン・インタフェースです。
• tfactlを使用した特定期間の診断ログの収集
  TFAのdiagcollectionモジュールには、様々なパラメータを取って、必要なエビデンス・セットがどの程度の量かまたはどの程度詳しいかをユーザーが制御できるようにする機能があります。

10.1.5.1 トレース・ファイル・アナライザ・コレクタ(tafctl)について

トレース・ファイル・アナライザ・コレクタ(TFA)は、Oracle Grid Infrastructureシステム、Oracle RACシステムおよび単一インスタンスのOracle Databaseシステムでの診断データの収集を簡素化する診断収集ユーティリティです。

TFAは、診断データを収集してパッケージ化するという点では、Oracle Grid Infrastructureに同梱されたdiagcollectionユーティリティに似ています。ただし、TFAは、diagcollectionよりもずっと強力で、診断情報の収集を一元理管理して自動化する機能を備えています。

TFAコレクタの機能は、次のとおりです。

• 診断データ収集の簡素化

• 単一コマンドによるクラスタ全体での全コンポーネントに関する診断データ収集の実行

• インシデント時刻前後の情報のみが含まれるようにする診断ファイルの切捨て

• 単一ノードでの収集済診断データの統合

TFAは、クラスタの各ノードまたはGrid Infrastructureがインストールされていない単一ノードで稼働します。TFAは、デーモンおよびコマンドライン・インタフェース(CLI)で構成されます。TFAデーモンは、デフォルトでは構成済のノードで常に稼働するJava仮想マシン(JVM)であり、TFAMainとして識別できます。CLIは、コマンドをTFAMainセキュア・ソケットおよびperlスクリプトtfactlに送信するJavaコマンドライン・プロセッサで構成されます。

TFAがインストーラを使用してOracle Grid Infrastructureとともにインストールされ、構成されていても、通常のパッチ・セット更新を使用するか、My Oracle Supportから最新のTFAをダウンロードしてパッチを適用できます。

インストールが完了すると、TFAMain JVMは構成内の各ノードで稼働し、インベントリ・プロセスを実行して見つかったトレース・ディレクトリ内でファイルを検出します。インベントリ・プロセスでは、このようなディレクトリ内のすべてのファイルについて最初と最後のタイムスタンプの他、ファイル・タイプも調べます。検出されたアラート・タイプのファイルは、重要なイベントがないか常に監視され、そのようなイベントが発生した場合、TFAは自動的に関連する診断データを収集できます(構成されている場合)が、いつでも手動による収集を開始することもできます。アラート・タイプのファイルは、CRS、ASMおよびRDBMSのアラート・ログです。デフォルトでは、自動診断データ収集は無効になっています。

10.1.5.2 tfactlコマンドの概要

tfactlは、トレース・ファイル・アナライザ・コレクタ(TFA)ユーティリティを管理するためのコマンドライン・インタフェースです。

ファイル・パス

TFAを管理するには、tfactlをOracle_base/binディレクトリから実行でき、rootユーザーまたはTFAを実行する権限を付与されたその他のユーザーとして実行できます。root以外のユーザーは、診断データ収集を実行するコマンドまたは所有するディレクトリを収集に使用できるようにするコマンドのみを実行できます。tfactlを実行するsudoアクセス権がユーザーに付与されている場合は、すべてのコマンドにアクセスできます。

構文

tfactl command [options]

tfactlコマンド

コマンド	説明
diagcollect	TFAで収集される情報のタイプを指定します
collection	TFAコレクションを管理します
analyze	過去の指定期間中に発生したデータベースまたはクラスタウェアのアラート・ログでパターンを検索します。デフォルトの期間は1時間です。
ips	トレース・ファイル・パッケージの内容を作成して管理します
run	指定のTFAサポート・ツールを実行します
start tool	TFAを起動します。ツールが指定されている場合は、指定のツールを起動します。
stop tool	TFAを停止します。ツールが指定されている場合は、指定のツールを停止します。
enable	TFAの自動起動を有効にします
disable	TFAの自動起動を無効にします
status	TFAプロセスの実行ステータスをチェックします
print	リクエストされた詳細を印刷します
access	TFAのユーザーおよびグループを追加、削除またはリストします
purge	TFAリポジトリからコレクションを削除します
directory	TFAでディレクトリを追加、削除または変更します
host	TFAでホストを追加または削除します
set	各種TFA機能をオン、オフまたは変更します
toolstatus	TFAサポート・ツールのステータスを印刷します
uninstall	ローカル・ノードからTFAをアンインストールします
diagnosetfa	TFA診断データを収集します

関連項目:

各コマンドで使用可能なオプションの詳細リストは、My Oracle Supportノート: 「TFA Collector - TFA with Database Support Tools Bundle」(ドキュメントID 1513912.1)を参照してください

10.1.5.3 tfactlを使用した特定期間の診断ログの収集

TFAのdiagcollectionモジュールには、様々なパラメータを取って、必要なエビデンス・セットがどの程度の量かまたはどの程度詳しいかをユーザーが制御できるようにする機能があります。

この例では、-fromスイッチと-toスイッチをtfactl diagcollectコマンドに使用して、4月2日午前0時から4月2日午後1時の間で、すべてのタイプの診断ログを収集するようにTFAに指示します。このコマンドは、指定の診断データ収集をすべてのクラスタ・ノードで起動し、TFAが起動されたノードで$TFA_HOME/repositoryディレクトリ内の各ノードのzipファイルに結果を格納します。

[oracle@docrac1 ~]# ./tfactl diagcollect -from "Apr/02/2016" -to "Apr/02/2016 13:00:00"
Collecting data for all nodes
Scanning files from Apr/02/2016 00:00:00 to Apr/02/2016 13:00:00

Collection Id : 20160402160419racnode1

Repository Location in docrac1 : /u01/app/oracle/tfa/repository
2016/04/02 15:04:21 EDT : Collection Name : tfa_Thu_Apr_2_15_04_19_EDT_2016.zip
2016/04/02 15:04:21 EDT : Sending diagcollect request to host : cehaovmsp102
2016/04/02 15:04:22 EDT : Scanning of files for Collection in progress...
2016/04/02 15:04:22 EDT : Collecting extra files...
2016/04/02 15:04:32 EDT : Getting list of files satisfying time range [04/02/2014 00:00:00 EDT, 04/02/2014 13:00:00 EDT]
2016/04/02 15:04:32 EDT : Starting Thread to identify stored files to collect
2016/04/02 15:04:32 EDT : Getting List of Files to Collect
2016/04/02 15:04:32 EDT : Trimming file : docrac1/u01/app/11.2.0/grid/log/docrac1/alertdocrac1.log with original file size : 9.7MB
2016/04/02 15:04:32 EDT : Trimming file : docrac1/u01/app/11.2.0/grid/log/docrac1/client/oifcfg.log with original file size : 1.2MB
2016/04/02 15:04:32 EDT : Trimming file : docrac1/u01/app/11.2.0/grid/log/docrac1/crfmond/crfmond.log with original file size : 3.4MB
2016/04/02 15:04:32 EDT : Trimming file : docrac1/u01/app/11.2.0/grid/log/docrac1/evmd/evmd.log with original file size : 3.2MB
2016/04/02 15:04:32 EDT : Trimming file : docrac1/u01/app/11.2.0/grid/log/docrac1/gpnpd/gpnpd.log with original file size : 608kB
2016/04/02 15:04:35 EDT : Trimming file : docrac1/rdbms/orcl/ORCL1/trace/alert_ORCL1.log with original file size : 1.4MB
2016/04/02 15:04:35 EDT : Finshed Getting List of Files to Collect
2016/04/02 15:04:35 EDT : Trimming file : docrac1/tnslsnr/docrac1/listener_scan1/trace/listener_scan1.log with original file size : 83MB
2016/04/02 15:04:35 EDT : Trimming file : docrac1/asm/+asm/+ASM1/trace/alert_+ASM1.log with original file size : 623kB
2016/04/02 15:04:35 EDT : Collecting ADR incident files...
2016/04/02 15:04:35 EDT : Waiting for collection of extra files
2016/04/02 15:05:10 EDT : Completed collection of extra files...
2016/04/02 15:05:10 EDT : Completed Zipping of all files
2016/04/02 15:05:10 EDT : Cleaning up temporary files
2016/04/02 15:05:10 EDT : Finished Cleaning up temporary files
2016/04/02 15:05:10 EDT : Finalizing the Collection Zip File
2016/04/02 15:05:11 EDT : Finished Finalizing the Collection Zip File
2016/04/02 15:05:11 EDT : Total Number of Files checked : 17168
2016/04/02 15:05:11 EDT : Total Size of all Files Checked : 2.3GB
2016/04/02 15:05:11 EDT : Number of files containing required range : 29
2016/04/02 15:05:11 EDT : Total Size of Files containing required range : 104MB
2016/04/02 15:05:11 EDT : Number of files trimmed : 8
2016/04/02 15:05:11 EDT : Total Size of data prior to zip : 1.3MB
2016/04/02 15:05:11 EDT : Saved 103MB by trimming files
2016/04/02 15:05:11 EDT : Zip file size : 121kB
2016/04/02 15:05:11 EDT : Total time taken : 49s
2016/04/02 15:05:11 EDT : Remote Collection in Progress...
2016/04/02 15:05:22 EDT : cehaovmsp102:Completed Collection
2016/04/02 15:05:22 EDT : Completed collection of zip files.

Logs are being collected to: /u01/app/oracle/tfa/repository/collection_Thu_Apr_2_15_04_19_EDT_2016_node_all
/u01/app/oracle/tfa/repository/collection_Thu_Apr_2_15_04_19_EDT_2016_node_all/docrac1.tfa_Thu_Apr_2_15_04_19_EDT_2016.zip
/u01/app/oracle/tfa/repository/collection_Thu_Apr_2_15_04_19_EDT_2016_node_all/cehaovmsp102.tfa_Thu_Apr_2_15_04_19_EDT_2016.zip

10.1.6 ハング・マネージャ

ハング・マネージャは、ハングしたデータベース・セッションを確実に検出して、適時に解決できます。

ハング・マネージャがアクティブになるのは、Oracle RACが有効になっている場合のみです。CLUSTER_DATABASE初期化パラメータを問い合せると、Oracle RACデータベースが使用されている(有効になっているか)どうかを判断できます。このパラメータがTRUEに設定されている場合、Oracle RACはそのデータベースで有効になっています。

Oracle Database 11g リリース2 (11.2.0.2)以降、ハング・マネージャでは、原因となるセッションまたはプロセスを終了することで検出されたハングを解決できます。デフォルトでは、ハング・マネージャは、インスタンスの終了もノードの削除も実行しません。ハング・マネージャは、検出されたハングをすべて解決するわけではありません。たとえば、アプリケーション問題が含まれる可能性があるハングは、正しい処理方針を決定するためにユーザーに任されます。また、ハングの原因が存在するインスタンスでCPUまたはIOのロードが高いことがハング・マネージャで判明した場合は、ハングの解決は先送りされます。これにより、原因となるセッションまたはプロセスには、進行してハングが自然に解決する時間が与えられます。ハング・マネージャは、Oracle Databaseインスタンスでのハングのみを解決し、Oracle ASMインスタンスでのハングは一切解決しません。

Oracle Database 12c リリース1から、クラスタでOracle Database Quality of Service (QoS) Managementがアクティブである場合、ハング・マネージャでは、Oracle Database QoS Managementによって提供される追加情報を使用して、ハングを無視するか解決するか判別します。

ハング・マネージャがハングを解決すると、アラート・ログで確認できるORA-32701インシデントを送信します。アラート・ログ・メッセージは、次のようになります。

ORA-32701: Possible hangs up to hang ID=24 detected
Incident details in: /ee/oracle/oracle_base/diag/rdbms/orcl/orcl1/incident/incdir_1944098/orcl1_dia0_34930694_i1944098.trc
DIA0 terminating blocker (ospid: 28311778 sid: 3398 ser#: 1) of hang with ID = 24
     requested by master DIA0 process on instance 2
     Hang Resolution Reason: Automatic hang resolution was performed to free a
    critical database process.
     by terminating session sid:3398 with serial # 1 (ospid:28311778)

前述のメッセージには、解決されるハング(IDが24のハング)が記載されています。また、原因となるセッションID、シリアル番号、オペレーティング・システム・プロセスIDとそれが存在するインスタンスも示されています。最後に、そのハングが解決される理由について簡潔な理由が提示されています。この場合、通常のユーザー・セッションは重要なデータベース・プロセスをブロックしているため、ユーザー・セッションを終了して重要なデータベース・プロセスを実行できるようにします。

注意:

アラート・ログのORA-32701インシデントでは、ハング・マネージャに関連する問題があることが示されません。かわりに、原因となるセッションを終了することで解決されるハングがハング・マネージャで検出されたことが示されます。

次のデータ・ディクショナリ・ビューを問い合せることで、Hang Managerのアクティビティを監視できます。

• V$HANG_INFO: ハング・マネージャで検出されたアクティブなハングおよびデッドロックが含まれます。ハング・マネージャによって解決されたハングまたは自己解決したハングは含まれません。このビューには、直近32個のアクティブなハングのみが表示されます。

• V$HANG_SESSION_INFO: V$HANG_INFOビューに含まれるすべてのハングについて、メイン・チェーンのセッションが含まれます。ハングの原因を含め、ハングごとにメイン・チェーンの最初の20セッションのみがこのビューに保持されます。

• GV$HANG_STATISTICSまたはV$HANG_STATISTICS: 検出されたハングまたはデッドロックに関するハング・マネージャの様々な統計が含まれます。この統計には、検出されたハング数、検出されたデッドロック数、ハング・マネージャで解決したハング数、無視されたハング数(ハングを無視した理由別に分類)、自己解決したハング数などがあります。

10.1.7 データベース・サーバーのメモリー不足の管理

Memory Guardは、サーバー上のメモリー不足をリアルタイムで検出し、新しいセッションを他のサーバーにリダイレクトして、メモリーが不足しているサーバー上のすべての使用可能メモリーが使用されることを防ぎます。

オープン・セッションまたはランナウェイ・ワークロードが多すぎるため、エンタープライズ・データベース・サーバーが使用可能メモリーをすべて使用することがあります。メモリーが不足すると、トランザクションが失敗することがあります。極端な場合には、サーバーが再起動し、アプリケーションの貴重なリソースが失われることもあります。

新しいセッションを別のサーバーに再ルートすると、メモリーが不足しているサーバー上の既存のワークロードが保護され、サーバーを使用可能な状態に保つことができます。Memory Guardはサーバーのメモリー不足を管理するOracle RACの機能で、Oracle RACデータベースにホストされているアプリケーションのサービス・レベルの管理に新しいリソース保護機能を追加します。

Oracle Database Quality of Service Managementが有効になっていて、Oracle Clusterwareサーバー・プールを管理している場合、クラスタ状態モニターは、クラスタ・サーバーのメモリー・リソースに関するリアルタイム情報を提供するメトリック・ストリームをMemory Guardに送信します。この情報の内容は次のとおりです。

• 使用可能メモリーの量

• 現在使用されているメモリーの量

ノードのメモリーが不足しているとMemory Guardが判断した場合は、新しい接続が作成されないように、そのノード上のOracle Clusterwareで管理されているデータベース・サービスが停止されます。メモリー不足が緩和されると、そのノードのサービスが自動的に再開し、リスナーはそのサーバーへの新規接続の送信を開始します。メモリー不足は、いくつかの方法で緩和できます(たとえば、既存のセッションの終了やユーザーの介入など)。

10.1.8 Oracle Databaseのサービスのクオリティ管理

Oracle Database Quality of Service (QoS) Managementは、システム全体のワークロード・リクエストを監視する自動化されたポリシーベースの製品です。

Oracle Database QoS Managementは、アプリケーション間で共有されるリソースを管理し、システム構成を調整して、アプリケーションの実行をビジネスに必要なパフォーマンス・レベルに維持します。Oracle Database QoS Managementは、システム構成および要求で発生した変更に対応し、アプリケーションのパフォーマンス・レベルがそれ以上変動することを回避します。

Oracle Database QoS管理は、ターゲット・システムの各作業リクエストのパフォーマンスを監視します。Oracle Database QoS Managementは、作業リクエストがデータベース・サービスを使用してデータベースへの接続をリクエストした時点で作業リクエストの追跡を開始します。作業リクエストの完了に必要な時間、つまりレスポンス時間(エンドツーエンドのレスポンス時間またはラウンドトリップ時間とも呼ばれます)は、データのリクエストが開始された時点からデータ・リクエストが完了した時点までの時間です。レスポンス時間の2つの構成要素、つまりリソースの使用に費やした時間とリソースの使用の待機に費やした時間を正確に測定することで、Oracle Database QoS Managementはシステム内のボトルネックを迅速に検出できます。その後、Oracle Database QoS Managementは、ボトルネックを緩和してサービス・レベルを維持または復元するためのリソースの再割当てを提案します。

Oracle Database QoS Managementは、次の目的でシステムのリソースを管理します。

• 要求を満たすのに十分なリソースが使用可能な場合は、ワークロードが変化した場合でも、アプリケーションに対するビジネスレベルのパフォーマンス要件が満たされるようにします。

• 要求を満たすのに十分なリソースが使用可能でない場合、Oracle Database QoS Managementは重要度の低いパフォーマンス要件を犠牲にして、より重要度の高いビジネス・パフォーマンスを満たそうとします。

Oracle Database QoS Managementを使用する利点

一般的な企業では、アプリケーションのレスポンス時間が許容レベル内にない場合、問題の解決に非常に時間がかかることがあります。多くの場合、管理者が行う最初の質問は、「システムは正しく構成されているか。パラメータを変更して問題を解決できるか。ハードウェアの追加が必要か」です。残念ながら、これらの質問に正確に回答するのは非常に困難です。その結果、非生産的でフラストレーションの多い実験を何時間にもわたって行うことになります。

Oracle Database QoS Managementには次の利点があります。

• Oracle Real Application Clusters(Oracle RAC)リソースを管理するシステム管理者の時間と費用の要件が軽減されます。

• パフォーマンス低下の回数の削減に役立ちます。

• アプリケーションのパフォーマンスを制限または低下させる問題の解決に必要な時間を短縮します。

• ワークロードが変化したときでもシステムを安定させます。

• サーバーの追加または削除をアプリケーションに対して透過的にします。

• サーバー障害がシステムに与える影響を低減します。

• サービス・レベル合意(SLA)が満たされるようにします。

• ハードウェア・リソースをより効果的に共有できるようにします。

Oracle Database QoS Managementは、クラスタ内のアプリケーションによって共有されるリソースの管理に役立ちます。Oracle Database QoS Managementは、パフォーマンス・ボトルネックの識別と解決を支援できます。Oracle Database QoS Managementは、アプリケーションまたはデータベースのパフォーマンスの問題を診断またはチューニングしません。アプリケーションのパフォーマンスをチューニングする場合、目標は最適なパフォーマンスの実現です。Oracle Database QoS Managementはアプリケーションのより高速な実行を追求するのではなく、アプリケーションが最適なパフォーマンス・レベルで稼働することを妨げる障害を排除します。

関連項目:

Oracle Database Quality of Service Managementユーザーズ・ガイド

10.2 Enterprise Managerを使用したOracle Clusterwareの監視

Enterprise Managerを使用して、Oracle Clusterwareを監視できます。

Oracle Enterprise Managerで使用可能なその他の監視機能には、次のものがあります。

• クラスタの各ノードのOracle Clusterwareステータスの表示

• VIPが再配置された場合の通知の受信

• プライベート・インターコネクト全体に対するスループットの監視

• nodeappsが停止または起動した場合の通知の受信

• データベース・インスタンスがVIPではなくパブリック・インタフェースを使用している場合のアラートの表示

• OCRまたは投票ディスク関連の問題、ノードの削除、およびその他のクラスタウェア・エラーに関するクラスタウェア・アラート・ログの監視

Oracle Clusterwareリソースを監視し、個別コンポーネントに対してクラスタ・コンポーネントヘルスの監視を使用することもできます。リソースを監視するには、クラスタの「ホーム」ページの「管理」リンクをクリックします。個々のクラスタ・コンポーネントの状態を監視するには、クラスタの「ホーム」ページの「関連リンク」セクションで「すべてのメトリック」リンクをクリックします。

• Oracle Clusterwareの情報へのアクセス
  クラスタ・データベース・ホームページから、様々な方法でOracle Clusterwareの情報にアクセスできます。
• クラスタ・トポロジ・ページの表示
  Oracle Enterprise Managerのトポロジ・ビューアを使用すると、クラスタ内のターゲット・タイプ間の関係をビジュアル表示できます。
• Enterprise Managerからのクラスタ状態モニター・データの表示
  Oracle Enterprise Manager Cloud Controlを使用してクラスタ状態モニター(CHM)のデータを表示できます。

関連項目:

• Oracle Clusterwareインストールの検証について

• CRSCTLを使用したクラスタの問題の診断

10.2.1 Oracle Clusterwareの情報へのアクセス

クラスタ・データベースの「ホーム」ページから、様々な方法でOracle Clusterwareの情報にアクセスできます。

Oracle Clusterwareの情報にアクセスするには、次の手順を実行します。

1. Oracle Enterprise Managerのクラスタ・データベース・ホームページにアクセスします。

   Enterprise Managerへのログインの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

2. 「一般」セクションで「クラスタ」をクリックし、「クラスタ・ホーム」ページを表示します。
3. 「クラスタ・ホーム」ページの「診断サマリー」セクションで、「インターコネクト・アラート」の隣にある番号をクリックして、クラスタ用の「インターコネクト」サブページを表示します。

   あるいは、「クラスタ」メニューで、「インターコネクト」を選択して「インターコネクト」ページを表示します。

4. 「クラスタ」メニューで、「構成」を選択してから、「トポロジ」を選択します。グラフィック表示されたノードをクリックして、制御をアクティブにします。
5. 「インタフェース」コンポーネントをクリックします。インタフェース・コンポーネントを右クリックして、メニューから「詳細の表示」を選択してクラスタ用の「インターコネクト」ページを表示します。
6. 「クラスタ・ホーム」ページの「クラスタ・データベース」セクションで、クラスタ・データベースの名前を選択して、そのデータベースのクラスタ・データベース・ホームページに戻ります。

関連項目:

「クラスタ: トポロジ」ページの表示

10.2.2 「クラスタ: トポロジ」ページの表示

Oracle Enterprise Managerのトポロジ・ビューアを使用すると、クラスタ内のターゲット・タイプ間の関係をビジュアル表示することができます。

選択内容の詳細の拡大や縮小、パン、および確認が可能です。トポロジ・ビューアでは、システム・ターゲット・タイプを表すそれぞれ個別のアイコンと、すべてのターゲット・タイプに対して、選択範囲を囲むフレームなどの標準化されたビジュアル・インジケータが使用されます。

トポロジ・ビューアにより、システム構成に基づいてアイコンが移入されます。リスナーがインスタンスにサービスを提供している場合、リスナー・アイコンとインスタンス・アイコンが直線で結ばれます。クラスタ・データベースがOracle ASMを使用するように構成されている場合、トポロジにはクラスタOracle ASMとクラスタ・データベースの関係が次の図のように表示されます。

図10-1 Oracle Enterprise Managerの「クラスタ・トポロジ」ページ

「図10-1 Oracle Enterprise Managerの「クラスタ・トポロジ」ページ」の説明

「構成の詳細の表示」オプションの選択を解除した場合、トポロジにはアラートや全体的ステータスなどの一般情報を含む、環境の監視ビューが表示されます。「構成の詳細の表示」オプションを選択した場合、任意のトポロジ・ビューに有効な追加の詳細が「選択の詳細」ページに表示されます。たとえば、「リスナー」コンポーネントの場合は、コンピュータ名とポート番号も表示されます。

アイコンをクリックしてからマウスの右ボタンを使用すると、使用可能なアクションのメニューが表示されます。いくつかのアクションでは、ターゲット・タイプに関連するページに移動して、タスクの監視またはチューニングを実行できます。

このページの詳細は、Oracle Enterprise Managerのオンライン・ヘルプを参照してください。

10.2.3 Enterprise Managerからのクラスタ状態モニター・データの表示

Oracle Enterprise Manager Cloud Controlを使用してクラスタ状態モニター(CHM)のデータを表示できます。

クラスタ状態モニターのメトリック・データは、Enterprise Manager Cloud Control内ではグラフィック表示で使用できます。このデータの完全なクラスタ・ビューは、クラスタ・ターゲット・ページからアクセスできます。クラスタ全体に関する過去1日のCHMデータは概要形式で表示できます。グラフで表示されるメトリック・カテゴリは、「CPU」、「メモリー」および「ネットワーク」です。

各カテゴリは、その他のメトリックを表示して、さらに詳しく個別に表示できます。たとえば、「CPU」を選択すると、「CPUシステム使用率」、「CPUユーザー使用率」および「CPUキューの長さ」の詳細を示すクラスタ・グラフが表示されます。どのクラスタ・ビューからも、個々のノード・ビューを選択して単一サーバーのパフォーマンスをさらに綿密に調べることができます。CPUの場合と同様に、各コアのパフォーマンスが表示されます。いつでもカーソルをグラフに沿って移動すると、そのポイントの数値およびタイムスタンプを示すツールチップを表示できます。

現在の日のパフォーマンスを調べる以外に、履歴データを確認することもできます。履歴データの量は、グリッド・インフラストラクチャ管理リポジトリでCHMリポジトリに対して構成されている保存時間によって管理されます。デフォルトは72時間です。使用可能な履歴データを表示するには、「表示モード」ドロップダウン・メニューを使用して「履歴」を選択します。すると、過去の日付を入力するか、データが使用可能な日付が太字フォントで表示されるポップアップ・カレンダから選択することができます。「チャートの表示」を選択すると、選択したメトリックのグラフが表示されます。

1. Enterprise Managerでターゲット・クラスタを選択します。
2. 「クラスタ」メニューから、「クラスタのヘルス・モニタリング」を選択します。
   
   
   図em_chm_integration_menu.pngの説明
   
   「クラスタのヘルス・モニタリング」ページが表示されます。
3. グラフを表示します。過去のデータを表示するには、「表示モード」を「リアル・タイム」から「履歴」に変更し、表示する日付を選択します。
   
   
   図em_chm_integration_historical_graphs.pngの説明
   
4. チャート・タイプを「CPU」、「メモリー」または「ネットワーク」に変更すると、「CPUユーザー使用率」、「プライベート・ネットワークIO」、「空きスワップ・メモリーの割合」など、さらに詳細を表示できます。
5. 「ネットワーク」または「CPU」のメトリック・グラフを表示しているときに、ノード名をクリックすると、ネットワーク・インタフェース別のパブリック・ネットワークIOトラフィックや各コアのCPU使用率など、そのノードについてのみさらに詳細を表示できます。
   
   
   図em_chm_integration_network_node_graphs.pngの説明
   

10.3 Oracle RAC環境における構成の問題のトラブルシューティング

クラスタ・レディ・サービス・コントロール(CRSCTL)・コマンドのcheckを使用すると、複数のOracle Clusterwareコンポーネントのステータスを同時に判別できます。

Oracle Database管理ツールを使用せず、手動でインストールやデータベース作成プロセスを完了しようとすると問題が発生することがあります。また、データベース管理者やシステム管理者がオペレーティング・システムまたはクラスタの重要な構成手順をインストール前に行わなかったために発生する問題もあります。Oracle ClusterwareとOracle Databaseのコンポーネントはいずれも、トラブルシューティングできるサブコンポーネントを持っています。

• Oracle Clusterwareアラート・ログについて
  Oracle Clusterwareは、重要なイベントが発生すると、アラート・メッセージで通知します。たとえば、クラスタ・レディ・サービス(CRS)・デーモン・プロセスが起動した場合、中断された場合、フェイルオーバー・プロセスが失敗した場合、またはOracle Clusterwareリソースの自動再起動が失敗した場合などに、CRSデーモン・プロセスからのアラート・メッセージが表示されます。
• Oracle Clusterwareコンポーネント・ログ・ファイルについて
  Oracle Clusterware 12cリリース1 (12.1.0.2)以降、Oracle Clusterwareプログラムによって書き込まれる診断データ・ファイルは、トレース・ファイルと呼ばれ、.trcファイル拡張子が付けられて、Automatic Diagnostic Repository (ADR)ホームのtraceサブディレクトリにまとめられます。
• CRSCTLを使用したクラスタの問題の診断
  rootオペレーティング・システム・ユーザーとしてCRSCTLコマンドを使用すると、Oracle Clusterwareインストールの問題を診断したり、Oracle Clusterwareを動的にデバッグできます。
• Oracle RACデータベースのアラート・ログ・メッセージの表示
  アラート・ログは、クラスタ・データベース内の各インスタンスに作成されます。

関連項目:

• Oracle RACのインストール、構成および管理に使用するツール

• Oracle Clusterwareインストールの検証について

10.3.1 Oracle Clusterwareアラート・ログについて

Oracle Clusterwareは、重要なイベントが発生すると、アラート・メッセージを書き込みます。たとえば、クラスタ・レディ・サービス(CRS)・デーモン・プロセスが起動した場合、中断された場合、フェイルオーバー・プロセスが失敗した場合、またはOracle Clusterwareリソースの自動再起動が失敗した場合などに、CRSデーモン・プロセスからのアラート・メッセージが表示されます。

Oracle Enterprise Managerは、クラスタウェア・ログ・ファイルを監視し、エラーが検出されると「クラスタ: ホーム」ページにアラートを表示します。たとえば、投票ディスクが利用できない場合はCRS-1604エラーが発生し、「クラスタ・ホーム」ページにクリティカル・アラートが書き込まれます。「メトリックとポリシー設定」ページで、エラー検出とアラートの設定をカスタマイズできます。

最初にOracle Clusterwareアラート・ログで重大なエラーを探す必要があります。多くの場合、ここには特定のコンポーネントに関する詳細情報を提供する他の診断ログへの参照が含まれます。Oracle Clusterwareのログ・ファイルの場所は、ORACLE_BASE/diag/crs/hostname/crs/trace/alert.logです(ORACLE_BASEはOracle Grid Infrastructureのインストール時に指定したOracleベース・パス、hostnameはホストの名前です)。

関連項目:

• Oracle Clusterwareの診断およびアラート・ログ・データの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

• 「Enterprise Managerを使用したOracle Clusterwareの監視」

10.3.2 Oracle Clusterwareコンポーネント・ログ・ファイルについて

Oracle Clusterware 12cリリース1 (12.1.0.2)以降、Oracle Clusterwareプログラムによって書き込まれる診断データ・ファイルは、トレース・ファイルと呼ばれ、.trcファイル拡張子が付けられて、Automatic Diagnostic Repository (ADR)ホームのtraceサブディレクトリにまとめられます。

トレース・ファイルの他に、Oracle Clusterware ADRホームのtraceサブディレクトリには単純なテキストのOracle Clusterwareアラート・ログが含まれます。名前は常にalert.logです。アラート・ログは、ADRホームのalertサブディレクトリにXMLファイルとしても書き込まれますが、テキスト・アラート・ログは簡単に読むことができます。

関連項目:

Oracle Clusterware管理およびデプロイメント・ガイド

10.3.3 CRSCTLを使用したクラスタの問題の診断

rootオペレーティング・システム・ユーザーとしてCRSCTLコマンドを使用すると、Oracle Clusterwareインストールの問題を診断したり、Oracle Clusterwareを動的にデバッグできます。

• Oracle Clusterwareインストールのステータスのチェック
  Oracle Clusterwareコンポーネントまたはデーモンのステータスを表示するには、CRSCTLのcheckコマンドを使用します。
• Oracle Clusterwareコンポーネントのデバッグの有効化
  CRSCTLコマンドを実行して、Oracle Clusterデーモン、イベント・マネージャ(EVM)、およびそれらのモジュールのデバッグを有効にできます。
• Oracle Clusterwareリソースのデバッグの有効化
  CRSCTLコマンドを使用して、Oracle Clusterwareに管理されているリソースのデバッグを有効にします。
• Oracle Clusterwareデーモンの有効化
  Oracle Clusterwareのデーモンが有効な場合、ノードが起動したときに自動的に起動します。
• Oracle Clusterwareデーモンの無効化
  デーモンが自動的に起動しないようにするには、crsctlコマンドを使用して無効にします。

関連項目:

• Oracle RACのインストール、構成および管理に使用するツール

• Oracle Clusterware管理およびデプロイメント・ガイド

10.3.3.1 Oracle Clusterwareインストールのステータスのチェック

Oracle Clusterwareコンポーネントまたはデーモンのステータスを表示するには、CRSCTLのcheckコマンドを使用します。

Oracle Clusterwareインストールの状態を判別するには、次の手順を実行します。

1. コマンド・ウィンドウで、rootユーザーとしてオペレーティング・システムにログインします。
2. CRSCTLを使用し、次のコマンドを使用してOracle Clusterwareのステータスをチェックします。

   # crsctl check cluster -all
   

3. 次の構文を使用すると、個々のOracle Clusterwareデーモンのステータスをチェックできます。daemonは、crsd、cssdまたはevmdです。

   # crsctl check daemon
   

4. クラスタの任意のノードで実行されているすべてのOracle Clusterwareリソースのステータスをリストするには、次のコマンドを使用します。

   # crsctl status resource -t
   

   このコマンドはすべての登録済Oracle Clusterwareリソースのステータスをリストし、このリストには、VIP、リスナー、データベース、サービス、Oracle ASMインスタンスおよびディスク・グループが表形式で含まれます。

関連項目:

crsctl check cluster

10.3.3.2 Oracle Clusterwareコンポーネントのデバッグの有効化

CRSCTLコマンドを実行して、Oracle Clusterデーモン、イベント・マネージャ(EVM)、およびそれらのモジュールのデバッグを有効にできます。

Oracle Clusterwareコンポーネントのデバッグを有効化するには、次の手順を実行します。

1. コマンド・ウィンドウで、rootユーザーとしてオペレーティング・システムにログインします。
2. 次のコマンドを使用してコンポーネントのモジュール名を取得します。component_nameは、デバッグを有効にするcrs、evm、cssなどのコンポーネント名です。

   # crsctl lsmodules component_name
   

   たとえば、cssコンポーネントのモジュールの表示では、次のような結果が戻ります。

   # crsctl lsmodules css
   The following are the CSS modules :: 
   CSSD
   COMMCRS
   COMMNS
   

3. component_nameが、有効化するデバッグのOracle Clusterwareコンポーネントの名前で、moduleがモジュールの名前で、さらにdebugging_levelが1から5のいずれかの番号であり、次のようなCRSCTLを使用します。

   # crsctl set log component module:debugging_level
   

   たとえば、cssコンポーネントのCSSDモジュールの最下位レベルのトレースを有効化するには、次のコマンドを使用します。

   # crsctl set log css CSSD:1

関連項目:

『Oracle Clusterware管理およびデプロイメント・ガイド』

10.3.3.3 Oracle Clusterwareリソースのデバッグの有効化

CRSCTLコマンドを使用して、Oracle Clusterwareに管理されているリソースのデバッグを有効にします。

Oracle Clusterwareリソースのデバッグを有効にするには、次の手順を実行します。

1. コマンド・ウィンドウで、rootユーザーとしてオペレーティング・システムにログインします。
2. 次のコマンドを実行し、デバッグの対象にできるリソースのリストを取得します。

   # crsctl check crs
   

3. 次のコマンドを実行してデバッグを有効にします。resource_nameはora.racnode1.vipなどのOracle Clusterwareリソース名、debugging_levelは1から5のいずれかの数字です。

   # crsctl set log crs "resource_name:debugging_level"
   

関連項目:

『Oracle Clusterware管理およびデプロイメント・ガイド』

10.3.3.4 Oracle Clusterwareデーモンの有効化

Oracle Clusterwareのデーモンが有効な場合、ノードが起動したときに自動的に起動します。

すべてのOracle Clusterwareデーモンの自動起動を有効にするには、次の手順を実行します。

1. コマンド・ウィンドウで、rootユーザーとしてオペレーティング・システムにログインします。
2. 次のCRSCTLコマンドを実行します。

   # crsctl enable crs
   

関連項目:

crsctl enable crs

10.3.3.5 Oracle Clusterwareデーモンの無効化

デーモンが自動的に起動しないようにするには、crsctlコマンドを使用して無効にします。

すべてのOracle Clusterwareデーモンの自動起動を無効にするには、次の手順を実行します。

1. コマンド・ウィンドウで、rootユーザーとしてオペレーティング・システムにログインします。
2. 次のCRSCTLコマンドを実行します。

   # crsctl disable crs
   

関連項目:

crsctl disable crs

10.3.4 Oracle RACデータベースのアラート・ログ・メッセージの表示

アラート・ログは、クラスタ・データベース内の各インスタンスに作成されます。

Oracle RACデータベース・インスタンスのアラート・ログを参照するには、次の手順を実行します。

1. クラスタ・データベースの「ホーム」ページで、「インスタンス」のリンクをクリックします。
2. アラート・ログを表示するインスタンスの名前をクリックします。

   「クラスタ・データベース・インスタンス: ホーム」ページが表示されます。

3. 「Oracleデータベース」メニューから、「ログ」、「アラート・ログ・エラー」の順に選択します。

   「アラート・ログ・エラー」ページが表示されます。

4. オプション: 「関連リンク」セクションの「XMLアラート・ログの内容」をクリックして、アラート・ログ内のすべてのエントリを表示します。

   「アラート・ログの内容の表示」ページで、「実行」をクリックして最新のエントリを表示するか、独自の検索基準を入力します。

関連項目:

Oracle RACのエラーを分析するためのファイルの場所の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。