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はトレース・ファイルを生成しません。
親トピック: 自律型ヘルス・フレームワーク
10.1.1.1 ノード・アプリケーションの存在の検証
CVUのcomp nodeapp
コマンドを使用して、すべてのノード上でのノード・アプリケーション、つまり仮想IP (VIP)、Oracle Notification Services (ONS)、およびGlobal Service Daemon (GSD)の存在を確認します。
ノード・アプリケーションの存在を確認するには、次の手順を実行します。
関連項目:
-
クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
親トピック: クラスタ検証ユーティリティ(CVU)
10.1.1.2 Oracle Clusterwareコンポーネントの整合性の検証
CVUのcomp crs
コマンドを使用して、すべてのOracle Clusterwareコンポーネントの存在を確認します。
Oracle Clusterwareコンポーネントの整合性を検証するには、次の手順を実行します。
関連項目:
-
クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
親トピック: クラスタ検証ユーティリティ(CVU)
10.1.1.3 Oracle Cluster Registryの整合性の検証
CVUのcomp ocr
コマンドを使用して、Oracle Clusterwareレジストリの整合性を検証します。
Oracle Clusterwareレジストリの整合性を検証するには、次の手順を実行します。
関連項目:
-
クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
親トピック: クラスタ検証ユーティリティ(CVU)
10.1.1.4 クラスタ全体の整合性の検証
CVUのcomp clu
コマンドを使用して、クラスタ内のすべてのノードにクラスタ構成の同一ビューがあるかチェックします。
クラスタの整合性を検証するには、次の手順を実行します。
関連項目:
-
クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
親トピック: クラスタ検証ユーティリティ(CVU)
10.1.1.5 インターコネクトの設定のチェック
CVUのcomp nodereach
またはcomp nodecon
コマンドを使用して、インターコネクトの設定をチェックします。
キャッシュ・フュージョンは、高速インターコネクトを使用してデータ・ブロックを別のインスタンスのバッファ・キャッシュに送ることにより、Oracle RACのパフォーマンスを強化します。最大限のパフォーマンスを得るために、高速インターコネクトは帯域幅が最も高いプライベート・ネットワークである必要があります。
ネットワーク接続の検証では、CVUコマンドラインでインタフェースを指定しない場合、すべての使用可能なネットワーク・インタフェースが検出されます。
相互接続の設定をチェックするには、次の手順を実行します。
関連項目:
-
クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
親トピック: クラスタ検証ユーティリティ(CVU)
10.1.1.6 トレースの有効化
トレースを有効にしないかぎり、CVUはトレース・ファイルを生成しません。
デフォルトではCVUトレース・ファイルはORACLE_BASE/crsdata/host_name/cvu
ディレクトリに作成されます。ログ・ファイルは自動的にローテーションされ、最新のログ・ファイルの名前はcvutrace.log.0
になります。必要に応じて不要なログ・ファイルを削除またはアーカイブしてディスク領域を解放する必要があります。
CVUを使用したトレースを有効にするには、次の手順を実行します。
関連項目:
トレースの有効化の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
親トピック: クラスタ検証ユーティリティ(CVU)
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
親トピック: ORAchk
10.1.2.2 ORAchkの実行
ORAchkは、定期的に実行するようにスケジュールすることも、必要に応じて実行することもできます。
デーモン・プロセスを使用して、一定の間隔で繰り返すヘルス・チェックをスケジュールすることをお薦めします。
次の目的を満たすようにデーモンを構成します。
-
一定の間隔で繰り返すヘルス・チェックをスケジュールする。
-
ヘルス・チェックの実行が完了したら、前回の実行からの相違点をわかりやすく表示した電子メール通知を送信する。
-
事前に定義した期間の経過後に、収集結果をパージする。
-
失効パスワードをチェックして電子メール通知を送信する。
-
自動化されたヘルス・チェックの実行について複数のプロファイルを格納する。
-
デーモンが稼働しているサーバーまたはノードの再起動時に自動的に再起動する。
次のシナリオでは、ヘルス・チェックをオンデマンドで実行することをお薦めします。
-
アップグレード前またはアップグレード後
-
サブネット間でのマシンの移動
-
ハードウェアの障害または修復
-
問題のトラブルシューティング
-
稼働テストに追加する場合
Oracle ORAchkでは、結果および推奨事項が含まれる詳細なHTMLレポートが生成されます。
最初の電子メール通知の後に実行されるヘルス・チェックにおいて、デーモンは、現在の実行と直近の実行の差分レポートをNOTIFICATION_EMAILリストに指定されたすべてのユーザーに電子メール送信します。
電子メール通知のメッセージには、次の情報が含まれます。
-
前回と比較したこの実行のシステム・ヘルス・スコア。
-
実行されたチェック数のサマリーと前回との差。
-
最新レポートの結果(添付ファイル)。
-
前回レポート結果(添付ファイル)。
-
差分レポート(添付ファイル)。
関連項目:
ORAchkの使用および構成の詳細は、『Oracle Autonomous Health Frameworkユーザーズ・ガイド』を参照してください。親トピック: ORAchk
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チェックが表示されます。
これは、パフォーマンス問題を診断する際に使用すると便利です。
親トピック: ORAchk
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はアプリケーションのより高速な実行を追求するのではなく、アプリケーションが最適なパフォーマンス・レベルで稼働することを妨げる障害を排除します。
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)のデータを表示できます。
親トピック: クラスタの監視およびトラブルシューティング
10.2.1 Oracle Clusterwareの情報へのアクセス
クラスタ・データベースの「ホーム」ページから、様々な方法でOracle Clusterwareの情報にアクセスできます。
Oracle Clusterwareの情報にアクセスするには、次の手順を実行します。
10.2.2 「クラスタ: トポロジ」ページの表示
Oracle Enterprise Managerのトポロジ・ビューアを使用すると、クラスタ内のターゲット・タイプ間の関係をビジュアル表示することができます。
選択内容の詳細の拡大や縮小、パン、および確認が可能です。トポロジ・ビューアでは、システム・ターゲット・タイプを表すそれぞれ個別のアイコンと、すべてのターゲット・タイプに対して、選択範囲を囲むフレームなどの標準化されたビジュアル・インジケータが使用されます。
トポロジ・ビューアにより、システム構成に基づいてアイコンが移入されます。リスナーがインスタンスにサービスを提供している場合、リスナー・アイコンとインスタンス・アイコンが直線で結ばれます。クラスタ・データベースがOracle ASMを使用するように構成されている場合、トポロジにはクラスタOracle ASMとクラスタ・データベースの関係が次の図のように表示されます。
「構成の詳細の表示」オプションの選択を解除した場合、トポロジにはアラートや全体的ステータスなどの一般情報を含む、環境の監視ビューが表示されます。「構成の詳細の表示」オプションを選択した場合、任意のトポロジ・ビューに有効な追加の詳細が「選択の詳細」ページに表示されます。たとえば、「リスナー」コンポーネントの場合は、コンピュータ名とポート番号も表示されます。
アイコンをクリックしてからマウスの右ボタンを使用すると、使用可能なアクションのメニューが表示されます。いくつかのアクションでは、ターゲット・タイプに関連するページに移動して、タスクの監視またはチューニングを実行できます。
このページの詳細は、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時間です。使用可能な履歴データを表示するには、「表示モード」ドロップダウン・メニューを使用して「履歴」を選択します。すると、過去の日付を入力するか、データが使用可能な日付が太字フォントで表示されるポップアップ・カレンダから選択することができます。「チャートの表示」を選択すると、選択したメトリックのグラフが表示されます。
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データベースのアラート・ログ・メッセージの表示
アラート・ログは、クラスタ・データベース内の各インスタンスに作成されます。
親トピック: クラスタの監視およびトラブルシューティング
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管理およびデプロイメント・ガイド』を参照してください。
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ファイルとしても書き込まれますが、テキスト・アラート・ログは簡単に読むことができます。
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
コマンドを使用して無効にします。
10.3.3.1 Oracle Clusterwareインストールのステータスのチェック
Oracle Clusterwareコンポーネントまたはデーモンのステータスを表示するには、CRSCTLのcheck
コマンドを使用します。
Oracle Clusterwareインストールの状態を判別するには、次の手順を実行します。
関連項目:
crsctl check cluster
親トピック: CRSCTLを使用したクラスタの問題の診断
10.3.3.2 Oracle Clusterwareコンポーネントのデバッグの有効化
CRSCTLコマンドを実行して、Oracle Clusterデーモン、イベント・マネージャ(EVM)、およびそれらのモジュールのデバッグを有効にできます。
Oracle Clusterwareコンポーネントのデバッグを有効化するには、次の手順を実行します。
10.3.3.3 Oracle Clusterwareリソースのデバッグの有効化
CRSCTLコマンドを使用して、Oracle Clusterwareに管理されているリソースのデバッグを有効にします。
Oracle Clusterwareリソースのデバッグを有効にするには、次の手順を実行します。
10.3.3.4 Oracle Clusterwareデーモンの有効化
Oracle Clusterwareのデーモンが有効な場合、ノードが起動したときに自動的に起動します。
すべてのOracle Clusterwareデーモンの自動起動を有効にするには、次の手順を実行します。
関連項目:
crsctl enable crs
親トピック: CRSCTLを使用したクラスタの問題の診断
10.3.3.5 Oracle Clusterwareデーモンの無効化
デーモンが自動的に起動しないようにするには、crsctl
コマンドを使用して無効にします。
すべてのOracle Clusterwareデーモンの自動起動を無効にするには、次の手順を実行します。
関連項目:
crsctl disable crs
親トピック: CRSCTLを使用したクラスタの問題の診断
10.3.4 Oracle RACデータベースのアラート・ログ・メッセージの表示
アラート・ログは、クラスタ・データベース内の各インスタンスに作成されます。
Oracle RACデータベース・インスタンスのアラート・ログを参照するには、次の手順を実行します。
関連項目:
Oracle RACのエラーを分析するためのファイルの場所の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。