11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
リリース11g以降のOracle Databaseは、診断データを収集して管理するための高度な障害診断インフラストラクチャを備えています。診断データには、以前のリリースにも含まれていたトレース・ファイル、ダンプおよびコア・ファイルに加えて、顧客やOracleサポート・サービスが問題を迅速かつ効率的に識別、調査、追跡、解決できる新しいタイプの診断データが含まれています。
この章の内容は次のとおりです。
ここでは、Oracle Databaseの障害診断インフラストラクチャに関するバックグラウンド情報を説明します。この章の内容は、次のとおりです。
障害診断インフラストラクチャは、問題の防止、検出、診断および解決に役立ちます。特に対象とする問題はクリティカル・エラーで、これには、データベース・コードの不具合、メタデータの破損、顧客データの破損によって生じるエラーなどがあります。
クリティカル・エラーが発生すると、インシデント番号が割り当てられ、エラーに関する診断データ（トレース・ファイルなど）が即時に取得されて、この番号にタグ付けされます。診断データは自動診断リポジトリ（ADR）に格納されます。ADRはデータベースの外部にあるファイルベースのリポジトリで、診断データはインシデント番号によって後で検索して分析できます。
障害診断インフラストラクチャの目的は次のとおりです。
これらの目的を達成するための主要なテクノロジは、次のとおりです。
クリティカル・エラーの診断と解決を容易にするために、障害診断インフラストラクチャには、問題とインシデントというOracle Databaseの概念が導入されています。
問題とは、データベース内のクリティカル・エラーです。クリティカル・エラーは、ORA-00600などの内部エラー、またはORA-07445（オペレーティング・システム例外）やORA-04031（共有プールのメモリー不足）などの重大なエラーを示します。問題はADRで追跡されます。各問題には、問題を説明するテキスト文字列の問題キーがあります。この問題キーには、エラー・コード（例: ORA 600）が含まれており、1つ以上のエラー・パラメータが含まれる場合もあります。
インシデントとは、問題の1回の発生です。問題（クリティカル・エラー）が複数回発生した場合は、発生ごとに1つのインシデントが作成されます。インシデントには日時が記録され、自動診断リポジトリ（ADR）で追跡されます。各インシデントは、ADR内で一意の数値であるインシデントIDによって識別されます。インシデントが発生すると、データベースでは次の処理が実行されます。
通常、クリティカル・エラーの診断と解決は、インシデント・アラートから開始されます。インシデント・アラートは、Enterprise Managerのデータベース・ホームページに表示されます。問題および関連するインシデントは、Enterprise ManagerまたはADRCIコマンドライン・ユーティリティを使用して表示できます。
1つの問題に対して、短期間に数十または数百のインシデントが生成される場合があります。その結果、大量の診断データが生成され、ADRの領域を大きく消費し、問題の診断と解決の効率が低下することになります。このため、障害診断インフラストラクチャでは、特定のしきい値に達した後は、フラッド制御がインシデント生成に適用されます。フラッド制御されたインシデントとは、アラート・ログ・エントリは作成されてADRに記録されるが、インシデント・ダンプは生成されないインシデントです。フラッド制御されたインシデントによって、診断データによるシステムのオーバーロードを回避しながら、クリティカル・エラーの発生を管理者に通知できます。Enterprise ManagerまたはADRCIを使用してインシデントを表示するときは、フラッド制御されたインシデントを表示するか非表示にするかを選択できます。
インシデントのフラッド制御のしきい値レベルは事前定義されており、変更できません。しきい値レベルは次のように定義されています。
さらに、1時間に同じ問題キーに対して50のインシデントが発生した場合、または1日に同じ問題キーに対して250のインシデントが発生した場合、その問題キーに対する後続のインシデントはADRに記録されません。この場合は、後続のインシデントが記録されないことを示すメッセージがアラート・ログに書き込まれます。問題キーに対してインシデントが継続して生成されている間は、1時間または1日が経過するまで、10分ごとにこのメッセージがアラート・ログに追加されます。1時間または1日が経過すると、その問題キーに対するインシデントの通常の記録が再開されます。
障害診断インフラストラクチャの主要なコンポーネントは次のとおりです。
ADRは、データベース診断データ（トレース、ダンプ、アラート・ログ、状態モニター・レポートなど）用のファイルベースのリポジトリです。ADRは、複数のインスタンスや製品間で統合されたディレクトリ構造を備えています。リリース11g以降、データベース、自動ストレージ管理（ASM）、その他のOracle製品やコンポーネントでは、すべての診断データがADRに格納されるようになりました。各製品のインスタンスごとに、ADR内の独自のホーム・ディレクトリ下に診断データが格納されます。たとえば、共有記憶域とASMを備えたOracle Real Application Clusters環境では、各データベース・インスタンスおよび各ASMインスタンスに1つの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パフォーマンス・チューニング・ガイド』を参照してください。
ダンプは、特殊なタイプのトレース・ファイルです。通常、ダンプはイベント（インシデントなど）に関する診断データの1回かぎりの出力です。これに対して、トレースは診断データの継続的な出力です。インシデントが発生すると、そのインシデントに対して作成されたインシデント・ディレクトリに1つ以上のダンプが書き込まれます。インシデント・ダンプのファイル名には、インシデント番号が含まれます。
コア・ファイルには、メモリー・ダンプがポート固有の形式ですべてバイナリで格納されます。コア・ファイル名は、文字列「core」とオペレーティング・システム・プロセスIDで構成されます。コア・ファイルを使用するのはOracleサポート・サービスのエンジニアのみです。プラットフォームによっては、コア・ファイルがない場合があります。
ADRには、前の各項で説明したファイルに加えて、状態モニター・レポート、データ修復レコード、SQLテスト・ケース、インシデント・パッケージなどが格納されます。これらのコンポーネントについては、この章で後述します。
Enterprise Managerサポート・ワークベンチ（サポート・ワークベンチ）は、問題（クリティカル・エラー）を調査およびレポートし、場合によっては修復できる機能で、使用しやすいグラフィカル・インタフェースを備えています。このサポート・ワークベンチは、初期障害診断データの収集、サポート・リクエスト番号の取得、診断データのOracleサポート・サービスへのアップロードを短時間かつ最小限の作業で実行できるセルフ・サービス機能を提供します。これによって、問題の解決時間を短縮できます。また、サポート・ワークベンチでは、SQL関連の問題やデータ破損の問題などの修復に役立つOracleアドバイザへのアクセスが推奨され、アドバイザに簡単にアクセスできます。
ADRコマンド・インタプリタ（ADRCI）は、問題の調査、ヘルス・チェック・レポートの表示、および初期障害診断データのパッケージ化とOracleサポート・サービスへのアップロードを、すべてコマンドライン環境内で実行できるユーティリティです。また、ADRCIを使用すると、ADRに格納されているトレース・ファイルの名前の表示、およびアラート・ログの表示（XMLタグは削除されます）を、フィルタ処理の有無を選択して実行できます。
ADRCIの詳細は、『Oracle Databaseユーティリティ』を参照してください。
自動診断リポジトリ（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製品またはコンポーネントの特定のインスタンスに関するすべての診断データ（トレース、ダンプ、アラート・ログなど）のルート・ディレクトリです。たとえば、ASMを備えたOracle Real Application Clusters環境では、各データベース・インスタンスおよび各ASMインスタンスに1つのADRホームがあります。すべてのADRホームは、同じ階層ディレクトリ構造を共有しています。
ADRホームの場所は、ADRベース・ディレクトリの後に続く次のパスで指定されます。
diag/product_type/product_id/instance_id
表8-1に、Oracle Databaseインスタンスの各パス・コンポーネントの値を示します。
| パス・コンポーネント | Oracle Databaseの値 |
|---|---|
|
product_type |
rdbms |
|
product_id |
データベース名 |
|
instance_id |
SID |
たとえば、SIDとデータベース名が両方ともorclbiのデータベースの場合、ADRホームの場所は次のようになります。
ADR_base/diag/rdbms/orclbi/orclbi/
ADRホーム・ディレクトリ内には、データベース・インスタンスが診断データを格納するサブディレクトリがあります。表8-2に、いくつかのサブディレクトリとその内容を示します。
図8-1に、Oracle DatabaseインスタンスのADRのディレクトリ階層を示します。他のOracle製品やコンポーネント（ASM、Oracle Net Servicesなど）用のADRホームも、この階層内の同じADRベース下に存在する場合があります。
Oracle Real Application Clusters（RAC）環境では、ADRベースは、ノードごとに独自のローカル記憶域に設定するか、共有記憶域に設定できます。共有記憶域に設定する利点は次のとおりです。
データ・リカバリ・アドバイザの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
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
次の表で、このビューに表示されるいくつかの情報を説明します。
ここでは、Enterprise Managerサポート・ワークベンチ（サポート・ワークベンチ）を使用して、問題（クリティカル・エラー）を調査およびレポートし、場合によってはその問題を修復する方法について説明します。最初に、実行する必要がある一般的なタスクを要約した「ロードマップ」を示します。
問題の調査は、Enterprise Managerの「サポート・ワークベンチ」ホームページから開始できます。ただし、データベース・ホームページでクリティカル・エラー・アラートの検討から開始するワークフローが一般的です。ここでは、このワークフローの概要について説明します。
図8-2に、問題を調査およびレポートし、場合によってはその問題を修復するためのタスクを示します。
次に、各タスクについて説明します。各タスクの詳細は、後続の各項で説明します。
最初に、Enterprise Managerのデータベース・ホームページにアクセスし、クリティカル・エラー・アラートを検討します。詳細を表示するアラートを選択し、「問題の詳細」ページに進みます。
問題の詳細を検証し、その問題に対して記録されたすべてのインシデントのリストを表示します。自動的に実行されていたヘルス・チェックの結果を表示します。
必要に応じて、追加のヘルス・チェックまたは他の診断を実行します。SQL関連エラーの場合は、必要に応じてSQLテスト・ケース・ビルダーを起動して、SQL問題に関連する必要なすべてのデータを収集し、Oracleサポート・サービスで問題を再現できる方法で情報をパッケージ化します。
必要に応じて、Oracle MetaLinkを使用してサービス・リクエストを作成し、サービス・リクエスト番号を問題情報とともに記録します。このステップをスキップした場合は、後でサービス・リクエストを作成できます。または、サポート・ワークベンチでサービス・リクエストを作成できます。
ガイド付きのワークフロー（ウィザード）を起動して、問題に対して収集した診断データを自動的にパッケージ化し、Oracleサポート・サービスにアップロードします。
必要に応じて、サポート・ワークベンチでサービス・リクエストのアクティビティ・ログを保持します。Oracleアドバイザを実行して、SQLエラーまたは破損データを修復します。
問題に対する1つ、複数またはすべてのインシデントのステータスを「クローズ」に設定します。
問題（クリティカル・エラー）を調査するプロセスでは、最初にデータベース・ホームページでクリティカル・エラー・アラートを検討します。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
クリティカル・エラー・アラートは「重大度」列に赤の×印で表示され、「カテゴリ」列に「インシデント」と表示されます。
「インシデント」ページまたは「データ障害」ページが表示されます。このページには次の内容が表示されます。
「問題の詳細」ページで調査を続行します。
「問題の詳細」ページに「インシデント」サブページが表示されます。
「インシデントの詳細」ページが表示されます。
このページには、クリティカル・エラーの検出時に自動的に実行されていたヘルス・チェックの結果が表示されます。
次のアクティビティを実行して、問題に関する追加の診断情報を収集します。この追加情報は、診断データに自動的に追加され、Oracleサポート・サービスにアップロードされます。これらのアクティビティを実行するかどうかを判断できない場合は、Oracleサポート・サービスの担当者に確認してください。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。
手順については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ここでは、Oracleサポート・サービスへのサービス・リクエストを作成し、サービス・リクエスト番号を問題情報とともに記録できます。このタスクをスキップした場合は、タスク5で、サポート・ワークベンチでドラフトのサービス・リクエストが自動的に作成されます。
新規のブラウザ・ウィンドウに、Oracle MetaLinkの「ログイン」と「登録」ページが表示されます。
（オプション）サービス・リクエスト番号（SR#）は次のステップで使用するため、記録しておきます。
「問題の詳細」ページにSR#が記録されます。この情報は参照のみです。
このタスクでは、サポート・ワークベンチのクイック・パッケージング・プロセスを使用して、問題に関する診断情報をパッケージ化し、Oracleサポート・サービスにアップロードします。クイック・パッケージングには最小限のステップがあり、ガイド付きワークフロー（ウィザード）に編成されています。ウィザードを使用して、1つの問題に対してインシデント・パッケージ（パッケージ）を作成し、そのパッケージからZIPファイルを作成してアップロードします。クイック・パッケージングでは、アップロードする診断情報を編集したりカスタマイズすることはできません。ただし、クイック・パッケージングを使用すると、直接的かつ簡単な方法で診断データをパッケージ化してアップロードできます。
アップロードする前に、機密データを編集したり診断情報から削除する場合、追加のユーザー・ファイル（アプリケーション構成ファイルやスクリプトなど）を添付する場合、あるいは他のカスタマイズを実行する場合は、カスタム・パッケージング・プロセスを使用する必要があります。このプロセスは手動操作が多いため、ステップ数も多くなります。 手順については、「カスタム・インシデント・パッケージの作成、編集およびアップロード」を参照してください。 このタスク5の手順ではなく、カスタム・パッケージング・プロセスの手順に従う場合は、終了後に「タスク6: サービス・リクエストの追跡と修復の実装」に進んでください。
「クイック・パッケージ」ウィザードの「新規パッケージの作成」ページが表示されます。
「はい」を選択すると、「クイック・パッケージング」ウィザードでドラフトのサービス・リクエストが作成されます。この場合は、後でOracle MetaLinkにログインして、サービス・リクエストの詳細を入力する必要があります。
「クイック・パッケージング」ウィザードが完了した後も、作成されたパッケージはサポート・ワークベンチで使用できます。カスタム・パッケージング操作を使用してパッケージを変更し（新規インシデントの追加など）、後でパッケージを再アップロードできます。 「インシデント・パッケージの表示と変更」を参照してください。
診断情報をOracleサポート・サービスにアップロードした後は、様々なアクティビティを実行してサービス・リクエストを追跡し、追加の診断情報を収集して、修復を実装できます。次のようなアクティビティがあります。
「問題の詳細」ページで、Bug#ラベルに隣接する「編集」ボタンをクリックします。この情報は参照のみです。
このアクティビティは、組織内の他のDBAと問題ステータスや履歴情報を共有する場合に実行します。たとえば、Oracleサポート・サービスとの対話の結果を記録できます。コメントを追加する手順は、次のとおりです。
これで、コメントがアクティビティ・ログに記録されます。
このアクティビティには、「カスタム・インシデント・パッケージの作成、編集およびアップロード」で説明するように、カスタム・パッケージング方法を使用する必要があります。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。
推奨されたアドバイザには、次のいずれかの方法でアクセスします。
表8-4に、クリティカル・エラーの修復に役立つアドバイザを示します。
| アドバイザ | 対象となるクリティカル・エラー | 参照先 |
|---|---|---|
|
データ・リカバリ・アドバイザ |
破損ブロック、破損または欠落したファイル、その他のデータ障害 |
|
|
SQL修復アドバイザ |
SQL文エラー |
特定のインシデントの処理が終了した場合は、そのインシデントをクローズできます。デフォルトでは、クローズしたインシデントは「問題の詳細」ページに表示されません。
すべてのインシデントは、クローズされているかどうかに関係なく、30日後にパージされます。インシデントのパージは、「インシデントの詳細」ページで無効にできます。
手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「問題の詳細」ページが表示されます。
確認ページが表示されます。
すべての問題を表示したり、特定の期間内に発生した問題のみを表示するには、Enterprise Managerの「サポート・ワークベンチ」ホームページ（図8-4）を使用します。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
「サポート・ワークベンチ」ホームページに「問題」サブページが表示されます。デフォルトでは、過去24時間の問題が表示されます。
このセクションでは、パフォーマンスの変化とインシデントの発生の関連を表示できます。
「問題の詳細」ページに「インシデント」サブページが表示されます。「インシデント」サブページには、オープンしてダンプが生成された（つまり、フラッド制御されていない）すべてのインシデントが表示されます。
「インシデントの詳細」ページが表示されます。
システム生成の問題（データベースに内部的に生成されたクリティカル・エラー）は、自動診断リポジトリ（ADR）に自動的に追加されて、サポート・ワークベンチで追跡されます。 サポート・ワークベンチでは、その問題に関する追加の診断データを収集して、診断データをOracleサポート・サービスにアップロードし、場合によっては問題を解決できます。これらの作業はすべて、「問題の調査、レポートおよび解決」で説明したように、使用しやすいワークフローで実行できます。
気づいた問題を同じワークフローで処理できるように、その問題を手動でADRに追加する場合があります。このような問題の例には、自動データベース診断モニター（ADDM）で診断されなかったグローバル・データベースのパフォーマンスに関する問題があります。サポート・ワークベンチは、このようなユーザー報告の問題を作成して処理するメカニズムを備えています。
手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「ユーザー報告の問題の作成」ページが表示されます。
「問題の詳細」ページが表示されます。
詳細は、「問題の調査、レポートおよび解決」を参照してください。
アラート・ログは、テキスト・エディタ、Enterprise ManagerまたはADRCIユーティリティを使用して表示できます。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
「アラート・ログの内容の表示」ページが表示されます。
V$DIAG_INFOビューを問い合せます。
トレース・ファイルは、自動診断リポジトリ（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トレース・ディレクトリへのパスが返されます。
ここでは、状態モニターとその使用方法を説明します。この項の内容は、次のとおりです。
リリース11g以降のOracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。
状態モニター・チェック（チェッカ、ヘルス・チェックまたはチェックとも呼ばれます）では、データベースの様々なレイヤーとコンポーネントが検証されます。ヘルス・チェックでは、ファイルの破損、物理ブロックおよび論理ブロックの破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。また、ヘルス・チェックの結果のレポートが生成され、多くの場合、問題を解決するための推奨事項が示されます。ヘルス・チェックは次の2つの方法で実行できます。
DBMS_HM PL/SQLパッケージまたはEnterprise Managerインタフェースのいずれかを使用して、ヘルス・チェックを手動で実行できます。チェッカは必要に応じて定期的に実行できます。また、サービス・リクエストの作業中に、Oracleサポート・サービスからチェッカの実行を要請される場合もあります。
状態モニター・チェックでは、結果、推奨事項およびその他の情報が自動診断リポジトリ（ADR）に格納されます。
ヘルス・チェックは次の2つのモードで実行できます。
OPENモードまたはMOUNTモード）のときは、チェックを実行できることを意味します。
NOMOUNTモード）している場合にチェックを実行できることを意味します。
DBオンライン・モードでは、すべてのヘルス・チェックを実行できます。DBオフライン・モードで使用できるのは、REDOの整合性チェックとDB構造の整合性チェックのみです。
状態モニターでは次のチェックが実行されます。
NOMOUNTモードの場合は、制御ファイルのみがチェックされます。
V$DATABASE_BLOCK_CORRUPTIONビューでも取得されます。このチェックではブロック間またはセグメント間の破損は検出されません。
V$CORRUPT_XID_LISTに格納します。ほとんどの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プロシージャは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、ADRCIユーティリティまたはDBMS_HM PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。
| レポートの表示方法 | 使用可能なレポート形式 |
|---|---|
|
Enterprise Manager |
HTML |
|
|
HTML、XMLおよびテキスト |
|
ADRCIユーティリティ |
XML |
チェッカの実行結果（結果、推奨事項およびその他の情報）はADRに格納されますが、レポートはすぐに生成されません。DBMS_HM PL/SQLパッケージまたはEnterprise Managerを使用してレポートを要求したときに、レポートがまだ生成されていない場合は、最初にADR内のチェッカ実行データからレポートが生成され、現行インスタンス用のADRホームのHMサブディレクトリにXML形式でレポート・ファイルとして格納された後に、レポートが表示されます。レポートがすでに生成されている場合は、そのレポートが表示されます。ADRCIユーティリティを使用する場合、レポートがまだ生成されていないときは、最初にレポート・ファイルを生成するためのコマンドを実行し、次にその内容を表示するためのコマンドを実行する必要があります。
チェッカ・レポートは、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: '/ade/sfogel_emdb/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: '/ade/sfogel_emdb/oracle/dbs/t_db1.f' is media corrupt Message : Object BMRTEST2 owned by SYS might be unavailable
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: '/ade/sfogel_e mdb/oracle/dbs/t_db1.f' is media corrupt FAILURE Block 64351 in datafile 1: '/ade/sfogel_e mdb/oracle/dbs/t_db1.f' is media corrupt
次の表では、パラメータが必要なヘルス・チェック用のパラメータを説明します。デフォルト値が（なし）のパラメータは必須です。
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
数値 |
（なし） |
ブロック・データ・ファイル番号 |
|
|
数値 |
（なし） |
データ・ブロック番号 |
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
テキスト |
0 |
最新の良好なREDOのSCN（既知の場合） |
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
テキスト |
（なし） |
UNDOセグメント番号 |
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
テキスト |
（なし） |
トランザクションID |
| パラメータ名 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
|
|
テキスト |
|
使用可能な値は、次のとおりです。 |
|
|
テキスト |
|
チェックする単一のコア・テーブルの名前。省略すると、すべてのコア・テーブルがチェックされます。 |
ほとんど発生しませんが、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文を修復できます。
この項の内容は、次のとおりです。
SQL修復アドバイザは、SQL文がクリティカル・エラーで失敗した後に実行します。このアドバイザは文を分析し、多くの場合、文を修復するためのパッチを推奨します。推奨事項を実装すると、適用したSQLパッチによってエラーが回避されます。これは、問合せオプティマイザによって、今後の実行に対して別の実行計画が選択されるためです。
SQL修復アドバイザは、サポート・ワークベンチの「問題の詳細」ページから実行します。 この項の説明は、SQL文によるクリティカル・エラーの通知をすでに受け取り、「問題の調査、レポートおよび解決」で説明したワークフローに従っていることを前提としています。
手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「SQL修復アドバイザ」ページが表示されます。
「処理中」ページが表示されます。その少し後に「SQL修復結果」ページが表示されます。
「SQLパッチ」列のチェック・マークは、推奨事項があることを示します。この列にチェック・マークがない場合は、SQL修復アドバイザがSQL文に対してパッチを提示できなかったことを意味します。
「修復の推奨」ページに、文に対する推奨パッチが表示されます。
「SQL修復結果」ページに戻り、確認メッセージが表示されます。
SQL修復アドバイザを使用してSQLパッチを適用した後は、そのSQLパッチを表示してパッチが適用されたことを確認したり、パッチを無効化または削除できます。パッチを削除する理由の1つに、後続リリースのOracle Databaseをインストールし、パッチを適用したSQL文でエラーが発生した不具合が修正されている場合があります。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。
「SQL計画管理」ページが表示されます。このページの詳細は、オンライン・ヘルプを参照してください。
「SQLパッチ」サブページに、データベース内のすべてのSQLパッチが表示されます。
SQLテキストをクリックして、その文の完全なテキストを表示します。
確認メッセージが表示され、パッチのステータスがDISABLEDに変更されます。後でパッチを再び有効にするには、パッチを選択して「有効化」をクリックします。
確認メッセージが表示されます。
データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。データ・リカバリ・アドバイザはEnterprise Managerサポート・ワークベンチ（サポート・ワークベンチ）、状態モニターおよびRMANユーティリティに統合され、データ破損の問題の表示、各問題の程度の評価（クリティカル、高優先度、低優先度）、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。
データ・リカバリ・アドバイザの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。ここでは、サポート・ワークベンチからアドバイザにアクセスする方法をいくつか説明します。
データ・リカバリ・アドバイザは、次の情報を表示したときにサポート・ワークベンチによって自動的に推奨され、サポート・ワークベンチからアクセスできます。
データ・リカバリ・アドバイザは「アドバイザ・セントラル」ページからも使用できます。このページへのリンクは、データベース・ホームページおよび「パフォーマンス」ページの「関連リンク」セクションにあります。
サポート・ワークベンチからデータ・リカバリ・アドバイザにアクセスする方法は次のとおりです。
「調査と解決」セクションの「データ・リカバリ・アドバイザ」リンクをクリックします。
このページへのアクセス手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
1つ以上のデータ破損結果を選択して、「リカバリ・アドバイザの起動」をクリックします。
「サポート・ワークベンチ」ホームページへのアクセス手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
ここでは、インシデント・パッケージに関するバックグラウンド情報を提供し、Enterprise Managerサポート・ワークベンチ（サポート・ワークベンチ）のカスタム・パッケージング・プロセスを使用してカスタマイズしたパッケージを作成、変更およびアップロードする方法を説明します。この項の内容は、次のとおりです。
診断データをカスタマイズしてOracleサポート・サービスにアップロードするには、最初に、インシデント・パッケージ（パッケージ）と呼ばれる中間論理構造にデータを収集します。パッケージは自動診断リポジトリ（ADR）に格納されているメタデータの集合で、ADR内外の診断データファイルやその他のファイルを指し示します。パッケージを作成するときは、そのパッケージに追加する問題を1つ以上選択します。次に、サポート・ワークベンチによって、選択した問題に関連する問題情報、インシデント情報および診断データ（トレース・ファイル、ダンプなど）がパッケージに自動的に追加されます。1つの問題に対して多数のインシデント（同じ問題の多数の発生）が存在する場合があるため、デフォルトでは、各問題の最初の3つと最後の3つのインシデントのみがパッケージに追加され、発生から90日を超えるインシデントは除外されます。このデフォルトの数は、サポート・ワークベンチの「インシデント・パッケージング構成」ページで変更できます。
パッケージが作成された後は、任意のタイプの外部ファイルを追加したり、選択したファイルをパッケージから削除できます。また、パッケージ内の選択したファイルを編集して機密データを削除することもできます。パッケージ・コンテンツを追加または削除すると、パッケージのメタデータのみが変更されます。
診断データをOracleサポート・サービスにアップロードする準備ができたら、最初に、パッケージのメタデータで参照されるすべてのファイルを含めてZIPファイルを作成します。次に、Oracle Configuration Managerを使用してそのZIPファイルをアップロードします。
次の各項では、パッケージの詳細を説明します。
問題の診断能力を向上させるには、問題に直接関連する診断データに加えて、その診断データに関連したデータの検証が必要になる場合があります。診断データは、時間、プロセスIDまたはその他の基準によって関係付けることができます。たとえば、インシデントの検証では、そのインシデントの5分後に発生したインシデントの検証も役立つ場合があります。同様に、インシデントの診断データには、インシデント発生時に実行されていたOracle Databaseプロセスのトレース・ファイルが含まれていることは明確ですが、元のプロセスに関連する他のプロセスのトレース・ファイルを含めることが役に立つ場合もあります。
このため、問題とそれに関連するインシデントがパッケージに追加されるときは、同時に、関連するトレース・ファイルとともに関係付けられたインシデントが追加されます。
パッケージの物理ファイルを作成する過程で、サポート・ワークベンチはインシデント・パッケージング・サービスを要求してパッケージをファイナライズします。ファイナライズとは、パッケージ内のインシデントに時間で関係付けられた追加のトレース・ファイル、および他の診断情報（アラート・ログ、ヘルス・チェッカ・レポート、SQLテスト・ケース、構成情報など）をパッケージに追加することを意味します。このため、ZIPファイル内のファイル数が、サポート・ワークベンチでパッケージ・コンテンツとして表示されたファイルの数より多くなる場合があります。
インシデント・パッケージング・サービスは一連のルールに従って、既存のパッケージ・データに関係付けるADR内のトレース・ファイルを決定します。一部のルールは、Enterprise Managerの「インシデント・パッケージング構成」ページで変更できます。
当初のパッケージ・データと関係付けられた追加データには機密情報が含まれている可能性があるため、Oracleサポート・サービスにアップロードする前に、このような機密情報を含むファイルを削除または編集することが重要です。このため、サポート・ワークベンチでは、パッケージをファイナライズするコマンドを独立した操作として実行できます。パッケージを手動でファイナライズした後は、パッケージ・コンテンツを検証し、ファイルを削除または編集してから、ZIPファイルを生成してアップロードできます。
Enterprise Managerサポート・ワークベンチには、インシデント・パッケージを作成してアップロードする方法として、クイック・パッケージング方法とカスタム・パッケージング方法があります。
クイック・パッケージング: 最小限のステップがある自動化された方法で、ガイド付きワークフロー（ウィザード）に編成されています。1つの問題を選択してパッケージ名と説明を入力し、パッケージ・コンテンツのアップロードを即時に実行するか、指定の日時に実行するかをスケジュールします。サポート・ワークベンチでは、問題に関連する診断データを自動的にパッケージに追加してファイナライズし、ZIPファイルを作成してアップロードします。この方法では、パッケージ・ファイルを追加、編集または削除したり、SQLテスト・ケースなどの他の診断データを追加することはできません。ただし、この方法は、初期障害診断データをOracleサポート・サービスにアップロードする最も簡単かつ迅速な方法です。
クイック・パッケージングが完了した後、ウィザードで作成されたパッケージはそのまま残ることに注意してください。このパッケージは、カスタム・パッケージング操作を使用して後で変更し、手動で再アップロードできます。
カスタム・パッケージング: 手動による方法で、ステップが多くなります。この方法は、詳細なパッケージング作業を行うサポート・ワークベンチの上級ユーザーを対象にしています。カスタム・パッケージングを使用すると、1つ以上の問題から新規パッケージを作成したり、1つ以上の問題を既存のパッケージに追加できます。新規または更新したパッケージに対して、次のような操作を実行できます。
これらの操作には、Oracleサポート・サービスに送信する診断情報が十分であることを確認するまで、数日間かかる場合があります。
カスタム・パッケージングでは、ZIPファイルの作成とOracleサポート・サービスへのアップロードを、2つの独立したステップとして実行できます。各ステップは、即時に実行するか、日時をスケジュールして実行できます。
ここでは、1つ以上の問題を表示してパッケージ化し、Oracleサポート・サービスにアップロードする高度なワークフローについて説明します。このワークフローでは、サポート・ワークベンチのカスタム・パッケージング機能を使用します。この機能によって、アップロードする前にインシデント・パッケージ（パッケージ）に対してファイルを追加、編集および削除できます。
手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「パッケージング・モードの選択」ページが表示されます。
|
注意: パッケージング・プロセスでは、関係付けられた追加の問題を自動的に選択してパッケージに追加できます。関係付けられた問題の例には、選択した問題の数分後に発生した問題があります。 詳細は、「インシデント・パッケージ内の関係付けられた診断データの概要」を参照してください。 |
「カスタム・パッケージング: パッケージの選択」ページが表示されます。
「パッケージのカスタマイズ」ページが表示されます。このページには、パッケージに含まれている問題とインシデントに加えて、選択可能なパッケージング・タスクが表示されます。これらのタスクは、新規パッケージまたは更新された既存のパッケージに対して実行します。
いくつかの一般的なパッケージング・タスクの手順については、「インシデント・パッケージの表示と変更」を参照してください。
パッケージに含まれているファイルのリスト（またはリストの一部）が表示されます（表示されるまでしばらく時間がかかる場合があります）。このリストには、関係付けられた診断情報を挿入することが決定され、ファイナライズ・プロセスでその情報が追加されたファイルが表示されます。
パッケージのファイナライズの定義については、「インシデント・パッケージ内の関係付けられた診断データの概要」を参照してください。
ファイルを編集および削除する手順については、「インシデント・パッケージ・ファイルの編集（コピー・アウトとコピー・イン）」および「インシデント・パッケージ・ファイルの削除」を参照してください。
ファイルの内容を表示するには、ファイルの表の右側の列にある眼鏡アイコンをクリックします。ホスト資格証明を入力します（要求された場合）。
「アップロード・ファイルの生成」ページが表示されます。
全パッケージのZIPファイルの場合は、常にパッケージのすべてのコンテンツ（元のコンテンツおよび関係付けられたすべてのデータ）がZIPファイルに追加されます。
増加分パッケージのZIPファイルの場合は、同じパッケージのZIPファイルが最後に作成された時点以降に新規追加または変更された診断情報のみがZIPファイルに追加されます。たとえば、パッケージに対して生成された物理ファイルにトレース・ファイルが最後に追加された時点以降にトレース情報がそのトレース・ファイルに追加された場合は、そのトレース・ファイルが増加分パッケージのZIPファイルに追加されます。逆に、パッケージに対して最後にアップロードした時点以降にトレース・ファイルを変更していない場合、そのトレース・ファイルは増加分パッケージのZIPファイルに追加されません。
ファイル作成ではシステム・リソースを大量に使用する場合があるため、ファイルの作成は、システム使用量が少ない時期にスケジュールすることをお薦めします。
「処理中」ページが表示され、ZIPファイルが作成されます。処理が完了すると、確認ページが表示されます。
「パッケージのカスタマイズ」ページに戻ります。
「アップロード・ファイルの表示/送信」ページが表示されます。
「Oracleに送信」ページが表示されます。選択したZIPファイルが表にリストされます。
「処理中」ページが表示されます。アップロードが正常に完了した場合は、確認ページが表示されます。アップロードが完了できなかった場合は、エラー・ページが表示されます。エラー・ページには、ZIPファイルをOracleに手動でアップロードするように要求するメッセージが表示される場合があります。その場合の手順については、Oracleサポート・サービス担当者に問い合せてください。
「アップロード・ファイルの表示/送信」ページに戻ります。「送信時刻」列で、アップロードしたファイルのステータスをチェックします。
カスタム・パッケージング方法を使用してインシデント・パッケージを作成した後は、Oracleサポート・サービスへのアップロード前に、そのパッケージのコンテンツを表示または変更できます。さらに、クイック・パッケージング方法を使用して診断データをパッケージ化してアップロードした後は、サポート・ワークベンチで作成したパッケージのコンテンツを表示または変更して、パッケージを再アップロードできます。パッケージを変更するには、パッケージング・タスクの選択肢からタスクを選択します。ほとんどのタスクは「パッケージのカスタマイズ」ページから選択できます。
ここでは、いくつかの一般的なパッケージング・タスクの手順について説明します。この項の内容は、次のとおりです。
また、次の各項では、パッケージの詳細の表示方法、特定のパッケージの「パッケージのカスタマイズ」ページにアクセスする方法について説明します。
「パッケージの詳細」ページには、パッケージ内のインシデント、トレース・ファイルおよびその他のファイルに関する情報が表示され、アクティビティ・ログを表示してパッケージに追加できます。
手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
自動診断リポジトリ（ADR）に現時点で格納されているパッケージのリストが表示されます。
パッケージ名に検索テキストが含まれているパッケージがすべて表示されます。全パッケージのリストを表示するには、「パッケージ」リンクを再度クリックします。
「パッケージの詳細」ページが表示されます。
「パッケージのカスタマイズ」ページでは、各種のパッケージング・タスク（問題の追加および削除、パッケージ・ファイルの追加、削除および修正（編集）、パッケージのZIPファイルの生成およびアップロードなど）を実行します。
「パッケージのカスタマイズ」ページが表示されます。
サポート・ワークベンチを使用すると、インシデント・パッケージ内の1つ以上のファイルを編集できます。この作業は、ファイル内の機密データを削除または上書きする場合に必要です。パッケージ・ファイルを編集するには、最初にパッケージから宛先ディレクトリにファイルをコピー・アウトし、テキスト・エディタまたは他のユーティリティを使用して編集してから、そのファイルをパッケージにコピーし直して、元のパッケージ・ファイルを上書きします。
次の手順では、パッケージがすでに作成されて診断データが格納されていることを前提としています。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
「ファイルのコピー・アウト」ページが表示されます。このページには、ファイルをコピーできるホストの名前が表示されます。
リストに表示するディレクトリの数を減らすには、「検索」フィールドに検索テキストを入力して「実行」をクリックします。ディレクトリ名に検索テキストが含まれているディレクトリがすべて表示されます。
「参照および選択: ファイルまたはディレクトリ」ウィンドウがクローズし、選択したディレクトリへのパスが「ファイルのコピー・アウト」ページの「宛先フォルダ」フィールドに表示されます。
「パッケージのカスタマイズ」ページに戻ると、コピー・アウトされたファイルをリストした確認メッセージが表示されます。
「ファイルのコピー・イン」ページが表示されます。このページには、コピー・アウトしたファイルが表示されます。
ファイルがパッケージにコピー・インされて、既存のファイルが上書きされます。「パッケージのカスタマイズ」ページに戻ると、コピー・インされたファイルをリストした確認メッセージが表示されます。
インシデント・パッケージには、任意のタイプの外部ファイルを追加できます。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
このページでは、パッケージに対してファイルを追加または削除できます。
「外部ファイルの追加」ページが表示されます。このページには、ファイルを選択可能なホストの名前が表示されます。
リストに表示するファイルまたはディレクトリの数を減らすには、「検索」フィールドに検索テキストを入力して「実行」をクリックします。ファイル名またはディレクトリ名に検索テキストが含まれているファイルまたはディレクトリがすべて表示されます。
「参照および選択」ウィンドウがクローズし、選択したファイルへのパスが「外部ファイルの追加」ページの「ファイル名」フィールドに表示されます。
「パッケージのカスタマイズ」ページに戻ると、「ファイル」サブページが表示されます。これで、選択したファイルがファイル・リストに表示されます。
インシデント・パッケージから任意のタイプのファイルを1つ以上削除できます。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
パッケージに含まれているファイルのリストが表示されます
このパッケージ対して物理ファイルをまだ生成していない場合は、すべてのパッケージ・ファイルがリストに表示されます。物理ファイルをすでに生成している場合は、ファイル・リストの上部に「表示」リストが表示されます。このリストでは、増加分パッケージ・コンテンツのみを表示するか、全パッケージ・コンテンツを表示するかを選択できます。デフォルトでは増加分パッケージ・コンテンツが選択されています。デフォルトの選択で表示されるのは、パッケージに対して物理ファイルが最後に生成された時点以降に作成または変更されたパッケージ・ファイルのみです。すべてのパッケージ・ファイルを表示するには、「表示」リストから「全パッケージ・コンテンツ」を選択します。
サポート・ワークベンチでは、インシデント・パッケージごとにアクティビティ・ログが保持されます。パッケージに対して実行したほとんどのアクティビティ（ファイルの追加や削除、パッケージのZIPファイルの作成など）はログに記録されます。独自のノートをログに追加することもできます。この機能は、特に、複数のデータベース管理者がパッケージで作業をする場合に便利です。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。
アクティビティ・ログが表示されます。
ノートの日時が記録され、リストに追加されます。
ここでは、インシデント・パッケージのプリファレンスの設定手順について説明します。インシデント・パッケージのプリファレンスの例には、インシデント情報を保持する日数、および各問題についてパッケージに含める最初と最後のインシデントの数があります（デフォルトでは、問題に多数のインシデントがある場合、最初の3つと最後の3つのインシデントのみがパッケージに追加されます）。この設定およびインシデント・パッケージの他のプリファレンスは、Enterprise ManagerまたはADRCIユーティリティを使用して変更できます。
手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。
「インシデント・パッケージング構成の表示」ページが表示されます。「ヘルプ」をクリックして、このページの設定の説明を表示します。
「インシデント・パッケージング構成の編集」ページが表示されます。
関連項目:
