9 診断データの管理
Oracle Databaseは、診断データを収集して管理するための高度な障害診断インフラストラクチャを備えています。診断データには、以前のリリースにも含まれていたトレース・ファイル、ダンプおよびコア・ファイルに加えて、顧客やOracleサポート・サービスが問題を迅速かつ効率的に識別、調査、追跡、解決できる新しいタイプの診断データが含まれています。
- Oracle Databaseの障害診断インフラストラクチャについて
Oracle Databaseには、データベースの問題を予防、検出、診断および解決するための障害診断インフラストラクチャが含まれています。 - 問題の調査、レポートおよび解決
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)により、問題(クリティカル・エラー)を調査して報告し、場合によっては、問題を解決できます。実行する必要がある一般的なタスクのセットをまとめた「ロードマップ」を使用できます。 - サポート・ワークベンチを使用した問題の表示
Cloud Controlでサポート・ワークベンチのホームページを使用して、すべての問題、または特定の期間内の問題を表示できます。 - 自動診断リポジトリへの問題の手動追加
Cloud Controlのサポート・ワークベンチを使用して、手動でADRに問題を追加できます。 - アラート・ログの表示
アラート・ログは、テキスト・エディタ、Cloud ControlまたはADRCIユーティリティで表示できます。 - トレース・ファイルの検索
トレース・ファイルは、自動診断リポジトリ(ADR)の各ADRホーム下にあるtrace
ディレクトリに格納されます。このディレクトリ内の個々のトレース・ファイルを検索するには、データ・ディクショナリ・ビューを使用します。たとえば、現行セッションのトレース・ファイルへのパス、または各Oracle Databaseプロセスのトレース・ファイルへのパスを検索できます。 - 状態モニターを使用したヘルス・チェックの実行
状態モニターにより、データベースの診断チェックを実行できます。 - SQL修復アドバイザを使用したSQLエラーの修復
まれなケースで、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文の修復を試みることができます。 - データ・リカバリ・アドバイザを使用したデータ破損の修復
データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。 - カスタム・インシデント・パッケージの作成、編集およびアップロード
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージを作成、編集およびアップロードできます。カスタム・インシデント・パッケージにより、Oracleサポート・サービスに送信する診断データを詳細に制御できます。
親トピック: 基本データベース管理
9.1 Oracle Databaseの障害診断インフラストラクチャについて
Oracle Databaseには、データベースの問題を防止、検出、診断および解決するための障害診断性インフラストラクチャが含まれています。
- 障害診断インフラストラクチャの概要
障害診断インフラストラクチャは、問題の防止、検出、診断および解決に役立ちます。特に対象とする問題はクリティカル・エラーで、これには、コードの不具合、メタデータの破損、顧客データの破損によって生じるエラーなどがあります。 - インシデントと問題
問題とは、データベース・インスタンス、Oracle Automatic Storage Management (Oracle ASM)インスタンス、またはその他のOracle製品やコンポーネントにおけるクリティカル・エラーです。インシデントとは、問題の1回の発生です。 - 障害診断インフラストラクチャのコンポーネント
障害診断インフラストラクチャは、自動診断リポジトリ(ADR)、様々なログ、トレース・ファイル、Enterprise Managerサポート・ワークベンチ、およびADRCIコマンドライン・ユーティリティを含む複数のコンポーネントで構成されています。 - 自動診断リポジトリの構造、内容および場所
自動診断リポジトリ(ADR)は、データベースの外部に格納されているディレクトリ構造です。そのため、データベースが停止しているときに問題の診断に使用できます。
親トピック: 診断データの管理
9.1.1 障害診断インフラストラクチャの概要
障害診断インフラストラクチャは、問題の防止、検出、診断および解決に役立ちます。特に対象とする問題はクリティカル・エラーで、これには、コードの不具合、メタデータの破損、顧客データの破損によって生じるエラーなどがあります。
クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断データ(トレース・ファイルなど)が即座に取得され、その番号でタグ付けされます。このデータは、自動診断リポジトリ(ADR) (データベースの外部のファイルベースのリポジトリ)に格納され、後からインシデント番号によって取得して分析できます。
障害診断インフラストラクチャの目的は次のとおりです。
-
初期障害の診断
-
問題の防止
-
問題が検出された後の損害および中断の抑制
-
問題の診断時間の短縮
-
問題の解決時間の短縮
-
顧客とOracleサポートのやり取りの簡略化
これらの目的を達成するための主要なテクノロジは、次のとおりです。
-
初期障害発生時の診断データの自動取得: クリティカル・エラーの場合は、初期障害時にエラー情報を取得することによって、問題の早期解決と停止時間の短縮の可能性が飛躍的に増大します。常時機能しているメモリーベースのトレース・システムは、多くのデータベース・コンポーネントから診断データを事前に収集するため、問題の根本原因を特定するのに役立ちます。このような事前の診断データは、飛行機の「ブラック・ボックス」フライト・レコーダで収集されるデータに類似しています。問題が検出されると、アラートが生成されて、障害診断インフラストラクチャがアクティブになり、診断データが取得されて格納されます。データはデータベース外部のリポジトリに格納され(このため、データベースが停止しているときに使用できます)、コマンドライン・ユーティリティおよびOracle Enterprise Manager Cloud Control (Cloud Control)を使用して容易にアクセスできます。
-
標準化されたトレース形式: すべてのデータベース・コンポーネント間でトレース形式を標準化することによって、DBAおよびOracleサポート・サービス担当者は単一のツール・セットを使用して問題を分析できます。問題の診断はさらに容易となり、停止時間は短縮されます。
-
ヘルス・チェック: クリティカル・エラーが検出されると、障害診断インフラストラクチャでは1つ以上のヘルス・チェックが実行され、クリティカル・エラーの詳細な分析が実行されます。ヘルス・チェックの結果は、エラーについて収集された他の診断データに追加されます。各ヘルス・チェックでは、データ・ブロックの破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。DBAは、定期的にまたは必要に応じてこれらのヘルス・チェックを手動で起動できます。
-
インシデント・パッケージ化サービス(IPS)およびインシデント・パッケージ: IPSを使用すると、クリティカル・エラーに関する診断データ(トレース、ダンプ、ヘルス・チェック・レポートなど)を自動的かつ容易に収集し、それらのデータをzipファイルにパッケージ化してOracleサポートに転送できます。クリティカル・エラーに関するすべての診断データは、そのエラーのインシデント番号でタグ付けされるため、分析に必要なファイルを判別するためにトレース・ファイルやその他のファイルを検索する必要はなく、インシデント・パッケージング・サービスにより必要なファイルが自動的に特定され、zipファイルに追加されます。zipファイルを作成する前に、IPSはまず、インシデント・パッケージという中間論理構造(パッケージ)に診断データを収集します。パッケージは自動診断リポジトリに格納されます。必要に応じて、この中間論理構造にアクセスして、その内容を表示および修正したり、詳細な診断データをいつでも追加または削除でき、さらに準備ができたらパッケージからzipファイルを作成できます。これらのステップが完了すれば、Oracleサポートにアップロードするzipファイルの準備は完了です。
-
データ・リカバリ・アドバイザ: データ・リカバリ・アドバイザはデータベースのヘルス・チェックおよびRMANに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。
-
SQLテスト・ケース・ビルダー: 多くのSQL関連の問題では、再現可能なテスト・ケースの取得が、問題の迅速な解決にとって重要な要因となります。問題とそれが発生した環境に関する可能なかぎりの情報を収集することは困難で時間がかかる場合がありますが、SQLテスト・ケース・ビルダーは、この収集作業を自動化します。迅速に収集された情報をOracleサポート・サービスにアップロードすると、サポート担当者は問題を簡単かつ正確に再現できます。
9.1.2 インシデントと問題
問題とは、データベース・インスタンス、Oracle Automatic Storage Management(Oracle ASM)インスタンス、またはその他のOracle製品やコンポーネントにおけるクリティカル・エラーです。インシデントとは、問題の1回の発生です。
- インシデントおよび問題について
クリティカル・エラーの診断と解決を容易にするために、障害診断インフラストラクチャには、問題とインシデントというOracle Databaseの2つの概念が導入されています。 - インシデントのフラッド制御
短時間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。このような理由から、障害診断インフラストラクチャでは、特定のしきい値に達すると、インシデントの生成にフラッド制御が適用されます。 - トポロジ全体に関連する問題
データベース・インスタンスで識別されるすべての問題については、診断能力フレームワークによって、Oracle Databaseインストールのトポロジ全体に関連する問題を識別できます。
9.1.2.1 インシデントおよび問題について
クリティカル・エラーの診断と解決を容易にするために、障害診断インフラストラクチャには、問題とインシデントというOracle Databaseの概念が導入されています。
問題とは、データベース・インスタンス、Oracle Automatic Storage Management(Oracle ASM)インスタンス、またはその他のOracle製品やコンポーネントにおけるクリティカル・エラーです。クリティカル・エラーには、内部エラー(ORA-00600
など)やその他の深刻なエラー(ORA-07445
(オペレーティング・システム例外)またはORA-04031
(共有プールのメモリー不足))が含まれます。問題はADRで追跡されます。各問題には、問題を説明する文字列である問題キーがあります。これには、エラー・コード(ORA
600
など)、場合によってはさらに1つ以上のエラー・パラメータが含まれます。
インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントには日時が記録され、自動診断リポジトリ(ADR)で追跡されます。各インシデントは、ADR内で一意の数値であるインシデントIDによって識別されます。インシデントが発生すると、データベースでは次の処理が実行されます。
-
アラート・ログにエントリを作成します。
-
インシデント・アラートをCloud Controlに送信します。
-
インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。
-
インシデント・ダンプをインシデントIDにタグ付けします。
-
そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。
通常、クリティカル・エラーの診断と解決は、インシデント・アラートから開始されます。インシデント・アラートは、Cloud Controlのデータベース・ホームページまたはOracle Automatic Storage Managementのホームページに表示されます。また、データベース・ホームページは、Oracle ASMインスタンスやその他のOracle製品またはコンポーネントのクリティカル・アラートを「関連アラート」セクションに表示します。アラートを表示した後、問題および関連するインシデントは、Cloud ControlまたはADRCIコマンドライン・ユーティリティを使用して表示できます。
関連項目:
親トピック: インシデントと問題
9.1.2.2 インシデントのフラッド制御
問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。このような理由から、障害診断インフラストラクチャでは、特定のしきい値に達すると、インシデントの生成にフラッド制御が適用されます。
フラッド制御されたインシデントとは、アラート・ログ・エントリは作成されてADRに記録されるが、インシデント・ダンプは生成されないインシデントです。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。Cloud ControlまたはADRCIのコマンドライン・ユーティリティを使用してインシデントを表示するときは、フラッド制御されたインシデントを表示するか非表示にするかを選択できます。
インシデントのフラッド制御のしきい値レベルは事前定義されており、変更できません。しきい値レベルは次のように定義されています。
-
1時間に同じ問題キーに対して5つのインシデントが発生した場合、その問題キーに対する後続のインシデントはフラッド制御されます。その問題キーに対するインシデントの通常(非フラッド制御)の記録は、次の1時間から再開されます。
-
1日に同じ問題キーに対して25のインシデントが発生した場合、その問題キーに対する後続のインシデントはフラッド制御されます。その問題キーに対するインシデントの通常の記録は、翌日から再開されます。
さらに、1時間に同じ問題キーに対して50のインシデントが発生した場合、または1日に同じ問題キーに対して250のインシデントが発生した場合、その問題キーに対する後続のインシデントはADRに記録されません。この場合は、後続のインシデントが記録されないことを示すメッセージがアラート・ログに書き込まれます。問題キーに対してインシデントが継続して生成されている間は、1時間または1日が経過するまで、10分ごとにこのメッセージがアラート・ログに追加されます。1時間または1日が経過すると、その問題キーに対するインシデントの通常の記録が再開されます。
親トピック: インシデントと問題
9.1.2.3 トポロジ全体に関連する問題
データベース・インスタンスで識別されるすべての問題については、診断能力フレームワークによって、Oracle Databaseインストールのトポロジ全体に関連する問題が識別できます。
単一インスタンス環境では、関連する問題はローカルのOracle ASMインスタンスで識別できます。Oracle RAC環境では、関連する問題はデータベース・インスタンスまたは他のノード上のOracle ASMインスタンスで識別できます。問題を調査する場合、関連する問題の情報を表示して収集できます。
問題が指定期間内に発生したり、同じ実行コンテキスト識別子を共有している場合、その問題は元の問題に関連しています。実行コンテキスト識別子(ECID)は、後からデータを取得するためにOracle DatabaseにコールするOracle Fusion Middlewareへのコールなど、Oracleソフトウェア・スタックを介した単一のコールに対するタグ付けおよび追跡のために使用されるグローバルに一意の識別子です。通常、ECIDは中間層で生成され、Oracle Call Interface (OCI)の属性としてデータベースに渡されます。Oracleソフトウェア・スタックの複数の層に単一のコールによる障害が存在する場合、生成された問題には同じECIDがタグ付けされるため、相関関係を確認できます。さらに、源になっている問題が発生した層を判別できます。
親トピック: インシデントと問題
9.1.3 障害診断インフラストラクチャのコンポーネント
障害診断インフラストラクチャは、自動診断リポジトリ(ADR)、様々なログ、トレース・ファイル、Enterprise Managerサポート・ワークベンチ、およびADRCIコマンドライン・ユーティリティを含む複数のコンポーネントで構成されています。
- 自動診断リポジトリ(ADR)
ADRは、データベース診断データ(トレース、ダンプ、アラート・ログ、状態モニターのレポートなど)のファイルベース・リポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。 - アラート・ログ
アラート・ログは、メッセージとエラーの発生順のログのXMLファイルです。 - トレース・ファイル、ダンプおよびコア・ファイル
トレース・ファイル、ダンプおよびコア・ファイルには、問題の調査に使用する診断データが含まれています。これらはADRに格納されます。 - DDLログ
データ定義言語(DDL)ログは、形式および基本動作がアラート・ログと同じファイルですが、データベースによって発行されたDDL文のみが含められます。 - デバッグ・ログ
Oracle Databaseコンポーネントは、検出しているコンポーネントの正しい動作を妨げないが、通常とは異なる条件、状態またはイベントを検出できます。コンポーネントでは、これらの条件、状態またはイベントについての警告を発行できます。デバッグ・ログは、これらの警告を記録するファイルとなります。 - ADRのその他の内容
ADRには、前の各項で説明したファイルに加えて、状態モニター・レポート、データ修復レコード、SQLテスト・ケース、インシデント・パッケージなどが格納されます。これらのコンポーネントについては、この章で後述します。 - Enterprise Managerサポート・ワークベンチ
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)は、問題(クリティカル・エラー)の調査、レポート、および場合によっては修復を、すべて使いやすいグラフィカル・インタフェースによって実現するファシリティです。 - ADRCIコマンドライン・ユーティリティ
ADRコマンド・インタプリタ(ADRCI)は、問題の調査、ヘルス・チェック・レポートの表示、および初期障害診断データのパッケージ化を、すべてコマンドライン環境内で実行できるようにするユーティリティです。
9.1.3.1 自動診断リポジトリ(ADR)
ADRは、データベース診断データ(トレース、ダンプ、アラート・ログ、状態モニターのレポートなど)のファイルベース・リポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。
データベース、Oracle Automatic Storage Management (Oracle ASM)、リスナー、Oracle ClusterwareなどのOracle製品またはコンポーネントでは、すべての診断データをADRに格納します。各製品のインスタンスはそれぞれ、診断データをADR内の独自のホーム・ディレクトリの下に配置します。たとえば、共有記憶域とOracle ASMを使用するOracle Real Application Clusters環境では、各データベース・インスタンスと各Oracle ASMインスタンスにADRホーム・ディレクトリがあります。ADRの統一されたディレクトリ構造、製品およびインスタンス間で一貫性のある診断データ形式、および統一されたツール・セットにより、ユーザーおよびOracleサポートは、複数のインスタンス間の診断データの相関関係を確認して分析できます。Oracle Clusterwareの場合、クラスタ内の各ホスト・ノードにADRホーム・ディレクトリが1つあります。
注意:
アラート・ログを含むすべての診断データがADRに格納されるため、初期化パラメータのBACKGROUND_DUMP_DEST
およびUSER_DUMP_DEST
が非推奨になりました。これらのパラメータは、ADRの場所を指定する初期化パラメータDIAGNOSTIC_DEST
に置き換えられています。
関連項目:
DIAGNOSTIC_DEST
パラメータとADRホームの詳細は、「自動診断リポジトリの構造、内容および場所」を参照してください。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.2 アラート・ログ
アラート・ログは、メッセージとエラーの発生順のログのXMLファイルです。
各ADRホームにアラート・ログが1つあります。各アラート・ログは、データベース、Oracle ASM、リスナー、Oracle Clusterwareなどのコンポーネント・タイプに固有です。
データベースの場合、アラート・ログには次のものに関するメッセージが含まれます。
-
クリティカル・エラー(インシデント)
-
管理操作(データベースの起動と停止、データベースのリカバリ、表領域の作成や削除など)。
-
マテリアライズド・ビューの自動リフレッシュ中に発生したエラー
-
その他のデータベース・イベント
アラート・ログは、Cloud ControlおよびADRCIユーティリティを使用して、テキスト形式(XMLタグは削除されます)で表示できます。また、下位互換性のためにADRに格納されたテキスト形式のアラート・ログもあります。ただし、テキスト形式は構造化されておらず、リリースごとに変更される場合があるため、アラート・ログの内容の解析はXML形式で行うことをお薦めします。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.3 トレース・ファイル、ダンプおよびコア・ファイル
トレース・ファイル、ダンプおよびコア・ファイルには、問題の調査に使用する診断データが含まれています。これらはADRに格納されます。
- トレース・ファイル
各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。トレース・ファイルはプロセスの存続期間にわたって定期的に更新され、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報を格納できます。さらに、プロセスでクリティカル・エラーが検出されると、そのエラーに関する情報が関連のトレース・ファイルに書き込まれます。 - ダンプ
ダンプは、特殊なタイプのトレース・ファイルです。ダンプでは、通常、1つのイベント(インシデントなど)に対応して1回だけ診断データが出力されますが、トレースでは、多くの場合、診断データが連続して出力されます。 - コア・ファイル
コア・ファイルには、メモリー・ダンプがポート固有の形式ですべてバイナリで格納されます。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.3.1 トレース・ファイル
各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。トレース・ファイルはプロセスの存続期間にわたって定期的に更新され、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報を格納できます。さらに、プロセスでクリティカル・エラーが検出されると、そのエラーに関する情報が関連のトレース・ファイルに書き込まれます。
SQLトレース機能でも、個別のSQL文に関するパフォーマンス情報を提供するトレース・ファイルが作成されます。SQLトレース機能は、セッションまたはインスタンスに対して使用可能にできます。
トレース・ファイルの名前は、プラットフォームに依存します。通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれ、サーバー・プロセスのトレース・ファイル名には、Oracle SID、「ora」の文字列、およびオペレーティング・システムのプロセス番号が含まれます。ファイル拡張子は.trc
です。たとえば、サーバー・プロセスのトレース・ファイル名は、orcl_ora_344.trcのようになります。トレース・ファイルは、対応するトレース・メタデータ(.trm
)ファイルを伴う場合があり、このファイルにはトレース・ファイルの構造情報が含まれていて、検索やナビゲーションに使用されます。
Oracle Databaseには、トレース・ファイルの分析に役立つツールが用意されています。アプリケーション・トレース機能、SQLトレース機能およびトレース・ツールの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
関連項目:
親トピック: トレース・ファイル、ダンプおよびコア・ファイル
9.1.3.3.2 ダンプ
ダンプは、特殊なタイプのトレース・ファイルです。ダンプでは、通常、1つのイベント(インシデントなど)に対応して1回だけ診断データが出力されますが、トレースでは、多くの場合、診断データが連続して出力されます。
インシデントが発生すると、データベースは、そのインシデント用に作成されたインシデント・ディレクトリに1つ以上のダンプを書き込みます。インシデントのダンプには、ファイル名にインシデント番号も付きます。
親トピック: トレース・ファイル、ダンプおよびコア・ファイル
9.1.3.3.3 コア・ファイル
コア・ファイルには、メモリー・ダンプがポート固有の形式ですべてバイナリで格納されます。
コア・ファイル名は、文字列「core」とオペレーティング・システム・プロセスIDで構成されます。コア・ファイルを使用するのはOracleサポート・サービスのエンジニアのみです。プラットフォームによっては、コア・ファイルがない場合があります。
親トピック: トレース・ファイル、ダンプおよびコア・ファイル
9.1.3.4 DDLログ
データ定義言語(DDL)ログは、形式および基本動作がアラート・ログと同じファイルですが、データベースによって発行されたDDL文のみが含められます。
DDLログは、RDBMSコンポーネントのみを対象として、およびENABLE_DDL_LOGGING
初期化パラメータがTRUE
に設定されている場合にのみ、作成されます。このパラメータがFALSE
に設定されている場合、DDL文はいずれのログにも含められません。
DDLログには、データベースによって発行されたDDL文ごとに1つのログ・レコードが含められます。DDLログは、IPSインシデント・パッケージに含まれています。
同じ情報が含まれている2つのDDLログが存在します。1つはXMLファイルで、もう1つはテキスト・ファイルです。DDLログはADRホームのlog/ddlサブディレクトリに格納されます。
関連項目:
ENABLE_DDL_LOGGING
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.5 デバッグ・ログ
Oracle Databaseコンポーネントでは、通常と異なるものの、検出しているコンポーネントの正しい操作を妨げない、条件、状態またはイベントを検出できます。コンポーネントでは、これらの条件、状態またはイベントについての警告を発行できます。デバッグ・ログは、これらの警告を記録するファイルとなります。
デバッグ・ログに記録されるこれらの警告は重大ではなく、インシデントの生成やアラート・ログへの書込みは必要ではありません。これらの警告は問題が発生した場合の診断に必要になる可能性があるため、ログ・ファイルにレコードが生成されます。
デバッグ・ログの形式および基本動作はアラート・ログと同じですが、修正が必要な可能性のある、考えられる問題に関する情報のみが含められます。
デバッグ・ログでは、アラート・ログとトレース・ファイルの情報量が削減されています。また、デバッグ情報の可視性が高められています。
デバッグ・ログは、IPSインシデント・パッケージに含まれています。デバッグ・ログの内容は、Oracleサポート用です。データベース管理者は、デバッグ・ログを直接使用しないでください。
注意:
Oracle Database 12cには個別のデバッグ・ログがあるため、アラート・ログおよびトレース・ファイルは簡素化されています。これらに格納される、デバッグ・ログに記録されている警告のタイプは削減されました。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.6 ADRのその他の内容
ADRには、前の各項で説明したファイルに加えて、状態モニター・レポート、データ修復レコード、SQLテスト・ケース、インシデント・パッケージなどが格納されます。これらのコンポーネントについては、この章で後述します。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.7 Enterprise Managerサポート・ワークベンチ
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)は、使いやすいグラフィカル・インタフェースで問題(クリティカル・エラー)を調査およびレポートできる機能で、場合によってはその問題を修復することもできます。
サポート・ワークベンチでは、セルフサービス方式で、初期障害の診断データの収集、サポート・リクエスト番号の取得、および診断データのOracleサポートへのアップロードを最小限の労力と非常に短い時間で行えるので、問題の解決にかかる時間を短縮できます。また、サポート・ワークベンチでは、SQL関連の問題やデータ破損の問題などを解決できるOracleアドバイザへの容易なアクセスを推奨および提供します。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.3.8 ADRCIコマンドライン・ユーティリティ
ADRコマンド・インタプリタ(ADRCI)は、問題の調査、ヘルス・チェック・レポートの表示、および初期障害診断データのパッケージ化を、すべてコマンドライン環境内で実行できるユーティリティです。
その後、このパッケージをOracleサポートにアップロードできます。また、ADRCIを使用すると、ADRに格納されているトレース・ファイルの名前の表示、およびアラート・ログの表示(XMLタグは削除されます)を、フィルタ処理の有無を選択して実行できます。
ADRCIの詳細は、『Oracle Databaseユーティリティ』を参照してください。
親トピック: 障害診断インフラストラクチャのコンポーネント
9.1.4 自動診断リポジトリの構造、内容および場所
自動診断リポジトリ(ADR)は、データベースの外部に格納されているディレクトリ構造です。そのため、データベースが停止しているときに問題の診断に使用できます。
ADRのルート・ディレクトリはADRベースと呼ばれます。その場所はDIAGNOSTIC_DEST
初期化パラメータによって設定されます。このパラメータを省略するかNULLのままにすると、データベースでは起動時にDIAGNOSTIC_DEST
を次のように設定します。
-
環境変数
ORACLE_BASE
が設定されている場合、DIAGNOSTIC_DEST
はORACLE_BASE
で指定されたディレクトリに設定されます。 -
環境変数
ORACLE_BASE
が設定されていない場合、DIAGNOSTIC_DEST
はORACLE_HOME/logに設定されます。
ADRベース内では、複数のADRホームが存在することがあり、各ADRホームは、特定のOracle製品やコンポーネントの特定のインスタンスに対するすべての診断データ(トレース、ダンプ、アラート・ログなど)のルート・ディレクトリです。たとえば、Oracle ASMを使用するOracle Real Application Clusters環境では、各データベース・インスタンス、Oracle ASMインスタンスおよびリスナーにADRホームがあります。
ADRホームは、製品またはコンポーネントのタイプに基づいて名前が付けられたADRベース・サブディレクトリにあります。図9-1は、これらのトップレベルのサブディレクトリを示しています。
注意:
構成に応じて、ADRに追加のサブディレクトリが作成される場合もあります。一部の製品では、期限切れの診断データがADRから自動的にパージされます。その他の製品の場合は、ADRCIユーティリティPURGE
コマンドを一定の間隔で使用して、期限切れの診断データをパージできます。
各ADRホームの場所は、ADRの基本ディレクトリから始まる次のパスで指定されます。
diag/product_type/product_id/instance_id
例として、表9-1に、Oracle Databaseインスタンスの様々なパス・コンポーネントの値を示します。
表9-1 Oracle DatabaseのADRホームのパス・コンポーネント
パス・コンポーネント | Oracle Databaseの値 |
---|---|
product_type |
rdbms |
product_id |
|
instance_id |
SID |
たとえば、SIDとデータベースの一意の名前が両方ともorclbi
のデータベースと同じ場合、ADRホームの場所は次のようになります。
ADR_base/diag/rdbms/orclbi/orclbi/
同様に、単一インスタンス環境におけるOracle ASMインスタンスへのADRホームのパスは、次のとおりです。
ADR_base/diag/asm/+asm/+asm/
ADRホーム・サブディレクトリ
各ADRホーム・ディレクトリ内には、診断データが含まれるサブディレクトリがあります。表9-2に、これらのサブディレクトリの一部とその内容を示します。
表9-2 ADRホーム・サブディレクトリ
サブディレクトリ名 | 目次 |
---|---|
alert |
XML形式のアラート・ログ。 |
cdump |
コア・ファイル |
incident |
複数のサブディレクトリ。各サブディレクトリは特定のインシデントにちなんで名付けられ、それぞれにそのインシデントにのみ関係するダンプが含められる |
trace |
バックグラウンドおよびサーバー・プロセスのトレース・ファイル、SQLトレース・ファイル、およびテキスト形式のアラート・ログ。 |
(その他) |
ADRホームのその他のサブディレクトリには、インシデント・パッケージ、状態モニター・レポート、アラート以外のログ(DDLログやデバッグ・ログなど)およびその他の情報が格納される。 |
図9-2に、データベース・インスタンスのADRのディレクトリ階層全体を示します。
Oracle Clusterware環境でのADR
Oracle ClusterwareではADRを使用し、独自のOracleホームおよびOracleベースがあります。Oracle ClusterwareのADRディレクトリ構造は、データベース・インスタンスのものとは異なります。1つのシステムではOracle Clusterwareのインスタンスは1つしかないため、Clusterware ADRホームでは、区別子としてシステムのホスト名のみを使用します。
Oracle Clusterwareが構成されると、ADRホームでは、製品タイプとインスタンスIDの両方にcrs
を使用し、製品IDにはシステム・ホスト名を使用します。したがって、dbprod01
という名前のホストでは、CRS ADRホームは次のようになります。
ADR_base/diag/crs/dbprod01/crs/
Oracle Real Application Clusters環境でのADR
Oracle Real Application Clusters(Oracle RAC)環境では、ADRベースはノードごとに独自のローカル記憶域に設定するか、ADRベースは共有記憶域に設定できます。ADRCIを使用して、すべてのインスタンスから集計された診断データを1つのレポートに表示できます。
Oracle ClientにおけるADR
インストールされたOracle Clientには、Oracle Clientコンポーネントのクリティカルな障害に関連する診断データのADRが含まれます。Oracle ClientとともにADRCIユーティリティがインストールされており、これにより、診断データを確認して、Oracleサポートにアップロードするためにパッケージ化できます。
V$DIAG_INFOビューを使用したADRの場所の表示
V$DIAG_INFO
ビューには、現在のOracle Databaseインスタンスにとって重要なADRの場所がすべてリストされます。
SELECT * FROM V$DIAG_INFO; INST_ID NAME VALUE ------- --------------------- ------------------------------------------------------------- 1 Diag Enabled TRUE 1 ADR Base /u01/oracle 1 ADR Home /u01/oracle/diag/rdbms/orclbi/orclbi 1 Diag Trace /u01/oracle/diag/rdbms/orclbi/orclbi/trace 1 Diag Alert /u01/oracle/diag/rdbms/orclbi/orclbi/alert 1 Diag Incident /u01/oracle/diag/rdbms/orclbi/orclbi/incident 1 Diag Cdump /u01/oracle/diag/rdbms/orclbi/orclbi/cdump 1 Health Monitor /u01/oracle/diag/rdbms/orclbi/orclbi/hm 1 Default Trace File /u01/oracle/diag/rdbms/orclbi/orclbi/trace/orcl_ora_22769.trc 1 Active Problem Count 8 1 Active Incident Count 20
次の表で、このビューに表示されるいくつかの情報を説明します。
表9-3 V$DIAG_INFOビューのデータ
名前 | 説明 |
---|---|
ADR Base |
ADRベースのパス |
ADR Home |
現行データベース・インスタンスのADRホームのパス |
Diag Trace |
バックグラウンド・プロセスのトレース・ファイル、サーバー・プロセスのトレース・ファイル、SQLトレース・ファイル、およびテキスト形式のアラート・ログの場所 |
Diag Alert |
XML形式のアラート・ログの場所 |
Default Trace File |
現行セッションのトレース・ファイルへのパス |
V$DIAG_CRITICAL_ERRORビューを使用したクリティカル・エラーの表示
V$DIAG_CRITICAL_ERROR
には、現在のOracle Databaseリリースでクリティカル・エラーとして指定されている、内部エラー以外のすべてのエラーがリストされます。内部エラーは常にクリティカル・エラーとして指定されているため、このビューに内部エラーはリストされません。
次の例は、V$DIAG_CRITICAL_ERROR
ビューの出力を示しています。
SELECT * FROM V$DIAG_CRITICAL_ERROR; FACILITY ERROR ---------- ---------------------------------------------------------------- ORA 7445 ORA 4030 ORA 4031 ORA 29740 ORA 255 ORA 355 ORA 356 ORA 239 ORA 240 ORA 494 ORA 3137 ORA 227 ORA 353 ORA 1578 ORA 32701 ORA 32703 ORA 29770 ORA 29771 ORA 445 ORA 25319 OCI 3106 OCI 3113 OCI 3135
次の表で、このビューに表示される情報を説明します。
表9-4 V$DIAG_CRITICAL_ERRORビューのデータ
列 | 説明 |
---|---|
|
そのエラーをレポート可能な機能(Oracle Database (ORA)、Oracle Call Interface (OCI)など) |
|
エラー番号 |
関連項目:
内部エラーの詳細は、「インシデントおよび問題について」
9.2 問題の調査、レポートおよび解決
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)により、問題(クリティカル・エラー)を調査して報告し、場合によっては、問題を解決できます。実行する必要がある一般的なタスクのセットをまとめた「ロードマップ」を使用できます。
注意:
この項で説明するタスクは、すべてCloud Controlベースです。すべてのタスク(または同等のタスク)は、ADRCI
コマンドライン・ユーティリティ、PL/SQLパッケージ(DBMS_HM
、DBMS_SQLDIAG
など)、およびその他のソフトウェア・ツールを使用して実行できます。ADRCI
ユーティリティの詳細は『Oracle Databaseユーティリティ』を、PL/SQLパッケージの詳細は『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
- 問題の調査、レポートおよび解決のロードマップ
問題の調査は、Cloud Controlの「サポート・ワークベンチ」ホームページから開始できます。ただし、標準的なワークフローはデータベースのホームページのクリティカル・エラー・アラートから始まります。 - タスク1: Cloud Controlでのクリティカル・エラー・アラートの表示
問題(クリティカル・エラー)を調査するプロセスでは、最初にデータベース・ホームページまたはOracle Automatic Storage Managementホームページでクリティカル・エラー・アラートを検討します。 - タスク2: 問題の詳細の表示
インシデント・マネージャ問題の詳細ページから調査を続けます。 - タスク3: (オプション)追加の診断情報の収集
問題に関する追加の診断情報を収集するために、次のアクティビティを実行できます。この追加情報は、診断データに自動的に追加され、Oracleサポート・サービスにアップロードされます。これらのアクティビティの実行に関して不明な点がある場合は、Oracleサポートの担当者に確認してください。 - タスク4: (オプション)サービス・リクエストの作成
この段階で、Oracleサポート・サービス・リクエストを作成し、問題の情報とともにサービス・リクエスト番号を記録できます。 - タスク5: 診断データのパッケージ化とOracleサポートへのアップロード
このタスクでは、サポート・ワークベンチのクイック・パッケージング・プロセスを使用して、問題に関する診断情報をパッケージ化し、Oracleサポートにアップロードします。 - タスク6: サービス・リクエストの追跡と修復の実施
診断情報をOracleサポートにアップロードした後、サービス・リクエストの追跡、追加の診断情報の収集および修復の実施のために様々なアクティビティを実行できます。
関連項目:
問題とその診断データの詳細は、「Oracle Databaseの障害診断インフラストラクチャについて」
親トピック: 診断データの管理
9.2.1 問題の調査、レポートおよび解決のロードマップ
問題の調査は、Cloud Controlの「サポート・ワークベンチ」ホームページから開始できます。ただし、標準的なワークフローはデータベースのホームページのクリティカル・エラー・アラートから始まります。
図9-3に、問題を調査およびレポートし、場合によってはその問題を修復するためのタスクを示します。
タスクの説明を次に示します。この後の項では、各タスクについて詳しく説明します。
-
タスク1: Cloud Controlでのクリティカル・エラー・アラートの表示
最初に、Cloud Controlのデータベース・ホームページにアクセスし、クリティカル・エラー・アラートを検討します。詳細を表示するアラートを選択し、「問題の詳細」ページに進みます。
-
問題の詳細を検証し、その問題に対して記録されたすべてのインシデントのリストを表示します。自動的に実行された状態チェックの結果を表示します。
-
必要に応じて、追加のヘルス・チェックまたは他の診断を実行します。SQL関連エラーの場合は、必要に応じてSQLテスト・ケース・ビルダーを起動して、SQL問題に関連する必要なすべてのデータを収集し、Oracleサポート・サービスで問題を再現できる方法で情報をパッケージ化します。
-
必要に応じて、My Oracle Supportでサービス・リクエストを作成し、問題情報にサービス・リクエスト番号を追加して記録します。このステップをスキップした場合、サービス・リクエストは後で作成するか、サポート・ワークベンチで作成することができます。
-
タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード
問題のために収集された診断データを自動的にパッケージ化してOracleサポートにアップロードするガイド付きワークフロー(ウィザード)を起動します。
-
オプションとして、サービス・リクエストのアクティビティ・ログをサポート・ワークベンチでメンテナンスします。Oracleアドバイザを実行して、SQLエラーまたは破損データを修復します。
親トピック: 問題の調査、報告および解決
9.2.2 タスク1: Cloud Controlでのクリティカル・エラー・アラートの表示
問題(クリティカル・エラー)を調査するプロセスでは、最初にデータベース・ホームページまたはOracle Automatic Storage Managementホームページでクリティカル・エラー・アラートを検討します。
クリティカル・エラー・アラートを表示するには、次のようにします。
親トピック: 問題の調査、報告および解決
9.2.4 タスク3: (オプション)追加の診断情報の収集
次のアクティビティを実行して、問題に関する追加の診断情報を収集します。この追加情報は、診断データに自動的に追加され、Oracleサポート・サービスにアップロードされます。これらのアクティビティの実行に関して不明な点がある場合は、Oracleサポートの担当者に確認してください。
-
追加のヘルス・チェックを手動で起動します。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。
-
SQLテスト・ケース・ビルダーを起動します。
親トピック: 問題の調査、報告および解決
9.2.5 タスク4: (オプション)サービス・リクエストの作成
ここでは、Oracleサポート・サービスへのサービス・リクエストを作成し、サービス・リクエスト番号を問題情報とともに記録できます。
このタスクをスキップした場合は、「タスク5: 診断データのパッケージ化とOracleサポートへのアップロード」で、サポート・ワークベンチによりドラフトのサービス・リクエストが自動的に作成されます。
サービス・リクエストを作成するには、次のようにします。
-
「エンタープライズ」メニューから、「My Oracle Support」を選択してから、「サービス・リクエスト」を選択します。
My Oracle Supportのログインおよび登録のページが表示されます。
-
My Oracle Supportにログインし、通常の方法でサービス・リクエストを作成します。
(オプション)次のステップのためにサービス・リクエスト番号(SR#)を覚えておきます。
-
(オプション)問題の詳細ページに戻り、次の手順を実行します。
-
「サマリー」セクションで、「SR#」ラベルの横にある「編集」ボタンをクリックします。
-
SR#を入力してから、「OK」をクリックします。
SR#が問題の詳細ページに記録されます。この情報は参照専用です。「問題の詳細」ページに戻る場合の詳細は、「サポート・ワークベンチを使用した問題の表示」を参照してください。
-
親トピック: 問題の調査、報告および解決
9.2.6 タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード
このタスクでは、サポート・ワークベンチのクイック・パッケージング・プロセスを使用して、問題に関する診断情報をパッケージ化し、Oracleサポート・サービスにアップロードします。
クイック・パッケージングは、最小限のステップをガイド付きワークフロー(ウィザード)にまとめたものです。ウィザードを使用して、1つの問題に対してインシデント・パッケージ(パッケージ)を作成し、そのパッケージからZIPファイルを作成してアップロードします。ただし、クイック・パッケージングでは、アップロードする診断情報の編集やその他のカスタマイズは行えません。ただし、クイック・パッケージングを使用すると、直接的かつ簡単な方法で診断データをパッケージ化してアップロードできます。
診断情報に含まれる機密データの編集や削除、追加のユーザー・ファイル(アプリケーション構成ファイルやスクリプトなど)の同封、その他のカスタマイズをアップロード前に実行するには、(手動のプロセスとステップが多い)カスタム・パッケージング・プロセスを使用する必要があります。手順については、「カスタム・インシデント・パッケージの作成、編集およびアップロード」を参照してください。このタスク5の手順のかわりにその手順を行う場合は、その手順を行い、完了してから「タスク6: サービス・リクエストの追跡と修復の実装」に進んでください。
注意:
サポート・ワークベンチはOracle Configuration Managerを使用して診断データをアップロードします。Oracle Configuration Managerがインストールされていなかったり、適切に構成されていないと、アップロードに失敗する場合があります。この場合、メッセージが表示され、Oracleサポートへファイルを手動でアップロードするように要求されます。アップロードは、My Oracle Supportを使用して手動で実行できます。
Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。
診断データをパッケージ化してOracleサポートにアップロードするには、次のようにします。
「クイック・パッケージング」ウィザードが完了したとき、新しいドラフトのサービス・リクエストが作成されている場合、Cloud ControlでMy Oracle Supportに表示される確認メッセージには、ドラフトのサービス・リクエストへのリンクが含まれています。リンクをクリックして、サービス・リクエストを確認および編集できます。
「クイック・パッケージング」ウィザードによって作成されたパッケージは、サポート・ワークベンチで引き続き使用できます。カスタム・パッケージング操作を使用してパッケージを変更し(新規インシデントの追加など)、後でパッケージを再度アップロードできます。「インシデント・パッケージの表示と変更」を参照してください。
親トピック: 問題の調査、報告および解決
9.2.7 タスク6: サービス・リクエストの追跡および修復の実施
診断情報をOracleサポート・サービスにアップロードした後は、様々なアクティビティを実行してサービス・リクエストを追跡し、追加の診断情報を収集して、修復を実装できます。
このアクティビティには次のものがあります。
-
問題情報にOracleバグ番号を追加します。
そのためには、問題の詳細ページで「バグ#」ラベルの横にある「編集」ボタンをクリックします。この情報は参照専用です。
-
問題のアクティビティ・ログにコメントを追加します。
このアクティビティは、組織内の他のDBAと問題ステータスや履歴情報を共有する場合に実行します。たとえば、Oracleサポート・サービスとの通信結果を記録できます。コメントを追加するステップは、次のとおりです。
-
「サポート・ワークベンチを使用した問題の表示」で説明しているように、この問題の「問題の詳細」ページにアクセスします。
-
「アクティビティ・ログ」をクリックして、アクティビティ・ログ・サブページを表示します。
-
「コメント」フィールドにコメントを入力し、「コメントの追加」をクリックします。
コメントがアクティビティ・ログに記録されます。
-
-
新規に発生したインシデントをパッケージ化して再アップロードします。
このアクティビティでは、「カスタム・インシデント・パッケージの作成、編集およびアップロード」で説明するように、カスタム・パッケージング方法を使用する必要があります。
-
ヘルス・チェックを実行します。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。
-
推奨されるOracleアドバイザを実行して修復を実施します。
推奨されたアドバイザには、次のいずれかの方法でアクセスします。
-
問題の詳細ページ: 「調査と解決」セクションの「セルフ・サービス」タブ
-
「サポート・ワークベンチ」ホームページ: 「チェッカ結果」サブページ
-
「インシデントの詳細」ページ: 「チェッカ結果」サブページ
表9-5に、クリティカル・エラーの修復に役立つアドバイザを示します。
表9-5 クリティカル・エラーの修復に役立つOracleアドバイザ
アドバイザ 対象になるクリティカル・エラー 参照 データ・リカバリ・アドバイザ
破損ブロック、破損または欠落しているファイル、その他のデータ障害
SQL修復アドバイザ
SQL文エラー
-
関連項目:
「インシデントの詳細」ページの「チェッカ結果」サブページを表示する手順は、「サポート・ワークベンチを使用した問題の表示」を参照してください
親トピック: 問題の調査、報告および解決
9.3 サポート・ワークベンチを使用した問題の表示
Cloud Controlでサポート・ワークベンチのホームページを使用して、すべての問題、または特定の期間内の問題を表示できます。
「サポート・ワークベンチ」ホームページ(データベースまたはOracle ASM)にアクセスするには:
問題とインシデントを表示するには:
-
「サポート・ワークベンチ」ホームページの「表示」リストから希望する期間を選択します。すべての問題を表示するには、「すべて」を選択します。
-
(オプション)「パフォーマンスとクリティカル・エラーのタイムライン」セクションが非表示の場合、セクション・ヘッダーの横にある「表示/非表示」アイコンをクリックして、セクションを表示します。
このセクションでは、パフォーマンスの変化とインシデントの発生の関連を表示できます。
-
(オプション)「詳細」列の下の「表示」をクリックして、特定の問題に関するすべてのインシデントのリストを表示します。次に、インシデントIDをクリックして、インシデントの詳細ページを表示します。
特定の問題の詳細を表示するには、次の手順を実行します。
関連項目:
親トピック: 診断データの管理
9.4 自動診断リポジトリへの問題の手動追加
Cloud Controlのサポート・ワークベンチを使用して、手動でADRに問題を追加できます。
システムで生成された問題(内部でデータベースに対して生成されたクリティカル・エラーなど)は、自動的に自動診断リポジトリ(ADR)に追加され、サポート・ワークベンチ内で追跡されます。
サポート・ワークベンチから、これらの問題に関する追加の診断データの収集、Oracleサポートへの診断データのアップロード、および場合によっては、問題を解決することもでき、このすべてを、「問題の調査、レポートおよび解決」で説明されている使いやすいワークフローを使用して実行できます。
気付いた問題を、同じワークフローで処理できるように、手動でADRに追加する必要がある場合もあります。このような問題の例には、自動データベース診断モニター(ADDM)で診断されなかったグローバル・データベースのパフォーマンスに関する問題があります。サポート・ワークベンチは、このようなユーザー報告の問題を作成して処理するメカニズムを備えています。
ユーザー報告の問題を作成するには:
関連項目:
問題とADRの詳細は、「Oracle Databaseの障害診断インフラストラクチャについて」
親トピック: 診断データの管理
9.5 アラート・ログの表示
アラート・ログは、テキスト・エディタ、Cloud ControlまたはADRCIユーティリティを使用して表示できます。
Cloud Controlでアラート・ログを表示するには:
-
Cloud Controlのデータベース・ホームページにアクセスします。
-
「Oracle Database」メニューから、「診断」を選択し、次に、「サポート・ワークベンチ」を選択します。
-
「関連リンク」で「アラート・ログの内容」をクリックします。
「アラート・ログの内容の表示」ページが表示されます。
-
表示するエントリの数を選択して「実行」をクリックします。
テキスト・エディタを使用してアラート・ログを表示するには:
-
SQL*PlusまたはSQL Developerなどの問合せツールを使用して、データベースに接続します。
-
「V$DIAG_INFOビューを使用したADRの場所の表示」に示すように、
V$DIAG_INFO
ビューを問い合せます。 -
XMLタグがないテキストのみのアラート・ログを表示するステップは、次のとおりです。
-
V$DIAG_INFO
問合せ結果からDiag
Trace
エントリに対応するパスをメモし、ディレクトリをそのパスに変更します。 -
テキスト・エディタを使用して、alert_SID.logファイルをオープンします。
-
-
XML形式のアラート・ログを表示するステップは、次のとおりです。
-
V$DIAG_INFO
問合せ結果からDiag
Alert
エントリに対応するパスをメモし、ディレクトリをそのパスに変更します。 -
テキスト・エディタを使用して、log.xmlファイルをオープンします。
-
関連項目:
ADRCIユーティリティを使用してテキスト形式(XMLタグは削除されます)のアラート・ログを表示し、そのアラート・ログに対して問合せを実行する方法については、『Oracle Databaseユーティリティ』を参照してください。
親トピック: 診断データの管理
9.6 トレース・ファイルの検索
トレース・ファイルは、自動診断リポジトリ(ADR)内の各ADRホーム下にあるtrace
ディレクトリに格納されます。このディレクトリ内の個々のトレース・ファイルを検索するには、データ・ディクショナリ・ビューを使用します。たとえば、現行セッションのトレース・ファイルへのパス、または各Oracle Databaseプロセスのトレース・ファイルへのパスを検索できます。
現行セッションのトレース・ファイルを検索するには:
-
次の問合せを発行します。
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';
トレース・ファイルへのフルパスが返されます。
現行インスタンスのすべてのトレース・ファイルを検索するには:
-
次の問合せを発行します。
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';
現在のインスタンスのADRトレース・ディレクトリへのパスが返されます。
各Oracle Databaseプロセスのトレース・ファイルを特定するには:
-
次の問合せを発行します。
SELECT PID, PROGRAM, TRACEFILE FROM V$PROCESS;
関連項目:
-
『Oracle Databaseユーティリティ』のADRCI
SHOW
TRACEFILE
コマンドに関する項
親トピック: 診断データの管理
9.7 状態モニターを使用したヘルス・チェックの実行
状態モニターにより、データベースの診断チェックを実行できます。
- 状態モニターについて
Oracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。 - ヘルス・チェックの手動実行
状態モニターでは、DBMS_HM
PL/SQLパッケージを使用するか、「アドバイザ・セントラル」ページの「チェッカ」サブページにあるCloud Controlインタフェースを使用して、手動でヘルス・チェックを実行できます。 - チェッカ・レポートの表示
チェッカを実行した後、その実行のレポートを表示できます。レポートには、結果、推奨事項およびその他の情報が含まれます。このレポートは、Cloud Control、ADRCIユーティリティまたはDBMS_HM
PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。 - 状態モニターのビュー
チェッカ・レポートを要求するかわりに、レポートが作成されたADRデータを直接問い合せると、特定のチェッカの実行結果を表示できます。 - ヘルス・チェック・パラメータの参考情報
いくつかのヘルス・チェックでは、パラメータが必要です。デフォルト値が(なし)
のパラメータは必須です。
親トピック: 診断データの管理
9.7.1 状態モニターについて
Oracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。
- 状態モニターについて
状態モニター・チェック(チェッカ、ヘルス・チェックまたはチェックとも呼ばれる)では、データベースの様々なレイヤーとコンポーネントが検証されます。 - ヘルス・チェックのタイプ
状態モニターでは、いくつかの異なるタイプのチェックが実行されます。
親トピック: 状態モニターを使用したヘルス・チェックの実行
9.7.1.1 状態モニター・チェックについて
状態モニター・チェック(チェッカ、ヘルス・チェックまたはチェックとも呼ばれます)では、データベースの様々なレイヤーとコンポーネントが検証されます。
ヘルス・チェックでは、ファイルの破損、物理ブロックおよび論理ブロック破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。また、ヘルス・チェックの結果のレポートが生成され、多くの場合、問題を解決するための推奨事項が示されます。ヘルス・チェックは次の2つの方法で実行できます。
-
リアクティブ: 障害診断インフラストラクチャでは、クリティカル・エラーの内容に応じてヘルス・チェックを自動的に実行できます。
-
手動: DBAは、
DBMS_HM
PL/SQLパッケージまたはCloud Controlインタフェースのいずれかを使用して、ヘルス・チェックを手動で実行できます。必要に応じて定期的にチェッカを実行できますが、Oracleサポートがサービス・リクエストについて共同で作業しているときにチェッカの実行をお願いさせていただくこともあります。
状態モニター・チェックでは、結果、推奨事項およびその他の情報が自動診断リポジトリ(ADR)に格納されます。
ヘルス・チェックは次の2つのモードで実行できます。
-
DBオンライン・モードは、データベースがオープン状態(つまり、
OPEN
モードまたはMOUNT
モード)のときは、チェックを実行できることを意味します。 -
DBオフライン・モードは、インスタンスは使用可能だがデータベース自体がクローズ(つまり、
NOMOUNT
モード)している場合にチェックを実行できることを意味します。
DBオンライン・モードでは、すべてのヘルス・チェックを実行できます。DBオフライン・モードで使用できるのは、REDOの整合性チェックとDB構造の整合性チェックのみです。
注意:
親トピック: 状態モニターについて
9.7.1.2 ヘルス・チェックのタイプ
状態モニターでは、いくつかの異なるタイプのチェックが実行されます。
状態モニターでは次のチェックが実行されます。
-
DB構造の整合性チェック: このチェックではデータベース・ファイルの整合性が検証され、これらのファイルがアクセス不可、破損状態または不整合の場合はエラーが報告されます。データベースがマウント・モードまたはオープン・モードの場合は、制御ファイルに列記されたログ・ファイルとデータファイルがチェックされます。データベースが
NOMOUNT
モードの場合は、制御ファイルのみがチェックされます。 -
データ・ブロックの整合性チェック: このチェックではチェックサム・エラー、先頭/末尾の不一致、ブロック内の論理的不整合などのディスク・イメージ・ブロック破損が検出されます。ほとんどの破損はブロック・メディア・リカバリを使用して修復できます。破損ブロック情報は
V$DATABASE_BLOCK_CORRUPTION
ビューでも取得されます。このチェックではブロック間またはセグメント間の破損は検出されません。 -
REDOの整合性チェック: このチェックではアクセス可能性と破損についてREDOログの内容がスキャンされ、可能な場合はアーカイブ・ログもスキャンされます。REDOの整合性チェックではアーカイブ・ログやREDOの破損などのエラーが報告されます。
-
UNDOセグメントの整合性チェック: このチェックでは、論理的なUNDO破損が検出されます。UNDO破損の場所を特定した後、このチェックではPMONおよびSMONを使用して、破損したトランザクションのリカバリを試みます。このリカバリに失敗した場合、状態モニターは破損の情報を
V$CORRUPT_XID_LIST
に格納します。ほとんどのUNDO破損は、コミットを強制実行することで解決できます。 -
トランザクションの整合性チェック: このチェックは、1つの特定トランザクションのみがチェックされることを除いて、UNDOセグメントの整合性チェックと同じです。
-
ディクショナリの整合性チェック: このチェックでは、
tab$
、col$
などのコア・ディクショナリ・オブジェクトの整合性が検証されます。次の操作を実行します。-
各ディクショナリ・オブジェクトに対するディクショナリ・エントリの内容が確認されます。
-
行間レベルのチェックが実行され、ディクショナリの行で論理的制約が適用されていることが確認されます。
-
オブジェクト関係のチェックが実行され、ディクショナリ・オブジェクト間で親子関係が規定されていることが確認されます。
ディクショナリの整合性チェックは、次のディクショナリ・オブジェクトに対して実行されます。
tab$
、clu$
、fet$
、uet$
、seg$
、undo$
、ts$
、file$
、obj$
、ind$
、icol$
、col$
、user$
、con$
、cdef$
、ccol$
、bootstrap$
、objauth$
、ugroup$
、tsq$
、syn$
、view$
、typed_view$
、superobj$
、seq$
、lob$
、coltype$
、subcoltype$
、ntab$
、refcon$
、opqtype$
、dependency$
、access$
、viewcon$
、icoldep$
、dual$
、sysauth$
、objpriv$
、defrole$
およびecol$
-
親トピック: 状態モニターについて
9.7.2 ヘルス・チェックの手動実行
状態モニターでは、DBMS_HM
PL/SQLパッケージを使用するか、「アドバイザ・セントラル」ページの「チェッカ」サブページにあるCloud Controlインタフェースを使用して、手動でヘルス・チェックを実行できます。
- DBMS_HM PL/SQLパッケージを使用したヘルス・チェックの実行
ヘルス・チェックを実行するためのDBMS_HM
プロシージャは、RUN_CHECK
と呼ばれています。 - Cloud Controlを使用したヘルス・チェックの実行
Cloud Controlは、状態モニター・チェッカを実行するためのインタフェースを提供します。
親トピック: 状態モニターを使用したヘルス・チェックの実行
9.7.2.1 DBMS_HM PL/SQLパッケージを使用したヘルス・チェックの実行
ヘルス・チェックを実行するためのDBMS_HM
プロシージャはRUN_CHECK
です。
-
RUN_CHECK
をコールするには、次のようにチェック名と実行名を指定します。BEGIN DBMS_HM.RUN_CHECK('Dictionary Integrity Check', 'my_run'); END; /
-
ヘルス・チェック名のリストを取得するには、次の問合せを実行します。
SELECT name FROM v$hm_check WHERE internal_check='N';
出力は次のようになります。
NAME ---------------------------------------------------------------- DB Structure Integrity Check Data Block Integrity Check Redo Integrity Check Transaction Integrity Check Undo Segment Integrity Check Dictionary Integrity Check
ほとんどのヘルス・チェックに入力パラメータを指定できます。パラメータ名と説明はV$HM_CHECK_PARAM
ビューを使用して表示できます。一部のパラメータは必須ですが、オプションのパラメータもあります。オプションのパラメータを省略すると、デフォルトが使用されます。次の問合せでは、すべてのヘルス・チェックのパラメータ情報が表示されます。
SELECT c.name check_name, p.name parameter_name, p.type, p.default_value, p.description FROM v$hm_check_param p, v$hm_check c WHERE p.check_id = c.id and c.internal_check = 'N' ORDER BY c.name;
入力パラメータは、セミコロン(;)で区切られた名前/値のペアとしてinput_params
引数で渡されます。次の例では、トランザクションIDをパラメータとして「トランザクションの整合性チェック」に渡す方法を示します。
BEGIN DBMS_HM.RUN_CHECK ( check_name => 'Transaction Integrity Check', run_name => 'my_run', input_params => 'TXN_ID=7.33.2'); END; /
関連項目:
-
DBMS_HM
の使用例の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ヘルス・チェックの手動実行
9.7.2.2 Cloud Controlを使用したヘルス・チェックの実行
Cloud Controlは、状態モニター・チェッカを実行するためのインタフェースを備えています。
Cloud Controlを使用して状態モニター・チェッカを実行するには:
- 「データベース・ホーム」ページにアクセスします。
- 「パフォーマンス」メニューから、「アドバイザ・ホーム」を選択します。
- 「チェッカ」をクリックして「チェッカ」サブページを表示します。
- 「チェッカ」セクションで、実行するチェッカをクリックします。
- 入力パラメータの値を入力するか、オプション・パラメータの場合は空白のままにしてデフォルトを使用します。
- 「OK」をクリックし、パラメータを確認して「OK」を再度クリックします。
親トピック: ヘルス・チェックの手動実行
9.7.3 チェッカ・レポートの表示
チェッカを実行した後は、その実行内容のレポートを表示できます。レポートには、結果、推奨事項およびその他の情報が含まれます。このレポートは、Cloud Control、ADRCIユーティリティまたはDBMS_HM
PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。
- チェッカ・レポートの表示について
チェッカの実行結果(結果、推奨事項およびその他の情報)はADRに格納されますが、レポートはすぐに生成されません。 - Cloud Controlを使用したレポートの表示
Cloud Controlを使用して、特定のチェッカの実行に関する状態モニター・レポートと結果を表示することもできます。 - DBMS_HMを使用したレポートの表示
状態モニター・チェッカ・レポートは、DBMS_HM
パッケージ・ファンクションGET_RUN_REPORT
を使用して表示できます。 - ADRCIユーティリティを使用したレポートの表示
ADRCIユーティリティを使用して、状態モニター・チェッカ・レポートを作成および表示できます。
親トピック: 状態モニターを使用したヘルス・チェックの実行
9.7.3.1 チェッカ・レポートの表示について
チェッカの実行結果(結果、推奨事項およびその他の情報)はADRに格納されますが、レポートはすぐに生成されません。
レポートの表示方法 | 使用可能なレポート形式 |
---|---|
Cloud Control |
HTML |
|
HTML、XMLおよびテキスト |
ADRCIユーティリティ |
XML |
DBMS_HM
PL/SQLパッケージまたはCloud Controlを使用してレポートを要求したときに、レポートがまだ生成されていない場合は、最初にADR内のチェッカ実行データからレポートが生成され、現行インスタンス用のADRホームのHMサブディレクトリにXML形式でレポート・ファイルとして格納された後に、レポートが表示されます。レポートがすでに生成されている場合は、そのレポートが表示されます。ADRCIユーティリティを使用する場合、レポートがまだ生成されていないときは、最初にレポート・ファイルを生成するためのコマンドを実行し、次にその内容を表示するためのコマンドを実行する必要があります。
チェッカ・レポートは、Cloud Controlを使用して表示することをお薦めします。
注意:
親トピック: チェッカ・レポートの表示
9.7.3.2 Cloud Controlを使用したレポートの表示
Cloud Controlを使用して、特定のチェッカ実行の状態モニター・レポートと結果を表示できます。
Cloud Controlを使用して実行結果を表示するには:
親トピック: チェッカ・レポートの表示
9.7.3.3 DBMS_HMを使用したレポートの表示
状態モニター・チェッカ・レポートは、DBMS_HM
パッケージ・ファンクションGET_RUN_REPORT
を使用して表示できます。
このファンクションを使用すると、HTML、XMLまたはテキスト形式のレポートを要求できます。デフォルトはテキスト形式で、次にSQL*Plusの例を示します。
SET LONG 100000 SET LONGCHUNKSIZE 1000 SET PAGESIZE 1000 SET LINESIZE 512 SELECT DBMS_HM.GET_RUN_REPORT('HM_RUN_1061') FROM DUAL; DBMS_HM.GET_RUN_REPORT('HM_RUN_1061') ----------------------------------------------------------------------- Run Name : HM_RUN_1061 Run Id : 1061 Check Name : Data Block Integrity Check Mode : REACTIVE Status : COMPLETED Start Time : 2007-05-12 22:11:02.032292 -07:00 End Time : 2007-05-12 22:11:20.835135 -07:00 Error Encountered : 0 Source Incident Id : 7418 Number of Incidents Created : 0 Input Parameters for the Run BLC_DF_NUM=1 BLC_BL_NUM=64349 Run Findings And Recommendations Finding Finding Name : Media Block Corruption Finding ID : 1065 Type : FAILURE Status : OPEN Priority : HIGH Message : Block 64349 in datafile 1: '/u01/app/oracle/dbs/t_db1.f' is media corrupt Message : Object BMRTEST1 owned by SYS might be unavailable Finding Finding Name : Media Block Corruption Finding ID : 1071 Type : FAILURE Status : OPEN Priority : HIGH Message : Block 64351 in datafile 1: '/u01/app/oracle/dbs/t_db1.f' is media corrupt Message : Object BMRTEST2 owned by SYS might be unavailable
関連項目:
DBMS_HM
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: チェッカ・レポートの表示
9.7.3.4 ADRCIユーティリティを使用したレポートの表示
ADRCIユーティリティを使用して、状態モニター・チェッカ・レポートを作成および表示できます。
ADRCIを使用してチェッカ・レポートを作成および表示するには:
注意:
親トピック: チェッカ・レポートの表示
9.7.4 状態モニターのビュー
チェッカ・レポートを要求するかわりに、レポートが作成されたADRデータを直接問い合せると、特定のチェッカ実行の結果を表示できます。
このデータは、V$HM_RUN
、V$HM_FINDING
およびV$HM_RECOMMENDATION
の各ビューを使用して表示できます。
次の例では、V$HM_RUN
ビューを問い合せて、チェッカ実行の履歴を表示します。
SELECT run_id, name, check_name, run_mode, src_incident FROM v$hm_run; RUN_ID NAME CHECK_NAME RUN_MODE SRC_INCIDENT ---------- ------------ ---------------------------------- -------- ------------ 1 HM_RUN_1 DB Structure Integrity Check REACTIVE 0 101 HM_RUN_101 Transaction Integrity Check REACTIVE 6073 121 TXNCHK Transaction Integrity Check MANUAL 0 181 HMR_tab$ Dictionary Integrity Check MANUAL 0 . . . 981 Proct_ts$ Dictionary Integrity Check MANUAL 0 1041 HM_RUN_1041 DB Structure Integrity Check REACTIVE 0 1061 HM_RUN_1061 Data Block Integrity Check REACTIVE 7418
次の例では、RUN_ID
1061を指定してV$HM_FINDING
ビューを問い合せ、リアクティブなデータ・ブロック・チェックの結果詳細を取得します。
SELECT type, description FROM v$hm_finding WHERE run_id = 1061; TYPE DESCRIPTION ------------- ----------------------------------------- FAILURE Block 64349 in datafile 1: '/u01/app/orac le/dbs/t_db1.f' is media corrupt FAILURE Block 64351 in datafile 1: '/u01/app/orac le/dbs/t_db1.f' is media corrupt
関連項目:
-
V$HM_*ビューの詳細は、『Oracle Databaseリファレンス』
を参照してください。
親トピック: 状態モニターを使用したヘルス・チェックの実行
9.7.5 ヘルス・チェック・パラメータの参考情報
いくつかのヘルス・チェックでは、パラメータが必要です。デフォルト値が(なし)
のパラメータは必須です。
表9-6 「データ・ブロックの整合性チェック」のパラメータ
パラメータ名 | タイプ | デフォルト値 | 説明 |
---|---|---|---|
|
数値 |
(なし) |
ブロック・データ・ファイル番号 |
|
数値 |
(なし) |
データ・ブロック番号 |
表9-7 「REDOの整合性チェック」のパラメータ
パラメータ名 | タイプ | デフォルト値 | 説明 |
---|---|---|---|
|
テキスト |
0 |
最新の良好なREDOのSCN(既知の場合) |
表9-8 「UNDOセグメントの整合性チェック」のパラメータ
パラメータ名 | タイプ | デフォルト値 | 説明 |
---|---|---|---|
|
テキスト |
(なし) |
UNDOセグメント番号 |
表9-9 「トランザクションの整合性チェック」のパラメータ
パラメータ名 | タイプ | デフォルト値 | 説明 |
---|---|---|---|
|
テキスト |
(なし) |
トランザクションID |
表9-10 「ディクショナリの整合性チェック」のパラメータ
パラメータ名 | タイプ | デフォルト値 | 説明 |
---|---|---|---|
|
テキスト |
|
指定できる値は次のとおりです。
|
|
テキスト |
|
チェックする単一のコア・テーブルの名前。省略すると、すべてのコア・テーブルがチェックされます。 |
親トピック: 状態モニターを使用したヘルス・チェックの実行
9.8 SQL修復アドバイザを使用したSQLエラーの修復
ほとんど発生しませんが、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文を修復できます。
- SQL修復アドバイザについて
SQL文が重大なエラーで失敗した後に、SQL修復アドバイザを実行します。 - SQL修復アドバイザの実行
SQL修復アドバイザは、サポート・ワークベンチの「問題の詳細」ページから実行します。 - SQLパッチの表示、無効化または削除
SQL修復アドバイザを使用してSQLパッチを適用した後、表示してその存在を確認し、無効化または削除するすることもできます。パッチを削除する理由の1つに、後続リリースのOracle Databaseをインストールし、パッチを適用したSQL文でエラーが発生した不具合が修正されている場合があります。
親トピック: 診断データの管理
9.8.1 SQL修復アドバイザについて
SQL修復アドバイザは、重大なエラーが発生してSQL文が失敗した場合に実行します。
このアドバイザによって、文が分析され、多くの場合、文を修復するためにパッチの適用が推奨されます。リコメンデーションを実装すると、適用されたSQLパッチによって、問合せオプティマイザで将来実行する場合の代替実行計画が選択され、失敗が回避されます。
親トピック: SQL修復アドバイザを使用したSQLエラーの修復
9.8.2 SQL修復アドバイザの実行
SQL修復アドバイザは、サポート・ワークベンチの「問題の詳細」ページから実行します。
通常、これを実行するのは、SQL文に起因するクリティカル・エラーの通知をすでに受け取り、「問題の調査、レポートおよび解決」で説明したワークフローに従っている場合です。
SQL修復アドバイザを実行するには:
-
失敗したSQL文に関連する問題の「問題の詳細」ページにアクセスします。
手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。
-
「調査と解決」セクションの「解決」ヘッダーで、「SQL修復アドバイザ」をクリックします。
-
「SQL修復アドバイザ」ページで次のステップを実行します。
-
必要な場合は現在のタスク名を変更し、必要に応じてタスクの説明を入力し、アドバイザ・タスクのオプションの時間制限を変更またはクリアし、設定を調整してアドバイザを即時に実行するか、後の日時に実行するかをスケジュールします。
-
「発行」をクリックします。
「処理中」ページが表示されます。その少し後に「SQL修復結果」ページが表示されます。
「SQLパッチ」列のチェック・マークは、推奨事項があることを示します。この列にチェック・マークがない場合は、SQL修復アドバイザがSQL文に対してパッチを提示できなかったことを意味します。
注意:
「SQL修復結果」ページが表示されない場合は、表示するために次のステップを実行します。
-
データベース・ホームページに移動します。
-
「パフォーマンス」メニューから、「アドバイザ・ホーム」を選択します。
-
「アドバイザ・セントラル」ページの「結果」リストで、SQL修復アドバイザの最新エントリを探します。
-
そのエントリを選択して「結果の表示」をクリックします。
-
-
推奨事項がある場合は、「SQLパッチ」列にチェック・マークが表示されます。推奨事項を参照するには、「表示」をクリックします。
「修復の推奨」ページに、文に対する推奨パッチが表示されます。
-
「実装」をクリックします。
「SQL修復結果」ページに戻り、確認メッセージが表示されます。
-
(オプション)「SQLワークシートを使用して検証」をクリックして、SQLワークシートの文を実行し、パッチによって文が正常に修復したことを検証します。
親トピック: SQL修復アドバイザを使用したSQLエラーの修復
9.8.3 SQLパッチの表示、無効化または削除
SQL修復アドバイザを使用してSQLパッチを適用した後は、そのSQLパッチを表示してパッチが適用されたことを確認したり、パッチを無効化または削除できます。パッチを削除する理由の1つに、後続リリースのOracle Databaseをインストールし、パッチを適用したSQL文でエラーが発生した不具合が修正されている場合があります。
SQLパッチを表示、無効化または削除するには:
関連項目:
親トピック: SQL修復アドバイザを使用したSQLエラーの修復
9.9 データ・リカバリ・アドバイザを使用したデータ破損の修復
データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。
データ・リカバリ・アドバイザはEnterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)、状態モニターおよびRMANユーティリティに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。
データ・リカバリ・アドバイザの使用方法の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。この項では、サポート・ワークベンチからアドバイザにアクセスする方法について説明します。
データ・リカバリ・アドバイザは、データ破損またはその他のデータ障害に関連するヘルス・チェックの結果を表示する場合にサポート・ワークベンチによって自動的に推奨され、サポート・ワークベンチからアクセスできます。データ・リカバリ・アドバイザは「アドバイザ・セントラル」ページからも使用できます。
Cloud Controlでデータ・リカバリ・アドバイザにアクセスするには:
-
Cloud Controlのデータベース・ホームページにアクセスします。
データ・リカバリ・アドバイザを使用できるのは、
SYSDBA
として接続している場合のみです。 -
「Oracle Database」メニューから、「診断」を選択し、次に、「サポート・ワークベンチ」を選択します。
-
「チェッカ結果」をクリックします。
チェッカ結果サブページが表示されます。
-
1つ以上のデータ破損結果を選択して、「リカバリ・アドバイザの起動」をクリックします。
関連項目:
データ・リカバリ・アドバイザの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
親トピック: 診断データの管理
9.10 カスタム・インシデント・パッケージの作成、編集およびアップロード
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージを作成、編集およびアップロードできます。カスタム・インシデント・パッケージにより、Oracleサポート・サービスに送信する診断データを詳細に制御できます。
- インシデント・パッケージ
インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造に診断データを収集できます。 - カスタム・パッケージングを使用した問題のパッケージ化とアップロード
カスタム・インシデント・パッケージ(パッケージ)を作成し、アップロードするには、サポート・ワークベンチ(サポート・ワークベンチ)を使用します。アップロードする前に、診断データ・ファイルをパッケージから手動で追加、編集、および削除できます。 - インシデント・パッケージの表示と変更
カスタム・パッケージング方法を使用してインシデント・パッケージを作成した後、Oracleサポートにアップロードする前に、そのパッケージのコンテンツを表示または変更できます。 - 相関パッケージの作成、編集およびアップロード
Oracleサポートにパッケージをアップロードした後、1つ以上の相関パッケージを作成およびアップロードできます。 - 相関パッケージの削除
相関パッケージは、そのパッケージを作成したターゲットのサポート・ワークベンチで削除します。 - インシデント・パッケージのプリファレンスの設定
インシデント・パッケージのプリファレンスを設定できます。インシデント・パッケージのプリファレンスの例には、インシデント情報を保持する日数や、各問題のパッケージに含める最初と最後のインシデント数などがあります。
親トピック: 診断データの管理
9.10.1 インシデント・パッケージ
インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造に診断データを収集できます。
- インシデント・パッケージについて
Oracleサポートに診断データをアップロードするためのカスタマイズ・アプローチでは、最初に、インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造内にデータを収集します。 - インシデント・パッケージ内の関係付けられた診断データについて
問題を診断するには、問題に直接関連する診断データのみでなく、直接関連するデータと相関する診断データも調べることが必要になる場合があります。 - クイック・パッケージングとカスタム・パッケージングについて
サポート・ワークベンチでは、インシデント・パッケージを作成してアップロードするために、クイック・パッケージング方法とカスタム・パッケージング方法の2つの方法を提供しています。 - 相関パッケージについて
相関パッケージは、関連する問題の診断データをパッケージおよびアップロードするための手段を提供します。
9.10.1.1 インシデント・パッケージについて
診断データをカスタマイズしてOracleサポート・サービスにアップロードするには、最初に、インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造にデータを収集します。
パッケージは自動診断リポジトリ(ADR)に格納されているメタデータの集合で、ADR内外の診断データファイルやその他のファイルを指し示します。パッケージを作成するときは、そのパッケージに追加する問題を1つ以上選択します。次に、サポート・ワークベンチによって、選択した問題に関連する問題情報、インシデント情報および診断データ(トレース・ファイル、ダンプなど)がパッケージに自動的に追加されます。1つの問題に対して多数のインシデント(同じ問題の多数の発生)が存在する場合があるため、デフォルトでは、各問題の最初の3つと最後の3つのインシデントのみがパッケージに追加され、発生から90日を超えるインシデントは除外されます。このデフォルトの数は、サポート・ワークベンチの「インシデント・パッケージング構成」ページで変更できます。
パッケージが作成されたら、あらゆるタイプの外部ファイルをパッケージに追加し、パッケージから選択したファイルを削除し、重要なデータを削除するパッケージ内の選択したファイルを編集できます。パッケージの内容を追加および削除する場合は、パッケージのメタデータのみが変更されます。
診断データをOracleサポート・サービスにアップロードする準備ができたら、最初に、パッケージのメタデータで参照されるすべてのファイルを含めてZIPファイルを作成します。次に、Oracle Configuration Managerを使用してそのZIPファイルをアップロードします。
注意:
Oracle Configuration Managerをインストールしていないか、適切に構成していない場合は、My Oracle Supportを使用してZIPファイルを手動でアップロードする必要があります。
Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。
9.10.1.2 インシデント・パッケージ内の関係付けられた診断データについて
問題を診断するには、問題に直接関連する診断データのみでなく、直接関連するデータと相関する診断データも調べる必要がある場合があります。
診断データは、時間、プロセスIDまたはその他の基準によって関係付けることができます。たとえば、インシデントの検証では、そのインシデントの5分後に発生したインシデントの検証も役立つ場合があります。同様に、インシデントの診断データには、インシデント発生時に実行されていたOracle Databaseプロセスのトレース・ファイルが含まれていることは明確ですが、元のプロセスに関連する他のプロセスのトレース・ファイルを含めることが役に立つ場合もあります。
このため、問題とそれに関連するインシデントがパッケージに追加されるときは、同時に、関連するトレース・ファイルとともに関係付けられたインシデントが追加されます。
パッケージの物理ファイルを作成する過程で、サポート・ワークベンチはインシデント・パッケージング・サービスを要求してパッケージをファイナライズします。ファイナライズとは、パッケージ内のインシデントに時間で関係付けられた追加のトレース・ファイル、および他の診断情報(アラート・ログ、ヘルス・チェッカ・レポート、SQLテスト・ケース、構成情報など)をパッケージに追加することを意味します。そのため、ZIPファイル内のファイル数が、サポート・ワークベンチでパッケージ・コンテンツとして表示されたファイルの数より多くなる場合があります。
インシデント・パッケージング・サービスは一連のルールに従って、既存のパッケージ・データに関係付けるADR内のトレース・ファイルを決定します。一部のルールは、Cloud Controlの「インシデント・パッケージング構成」ページで変更できます。
当初のパッケージ・データと関係付けられた追加データには機密情報が含まれている可能性があるため、Oracleサポート・サービスにアップロードする前に、このような機密情報を含むファイルを削除または編集することが重要です。このため、サポート・ワークベンチでは、パッケージをファイナライズするコマンドを独立した操作として実行できます。パッケージを手動でファイナライズした後は、パッケージ・コンテンツを検証し、ファイルを削除または編集してから、ZIPファイルを生成してアップロードできます。
注意:
パッケージのファイナライズは、パッケージがクローズして変更不可になることではありません。ファイナライズしたパッケージには、引続き診断データを追加できます。また、同じパッケージを複数回ファイナライズすることもできます。ファイナライズするたびに、関係付けられた新しいデータが追加されます。
親トピック: インシデント・パッケージ
9.10.1.3 クイック・パッケージングとカスタム・パッケージングについて
サポート・ワークベンチには、インシデント・パッケージを作成してアップロードする方法として、クイック・パッケージング方法とカスタム・パッケージング方法があります。
クイック・パッケージング: 最小限のステップがある自動化された方法で、ガイド付きワークフロー(ウィザード)に編成されています。1つの問題を選択してパッケージ名と説明を入力し、パッケージ・コンテンツのアップロードを即時に実行するか、指定の日時に実行するかをスケジュールします。サポート・ワークベンチでは、問題に関連する診断データを自動的にパッケージに追加してファイナライズし、ZIPファイルを作成してアップロードします。この方法では、パッケージ・ファイルを追加、編集または削除したり、SQLテスト・ケースなどの他の診断データを追加することはできません。ただし、この方法は、初期障害診断データをOracleサポート・サービスにアップロードする最も簡単かつ迅速な方法です。クイック・パッケージングは、「問題の調査、レポートおよび解決」で説明しているワークフローで使用される方法です。
クイック・パッケージングが完了した後、ウィザードで作成されたパッケージはそのまま残ります。このパッケージは、カスタム・パッケージング操作を使用して後で変更し、手動で再アップロードできます。
カスタム・パッケージング: ステップが多く、より詳細な手動の方法です。これは、パッケージング・プロセスの詳細な制御を行うエキスパートのサポート・ワークベンチ・ユーザーを対象としています。カスタム・パッケージングでは、1つ以上の問題のある新規パッケージを作成、または1つ以上の問題を既存のパッケージに追加できます。これらの各種の操作を新規または更新されたパッケージで実行でき、これには次の操作が含まれます。
-
問題やインシデントを追加または削除できます。
-
パッケージに対してトレース・ファイルを追加、編集または削除できます。
-
任意のタイプの外部ファイルを追加または削除できます。
-
その他の診断データ(SQLテスト・ケースなど)を追加できます。
-
パッケージを手動でファイナライズしてからパッケージ・コンテンツを表示して、機密データを編集または削除する必要があるか、ファイルを削除してパッケージ・サイズを縮小する必要があるかを決定できます。
これらの操作には、Oracleサポートに送信する診断情報が十分であることを確認するまで、数日間かかる場合があります。
カスタム・パッケージングでは、ZIPファイルの作成とOracleサポートへのアップロードの要求を、2つの独立したステップとして実行できます。各ステップは、即時に実行するか、日時をスケジュールして実行できます。
関連項目:
クイック・パッケージング方法の手順については、「タスク5: 診断データのパッケージ化とOracleサポートへのアップロード」を参照してください
親トピック: インシデント・パッケージ
9.10.1.4 相関パッケージについて
相関パッケージは、関連する問題に対して診断データのパッケージングおよびアップロードのための手段を提供します。
「トポロジ全体に関連する問題」で説明しているように、データベース・インスタンスの問題は、他のデータベース・インスタンスやOracle Automatic Storage Managementインスタンスの問題に関連している可能性があります。データベース・インスタンスの問題に対するパッケージ(メイン・パッケージ)を作成およびアップロードした後、関連する問題についての相関パッケージを作成およびアップロードできます。これは、サポート・ワークベンチのカスタム・パッケージング・ワークフローでのみ実行できます。
関連項目:
親トピック: インシデント・パッケージ
9.10.2 カスタム・パッケージングを使用した問題のパッケージ化とアップロード
サポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージ(パッケージ)を作成およびアップロードできます。アップロードする前に、診断データ・ファイルをパッケージから手動で追加、編集、および削除できます。
カスタム・パッケージングを使用して問題をパッケージ化およびアップロードするには:
-
「サポート・ワークベンチ」ホームページにアクセスします。
手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。
-
(オプション)パッケージに含める各問題について、問題に関連付けられているサービス・リクエスト番号(SR#)を指定します(ある場合)。指定するには、各問題について次のステップを実行します。
-
「サポート・ワークベンチ」ホームページの下部にある「問題」サブページで、問題を選択して「表示」をクリックします。
注意:
問題のリストに対象の問題がみつからない場合、または問題数が多くてスクロールできない場合は、「表示」リストから期間を選択して「実行」をクリックします。対象の問題を選択して「表示」をクリックします。
問題の詳細ページが表示されます。
-
SR#ラベルの横にある「編集」をクリックし、サービス・リクエスト番号を入力して、「OK」をクリックします。
「問題の詳細」ページにサービス・リクエスト番号が表示されます。
-
ページの上部にあるロケータ・リンクで「サポート・ワークベンチ」をクリックし、「サポート・ワークベンチ」ホームページに戻ります。
-
-
「サポート・ワークベンチ」ホームページで、パッケージ化する問題を選択して「パッケージ」をクリックします。
「パッケージング・モードの選択」ページが表示されます。
注意:
パッケージング・プロセスでは、関係付けられた追加の問題を自動的に選択してパッケージに追加できます。関係付けられた問題の例には、選択した問題の数分後に発生した問題があります。詳細は、「インシデント・パッケージ内の関係付けられた診断データについて」を参照してください。
-
「カスタム・パッケージング」オプションを選択して「続行」をクリックします。
「カスタム・パッケージング: パッケージの選択」ページが表示されます。
-
次のいずれかの操作を行います。
-
新規パッケージを作成するには、「新規パッケージの作成」オプションを選択し、パッケージ名と説明を入力して「OK」をクリックします。
-
選択した問題を既存のパッケージに追加するには、「既存パッケージからの選択」オプションを選択し、更新するパッケージを選択して「OK」をクリックします。
「パッケージのカスタマイズ」ページが表示されます。選択するパッケージ・タスクのセレクションに加え、パッケージに含まれている問題およびインシデントが表示されます。新しいパッケージまたは更新した既存パッケージに対して実行できます。
-
-
(オプション)「パッケージング・タスク」セクションで、リンクをクリックして1つ以上のパッケージング・タスクを実行します。または、「パッケージのカスタマイズ」ページとそのサブページにある他のコントロールを使用して、パッケージを操作します。完了後に「パッケージのカスタマイズ」ページに戻ります。
いくつかの一般的なパッケージング・タスクの手順については、「インシデント・パッケージの表示と変更」を参照してください。
-
「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「Oracleサポートに送信」ヘッダー下にある「コンテンツ準備の終了」をクリックしてパッケージをファイナライズします。
パッケージに含まれるファイルのリスト(または部分的なリスト)が表示されます。(これには少し時間がかかる場合があります。)リストには、相関診断情報を含むかどうかを識別し、終了プロセスによって追加されたファイルが含まれます。
パッケージのファイナライズの定義の概要については、「インシデント・パッケージ内の関係付けられた診断データについて」を参照してください。
-
「ファイル」をクリックして、パッケージ内のファイルをすべて表示します。リストを検証して、公開できない機密データのファイルがあるかどうかを確認します。該当するファイルが見つかった場合は、それらのファイルを除外(削除)または編集します。
ファイルを編集および削除する手順については、「インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)」および「インシデント・パッケージ・ファイルの削除」を参照してください。
ファイルの内容を表示するには、ファイルの表の右側の列にある眼鏡アイコンをクリックします。ホスト資格証明を入力します(要求された場合)。
注意:
通常、トレース・ファイルはOracle内部でのみ使用します。
-
「アップロード・ファイルの生成」をクリックします。
「アップロード・ファイルの生成」ページが表示されます。
-
「全体」または「増分」オプションを選択して、全パッケージのZIPファイルまたは増加分パッケージのZIPファイルを生成します。
全パッケージのZIPファイルの場合は、常にパッケージのすべてのコンテンツ(元のコンテンツおよび関係付けられたすべてのデータ)がZIPファイルに追加されます。
増加分パッケージのZIPファイルの場合は、同じパッケージのZIPファイルが最後に作成された時点以降に新規追加または変更された診断情報のみがZIPファイルに追加されます。たとえば、パッケージに対して生成された物理ファイルにトレース・ファイルが最後に追加された時点以降にトレース情報がそのトレース・ファイルに追加された場合は、そのトレース・ファイルが増加分パッケージのZIPファイルに追加されます。逆に、パッケージに対して最後にアップロードした時点以降にトレース・ファイルを変更していない場合、そのトレース・ファイルは増加分パッケージのZIPファイルに追加されません。
注意:
パッケージに対してアップロード・ファイルが作成されていない場合、「増分」オプションは使用不可になります。
-
ファイル作成を即時実行するか、後の日時に実行するかをスケジュールして(「即時」または「後で」を選択)、「発行」をクリックします。
ファイル作成ではシステム・リソースを大量に使用する場合があるため、ファイルの作成は、システム使用量が少ない時期にスケジュールすることをお薦めします。
「処理中」ページが表示され、ZIPファイルが作成されます。処理が完了すると、確認ページが表示されます。
注意:
ZIPファイルが作成されると、パッケージは自動的にファイナライズされます。
-
「OK」をクリックします。
「パッケージのカスタマイズ」ページに戻ります。
-
「Oracleに送信」をクリックします。
「アップロード・ファイルの表示/送信」ページが表示されます。
-
(オプション)相関パッケージを作成してオラクル社に送信するには、「相関パッケージの送信」リンクをクリックします。
「相関パッケージの作成、編集およびアップロード」を参照してください。相関パッケージに対する作業が完了した後、ページの上部にある「パッケージの詳細」リンクをクリックし、「パッケージのカスタマイズ」をクリックし、次に、再度「Oracleに送信」をクリックして、「アップロード・ファイルの表示/送信」ページに戻ります。
-
アップロードするZIPファイルを選択して「Oracleに送信」をクリックします。
「Oracleに送信」ページが表示されます。選択したZIPファイルが表にリストされます。
-
要求されたMy Oracle Support情報を入力します。「新規サービス・リクエスト(SR)の作成」の横にある「はい」または「いいえ」を選択します。「はい」を選択すると、ドラフトのサービス・リクエストが作成されます。この場合は、後でMy Oracle Supportにログインして、サービス・リクエストの詳細を入力する必要があります。「いいえ」を選択した場合は、既存のサービス・リクエスト番号を入力します。
-
アップロードを即時または後の日時にスケジュールして、「発行」をクリックします。
「処理中」ページが表示されます。アップロードが正常に完了した場合は、確認ページが表示されます。アップロードが完了できなかった場合は、エラー・ページが表示されます。エラー・ページには、ZIPファイルをOracleに手動でアップロードするように要求するメッセージが表示される場合があります。その場合の手順については、Oracleサポート・サービス担当者に問い合せてください。
-
「OK」をクリックします。
「アップロード・ファイルの表示/送信」ページに戻ります。「送信時刻」列で、アップロードしたファイルのステータスをチェックします。
注意:
サポート・ワークベンチでは、Oracle Configuration Managerを使用して物理ファイルをアップロードします。Oracle Configuration Managerがインストールされていなかったり、適切に構成されていないと、アップロードに失敗する場合があります。失敗した場合は、ファイルをOracleサポート・サービスに手動でアップロードするように要求するメッセージが、パッケージのZIPファイルへのパスとともに表示されます。アップロードは、My Oracle Supportを使用して手動で実行できます。
Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。
-
(オプション)相関パッケージを作成およびアップロードします。
手順については、「相関パッケージの作成、編集およびアップロード」を参照してください。
9.10.3 インシデント・パッケージの表示と変更
カスタム・パッケージング方法を使用してインシデント・パッケージを作成した後は、Oracleサポート・サービスへのアップロード前に、そのパッケージのコンテンツを表示または変更できます。
さらに、クイック・パッケージング方法を使用して診断データをパッケージ化してアップロードした後は、サポート・ワークベンチで作成したパッケージのコンテンツを表示または変更して、パッケージを再アップロードできます。パッケージを変更するには、パッケージ・タスクの選択対象から選択しますが、それらのほとんどは「パッケージのカスタマイズ」ページで使用できます。
- パッケージの詳細の表示
「パッケージの詳細」ページには、パッケージ内のインシデント、トレース・ファイルおよびその他のファイルに関する情報が含まれており、アクティビティ・ログを表示してパッケージに追加できます。 - 「パッケージのカスタマイズ」ページへのアクセス
「パッケージのカスタマイズ」ページでは、問題の追加および削除、パッケージ・ファイルの追加、削除および修正(編集)、パッケージのZIPファイルの生成およびアップロードなどの様々なパッケージング・タスクを実行します。 - インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)
サポート・ワークベンチでは、インシデント・パッケージ内の1つ以上のファイルを編集できます。 - インシデント・パッケージへの外部ファイルの追加
インシデント・パッケージには、任意のタイプの外部ファイルを追加できます。 - インシデント・パッケージ・ファイルの削除
インシデント・パッケージから任意のタイプのファイルを1つ以上削除できます。 - インシデント・パッケージのアクティビティ・ログの表示と更新
サポート・ワークベンチでは、各インシデント・パッケージのアクティビティ・ログが保持されます。
9.10.3.1 パッケージの詳細の表示
「パッケージの詳細」ページには、パッケージ内のインシデント、トレース・ファイルおよびその他のファイルに関する情報が含まれており、アクティビティ・ログを表示してパッケージに追加できます。
パッケージの詳細を表示するには:
親トピック: インシデント・パッケージの表示と変更
9.10.3.2 「パッケージのカスタマイズ」ページへのアクセス
「パッケージのカスタマイズ」ページでは、各種のパッケージング・タスク(問題の追加および削除、パッケージ・ファイルの追加、削除および修正(編集)、パッケージのZIPファイルの生成およびアップロードなど)を実行します。
「パッケージのカスタマイズ」ページにアクセスするには:
親トピック: インシデント・パッケージの表示と変更
9.10.3.3 インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)
サポート・ワークベンチを使用すると、インシデント・パッケージ内の1つ以上のファイルを編集できます。
この作業は、ファイル内の機密データを削除または上書きする場合に必要です。パッケージ・ファイルを編集するには、最初にパッケージから宛先ディレクトリにファイルをコピー・アウトし、テキスト・エディタまたは他のユーティリティを使用して編集してから、そのファイルをパッケージにコピーし直して、元のパッケージ・ファイルを上書きします。
次の手順では、パッケージがすでに作成されて診断データが格納されていることを前提としています。
インシデント・パッケージ・ファイルを編集するには:
-
対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
-
「パッケージング・タスク」セクションで、「ユーザー・データの修正」ヘッダー下にある「コンテンツ編集のためのファイルのコピー・アウト」をクリックします。
ホスト資格証明を要求された場合は、資格証明を入力し、「OK」をクリックします。
ファイルのコピー・アウト・ページが表示されます。ファイルをコピーできるホスト名が表示されます。
-
次のいずれかを実行して、ファイルの宛先ディレクトリを指定します。
-
「宛先フォルダ」フィールドにディレクトリ・パスを入力します。
-
「宛先フォルダ」フィールドの横にある拡大鏡アイコンをクリックして、次のステップを実行します。
-
ホスト資格証明がプロンプトで要求された場合は、ファイルのコピー・アウト先のホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。
「参照および選択: ファイルまたはディレクトリ」ウィンドウが表示されます。
-
対象の宛先ディレクトリを選択して「選択」をクリックします。
「参照および選択: ファイルまたはディレクトリ」ウィンドウがクローズし、選択したディレクトリへのパスが「ファイルのコピー・アウト」ページの「宛先フォルダ」フィールドに表示されます。
-
-
-
「コピー・アウトするファイル」で、対象のファイルを選択して「OK」をクリックします。
注意:
対象のファイルが見つからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「OK」をクリックします。
「パッケージのカスタマイズ」ページに戻ると、コピー・アウトされたファイルをリストした確認メッセージが表示されます。
-
テキスト・エディタまたは他のユーティリティを使用して、ファイルを編集します。
-
「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「ユーザー・データの修正」ヘッダー下にある「コンテンツ置換えのためのファイルのコピー・イン」をクリックします。
ファイルのコピー・イン・ページが表示されます。コピーしたファイルが表示されます。
-
コピー・インするファイルを選択して「OK」をクリックします。
ファイルがパッケージにコピー・インされて、既存のファイルが上書きされます。「パッケージのカスタマイズ」ページに戻ると、コピー・インされたファイルをリストした確認メッセージが表示されます。
親トピック: インシデント・パッケージの表示と変更
9.10.3.4 インシデント・パッケージへの外部ファイルの追加
インシデント・パッケージには、任意のタイプの外部ファイルを追加できます。
外部ファイルをインシデント・パッケージに追加するには:
-
対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
-
「ファイル」リンクをクリックして「ファイル」サブページを表示します。
このページでは、パッケージに対してファイルを追加または削除できます。
-
「外部ファイルの追加」をクリックします。
外部ファイルの追加ページが表示されます。これには選択したファイルからホスト名が表示されます。
-
次のいずれかを実行して、追加するファイルを指定します。
-
「ファイル名」フィールドに、ファイルへのフルパスを入力します。
-
「ファイル名」フィールドの横にある拡大鏡アイコンをクリックして、次のステップを実行します。
-
ホスト資格証明がプロンプトで要求された場合は、外部ファイルが存在するホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。
-
「参照および選択: ファイルまたはディレクトリ」ウィンドウで必要なファイルを選択し、「選択」をクリックします。
「参照および選択」ウィンドウがクローズし、選択したファイルへのパスが「外部ファイルの追加」ページの「ファイル名」フィールドに表示されます。
-
-
-
「OK」をクリックします。
「パッケージのカスタマイズ」ページに戻ると、「ファイル」サブページが表示されます。これで、選択したファイルがファイル・リストに表示されます。
親トピック: インシデント・パッケージの表示と変更
9.10.3.5 インシデント・パッケージ・ファイルの削除
インシデント・パッケージから任意のタイプのファイルを1つ以上削除できます。
インシデント・パッケージ・ファイルを削除するには:
親トピック: インシデント・パッケージの表示と変更
9.10.3.6 インシデント・パッケージのアクティビティ・ログの表示と更新
サポート・ワークベンチでは、インシデント・パッケージごとにアクティビティ・ログが保持されます。
パッケージに対して実行したほとんどのアクティビティ(ファイルの追加や削除、パッケージのZIPファイルの作成など)はログに記録されます。独自のノートをログに追加することもできます。特に、これは、複数のデータベース管理者がパッケージを使用している場合に役立ちます。
インシデント・パッケージのアクティビティ・ログを表示および更新するには:
親トピック: インシデント・パッケージの表示と変更
9.10.4 相関パッケージの作成、編集およびアップロード
Oracleサポート・サービスにパッケージをアップロードした後、1つ以上の相関パッケージを作成およびアップロードできます。
データベース・ホームページの「関連アラート」セクションにクリティカル・アラートが表示されている場合は上記をお薦めします。相関パッケージは、メイン・パッケージと呼ばれる元のパッケージと関連付けられています。メイン・パッケージには、データベース・インスタンス内で発生した問題が含まれます。相関パッケージには、他のインスタンス(Oracle ASMインスタンスやその他のデータベース・インスタンス)で発生した問題や、メイン・パッケージにある問題に関連する問題が含まれます。相関パッケージは、関連するインスタンスにそれぞれ1つのみ存在できます。
相関パッケージを作成、編集およびアップロードするには:
-
メイン・パッケージの「パッケージの詳細」ページを表示します。
手順については、「パッケージの詳細の表示」を参照してください。
-
「パッケージの詳細」ページ上で「パッケージのカスタマイズ」をクリックします。
-
「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションの「追加の診断データ」で、「相関パッケージの作成/更新」をクリックします。
-
「相関パッケージ」ページの「相関パッケージ」で、インシデントのあるインスタンスを1つ以上選択して「作成」をクリックします。
確認メッセージが表示され、新規に作成された相関パッケージのパッケージIDが「ID」列に表示されます。
-
相関パッケージを作成したインスタンスを選択し、「コンテンツ準備の終了」をクリックします。
確認メッセージが表示されます。
-
(オプション)次のステップで相関パッケージを表示および編集します。
-
パッケージIDをクリックしてパッケージを表示します。
資格証明を要求された場合は、「ログイン」をクリックします。
-
「パッケージの詳細」ページで「ファイル」をクリックしてパッケージ内のファイルを表示します。
-
「パッケージのカスタマイズ」をクリックして、「インシデント・パッケージの表示と変更」に記載されている目的のカスタマイズ・タスクを実行します。
-
-
アップロードするそれぞれの相関パッケージについて、「アップロード・ファイルの生成」をクリックします。
-
オラクル社に送信するそれぞれの相関パッケージについて、「Oracleに送信」をクリックします。
注意:
「Oracleに送信」が使用できない場合は、そのインスタンスに対して関連付けられたインシデントはありません。
関連項目:
9.10.5 相関パッケージの削除
相関パッケージは、そのパッケージを作成したターゲットのサポート・ワークベンチで削除します。
たとえば、Oracle ASMインスタンス・ターゲットに対して相関パッケージを作成した場合は、そのOracle ASMインスタンスのサポート・ワークベンチにアクセスします。
相関パッケージを削除するには:
関連項目:
9.10.6 インシデント・パッケージのプリファレンスの設定
インシデント・パッケージのプリファレンスを設定できます。インシデント・パッケージのプリファレンスの例には、インシデント情報を保持する日数や、各問題のパッケージに含める最初と最後のインシデント数などがあります。
デフォルトでは、問題のインシデントが多数存在する場合、最初の3つと最後の3つのインシデントのみがパッケージ化されます。これらまたはその他のインシデント・パッケージのプリファレンスは、Cloud ControlまたはADRCIユーティリティを使用して変更できます。
Cloud Controlを使用してインシデント・パッケージのプリファレンスを設定するには:
関連項目: