| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
リリース11g以降のOracle Databaseは、診断データを収集して管理するための高度な障害診断インフラストラクチャを備えています。診断データには、以前のリリースにも含まれていたトレース・ファイル、ダンプおよびコア・ファイルに加えて、顧客やOracleサポート・サービスが問題を迅速かつ効率的に識別、調査、追跡、解決できる新しいタイプの診断データが含まれています。
この章の内容は、次のとおりです。
ここでは、Oracle Databaseの障害診断インフラストラクチャに関するバックグラウンド情報を説明します。内容は次のとおりです。
障害診断インフラストラクチャは、問題の防止、検出、診断および解決に役立ちます。特に対象とする問題はクリティカル・エラーで、これには、コードの不具合、メタデータの破損、顧客データの破損によって生じるエラーなどがあります。
クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断データ(トレース・ファイルなど)が即座に取得され、その番号でタグ付けされます。このデータは、自動診断リポジトリ(ADR) (データベースの外部のファイルベースのリポジトリ)に格納され、後からインシデント番号によって取得して分析できます。
障害診断インフラストラクチャの目的は次のとおりです。
初期障害の診断
問題の防止
問題が検出された後の損害および中断の抑制
問題の診断時間の短縮
問題の解決時間の短縮
顧客とOracleサポートのやり取りの簡略化
これらの目的を達成するための主要なテクノロジは、次のとおりです。
初期障害発生時の診断データの自動取得: クリティカル・エラーの場合は、初期障害時にエラー情報を取得することによって、問題の早期解決と停止時間の短縮の可能性が飛躍的に増大します。常時機能しているメモリーベースのトレース・システムは、多くのデータベース・コンポーネントから診断データを事前に収集するため、問題の根本原因を特定するのに役立ちます。このような事前の診断データは、飛行機の「ブラック・ボックス」フライト・レコーダで収集されるデータに類似しています。問題が検出されると、アラートが生成されて、障害診断インフラストラクチャがアクティブになり、診断データが取得されて格納されます。診断データは、データベースの外部にあるリポジトリに格納され(したがって、データベースが停止した場合でもデータを使用できます)、コマンドライン・ユーティリティおよびEnterprise Managerを使用して簡単にアクセスできます。
標準化されたトレース形式: すべてのデータベース・コンポーネント間でトレース形式を標準化することによって、DBAおよびOracleサポート・サービス担当者は単一のツール・セットを使用して問題を分析できます。問題の診断はさらに容易となり、停止時間は短縮されます。
ヘルス・チェック: クリティカル・エラーが検出されると、障害診断インフラストラクチャでは1つ以上のヘルス・チェックが実行され、クリティカル・エラーの詳細な分析が実行されます。ヘルス・チェックの結果は、エラーについて収集された他の診断データに追加されます。各ヘルス・チェックでは、データ・ブロックの破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。DBAは、定期的にまたは必要に応じてこれらのヘルス・チェックを手動で起動できます。
インシデント・パッケージ化サービス(IPS)およびインシデント・パッケージ: IPSを使用すると、クリティカル・エラーに関する診断データ(トレース、ダンプ、ヘルス・チェック・レポートなど)を自動的かつ容易に収集し、それらのデータをzipファイルにパッケージ化してOracleサポートに転送できます。クリティカル・エラーに関するすべての診断データは、そのエラーのインシデント番号でタグ付けされるため、分析に必要なファイルを判別するためにトレース・ファイルやその他のファイルを検索する必要はなく、インシデント・パッケージング・サービスにより必要なファイルが自動的に特定され、zipファイルに追加されます。zipファイルを作成する前に、IPSはまず、インシデント・パッケージという中間論理構造(パッケージ)に診断データを収集します。パッケージは自動診断リポジトリに格納されます。必要に応じて、この中間論理構造にアクセスして、その内容を表示および修正したり、詳細な診断データをいつでも追加または削除でき、さらに準備ができたらパッケージからzipファイルを作成できます。これらの手順が完了すれば、Oracleサポートにアップロードするzipファイルの準備は完了です。
データ・リカバリ・アドバイザ: データ・リカバリ・アドバイザはデータベースのヘルス・チェックおよびRMANに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。
SQLテスト・ケース・ビルダー: 多くのSQL関連の問題では、再現可能なテスト・ケースの取得が、問題の迅速な解決にとって重要な要因となります。問題とそれが発生した環境に関する可能なかぎりの情報を収集することは困難で時間がかかる場合がありますが、SQLテスト・ケース・ビルダーは、この収集作業を自動化します。迅速に収集された情報をOracleサポート・サービスにアップロードすると、サポート担当者は問題を簡単かつ正確に再現できます。
|
関連項目:
|
クリティカル・エラーの診断と解決を容易にするために、障害診断インフラストラクチャには、問題とインシデントというOracle Databaseの概念が導入されています。
問題とは、データベース・インスタンス、Oracle Automatic Storage Management(Oracle ASM)インスタンス、またはその他のOracle製品やコンポーネントにおけるクリティカル・エラーです。クリティカル・エラーには、内部エラー(ORA-00600など)やその他の深刻なエラー(ORA-07445(オペレーティング・システム例外)またはORA-04031(共有プールのメモリー不足))が含まれます。問題はADRで追跡されます。各問題には、問題を説明する文字列である問題キーがあります。これには、エラー・コード(ORA 600など)、場合によってはさらに1つ以上のエラー・パラメータが含まれます。
インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントには日時が記録され、自動診断リポジトリ(ADR)で追跡されます。各インシデントは、ADR内で一意の数値であるインシデントIDによって識別されます。インシデントが発生すると、データベースでは次の処理が実行されます。
アラート・ログにエントリを作成します。
Oracle Enterprise Manager (Enterprise Manager)にインシデント・アラートを送信します。
インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。
インシデント・ダンプをインシデントIDにタグ付けします。
そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。
クリティカル・エラーの診断と解決は、通常、インシデント・アラートから開始されます。インシデント・アラートは、Enterprise Managerのデータベース・ホームページまたはOracle Automatic Storage Managementのホームページに表示されます。また、データベース・ホームページは、Oracle ASMインスタンスやその他のOracle製品またはコンポーネントのクリティカル・アラートを「関連アラート」セクションに表示します。アラートを表示した後、問題および関連するインシデントは、Enterprise ManagerまたはADRCIコマンドライン・ユーティリティを使用して表示できます。
次の項ではインシデントおよび問題について詳細に説明します。
問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。このような理由から、障害診断インフラストラクチャでは、特定のしきい値に達すると、インシデントの生成にフラッド制御が適用されます。フラッド制御されたインシデントとは、アラート・ログ・エントリは作成されてADRに記録されるが、インシデント・ダンプは生成されないインシデントです。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。Enterprise ManagerまたはADRCIのコマンドライン・ユーティリティを使用してインシデントを表示するときは、フラッド制御されたインシデントを表示するか非表示にするかを選択できます。
インシデントのフラッド制御のしきい値レベルは事前定義されており、変更できません。しきい値レベルは次のように定義されています。
1時間に同じ問題キーに対して5つのインシデントが発生した場合、その問題キーに対する後続のインシデントはフラッド制御されます。その問題キーに対するインシデントの通常(非フラッド制御)の記録は、次の1時間から再開されます。
1日に同じ問題キーに対して25のインシデントが発生した場合、その問題キーに対する後続のインシデントはフラッド制御されます。その問題キーに対するインシデントの通常の記録は、翌日から再開されます。
さらに、1時間に同じ問題キーに対して50のインシデントが発生した場合、または1日に同じ問題キーに対して250のインシデントが発生した場合、その問題キーに対する後続のインシデントはADRに記録されません。この場合は、後続のインシデントが記録されないことを示すメッセージがアラート・ログに書き込まれます。問題キーに対してインシデントが継続して生成されている間は、1時間または1日が経過するまで、10分ごとにこのメッセージがアラート・ログに追加されます。1時間または1日が経過すると、その問題キーに対するインシデントの通常の記録が再開されます。
データベース・インスタンスで識別されるすべての問題については、診断能力フレームワークによって、Oracle Databaseインストールのトポロジ全体に関連する問題が識別できます。単一インスタンス環境では、関連する問題はローカルのOracle ASMインスタンスで識別できます。Oracle RAC環境では、関連する問題はデータベース・インスタンスまたは他のノード上のOracle ASMインスタンスで識別できます。問題を調査する場合、関連する問題の情報を表示して収集できます。
問題が指定期間内に発生したり、同じ実行コンテキスト識別子を共有している場合、その問題は元の問題に関連しています。実行コンテキスト識別子(ECID)は、後からデータを取得するためにOracle DatabaseにコールするOracle Fusion Middlewareへのコールなど、Oracleソフトウェア・スタックを介した単一のコールに対するタグ付けおよび追跡のために使用されるグローバルに一意の識別子です。通常、ECIDは中間層で生成され、Oracle Call Interface (OCI)の属性としてデータベースに渡されます。Oracleソフトウェア・スタックの複数の層に単一のコールによる障害が存在する場合、生成された問題には同じECIDがタグ付けされるため、相関関係を確認できます。さらに、源になっている問題が発生した層を判別できます。
障害診断インフラストラクチャの主要なコンポーネントは次のとおりです。
ADRは、データベース診断データ(トレース、ダンプ、アラート・ログ、状態モニターのレポートなど)のファイルベース・リポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。リリース11g以降では、データベース、Oracle Automatic Storage Management(Oracle ASM)、リスナー、およびその他のオラクル社の製品やコンポーネントは、すべての診断データをADRに格納します。各製品のインスタンスはそれぞれ、診断データをADR内の独自のホーム・ディレクトリの下に配置します。たとえば、共有記憶域とOracle ASMを使用するOracle Real Application Clusters環境では、各データベース・インスタンスと各Oracle ASMインスタンスにADRホーム・ディレクトリがあります。ADRの統一されたディレクトリ構造、製品およびインスタンス間で一貫性のある診断データ形式、および統一されたツール・セットにより、ユーザーおよびOracleサポートは、複数のインスタンス間の診断データの相関関係を確認して分析できます。
アラート・ログは、データベースのメッセージとエラーの発生順のログのXMLファイルです。これはADRに格納され、次のものに関するメッセージが含まれます。
クリティカル・エラー(インシデント)
管理操作(データベースの起動と停止、データベースのリカバリ、表領域の作成や削除など)。
マテリアライズド・ビューの自動リフレッシュ中に発生したエラー
その他のデータベース・イベント
アラート・ログは、Enterprise ManagerおよびADRCIユーティリティを使用して、テキスト形式(XMLタグは削除されます)で表示できます。また、下位互換性のためにADRに格納されたテキスト形式のアラート・ログもあります。ただし、テキスト形式は構造化されておらず、リリースごとに変更される場合があるため、アラート・ログの内容の解析はXML形式で行うことをお薦めします。
トレース・ファイル、ダンプおよびコア・ファイルには、問題の調査に使用する診断データが含まれています。これらはADRに格納されます。
各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。トレース・ファイルはプロセスの存続期間にわたって定期的に更新され、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報を格納できます。さらに、プロセスでクリティカル・エラーが検出されると、そのエラーに関する情報が関連のトレース・ファイルに書き込まれます。トレース・ファイルはSQLトレース機能によっても作成され、各SQL文のパフォーマンス情報が提供されます。SQLトレース機能は、セッションまたはインスタンスに対して使用可能にできます。
トレース・ファイルの名前は、プラットフォームに依存します。通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれ、サーバー・プロセスのトレース・ファイル名には、Oracle SID、「ora」の文字列、およびオペレーティング・システムのプロセス番号が含まれます。ファイル拡張子は.trcです。たとえば、サーバー・プロセスのトレース・ファイル名は、orcl_ora_344.trcのようになります。トレース・ファイルは、対応するトレース・マップ(.trm)ファイルを伴う場合があり、このファイルにはトレース・ファイルの構造情報が含まれていて、検索やナビゲーションに使用されます。
Oracle Databaseには、トレース・ファイルの分析に役立つツールが用意されています。アプリケーション・トレース機能、SQLトレース機能およびトレース・ツールの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ADRには、前の各項で説明したファイルに加えて、状態モニター・レポート、データ修復レコード、SQLテスト・ケース、インシデント・パッケージなどが格納されます。これらのコンポーネントについては、この章で後述します。
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)は、使いやすいグラフィカル・インタフェースで問題(クリティカル・エラー)を調査およびレポートできる機能で、場合によってはその問題を修復することもできます。サポート・ワークベンチでは、セルフサービス方式で、初期障害の診断データの収集、サポート・リクエスト番号の取得、および診断データのOracleサポートへのアップロードを最小限の労力と非常に短い時間で行えるので、問題の解決にかかる時間を短縮できます。また、サポート・ワークベンチでは、SQL関連の問題やデータ破損の問題などを解決できるOracleアドバイザへの容易なアクセスを推奨および提供します。
自動診断リポジトリ(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ホームのその他のサブディレクトリ。インシデント・パッケージ、状態監視レポートおよびその他の情報が格納される |
図9-2に、データベース・インスタンスのADRのディレクトリ階層全体を示します。
Oracle Real Application Clusters環境でのADR
Oracle Real Application Clusters(Oracle RAC)環境では、ADRベースはノードごとに独自のローカル記憶域に設定するか、ADRベースは共有記憶域に設定できます。ADRCIを使用して、すべてのインスタンスから集計された診断データを1つのレポートに表示できます。
インストールされた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リリースでクリティカル・エラーとして指定されている、内部エラー以外のすべてのエラーがリストされます。内部エラーは常にクリティカル・エラーとして指定されているため、このビューに内部エラーはリストされません。
次の例は、Oracle Database 11g リリース2 (11.2.0.2)での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)など) |
|
|
エラー番号 |
ここでは、Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、問題(クリティカル・エラー)を調査およびレポートし、場合によってはその問題を修復する方法について説明します。最初に、実行する必要がある一般的なタスクを要約した「ロードマップ」を示します。
|
注意: この項で説明するタスクは、すべてEnterprise Managerベースです。すべてのタスク(または同等のタスク)は、ADRCIコマンドライン・ユーティリティ、PL/SQLパッケージ(DBMS_HM、DBMS_SQLDIAGなど)、およびその他のソフトウェア・ツールを使用して実行できます。ADRCIユーティリティの詳細は『Oracle Databaseユーティリティ』 |
問題の調査は、Enterprise Managerの「サポート・ワークベンチ」ホームページから開始できます。ただし、標準的なワークフローはデータベースのホームページのクリティカル・エラー・アラートから始まります。この項では、そのワークフローの概要について説明します。
図9-3に、問題を調査およびレポートし、場合によってはその問題を修復するためのタスクを示します。
タスクの説明を次に示します。この後の項では、各タスクについて詳しく説明します。
タスク1: Enterprise Managerでのクリティカル・エラー・アラートの表示
最初に、Enterprise Managerでデータベースのホームページにアクセスし、クリティカル・エラー・アラートを確認します。詳細を表示するアラートを選択し、「問題の詳細」ページに進みます。
問題の詳細を検証し、その問題に対して記録されたすべてのインシデントのリストを表示します。自動的に実行された状態チェックの結果を表示します。
必要に応じて、追加のヘルス・チェックまたは他の診断を実行します。SQL関連エラーの場合は、必要に応じてSQLテスト・ケース・ビルダーを起動して、SQL問題に関連する必要なすべてのデータを収集し、Oracleサポート・サービスで問題を再現できる方法で情報をパッケージ化します。
必要に応じて、My Oracle Supportでサービス・リクエストを作成し、問題情報にサービス・リクエスト番号を追加して記録します。この手順をスキップした場合、サービス・リクエストは後で作成するか、サポート・ワークベンチで作成することができます。
タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード
問題のために収集された診断データを自動的にパッケージ化してOracleサポートにアップロードするガイド付きワークフロー(ウィザード)を起動します。
オプションとして、サービス・リクエストのアクティビティ・ログをサポート・ワークベンチでメンテナンスします。Oracleアドバイザを実行して、SQLエラーまたは破損データを修復します。
問題に対する1つ、複数またはすべてのインシデントのステータスを「クローズ」に設定します。
問題(クリティカル・エラー)を調査するプロセスでは、最初にデータベース・ホームページまたはOracle Automatic Storage Managementホームページでクリティカル・エラー・アラートを検討します。
クリティカル・エラー・アラートを表示するには、次のようにします。
Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
次の手順のうち1つを実行してクリティカル・エラー・アラートを表示します。クリティカル・エラー・アラートは「重大度」列に赤の×印で表示され、「カテゴリ」列に「インシデント」というテキストが表示されます。
「アラート」セクションでアラートを表示します。
「アラート」を表示するには、「アラート」ヘッダーの横にある表示/非表示アイコンをクリックすることが必要な場合があります。
「関連アラート」セクションでアラートを表示します。
「ターゲット名」は、クリティカル・エラーが発生したOracle製品またはコンポーネントを示します。詳細は、「トポロジ全体に関連する問題」を参照してください。
次の手順を実行して、Oracle ASMインスタンスのクリティカル・アラートを表示します。
「一般」セクションで「ASM」ラベルの横にあるリンクをクリックします。
自動ストレージ管理ホームページで下にスクロールして「アラート」セクションを表示します。
「メッセージ」列で、調査するクリティカル・エラー・アラートのメッセージをクリックします。
「インシデント」ページまたは「データ障害」ページが表示されます。このページには次の内容が表示されます。
問題に関する情報(問題のインシデント数を含む)
過去24時間に発生したクリティカル・エラーに関する「パフォーマンスとクリティカル・エラー」時間グラフ(データベース・インスタンスのみ)。
アラートの詳細(重大度、タイムスタンプ、メッセージを含む)
アラートをクリアしたり、アラートに関するコメントを記録するためのコントロール。
「パフォーマンスとクリティカル・エラー」時間グラフがあればこれを検討し、パフォーマンスの問題とクリティカル・エラーの間の関連をメモします。アラートはクリアしてもかまいませんが、コメントを付けて残しておくこともできます。
「問題の詳細」ページを表示して調査を続行します。
問題の詳細を表示するには、次のようにします。
「インシデント」ページまたは「データ障害」ページで、「問題の詳細の表示」をクリックします。
問題の詳細ページにインシデント・サブページが表示されます。
(オプション)次のどちらか、または両方を実行します。
「調査と解決」セクションの「セルフ・サービス」タブの「診断」で「トポロジ全体に関連する問題」をクリックします。
ローカルのOracle Automatic Storage Management(Oracle ASM)インスタンス、またはOracle Real Application Clusters環境における他のノード上のデータベースまたはOracle ASMインスタンスにおける関連する問題を示すページが表示されます。Enterprise Managerのデータベース・ホームページ上の「関連アラート」セクションにクリティカル・アラートが表示されている場合は、この手順をお薦めします。
詳細は、「トポロジ全体に関連する問題」を参照してください。
これらの手順を実行してインシデントの詳細を表示します。
「インシデント」サブページ内でインシデントを選択してから、「表示」をクリックします。
(オプション)「インシデントの詳細」ページで、「チェッカ結果」をクリックして「チェッカ結果」サブページを表示します。
このページには、クリティカル・エラー検出時に自動的に実行された状態チェックの結果が表示されます。
詳細は、「状態モニターを使用したヘルス・チェックの実行」を参照してください。
次のアクティビティを実行して、問題に関する追加の診断情報を収集します。この追加情報は、Oracleサポートにアップロードされる診断データに自動的に追加されます。これらのアクティビティの実行に関して不明な点がある場合は、Oracleサポートの担当者に確認してください。
追加のヘルス・チェックを手動で起動します。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。
SQLテスト・ケース・ビルダーを起動します。
詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ここでは、Oracleサポート・サービスへのサービス・リクエストを作成し、サービス・リクエスト番号を問題情報とともに記録できます。このタスクをスキップした場合は、タスク5で、サポート・ワークベンチでドラフトのサービス・リクエストが自動的に作成されます。
サービス・リクエストを作成するには、次のようにします。
「問題の詳細」ページの「調査と解決」セクションで、「My Oracle Support and Researchに移動」をクリックします。
新しいブラウザ・ウィンドウで「My Oracle Supportのサインインと登録」ページが表示されます。
My Oracle Supportにログインし、通常の方法でサービス・リクエストを作成します。
(オプション)次の手順のためにサービス・リクエスト番号(SR#)を覚えておきます。
(オプション)問題の詳細ページに戻り、次の手順を実行します。
「サマリー」セクションで、「SR#」ラベルの横にある「編集」ボタンをクリックします。
SR#を入力してから、「OK」をクリックします。
SR#が問題の詳細ページに記録されます。この情報は参照専用です。
このタスクでは、サポート・ワークベンチのクイック・パッケージング・プロセスを使用して、問題に関する診断情報をパッケージ化し、Oracleサポート・サービスにアップロードします。クイック・パッケージングは、最小限の手順をガイド付きワークフロー(ウィザード)にまとめたものです。ウィザードを使用して、1つの問題に対してインシデント・パッケージ(パッケージ)を作成し、そのパッケージからZIPファイルを作成してアップロードします。ただし、クイック・パッケージングでは、アップロードする診断情報の編集やその他のカスタマイズは行えません。ただし、クイック・パッケージングを使用すると、直接的かつ簡単な方法で診断データをパッケージ化してアップロードできます。
診断情報に含まれる機密データの編集や削除、追加のユーザー・ファイル(アプリケーション構成ファイルやスクリプトなど)の同封、その他のカスタマイズをアップロード前に実行するには、(手動のプロセスと手順が多い)カスタム・パッケージング・プロセスを使用する必要があります。手順については、「カスタム・インシデント・パッケージの作成、編集およびアップロード」を参照してください。このタスク5の手順のかわりにその手順を行う場合は、その手順を行い、完了してから「タスク6: サービス・リクエストの追跡と修復の実装」に進んでください。
|
注意: サポート・ワークベンチはOracle Configuration Managerを使用して診断データをアップロードします。Oracle Configuration Managerがインストールされていなかったり、適切に構成されていないと、アップロードに失敗する場合があります。この場合、メッセージが表示され、Oracleサポートへファイルを手動でアップロードするように要求されます。アップロードは、My Oracle Supportを使用して手動で実行できます。Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。 |
診断データをパッケージ化してOracleサポートにアップロードするには、次のようにします。
問題の詳細ページの「調査と解決」セクションで、「クイック・パッケージ」をクリックします。
「クイック・パッケージ」ウィザードの「新規パッケージの作成」ページが表示されます。
必要に応じて、パッケージ名と説明を入力します。
ページの残りのフィールドに必要事項を入力します。問題に対してサービス・リクエストをすでに作成している場合は、「新規サービス・リクエスト(SR)の作成」の横にある「いいえ」を選択します。
「はい」を選択すると、「クイック・パッケージング」ウィザードでドラフトのサービス・リクエストが作成されます。後でMy Oracle Supportにログインして、このサービス・リクエストの詳細を入力する必要があります。
「次」をクリックし、「クイック・パッケージング」ウィザードの残りのページに進みます。
作成されたパッケージは、クイック・パッケージング・ウィザードの手順の完了後も引き続きサポート・ワークベンチで使用できます。カスタム・パッケージング操作を使用してパッケージを変更し(新規インシデントの追加など)、後でパッケージを再アップロードできます。「インシデント・パッケージの表示と変更」を参照してください。
診断情報をOracleサポート・サービスにアップロードした後は、様々なアクティビティを実行してサービス・リクエストを追跡し、追加の診断情報を収集して、修復を実装できます。このアクティビティには次のものがあります。
問題情報にOracleバグ番号を追加します。
そのためには、問題の詳細ページで「バグ#」ラベルの横にある「編集」ボタンをクリックします。この情報は参照専用です。
このアクティビティは、組織内の他のDBAと問題ステータスや履歴情報を共有する場合に実行します。たとえば、Oracleサポート・サービスとの対話の結果を記録できます。コメントを追加する手順は、次のとおりです。
「Enterprise Managerサポート・ワークベンチを使用した問題の表示」で説明するように、該当する問題の「問題の詳細」ページにアクセスします。
「アクティビティ・ログ」をクリックして、アクティビティ・ログ・サブページを表示します。
「コメント」フィールドにコメントを入力し、「コメントの追加」をクリックします。
コメントがアクティビティ・ログに記録されます。
新規に発生したインシデントをパッケージ化して再アップロードします。
このアクティビティには、「カスタム・インシデント・パッケージの作成、編集およびアップロード」で説明するように、カスタム・パッケージング方法を使用する必要があります。
ヘルス・チェックを実行します。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。
推奨されるOracleアドバイザを実行して修復を実施します。
推奨されたアドバイザには、次のいずれかの方法でアクセスします。
問題の詳細ページ: 「調査と解決」セクションの「セルフ・サービス」タブ
「サポート・ワークベンチ」ホームページ: 「チェッカ結果」サブページ
「インシデントの詳細」ページ: 「チェッカ結果」サブページ
表9-5に、クリティカル・エラーの修復に役立つアドバイザを示します。
特定のインシデントの処理が終了した場合は、そのインシデントをクローズできます。デフォルトでは、クローズされたインシデントは問題の詳細ページに表示されません。
クローズされたかどうかにかかわらず、インシデントはすべて30日後にパージされます。インシデントのパージはインシデントの詳細ページで無効化できます。
インシデントをクローズする手順は、次のとおりです。
「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
目的の問題を選択して「表示」をクリックします。
問題の詳細ページが表示されます。
クローズするインシデントを選択して「閉じる」をクリックします。
「確認」ページが表示されます。
必要に応じてコメントを入力し、「OK」をクリックします。
すべての問題を表示したり、特定の期間内に発生した問題のみを表示するには、Enterprise Managerの「サポート・ワークベンチ」ホームページ(図9-5)を使用します。
「サポート・ワークベンチ」ホームページ(データベースまたはOracle ASM)にアクセスする手順は、次のとおりです。
Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
次のいずれかを実行します。
「診断サマリー」セクションで「アクティブなインシデント」ラベルの横にある数字リンクをクリックします。
トップページで「ソフトウェアとサポート」をクリックしてから「サポート」の「サポート・ワークベンチ」をクリックします。
データベース・インスタンスの「サポート・ワークベンチ」ホームページに「問題」サブページが表示されます。デフォルトでは、過去24時間の問題が表示されます。
Oracle ASMインスタンスの「サポート・ワークベンチ」ホームページを表示するには、「関連リンク」セクションの「サポート・ワークベンチ(+ASM_hostname)」リンクをクリックします。
問題とインシデントの表示方法
「サポート・ワークベンチ」ホームページの「表示」リストから希望する期間を選択します。すべての問題を表示するには、「すべて」を選択します。
(オプション)「パフォーマンスとクリティカル・エラー」セクションが非表示の場合は、セクション・ヘッダーに隣接する表示/非表示アイコンをクリックするとセクションが表示されます。
このセクションでは、パフォーマンスの変化とインシデントの発生の関連を表示できます。
(オプション)「詳細」列の下の「表示」をクリックして、特定の問題に関するすべてのインシデントのリストを表示します。次に、インシデントIDをクリックして、インシデントの詳細ページを表示します。
特定の問題の詳細を表示するには、次の手順を実行します。
サポート・ワークベンチのホームページで、問題を選択して「表示」をクリックします。
問題の詳細ページにインシデント・サブページが表示されます。「インシデント」サブページには、オープンしてダンプが生成された(つまり、フラッド制御されていない)すべてのインシデントが表示されます。
(オプション)オープン状態のインシデントとクローズしたインシデントの両方を表示するには、「ステータス」リストで「すべてのインシデント」を選択します。通常のインシデントとフラッド制御されているインシデントの両方を表示するには、「ダンプされたデータ」リストで「すべてのインシデント」を選択します。
(オプション)インシデントの詳細を表示するには、インシデントを選択して「表示」をクリックします。
インシデントの詳細ページが表示されます。
(オプション)「インシデントの詳細」ページで、インシデントのチェッカ結果を表示するには、「チェッカ結果」をクリックします。
(オプション)インシデントの詳細ページに、そのインシデントに対して実行可能なユーザー・アクションを表示するには、「追加の診断」をクリックします。各ユーザー・アクションにより、インシデントまたはその問題に関する追加の診断情報を収集できます。
システムで生成された問題(内部でデータベースに生成されたクリティカル・エラー)は、自動的に自動診断リポジトリ(ADR)に追加され、サポート・ワークベンチ内で追跡されます。サポート・ワークベンチから、それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできたり、場合によっては問題を解決することもでき、それらはすべて「問題の調査、レポートおよび解決」で説明されている使いやすいワークフローに記載されています。
気づいた問題を同じワークフローで処理できるように、その問題を手動でADRに追加する場合があります。このような問題の例には、自動データベース診断モニター(ADDM)で診断されなかったグローバル・データベースのパフォーマンスに関する問題があります。サポート・ワークベンチは、このようなユーザー報告の問題を作成して処理するメカニズムを備えています。
ユーザー報告の問題を作成する手順は、次のとおりです。
「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「関連リンク」で「ユーザー報告の問題の作成」をクリックします。
「ユーザー報告の問題の作成」ページが表示されます。
リストされている問題のタイプのいずれかと問題が一致する場合は、その問題のタイプを選択して「推奨アドバイザの実行」をクリックし、Oracleアドバイザを実行して問題の解決を試みます。
推奨アドバイザで問題が解決しない場合、またはアドバイザを実行しなかった場合は、次のいずれかを実行します。
リストされている問題のタイプのいずれかと問題が一致する場合は、その問題のタイプを選択して「問題の作成の続行」をクリックします。
リストされている問題のタイプのいずれかと問題が一致しない場合は、問題のタイプ「上記のいずれでもない」を選択して説明を入力し、「問題の作成の続行」をクリックします。
問題の詳細ページが表示されます。
「問題の詳細」ページの手順に従います。
詳細は、「問題の調査、レポートおよび解決」を参照してください。
アラート・ログは、テキスト・エディタ、Enterprise ManagerまたはADRCIユーティリティを使用して表示できます。
Enterprise Managerを使用してアラート・ログを表示する手順は、次のとおりです。
Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
「関連リンク」で「アラート・ログの内容」をクリックします。
「アラート・ログの内容の表示」ページが表示されます。
表示するエントリの数を選択して「実行」をクリックします。
テキスト・エディタを使用してアラート・ログを表示する手順は、次のとおりです。
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ユーティリティ』を参照してください。 |
トレース・ファイルは、自動診断リポジトリ(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;
ここでは、状態モニターとその使用方法を説明します。この章では、次の項目について説明します。
リリース11g以降のOracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。
状態モニター・チェック(チェッカ、ヘルス・チェックまたはチェックとも呼ばれます)では、データベースの様々なレイヤーとコンポーネントが検証されます。ヘルス・チェックでは、ファイルの破損、物理ブロックおよび論理ブロック破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。また、ヘルス・チェックの結果のレポートが生成され、多くの場合、問題を解決するための推奨事項が示されます。ヘルス・チェックは次の2つの方法で実行できます。
リアクティブ: 障害診断インフラストラクチャでは、クリティカル・エラーの内容に応じてヘルス・チェックを自動的に実行できます。
手動: DBAは、DBMS_HM PL/SQLパッケージまたはEnterprise Managerインタフェースのいずれかを使用して、ヘルス・チェックを手動で実行できます。必要に応じて定期的にチェッカを実行できますが、Oracleサポートがサービス・リクエストについて共同で作業しているときにチェッカの実行をお願いさせていただくこともあります。
状態モニター・チェックでは、結果、推奨事項およびその他の情報が自動診断リポジトリ(ADR)に格納されます。
ヘルス・チェックは次の2つのモードで実行できます。
DBオンライン・モードは、データベースがオープン状態(つまり、OPENモードまたはMOUNTモード)のときは、チェックを実行できることを意味します。
DBオフライン・モードは、インスタンスは使用可能だがデータベース自体がクローズ(つまり、NOMOUNTモード)している場合にチェックを実行できることを意味します。
DBオンライン・モードでは、すべてのヘルス・チェックを実行できます。DBオフライン・モードで使用できるのは、REDOの整合性チェックとDB構造の整合性チェックのみです。
状態モニターでは次のチェックが実行されます。
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$
状態モニターでは、次の2つの方法でヘルス・チェックを手動で実行できます。
DBMS_HM PL/SQLパッケージを使用する方法
「アドバイザ・セントラル」ページの「チェッカ」サブページにあるEnterprise Managerインタフェースを使用する方法
ヘルス・チェックを実行するための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; /
Enterprise Managerは、状態モニター・チェッカを実行するためのインタフェースを備えています。
Enterprise Managerを使用して状態モニター・チェッカを実行する手順は、次のとおりです。
データベース・ホームページにある「関連リンク」セクションで、「アドバイザ・セントラル」をクリックします。
「チェッカ」をクリックして「チェッカ」サブページを表示します。
「チェッカ」セクションで、実行するチェッカをクリックします。
入力パラメータの値を入力するか、オプション・パラメータの場合は空白のままにしてデフォルトを使用します。
「実行」をクリックし、パラメータを確認して「実行」を再度クリックします。
チェッカを実行した後は、その実行内容のレポートを表示できます。レポートには、結果、推奨事項およびその他の情報が含まれます。このレポートは、Enterprise Manager、ADRCIユーティリティまたはDBMS_HM PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。
| レポートの表示方法 | 使用可能なレポート形式 |
|---|---|
| Enterprise Manager | HTML |
DBMS_HM PL/SQLパッケージ |
HTML、XMLおよびテキスト |
| ADRCIユーティリティ | XML |
チェッカの実行結果(結果、推奨事項およびその他の情報)はADRに格納されますが、レポートはすぐに生成されません。DBMS_HM PL/SQLパッケージまたはEnterprise Managerを使用してレポートを要求したときに、レポートがまだ生成されていない場合は、最初にADR内のチェッカ実行データからレポートが生成され、現行インスタンス用のADRホームのHMサブディレクトリにXML形式でレポート・ファイルとして格納された後に、レポートが表示されます。レポートがすでに生成されている場合は、そのレポートが表示されます。ADRCIユーティリティを使用する場合、レポートがまだ生成されていないときは、最初にレポート・ファイルを生成するためのコマンドを実行し、次にその内容を表示するためのコマンドを実行する必要があります。
チェッカ・レポートは、Enterprise Managerを使用して表示することをお薦めします。次の各項では、各表示方法の手順を説明します。
Enterprise Managerを使用して、特定のチェッカ実行の状態モニター・レポートと結果を表示できます。
Enterprise Managerを使用して実行結果を表示する手順は、次のとおりです。
データベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
「関連リンク」セクションで、「アドバイザ・セントラル」をクリックします。
「チェッカ」をクリックして「チェッカ」サブページを表示します。
表示するチェッカ実行の実行名をクリックします。
「実行の詳細」ページにチェッカ実行の結果が表示されます。
「実行」をクリックして「実行」サブページを表示します。
チェッカ実行に関する詳細な情報が表示されます。
「レポートの表示」をクリックして、チェッカ実行のレポートを表示します。
レポートが新規のブラウザ・ウィンドウに表示されます。
状態モニター・チェッカ・レポートは、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 Paramters 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パッケージおよびタイプ・リファレンス』 |
ADRCIユーティリティを使用して、状態モニター・チェッカ・レポートを作成および表示できます。
ADRCIを使用してチェッカ・レポートを作成および表示する手順は、次のとおりです。
オペレーティング・システム環境変数(ORACLE_HOMEなど)が適切に設定されていることを確認し、次のコマンドをオペレーティング・システムのコマンド・プロンプトに入力します。
ADRCI
ユーティリティが起動し、次のプロンプトが表示されます。
adrci>>
必要に応じて、現行のADRホームを変更できます。すべてのADRホームをリストするにはSHOW HOMESコマンドを、現行のADRホームを変更するにはSET HOMEPATHコマンドを使用します。詳細は、『Oracle Databaseユーティリティ』を参照してください。
次のコマンドを入力します。
show hm_run
このコマンドによって、ADRリポジトリに登録されている(V$HM_RUNに格納された)すべてのチェッカ実行がリストされます。
レポートを作成するチェッカ実行を検索し、チェッカ実行名をメモします。このチェッカ実行のレポートがすでに生成されている場合は、REPORT_FILEフィールドにファイル名が表示されます。レポートが生成されていない場合は、次のコマンドを実行してレポートを生成します。
create report hm_run run_name
レポートを表示するには、次のコマンドを入力します。
show report hm_run run_name
チェッカ・レポートを要求するかわりに、レポートが作成された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
次の表では、パラメータが必要なヘルス・チェック用のパラメータを説明します。デフォルト値が(なし)のパラメータは必須です。
表9-6 「データ・ブロックの整合性チェック」のパラメータ
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
数値 |
(なし) |
ブロック・データ・ファイル番号 |
|
|
数値 |
(なし) |
データ・ブロック番号 |
表9-10 「ディクショナリの整合性チェック」のパラメータ
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
テキスト |
|
可能な値は次のとおりです。
|
|
|
テキスト |
|
チェックする単一のコア・テーブルの名前。省略すると、すべてのコア・テーブルがチェックされます。 |
ほとんど発生しませんが、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文を修復できます。
この項の内容は次のとおりです。
SQL修復アドバイザは、重大なエラーが発生してSQL文が失敗した場合に実行します。このアドバイザによって、文が分析され、多くの場合、文を修復するためにパッチの適用が推奨されます。リコメンデーションを実装すると、適用されたSQLパッチによって、問合せオプティマイザで将来実行する場合の代替実行計画が選択され、失敗が回避されます。
SQL修復アドバイザは、サポート・ワークベンチの「問題の詳細」ページから実行します。この項の説明は、SQL文によるクリティカル・エラーの通知をすでに受け取り、「問題の調査、レポートおよび解決」で説明したワークフローに従っていることを前提としています。
SQL修復アドバイザを実行する手順は、次のとおりです。
失敗したSQL文に関連する問題の「問題の詳細」ページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「調査と解決」セクションの「セルフ・サービス」タブにある「解決」ヘッダーで、「SQL修復アドバイザ」をクリックします。
「SQL修復アドバイザ」ページで次の手順を実行します。
必要な場合は現在のタスク名を変更し、必要に応じてタスクの説明を入力し、アドバイザ・タスクのオプションの時間制限を変更またはクリアし、設定を調整してアドバイザを即時に実行するか、後の日時に実行するかをスケジュールします。
「発行」をクリックします。
「処理中」ページが表示されます。その少し後に「SQL修復結果」ページが表示されます。
「SQLパッチ」列のチェック・マークは、推奨事項があることを示します。この列にチェック・マークがない場合は、SQL修復アドバイザがSQL文に対してパッチを提示できなかったことを意味します。
|
注意: 「SQL修復結果」ページが表示されない場合は、表示するために次の手順を実行します。
|
推奨事項がある場合は、「SQLパッチ」列にチェック・マークが表示されます。推奨事項を参照するには、「表示」をクリックします。
「修復の推奨」ページに、文に対する推奨パッチが表示されます。
「実装」をクリックします。
「SQL修復結果」ページに戻り、確認メッセージが表示されます。
(オプション)「SQLワークシートを使用して検証」をクリックして、SQLワークシートの文を実行し、パッチによって文が正常に修復したことを検証します。
SQL修復アドバイザを使用してSQLパッチを適用した後は、そのSQLパッチを表示してパッチが適用されたことを確認したり、パッチを無効化または削除できます。パッチを削除する理由の1つに、後続リリースのOracle Databaseをインストールし、パッチを適用したSQL文でエラーが発生した不具合が修正されている場合があります。
SQLパッチを表示、無効化または削除する手順は、次のとおりです。
Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
ページの上部で、「サーバー」をクリックし、「サーバー」ページを表示します。
「問合せオプティマイザ」セクションで、「SQL計画管理」をクリックします。
「SQL計画管理」ページが表示されます。このページの詳細は、オンライン・ヘルプを参照してください。
ページの上部にある「SQLパッチ」をクリックして「SQLパッチ」サブページを表示します。
「SQLパッチ」サブページに、データベース内のすべてのSQLパッチが表示されます。
関連するSQLテキストを検証して、特定のパッチを検索します。
SQLテキストをクリックして、その文の完全なテキストを表示します。
パッチを無効化するには、パッチを選択して「無効化」をクリックします。
確認メッセージが表示され、パッチのステータスがDISABLEDに変更されます。後でパッチを再び有効にするには、パッチを選択して「有効化」をクリックします。
パッチを削除するには、パッチを選択して「削除」をクリックします。
確認メッセージが表示されます。
データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。データ・リカバリ・アドバイザはEnterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)、状態モニターおよびRMANユーティリティに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。
ここでは、サポート・ワークベンチからアドバイザにアクセスする方法をいくつか説明します。データ・リカバリ・アドバイザは、次の情報を表示したときにサポート・ワークベンチによって自動的に推奨され、サポート・ワークベンチからアクセスできます。
データ破損またはその他のデータ障害に関連する問題の詳細。
データ破損またはその他のデータ障害に関連するヘルス・チェック結果。
データ・リカバリ・アドバイザは「アドバイザ・セントラル」ページからも使用できます。このページへのリンクは、データベース・ホームページおよび「パフォーマンス」ページの「関連リンク」セクションにあります。
|
注意: データ・リカバリ・アドバイザを使用できるのは、SYSDBAとして接続している場合のみです。 |
サポート・ワークベンチからデータ・リカバリ・アドバイザにアクセスする方法は次のとおりです。
「問題の詳細」ページからのアクセス
「調査と解決」セクションの「データ・リカバリ・アドバイザ」リンクをクリックします。
このページへのアクセス手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「サポート・ワークベンチ」ホームページの「チェッカ結果」サブページからのアクセス
1つ以上のデータ破損結果を選択して、「リカバリ・アドバイザの起動」をクリックします。
「サポート・ワークベンチ」ホームページへのアクセス手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
|
関連項目: データ・リカバリ・アドバイザの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージを作成、編集およびアップロードできます。カスタム・インシデント・パッケージにより、Oracleサポート・サービスに送信する診断データを詳細に制御できます。
この項の内容は、次のとおりです。
診断データをカスタマイズして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インストレーションおよび管理ガイド』を参照してください。 |
次の各項では、パッケージの詳細を説明します。
問題を診断するには、問題に直接関連する診断データのみでなく、直接関連するデータと相関する診断データも調べる必要がある場合があります。診断データは、時間、プロセスIDまたはその他の基準によって関係付けることができます。たとえば、インシデントの検証では、そのインシデントの5分後に発生したインシデントの検証も役立つ場合があります。同様に、インシデントの診断データには、インシデント発生時に実行されていたOracle Databaseプロセスのトレース・ファイルが含まれていることは明確ですが、元のプロセスに関連する他のプロセスのトレース・ファイルを含めることが役に立つ場合もあります。
このため、問題とそれに関連するインシデントがパッケージに追加されるときは、同時に、関連するトレース・ファイルとともに関係付けられたインシデントが追加されます。
パッケージの物理ファイルを作成する過程で、サポート・ワークベンチはインシデント・パッケージング・サービスを要求してパッケージをファイナライズします。ファイナライズとは、パッケージ内のインシデントに時間で関係付けられた追加のトレース・ファイル、および他の診断情報(アラート・ログ、ヘルス・チェッカ・レポート、SQLテスト・ケース、構成情報など)をパッケージに追加することを意味します。そのため、ZIPファイル内のファイル数が、サポート・ワークベンチでパッケージ・コンテンツとして表示されたファイルの数より多くなる場合があります。
インシデント・パッケージング・サービスは一連のルールに従って、既存のパッケージ・データに関係付けるADR内のトレース・ファイルを決定します。一部のルールは、Enterprise Managerの「インシデント・パッケージング構成」ページで変更できます。
当初のパッケージ・データと関係付けられた追加データには機密情報が含まれている可能性があるため、Oracleサポート・サービスにアップロードする前に、このような機密情報を含むファイルを削除または編集することが重要です。このため、サポート・ワークベンチでは、パッケージをファイナライズするコマンドを独立した操作として実行できます。パッケージを手動でファイナライズした後は、パッケージ・コンテンツを検証し、ファイルを削除または編集してから、ZIPファイルを生成してアップロードできます。
|
注意: パッケージのファイナライズは、パッケージがクローズして変更不可になることではありません。ファイナライズしたパッケージには、引続き診断データを追加できます。また、同じパッケージを複数回ファイナライズすることもできます。ファイナライズするたびに、関係付けられた新しいデータが追加されます。 |
Enterprise Managerサポート・ワークベンチには、インシデント・パッケージを作成してアップロードする方法として、クイック・パッケージング方法とカスタム・パッケージング方法があります。
クイック・パッケージング: 最小限のステップがある自動化された方法で、ガイド付きワークフロー(ウィザード)に編成されています。1つの問題を選択してパッケージ名と説明を入力し、パッケージ・コンテンツのアップロードを即時に実行するか、指定の日時に実行するかをスケジュールします。サポート・ワークベンチでは、問題に関連する診断データを自動的にパッケージに追加してファイナライズし、ZIPファイルを作成してアップロードします。この方法では、パッケージ・ファイルを追加、編集または削除したり、SQLテスト・ケースなどの他の診断データを追加することはできません。ただし、この方法は、初期障害診断データをOracleサポート・サービスにアップロードする最も簡単かつ迅速な方法です。クイック・パッケージングは、「問題の調査、レポートおよび解決」で示すワークフローで使用される方法です。
クイック・パッケージングが完了した後、ウィザードで作成されたパッケージはそのまま残ることに注意してください。このパッケージは、カスタム・パッケージング操作を使用して後で変更し、手動で再アップロードできます。
カスタム・パッケージング: 手順が多く、より詳細な手動の方法です。これは、パッケージング・プロセスの詳細な制御を行うエキスパートのサポート・ワークベンチ・ユーザーを対象としています。カスタム・パッケージングでは、1つ以上の問題のある新規パッケージを作成、または1つ以上の問題を既存のパッケージに追加できます。これらの各種の操作を新規または更新されたパッケージで実行でき、これには次の操作が含まれます。
問題やインシデントを追加または削除できます。
パッケージに対してトレース・ファイルを追加、編集または削除できます。
任意のタイプの外部ファイルを追加または削除できます。
その他の診断データ(SQLテスト・ケースなど)を追加できます。
パッケージを手動でファイナライズしてからパッケージ・コンテンツを表示して、機密データを編集または削除する必要があるか、ファイルを削除してパッケージ・サイズを縮小する必要があるかを決定できます。
これらの操作には、Oracleサポートに送信する診断情報が十分であることを確認するまで、数日間かかる場合があります。
カスタム・パッケージングでは、ZIPファイルの作成とOracleサポート・サービスへのアップロードを、2つの独立したステップとして実行できます。各ステップは、即時に実行するか、日時をスケジュールして実行できます。
相関パッケージは、関連する問題に対して診断データのパッケージングおよびアップロードのための手段を提供します。「トポロジ全体に関連する問題」で示すとおり、データベース・インスタンスの問題に関連する問題が他のデータベース・インスタンスやOracle Automatic Storage Managementインスタンスにもある場合があります。データベース・インスタンスの問題に対するパッケージ(メイン・パッケージ)を作成およびアップロードした後、関連する問題についての相関パッケージを作成およびアップロードできます。これは、Enterprise Managerのサポート・ワークベンチのカスタム・パッケージング・ワークフローでのみ実行できます。
Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージ(パッケージ)を作成およびアップロードできます。アップロードする前に、診断データ・ファイルをパッケージから手動で追加、編集、および削除できます。
カスタム・パッケージングを使用して問題をパッケージ化およびアップロードする手順は、次のとおりです。
「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
(オプション)パッケージに含める各問題について、問題に関連付けられているサービス・リクエスト番号(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インストレーションおよび管理ガイド』を参照してください。 |
(オプション)相関パッケージを作成およびアップロードします。
手順については、「相関パッケージの作成、編集およびアップロード」を参照してください。
カスタム・パッケージング方法を使用してインシデント・パッケージを作成した後は、Oracleサポート・サービスへのアップロード前に、そのパッケージのコンテンツを表示または変更できます。さらに、クイック・パッケージング方法を使用して診断データをパッケージ化してアップロードした後は、サポート・ワークベンチで作成したパッケージのコンテンツを表示または変更して、パッケージを再アップロードできます。パッケージを変更するには、パッケージ・タスクの選択対象から選択しますが、それらのほとんどは「パッケージのカスタマイズ」ページで使用できます。(図9-7を参照。)
この項では、最も一般的なパッケージ・タスクの一部について説明します。内容は次のとおりです。
また、次の各項では、パッケージの詳細の表示方法、特定のパッケージの「パッケージのカスタマイズ」ページにアクセスする方法について説明します。
「パッケージの詳細」ページには、パッケージ内のインシデント、トレース・ファイルおよびその他のファイルに関する情報が表示され、アクティビティ・ログを表示してパッケージに追加できます。
パッケージの詳細を表示する手順は、次のとおりです。
「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「パッケージ」リンクをクリックして「パッケージ」サブページを表示します。
自動診断リポジトリ(ADR)に現時点で格納されているパッケージのリストが表示されます。
(オプション)表示するパッケージの数を減らすには、リストの上部にある「検索」フィールドにテキストを入力して「実行」をクリックします。
パッケージ名に検索テキストが含まれているパッケージがすべて表示されます。全パッケージのリストを表示するには、「パッケージ」リンクを再度クリックします。
「パッケージ名」列で、対象のパッケージのリンクをクリックします。
「パッケージの詳細」ページが表示されます。
「パッケージのカスタマイズ」ページでは、各種のパッケージング・タスク(問題の追加および削除、パッケージ・ファイルの追加、削除および修正(編集)、パッケージのZIPファイルの生成およびアップロードなど)を実行します。
「パッケージのカスタマイズ」ページにアクセスする手順は、次のとおりです。
「パッケージの詳細の表示」で説明するように、特定のパッケージの「パッケージの詳細」ページにアクセスします。
「パッケージのカスタマイズ」をクリックします。
「パッケージのカスタマイズ」ページが表示されます。図9-7を参照してください。
サポート・ワークベンチを使用すると、インシデント・パッケージ内の1つ以上のファイルを編集できます。この作業は、ファイル内の機密データを削除または上書きする場合に必要です。パッケージ・ファイルを編集するには、最初にパッケージから宛先ディレクトリにファイルをコピー・アウトし、テキスト・エディタまたは他のユーティリティを使用して編集してから、そのファイルをパッケージにコピーし直して、元のパッケージ・ファイルを上書きします。
次の手順では、パッケージがすでに作成されて診断データが格納されていることを前提としています。
インシデント・パッケージ・ファイルを編集する手順は、次のとおりです。
対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
「パッケージング・タスク」セクションで、「ユーザー・データの修正」ヘッダー下にある「コンテンツ編集のためのファイルのコピー・アウト」をクリックします。
ファイルのコピー・アウト・ページが表示されます。ファイルをコピーできるホスト名が表示されます。
次のいずれかを実行して、ファイルの宛先ディレクトリを指定します。
「宛先フォルダ」フィールドにディレクトリ・パスを入力します。
「宛先フォルダ」フィールドの横にある懐中電灯アイコンをクリックして、次の手順を実行します。
ホスト資格証明がプロンプトで要求された場合は、ファイルのコピー・アウト先のホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。
「参照および選択: ファイルまたはディレクトリ」ウィンドウで、ディレクトリ・リンクをクリックしてディレクトリ階層の下位に移動するか、「パス」ラベルの横にあるディレクトリ名をクリックしてディレクトリ階層の上位に移動して、対象の宛先ディレクトリを検索します。
リストに表示するディレクトリの数を減らすには、「検索」フィールドに検索テキストを入力して「実行」をクリックします。ディレクトリ名に検索テキストが含まれているディレクトリがすべて表示されます。
対象の宛先ディレクトリを選択して「選択」をクリックします。
「参照および選択: ファイルまたはディレクトリ」ウィンドウがクローズし、選択したディレクトリへのパスが「ファイルのコピー・アウト」ページの「宛先フォルダ」フィールドに表示されます。
「コピー・アウトするファイル」で、対象のファイルを選択して「OK」をクリックします。
|
注意: 対象のファイルがみつからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「OK」をクリックします。 |
「パッケージのカスタマイズ」ページに戻ると、コピー・アウトされたファイルをリストした確認メッセージが表示されます。
テキスト・エディタまたは他のユーティリティを使用して、ファイルを編集します。
「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「ユーザー・データの修正」ヘッダー下にある「コンテンツ置換えのためのファイルのコピー・イン」をクリックします。
ファイルのコピー・イン・ページが表示されます。コピーしたファイルが表示されます。
コピー・インするファイルを選択して「OK」をクリックします。
ファイルがパッケージにコピー・インされて、既存のファイルが上書きされます。「パッケージのカスタマイズ」ページに戻ると、コピー・インされたファイルをリストした確認メッセージが表示されます。
インシデント・パッケージには、任意のタイプの外部ファイルを追加できます。
外部ファイルをインシデント・パッケージに追加する手順は、次のとおりです。
対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
「ファイル」リンクをクリックして「ファイル」サブページを表示します。
このページでは、パッケージに対してファイルを追加または削除できます。
「外部ファイルの追加」をクリックします。
外部ファイルの追加ページが表示されます。これには選択したファイルからホスト名が表示されます。
次のいずれかを実行して、追加するファイルを指定します。
「ファイル名」フィールドに、ファイルへのフルパスを入力します。
「ファイル名」フィールドの横にある懐中電灯アイコンをクリックして、次の手順を実行します。
ホスト資格証明がプロンプトで要求された場合は、外部ファイルが存在するホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。
「参照および選択: ファイルまたはディレクトリ」ウィンドウで、ディレクトリ・リンクをクリックしてディレクトリ階層の下位に移動するか、「パス」ラベルの横にあるディレクトリ名をクリックしてディレクトリ階層の上位に移動して、対象のファイルを検索します。
リストに表示するファイルまたはディレクトリの数を減らすには、「検索」フィールドに検索テキストを入力して「実行」をクリックします。ファイル名またはディレクトリ名に検索テキストが含まれているファイルまたはディレクトリがすべて表示されます。
「選択」列で、対象のファイルをクリックして選択し、「選択」をクリックします。
「参照および選択」ウィンドウがクローズし、選択したファイルへのパスが「外部ファイルの追加」ページの「ファイル名」フィールドに表示されます。
「OK」をクリックします。
「パッケージのカスタマイズ」ページに戻ると、「ファイル」サブページが表示されます。これで、選択したファイルがファイル・リストに表示されます。
インシデント・パッケージから任意のタイプのファイルを1つ以上削除できます。
インシデント・パッケージ・ファイルを削除する手順は、次のとおりです。
対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
「ファイル」リンクをクリックして「ファイル」サブページを表示します。
パッケージに含まれているファイルのリストが表示されます。
パッケージの物理ファイルをまだ生成していない場合、すべてのパッケージ・ファイルがリストに表示されます。すでに物理ファイルを生成している場合、ファイル・リストの上部に「表示」リストが表示されます。ここで、増分パッケージのコンテンツのみを表示するか、パッケージの内容すべてを表示するかを選択できます。デフォルトではパッケージの内容の増分を表示します。このデフォルト設定では、パッケージの物理ファイルが最後に生成されたとき以降に作成または変更されたパッケージ・ファイルのみが表示されます。すべてのパッケージ・ファイルを表示するには、「表示」リストから「全パッケージ・コンテンツ」を選択します。
削除するファイルを選択して「除外」をクリックします。
|
注意: 対象のファイルがみつからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「削除」をクリックします。 |
サポート・ワークベンチでは、インシデント・パッケージごとにアクティビティ・ログが保持されます。パッケージに対して実行したほとんどのアクティビティ(ファイルの追加や削除、パッケージのZIPファイルの作成など)はログに記録されます。独自のノートをログに追加することもできます。特に、これは、複数のデータベース管理者がパッケージを使用している場合に役立ちます。
インシデント・パッケージのアクティビティ・ログを表示および更新する手順は、次のとおりです。
対象のインシデント・パッケージの「パッケージの詳細」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
「アクティビティ・ログ」リンクをクリックして、「アクティビティ・ログ」サブページを表示します。
アクティビティ・ログが表示されます。
独自のノートをアクティビティ・ログに追加するには、「ノート」フィールドにテキストを入力して「ノートの追加」をクリックします。
ノートの日時が記録され、リストに追加されます。
Oracleサポート・サービスにパッケージをアップロードした後、1つ以上の相関パッケージを作成およびアップロードできます。データベース・ホームページの「関連アラート」セクションにクリティカル・アラートが表示されている場合は上記をお薦めします。相関パッケージは、メイン・パッケージと呼ばれる元のパッケージと関連付けられています。メイン・パッケージには、データベース・インスタンス内で発生した問題が含まれます。相関パッケージには、他のインスタンス(Oracle ASMインスタンスやその他のデータベース・インスタンス)で発生した問題や、メイン・パッケージにある問題に関連する問題が含まれます。相関パッケージは、関連するインスタンスにそれぞれ1つのみ存在できます。
相関パッケージを作成、編集およびアップロードする手順は、次のとおりです。
メイン・パッケージの「パッケージの詳細」ページを表示します。
手順については、「パッケージの詳細の表示」を参照してください。
「パッケージの詳細」ページ上で「パッケージのカスタマイズ」をクリックします。
「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションの「追加の診断データ」で、「相関パッケージの作成/更新」をクリックします。
図9-7を参照してください。
「相関パッケージ」ページの「相関パッケージ」で、インシデントのあるインスタンスを1つ以上選択して「作成」をクリックします。
確認メッセージが表示され、新規に作成された相関パッケージのパッケージIDが「ID」列に表示されます。
相関パッケージを作成したインスタンスを選択し、「コンテンツ準備の終了」をクリックします。
確認メッセージが表示されます。
(オプション)次の手順で相関パッケージを表示および編集します。
パッケージIDをクリックしてパッケージを表示します。
資格証明を要求された場合は、「ログイン」をクリックします。
「パッケージの詳細」ページで「ファイル」をクリックしてパッケージ内のファイルを表示します。
「パッケージのカスタマイズ」をクリックして、「インシデント・パッケージの表示と変更」に示すカスタマイズのタスクのうち必要なものを実行します。
アップロードするそれぞれの相関パッケージについて、「アップロード・ファイルの生成」をクリックします。
オラクル社に送信するそれぞれの相関パッケージについて、「Oracleに送信」をクリックします。
|
注意: 「Oracleに送信」が使用できない場合は、そのインスタンスに対して関連付けられたインシデントはありません。 |
相関パッケージは、そのパッケージを作成したターゲットのEnterprise Managerサポート・ワークベンチで削除します。たとえば、Oracle ASMインスタンス・ターゲットに対して相関パッケージを作成した場合は、そのOracle ASMインスタンスのサポート・ワークベンチにアクセスします。
相関パッケージを削除する手順は、次のとおりです。
相関パッケージを作成したターゲットのサポート・ワークベンチにアクセスします。
|
ヒント: サポート・ワークベンチのページ下部の「関連リンク」セクションを参照してください。または、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。 |
「パッケージ」をクリックして「パッケージ」のサブページを表示します。
リストから、相関パッケージを検索します。パッケージの説明を表示し、相関パッケージであることを確認します。
パッケージを選択して「削除」をクリックします。
確認ページで「はい」をクリックします。
ここでは、インシデント・パッケージのプリファレンスを設定する手順について説明します。インシデント・パッケージのプリファレンスの例には、インシデント情報を保持する日数や、各問題のパッケージに含める最初と最後のインシデント数などがあります。(デフォルトでは、問題のインシデントが多数存在する場合、最初の3つと最後の3つのインシデントのみがパッケージ化されます。)これらのインシデントやその他のインシデント・パッケージのプリファレンスは、Enterprise ManagerまたはADRCIユーティリティを使用して変更できます。
Enterprise Managerを使用してインシデント・パッケージのプリファレンスを設定する手順は、次のとおりです。
「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
ページの下部にある「関連リンク」セクションで、「インシデント・パッケージング構成」をクリックします。
「インシデント・パッケージング構成の表示」ページが表示されます。「ヘルプ」をクリックして、このページの設定の説明を表示します。
「編集」をクリックします。
「インシデント・パッケージング構成の編集」ページが表示されます。
設定を編集し、「OK」をクリックして変更を適用します。
|
関連項目:
|
