日本語PDF
  1. データベース管理者ガイド
  2. 基本データベース管理
  3. 問題の診断と解決

9 問題の診断と解決

Oracle Databaseには、データベースの問題を診断して解決するために、診断データの収集と管理ための高度な障害診断インフラストラクチャが含まれています。診断データには、以前のリリースにも含まれていたトレース・ファイル、ダンプおよびコア・ファイルに加えて、顧客やOracleサポート・サービスが問題を迅速かつ効率的に識別、調査、追跡、解決できる新しいタイプの診断データが含まれています。

  • Oracle Databaseの障害診断インフラストラクチャについて
    Oracle Databaseには、データベースの問題を予防、検出、診断および解決するための障害診断インフラストラクチャが含まれています。
  • 問題の調査、報告および解決について
    Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)により、問題(クリティカル・エラー)を調査して報告し、場合によっては、解決できます。実行する必要がある一般的なタスクのセットをまとめた「ロードマップ」を使用できます。
  • 問題の診断
    この項では、Oracleデータベースでの問題を診断するための様々な方法について説明します。
  • 問題の報告
    Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージを作成、編集およびアップロードできます。カスタム・インシデント・パッケージにより、Oracleサポート・サービスに送信する診断データを詳細に制御できます。
  • 問題の解決
    この項では、SQL修復アドバイザやデータ・リカバリ・アドバイザなどのアドバイザ・ツール、およびリソース・マネージャおよび関連APIなどのリソース管理ツールを使用してデータベースの問題を解決する方法について説明します。

親トピック: 基本データベース管理

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サポート・サービスにアップロードすると、サポート担当者は問題を簡単かつ正確に再現できます。

親トピック: Oracle Databaseの障害診断インフラストラクチャについて

9.1.2 インシデントと問題

問題とは、データベース・インスタンス、Oracle Automatic Storage Management(Oracle ASM)インスタンス、またはその他のOracle製品やコンポーネントにおけるクリティカル・エラーです。インシデントとは、問題の1回の発生です。

  • インシデントおよび問題について
    クリティカル・エラーの診断と解決を容易にするために、障害診断インフラストラクチャには、問題とインシデントというOracle Databaseの2つの概念が導入されています。
  • インシデントのフラッド制御
    短時間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。このような理由から、障害診断インフラストラクチャでは、特定のしきい値に達すると、インシデントの生成にフラッド制御が適用されます。
  • トポロジ全体に関連する問題
    データベース・インスタンスで識別されるすべての問題については、診断能力フレームワークによって、Oracle Databaseインストールのトポロジ全体に関連する問題を識別できます。

親トピック: 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)は、問題の調査、ヘルス・チェック・レポートの表示、および初期障害診断データのパッケージ化を、すべてコマンドライン環境内で実行できるようにするユーティリティです。

親トピック: Oracle Databaseの障害診断インフラストラクチャについて

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に置き換えられています。

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は、これらのトップレベルのサブディレクトリを示しています。

図9-1 ADR内の製品/コンポーネント・タイプのサブディレクトリ

図9-1の説明が続きます
「図9-1 ADR内の製品/コンポーネント・タイプのサブディレクトリ」の説明

ノート:

構成に応じて、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

DB_UNIQUE_NAME

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のディレクトリ階層全体を示します。

図9-2 データベース・インスタンスのADRディレクトリ構造

図9-2の説明が続きます
「図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 Clusterware管理およびデプロイメント・ガイド

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ビューのデータ

列 説明

FACILITY

そのエラーをレポート可能な機能(Oracle Database (ORA)、Oracle Call Interface (OCI)など)

ERROR

エラー番号

関連項目:

内部エラーの詳細は、「インシデントおよび問題について」

親トピック: Oracle Databaseの障害診断インフラストラクチャについて

9.2 問題の調査、報告および解決について

Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)により、問題(クリティカル・エラー)を調査して報告し、場合によっては、問題を解決できます。実行する必要がある一般的なタスクのセットをまとめた「ロードマップ」を使用できます。

ノート:

この項で説明するタスクは、すべてCloud Controlベースです。すべてのタスク(または同等のタスク)は、ADRCIコマンドライン・ユーティリティ、PL/SQLパッケージ(DBMS_HM、DBMS_SQLDIAGなど)、およびその他のソフトウェア・ツールを使用して実行できます。ADRCIユーティリティの詳細は『Oracle Databaseユーティリティ』を、PL/SQLパッケージの詳細は『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

関連項目:

問題とその診断データの詳細は、「Oracle Databaseの障害診断インフラストラクチャについて」

親トピック: 問題の診断と解決

9.2.1 問題の調査、報告および解決のロードマップ

問題の調査は、Cloud Controlの「サポート・ワークベンチ」ホームページから開始できます。ただし、標準的なワークフローはデータベースのホームページのクリティカル・エラー・アラートから始まります。

図9-3に、問題を調査およびレポートし、場合によってはその問題を修復するためのタスクを示します。

図9-3 問題の調査、レポートおよび解決のためのワークフロー

図9-3の説明が続きます
「図9-3 問題の調査、レポートおよび解決のためのワークフロー」の説明

タスクの説明を次に示します。この後の項では、各タスクについて詳しく説明します。

関連項目:

「サポート・ワークベンチを使用した問題の表示」

親トピック: 問題の調査、報告および解決について

9.2.2 タスク1: Cloud Controlでのクリティカル・エラー・アラートの表示

問題(クリティカル・エラー)を調査するプロセスでは、最初にデータベース・ホームページまたはOracle Automatic Storage Managementホームページでクリティカル・エラー・アラートを検討します。

クリティカル・エラー・アラートを表示するには、次のようにします。

  1. Cloud Controlのデータベース・ホームページにアクセスします。
  2. 「インシデントと問題」セクションでアラートを表示します。

    必要に応じて、「アラート」ヘッダーの横にある表示/非表示アイコンをクリックしてアラートを表示します。

    また、「カテゴリ」リストで特定のカテゴリを選択し、このカテゴリについてのみアラートを表示することもできます。

    diag_incidents_and_problems.gifの説明が続きます
    図diag_incidents_and_problems.gifの説明
  3. 「サマリー」列で、調査するクリティカル・エラー・アラートのメッセージをクリックします。

    「インシデント・マネージャ」の「問題の詳細」ページの「一般」サブページが表示されます。このページには次の内容が表示されます。

    • 問題の詳細

    • 「トラッキング」セクションのアラートに関するコメントを承認、クリアまたは記録できるようにする各種のコントロール

    • サポート・ワークベンチを使用して問題を診断し、「ガイドされた解決」セクションに診断情報を格納できる各種のリンク。

    調査中の問題のタイプに応じて、その他のセクションが表示される場合があります。

    問題に関する詳細を表示するには、「インシデント・マネージャ」の「問題の詳細」ページで次のサブページをクリックします。

    • 「インシデント」サブページには、問題の個々のインシデントに関する情報が含まれています。

    • 「My Oracle Supportのナレッジ」サブページでは、My Oracle Supportにアクセスして問題に関する詳細を入手できます。

    • 「更新」サブページには、その問題について入力されたすべての更新が表示されます。

    • 「関連する問題」サブページには、現在の問題と同じ問題キーを持つその他の未解決問題が表示されます。

  4. 次のアクションのいずれかを実行します。

親トピック: 問題の調査、報告および解決について

9.2.3 タスク2: 問題の詳細の表示

インシデント・マネージャ問題の詳細ページから調査を続けます。

問題の詳細を表示するには、次のようにします。

  1. インシデント・マネージャ問題の詳細ページの一般サブページで、「診断」サブセクションの「サポート・ワークベンチ: 問題の詳細」をクリックします。

    「サポート・ワークベンチ」の「問題の詳細」ページが表示されます。

  2. (オプション)次の処理を1つ以上完了します。

    • 「調査と解決」セクションの「診断」で、「トポロジ全体に関連する問題」をクリックします。

      ローカルのOracle Automatic Storage Management(Oracle ASM)インスタンス、またはOracle Real Application Clusters環境における他のノード上のデータベースまたはOracle ASMインスタンスにおける関連する問題を示すページが表示されます。Cloud Controlのデータベース・ホームページ上の「関連アラート」セクションにクリティカル・アラートが表示されている場合は、このステップをお薦めします。

      詳細は、「トポロジ全体に関連する問題」を参照してください。

    • 「インシデント」サブページにインシデントの詳細を表示するには、インシデントを選択して「表示」をクリックします。

      インシデントの詳細ページにダンプ・ファイル・サブページが表示されます。

    • 「インシデントの詳細」ページで、「チェッカ結果」を選択して「チェッカ結果」サブページを表示します。

      このページには、クリティカル・エラー検出時に自動的に実行された状態チェックの結果が表示されます。

親トピック: 問題の調査、報告および解決について

9.2.4 タスク3: (オプション)追加の診断情報の収集

次のアクティビティを実行して、問題に関する追加の診断情報を収集します。この追加情報は、診断データに自動的に追加され、Oracleサポート・サービスにアップロードされます。これらのアクティビティの実行に関して不明な点がある場合は、Oracleサポートの担当者に確認してください。

親トピック: 問題の調査、報告および解決について

9.2.5 タスク4: (オプション)サービス・リクエストの作成

ここでは、Oracleサポート・サービスへのサービス・リクエストを作成し、サービス・リクエスト番号を問題情報とともに記録できます。

このタスクをスキップした場合は、「タスク5: 診断データのパッケージ化とOracleサポートへのアップロード」で、サポート・ワークベンチによりドラフトのサービス・リクエストが自動的に作成されます。

サービス・リクエストを作成するには、次のようにします。

  1. 「エンタープライズ」メニューから、「My Oracle Support」を選択してから、「サービス・リクエスト」を選択します。

    My Oracle Supportのログインおよび登録のページが表示されます。

  2. My Oracle Supportにログインし、通常の方法でサービス・リクエストを作成します。

    (オプション)次のステップのためにサービス・リクエスト番号(SR#)を覚えておきます。

  3. (オプション)問題の詳細ページに戻り、次の手順を実行します。

    1. 「サマリー」セクションで、「SR#」ラベルの横にある「編集」ボタンをクリックします。

    2. 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サポートにアップロードするには、次のようにします。

  1. サポート・ワークベンチ問題の詳細ページの調査と解決」セクションで、「クイック・パッケージ」をクリックします。

    「クイック・パッケージ」ウィザードの「新規パッケージの作成」ページが表示されます。

    ノート:

    まだ「問題の詳細」ページに移動していない場合は、このページに戻るための手順について、「サポート・ワークベンチを使用した問題の表示」を参照してください。

  2. (オプション)パッケージ名と説明を入力します。
  3. ページの残りのフィールドをすべて入力します。すでにこの問題に関するサービス・リクエストを作成している場合は、「新規サービス・リクエスト(SR)の作成」に対して「いいえ」オプション・ボタンを選択します。

    「新規サービス・リクエスト(SR)の作成」に対して「はい」オプション・ボタンを選択すると、「クイック・パッケージング」ウィザードにより、自動的にドラフトのサービス・リクエストが作成されます。後でMy Oracle Supportにログインして、このサービス・リクエストの詳細を入力する必要があります。

    「次へ」をクリックします。

    クイック・パッケージング・ウィザードによって表示されるページには、新しいパッケージを作成するコマンドが処理中であることが示されます。終了すると、クイック・パッケージング: コンテンツの表示ページが表示されます。

  4. 「コンテンツの表示」ページの内容を確認し、作成されたパッケージのサイズをノートにとってから「次へ」をクリックします。

    クイック・パッケージング: マニフェストの作成ページが表示されます。

  5. このページの情報を確認し、(「パス」ヘッダーの横にリストされる)マニフェストの場所をノートにとります。情報を確認したら「次へ」をクリックします。

    クイック・パッケージング: スケジュール・ページが表示されます。

  6. 「即時」または「後で」のいずれかを選択します。「後で」を選択する場合は、パッケージをMy Oracle Supportに発行する時間に関する追加情報を指定します。選択を行い、必要な情報を指定した後で、「発行」をクリックします。

    「処理中: パッケージのパッケージング中およびOracleへの送信中」という進捗ページが表示されます。

「クイック・パッケージング」ウィザードが完了したとき、新しいドラフトのサービス・リクエストが作成されている場合、Cloud ControlでMy Oracle Supportに表示される確認メッセージには、ドラフトのサービス・リクエストへのリンクが含まれています。リンクをクリックして、サービス・リクエストを確認および編集できます。

「クイック・パッケージング」ウィザードによって作成されたパッケージは、サポート・ワークベンチで引き続き使用できます。カスタム・パッケージング操作を使用してパッケージを変更し(新規インシデントの追加など)、後でパッケージを再度アップロードできます。「インシデント・パッケージの表示と変更」を参照してください。

親トピック: 問題の調査、報告および解決について

9.2.7 タスク6: サービス・リクエストの追跡および修復の実施

診断情報をOracleサポート・サービスにアップロードした後は、様々なアクティビティを実行してサービス・リクエストを追跡し、追加の診断情報を収集して、修復を実装できます。

このアクティビティには次のものがあります。

  • 問題情報にOracleバグ番号を追加します。

    そのためには、問題の詳細ページで「バグ#」ラベルの横にある「編集」ボタンをクリックします。この情報は参照専用です。

  • 問題のアクティビティ・ログにコメントを追加します。

    このアクティビティは、組織内の他のDBAと問題ステータスや履歴情報を共有する場合に実行します。たとえば、Oracleサポート・サービスとの通信結果を記録できます。コメントを追加するステップは、次のとおりです。

    1. 「サポート・ワークベンチを使用した問題の表示」で説明しているように、この問題の「問題の詳細」ページにアクセスします。

    2. 「アクティビティ・ログ」をクリックして、アクティビティ・ログ・サブページを表示します。

    3. 「コメント」フィールドにコメントを入力し、「コメントの追加」をクリックします。

      コメントがアクティビティ・ログに記録されます。

  • 新規に発生したインシデントをパッケージ化して再アップロードします。

    このアクティビティについては、問題の報告で説明されているカスタム・パッケージング方法を使用する必要があります。

  • ヘルス・チェックを実行します。

    状態モニターによる事前対策的な問題識別を参照してください。

  • 推奨されるOracleアドバイザを実行して修復を実施します。

    推奨されたアドバイザには、次のいずれかの方法でアクセスします。

    • 問題の詳細ページ—「調査と解決」セクションの「セルフ・サービス」タブ

    • 「サポート・ワークベンチ」ホームページ—「チェッカ結果」サブページ

    • 「インシデントの詳細」ページ—「チェッカ結果」サブページ

    表9-5に、クリティカル・エラーの修復に役立つアドバイザを示します。

    表9-5 クリティカル・エラーの修復に役立つOracleアドバイザ

    アドバイザ 対象となるクリティカル・エラー 参照

    データ・リカバリ・アドバイザ

    破損ブロック、破損または欠落しているファイル、その他のデータ障害

    「データ・リカバリ・アドバイザを使用したデータ破損の修復」

    SQL修復アドバイザ

    SQL文のエラー

    「SQL修復アドバイザを使用したSQLエラーの修復」

関連項目:

「インシデントの詳細」ページの「チェッカ結果」サブページを表示する手順は、「サポート・ワークベンチを使用した問題の表示」を参照してください

親トピック: 問題の調査、報告および解決について

9.3 問題の診断

この項では、Oracleデータベースでの問題を診断するための様々な方法について説明します。

親トピック: 問題の診断と解決

9.3.1 反応的な問題識別

この項では、Oracleデータベースの問題を反応的に識別する方法について説明します。

親トピック: 問題の診断

9.3.1.1 サポート・ワークベンチを使用した問題の表示

Cloud Controlでサポート・ワークベンチのホームページを使用して、すべての問題、または特定の期間内の問題を表示できます。

図9-4 Cloud Controlのサポート・ワークベンチのホームページ

図9-4の説明が続きます
「図9-4 Cloud Controlのサポート・ワークベンチのホームページ」の説明

「サポート・ワークベンチ」ホームページ(データベースまたはOracle ASM)にアクセスするには:

  1. Cloud Controlのデータベース・ホームページにアクセスします。

  2. 「Oracle Database」メニューから、「診断」を選択し、次に、「サポート・ワークベンチ」を選択します。

    データベース・インスタンスの「サポート・ワークベンチ」ホームページに「問題」サブページが表示されます。デフォルトでは、過去24時間の問題が表示されます。

  3. Oracle ASMインスタンスの「サポート・ワークベンチ」ホームページを表示するには、「関連リンク」セクションの「サポート・ワークベンチ(+ASM_hostname)」リンクをクリックします。

問題とインシデントを表示するには:

  1. 「サポート・ワークベンチ」ホームページの「表示」リストから希望する期間を選択します。すべての問題を表示するには、「すべて」を選択します。

  2. (オプション)「パフォーマンスとクリティカル・エラーのタイムライン」セクションが非表示の場合、セクション・ヘッダーの横にある「表示/非表示」アイコンをクリックして、セクションを表示します。

    このセクションでは、パフォーマンスの変化とインシデントの発生の関連を表示できます。

  3. (オプション)「詳細」列の下の「表示」をクリックして、特定の問題に関するすべてのインシデントのリストを表示します。次に、インシデントIDをクリックして、インシデントの詳細ページを表示します。

特定の問題の詳細を表示するには:

  1. サポート・ワークベンチのホームページで、問題を選択して「表示」をクリックします。

    問題の詳細ページにインシデント・サブページが表示されます。「インシデント」サブページには、オープンしてダンプが生成された(つまり、フラッド制御されていない)すべてのインシデントが表示されます。

  2. (オプション)通常のインシデントとフラッド制御されたインシデントの両方を表示するには、「ダンプされたデータ」リストで「すべて」を選択します。
  3. (オプション)インシデントの詳細を表示するには、インシデントを選択して「表示」をクリックします。

    インシデントの詳細ページが表示されます。

  4. (オプション)「インシデントの詳細」ページで、インシデントのチェッカ結果を表示するには、「チェッカ結果」をクリックします。
  5. (オプション)インシデントの詳細ページに、そのインシデントに対して実行可能なユーザー・アクションを表示するには、「追加の診断」をクリックします。各ユーザー・アクションにより、インシデントまたはその問題に関する追加の診断情報を収集できます。
9.3.1.2 自動診断リポジトリへの問題の手動追加

Cloud Controlのサポート・ワークベンチを使用して、手動でADRに問題を追加できます。

システムで生成された問題(内部でデータベースに対して生成されたクリティカル・エラーなど)は、自動的に自動診断リポジトリ(ADR)に追加され、サポート・ワークベンチ内で追跡されます。

サポート・ワークベンチから、これらの問題に関する診断データの追加収集、Oracleサポートへの診断データのアップロード、および場合によっては、問題の解決もでき、このすべてを、「問題の調査、報告および解決について」で説明されている使いやすいワークフローを使用して実行できます。

気付いた問題を、同じワークフローで処理できるように、手動でADRに追加する必要がある場合もあります。このような問題の例には、自動データベース診断モニター(ADDM)で診断されなかったグローバル・データベースのパフォーマンスに関する問題があります。サポート・ワークベンチは、このようなユーザー報告の問題を作成して処理するメカニズムを備えています。

ユーザー報告の問題を作成するには:

  1. 「サポート・ワークベンチ」ホームページにアクセスします。

    手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。

  2. 「関連リンク」で「ユーザー報告の問題の作成」をクリックします。

    「ユーザー報告の問題の作成」ページが表示されます。

    create_user_reported_prob.gifの説明が続きます
    図create_user_reported_prob.gifの説明
  3. リストされている問題のタイプのいずれかと問題が一致する場合は、その問題のタイプを選択して「推奨アドバイザの実行」をクリックし、Oracleアドバイザを実行して問題の解決を試みます。
  4. 推奨アドバイザで問題が解決しない場合、またはアドバイザを実行しなかった場合は、次のいずれかを実行します。

    • リストされている問題のタイプのいずれかと問題が一致する場合は、その問題のタイプを選択して「問題の作成の続行」をクリックします。

    • リストされている問題のいずれかのタイプと問題が一致しない場合は、問題のタイプ「その他」を選択して、「問題の作成の続行」をクリックします。

    問題の詳細ページが表示されます。

  5. 「問題の詳細」ページの手順に従います。

    詳細は、問題の調査、報告および解決についてを参照してください。

9.3.1.3 インシデントの手動作成

自動診断リポジトリ・コマンド・インタプリタ(ADRCI)ユーティリティを使用して、手動でインシデントを作成できます。

ADRCIユーティリティを使用してインシデントを手動で作成するには:

  1. ORACLE_HOMEおよびPATH環境変数が適切に設定されていることを確認します。PATH環境変数には、ORACLE_HOME/binディレクトリが含まれている必要があります。

  2. オペレーティング・システムのコマンド・プロンプトで次のコマンドを実行して、ADRCIユーティリティを起動します。

    ADRCI

    ADRCIユーティリティが起動し、次のプロンプトが表示されます。

    adrci>

  3. 次の構文を使用してADRCIコマンドを実行し、インシデントを手動で作成します。

    adrci> dde create incident type incident_type

    incident_type値で、作成するインシデントのタイプを指定します。

関連項目:

親トピック: 反応的な問題識別

9.3.2 状態モニターによる事前対策的な問題識別

状態モニターにより、データベースの診断チェックを実行できます。

  • 状態モニターについて
    Oracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。
  • ヘルス・チェックの手動実行
    状態モニターでは、DBMS_HM PL/SQLパッケージを使用するか、「アドバイザ・セントラル」ページの「チェッカ」サブページにあるCloud Controlインタフェースを使用して、手動でヘルス・チェックを実行できます。
  • チェッカ・レポートの表示
    チェッカを実行した後、その実行のレポートを表示できます。レポートには、結果、推奨事項およびその他の情報が含まれます。このレポートは、Cloud Control、ADRCIユーティリティまたはDBMS_HM PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。
  • 状態モニターのビュー
    チェッカ・レポートを要求するかわりに、レポートが作成されたADRデータを直接問い合せると、特定のチェッカの実行結果を表示できます。
  • ヘルス・チェック・パラメータの参考情報
    いくつかのヘルス・チェックでは、パラメータが必要です。デフォルト値が(なし)のパラメータは必須です。

親トピック: 問題の診断

9.3.2.1 状態モニターについて

Oracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。

  • 状態モニターについて
    状態モニター・チェック(チェッカ、ヘルス・チェックまたはチェックとも呼ばれる)では、データベースの様々なレイヤーとコンポーネントが検証されます。
  • ヘルス・チェックのタイプ
    状態モニターでは、いくつかの異なるタイプのチェックが実行されます。

親トピック: 状態モニターによる事前対策的な問題識別

9.3.2.1.1 状態モニター・チェックについて

状態モニター・チェック(チェッカ、ヘルス・チェックまたはチェックとも呼ばれます)では、データベースの様々なレイヤーとコンポーネントが検証されます。

ヘルス・チェックでは、ファイルの破損、物理ブロックおよび論理ブロック破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。また、ヘルス・チェックの結果のレポートが生成され、多くの場合、問題を解決するための推奨事項が示されます。ヘルス・チェックは次の2つの方法で実行できます。

  • リアクティブ—障害診断インフラストラクチャでは、クリティカル・エラーの内容に応じてヘルス・チェックを自動的に実行できます。

  • 手動—DBAは、DBMS_HM PL/SQLパッケージまたはCloud Controlインタフェースのいずれかを使用して、ヘルス・チェックを手動で実行できます。必要に応じて定期的にチェッカを実行できますが、Oracleサポートがサービス・リクエストについて共同で作業しているときにチェッカの実行をお願いさせていただくこともあります。

状態モニター・チェックでは、結果、推奨事項およびその他の情報が自動診断リポジトリ(ADR)に格納されます。

ヘルス・チェックは次の2つのモードで実行できます。

  • DBオンライン・モードは、データベースがオープン状態(つまり、OPENモードまたはMOUNTモード)のときは、チェックを実行できることを意味します。

  • DBオフライン・モードは、インスタンスは使用可能だがデータベース自体がクローズ(つまり、NOMOUNTモード)している場合にチェックを実行できることを意味します。

DBオンライン・モードでは、すべてのヘルス・チェックを実行できます。DBオフライン・モードで使用できるのは、REDOの整合性チェックとDB構造の整合性チェックのみです。

ノート:

「自動診断リポジトリ(ADR)」

9.3.2.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.3.2.2 ヘルス・チェックの手動実行

状態モニターでは、DBMS_HM PL/SQLパッケージを使用するか、「アドバイザ・セントラル」ページの「チェッカ」サブページにあるCloud Controlインタフェースを使用して、手動でヘルス・チェックを実行できます。

親トピック: 状態モニターによる事前対策的な問題識別

9.3.2.2.1 DBMS_HM PL/SQLパッケージを使用したヘルス・チェックの実行

ヘルス・チェックを実行するためのDBMS_HMプロシージャはRUN_CHECKです。

  1. RUN_CHECKをコールするには、次のようにチェック名と実行名を指定します。 

    BEGIN
  DBMS_HM.RUN_CHECK('Dictionary Integrity Check', 'my_run');
END;
/

  2. ヘルス・チェック名のリストを取得するには、次の問合せを実行します。

    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;
/
9.3.2.2.2 Cloud Controlを使用したヘルス・チェックの実行

Cloud Controlは、状態モニター・チェッカを実行するためのインタフェースを備えています。

Cloud Controlを使用して状態モニター・チェッカを実行するには:

  1. 「データベース・ホーム」ページにアクセスします。
  2. 「パフォーマンス」メニューから、「アドバイザ・ホーム」を選択します。
  3. 「チェッカ」をクリックして「チェッカ」サブページを表示します。
  4. 「チェッカ」セクションで、実行するチェッカをクリックします。
  5. 入力パラメータの値を入力するか、オプション・パラメータの場合は空白のままにしてデフォルトを使用します。
  6. 「OK」をクリックし、パラメータを確認して「OK」を再度クリックします。
9.3.2.3 チェッカ・レポートの表示

チェッカを実行した後は、その実行内容のレポートを表示できます。レポートには、結果、推奨事項およびその他の情報が含まれます。このレポートは、Cloud Control、ADRCIユーティリティまたはDBMS_HM PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。

親トピック: 状態モニターによる事前対策的な問題識別

9.3.2.3.1 チェッカ・レポートの表示について

チェッカの実行結果(結果、推奨事項およびその他の情報)はADRに格納されますが、レポートはすぐに生成されません。

レポートの表示方法 使用可能なレポート形式

Cloud Control

HTML

DBMS_HM PL/SQLパッケージ

HTML、XMLおよびテキスト

ADRCIユーティリティ

XML

DBMS_HM PL/SQLパッケージまたはCloud Controlを使用してレポートを要求したときに、レポートがまだ生成されていない場合は、最初にADR内のチェッカ実行データからレポートが生成され、現行インスタンス用のADRホームのHMサブディレクトリにXML形式でレポート・ファイルとして格納された後に、レポートが表示されます。レポートがすでに生成されている場合は、そのレポートが表示されます。ADRCIユーティリティを使用する場合、レポートがまだ生成されていないときは、最初にレポート・ファイルを生成するためのコマンドを実行し、次にその内容を表示するためのコマンドを実行する必要があります。

チェッカ・レポートは、Cloud Controlを使用して表示することをお薦めします。

ノート:

「自動診断リポジトリ(ADR)」

9.3.2.3.2 Cloud Controlを使用したレポートの表示

Cloud Controlを使用して、特定のチェッカ実行の状態モニター・レポートと結果を表示できます。

Cloud Controlを使用して実行結果を表示するには:

  1. 「データベース・ホーム」ページにアクセスします。
  2. 「パフォーマンス」メニューから、「アドバイザ・ホーム」を選択します。
  3. 「チェッカ」をクリックして「チェッカ」サブページを表示します。
  4. 表示するチェッカ実行の実行名をクリックします。

    「実行の詳細」ページにチェッカ実行の「結果」サブページが表示されます。

  5. 「実行」をクリックして「実行」サブページを表示します。

    チェッカ実行に関する詳細がCloud Controlに表示されます。

  6. 「レポートの表示」をクリックして、チェッカ実行のレポートを表示します。

    レポートが新規のブラウザ・ウィンドウに表示されます。

9.3.2.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.3.2.3.4 ADRCIユーティリティを使用したレポートの表示

ADRCIユーティリティを使用して、状態モニター・チェッカ・レポートを作成および表示できます。

ADRCIを使用してチェッカ・レポートを作成および表示するには:

  1. ORACLE_HOMEおよびPATH環境変数が正しく設定されていることを確認し、オペレーティング・システムのコマンド・プロンプトで次のコマンドを実行してADRCIユーティリティを起動します。
    ADRCI

    ADRCIユーティリティが起動し、次のプロンプトが表示されます。

    adrci>

    必要に応じて、現行のADRホームを変更できます。すべてのADRホームをリストするにはSHOW HOMESコマンドを、現行のADRホームを変更するにはSET HOMEPATHコマンドを使用します。詳細は、『Oracle Databaseユーティリティ』を参照してください。

  2. 次のコマンドを入力します。
    show hm_run

    このコマンドによって、ADRに登録されている(V$HM_RUNに格納された)すべてのチェッカ実行がリストされます。

  3. レポートを作成するチェッカ実行を検索し、チェッカ実行名をノートにとります。このチェッカ実行のレポートがすでに生成されている場合は、REPORT_FILEフィールドにファイル名が表示されます。レポートが生成されていない場合は、次のコマンドを実行してレポートを生成します。
    create report hm_run run_name
  4. レポートを表示するには、次のコマンドを入力します。
    show report hm_run run_name

ノート:

「自動診断リポジトリ(ADR)」

9.3.2.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

関連項目:

親トピック: 状態モニターによる事前対策的な問題識別

9.3.2.5 ヘルス・チェック・パラメータの参考情報

いくつかのヘルス・チェックでは、パラメータが必要です。デフォルト値が(なし)のパラメータは必須です。

表9-6 「データ・ブロックの整合性チェック」のパラメータ

パラメータ名 タイプ デフォルト値 説明

BLC_DF_NUM

数値

(なし)

ブロック・データ・ファイル番号

BLC_BL_NUM

数値

(なし)

データ・ブロック番号

表9-7 「REDOの整合性チェック」のパラメータ

パラメータ名 タイプ デフォルト値 説明

SCN_TEXT

テキスト

0

最新の良好なREDOのSCN(既知の場合)

表9-8 「UNDOセグメントの整合性チェック」のパラメータ

パラメータ名 タイプ デフォルト値 説明

USN_NUMBER

テキスト

(なし)

UNDOセグメント番号

表9-9 「トランザクションの整合性チェック」のパラメータ

パラメータ名 タイプ デフォルト値 説明

TXN_ID

テキスト

(なし)

トランザクションID

表9-10 「ディクショナリの整合性チェック」のパラメータ

パラメータ名 タイプ デフォルト値 説明

CHECK_MASK

テキスト

ALL

使用可能な値は、次のとおりです。

  • COLUMN_CHECKS—列のチェックのみを実行します。コア・テーブル内の列レベルの制約を検証します。

  • ROW_CHECKS—行のチェックのみを実行します。コア・テーブル内の行レベルの制約を検証します。

  • REFERENTIAL_CHECKS—参照チェックのみを実行します。コア・テーブル内の参照の制約を検証します。

  • ALL—すべてのチェックを実行します。

TABLE_NAME

テキスト

ALL_CORE_TABLES

チェックする単一のコア・テーブルの名前。省略すると、すべてのコア・テーブルがチェックされます。

9.3.3 その他の診断データの収集

この項では、アラート・ログおよびトレース・ファイルを使用して追加で診断データを収集する方法について説明します。

  • アラート・ログの表示
    アラート・ログは、テキスト・エディタ、Cloud ControlまたはADRCIユーティリティで表示できます。
  • トレース・ファイルの検索
    トレース・ファイルは、自動診断リポジトリ(ADR)の各ADRホーム下にあるtraceディレクトリに格納されます。このディレクトリ内の個々のトレース・ファイルを検索するには、データ・ディクショナリ・ビューを使用します。たとえば、現行セッションのトレース・ファイルへのパス、または各Oracle Databaseプロセスのトレース・ファイルへのパスを検索できます。

親トピック: 問題の診断

9.3.3.1 アラート・ログの表示

アラート・ログは、テキスト・エディタ、Cloud ControlまたはADRCIユーティリティを使用して表示できます。

Cloud Controlでアラート・ログを表示するには:

  1. Cloud Controlのデータベース・ホームページにアクセスします。

  2. 「Oracle Database」メニューから、「診断」を選択し、次に、「サポート・ワークベンチ」を選択します。

  3. 「関連リンク」で「アラート・ログの内容」をクリックします。

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

  4. 表示するエントリの数を選択して「実行」をクリックします。

テキスト・エディタを使用してアラート・ログを表示するには:

  1. SQL*PlusまたはSQL Developerなどの問合せツールを使用して、データベースに接続します。

  2. 「V$DIAG_INFOビューを使用したADRの場所の表示」に示すように、V$DIAG_INFOビューを問い合せます。

  3. XMLタグがないテキストのみのアラート・ログを表示するステップは、次のとおりです。

    1. V$DIAG_INFO問合せ結果からDiag Traceエントリに対応するパスをノートにとり、ディレクトリをそのパスに変更します。

    2. テキスト・エディタを使用して、alert_SID.logファイルをオープンします。

  4. XML形式のアラート・ログを表示するステップは、次のとおりです。

    1. V$DIAG_INFO問合せ結果からDiag Alertエントリに対応するパスをノートにとり、ディレクトリをそのパスに変更します。

    2. テキスト・エディタを使用して、log.xmlファイルをオープンします。

関連項目:

ADRCIユーティリティを使用してテキスト形式(XMLタグは削除されます)のアラート・ログを表示し、そのアラート・ログに対して問合せを実行する方法については、『Oracle Databaseユーティリティ』を参照してください。

親トピック: その他の診断データの収集

9.3.3.2 トレース・ファイルの検索

トレース・ファイルは、自動診断リポジトリ(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;

9.3.4 SQLテスト・ケース・ビルダーを使用したテスト・ケースの作成

SQLテスト・ケース・ビルダーは、異なるデータベース・インスタンス内の問題の再現に必要な情報を自動的に収集するツールです。

SQLテスト・ケースは、パフォーマンスの問題が発生した特定のSQL文の実行計画を開発者が再現できるようにするための一連の情報です。

この項では、次の項目について説明します。

親トピック: 問題の診断

9.3.4.1 SQLテスト・ケース・ビルダーの目的

SQLテスト・ケース・ビルダーによって、問題に関する情報とその問題が発生した環境に関する情報を収集し再現するプロセスが自動化されます。

ほとんどのSQLコンポーネントでは、再現可能なテスト・ケースを取得することが、迅速に不具合を解決するための最も重要な要因となります。ユーザーにとって最も長く手間のかかるステップでもあります。SQLテスト・ケース・ビルダーの目的は、SQLインシデントに関連する情報をできるだけ多く収集し、Oracleスタッフが別のシステムで問題を再現できるようにパッケージ化することです。

SQLテスト・ケース・ビルダーの出力は、事前に定義されたディレクトリに集められたスクリプトです。これらのスクリプトには、別のデータベース・インスタンスでの必要なすべてのオブジェクトと環境の再作成に必要なコマンドが含まれています。テスト・ケースの準備が整ったら、そのディレクトリのZIPファイルを作成して別のデータベースに移動するか、またはそのファイルをOracleサポートにアップロードできます。

9.3.4.2 SQLテスト・ケース・ビルダーの概念

SQLテスト・ケース・ビルダーの主な概念には、SQLインシデント、記録される情報のタイプおよび出力の形式が含まれます。

この項では、次の項目について説明します。

親トピック: SQLテスト・ケース・ビルダーを使用したテスト・ケースの作成

9.3.4.2.1 SQLインシデント

Oracle Databaseの障害診断インフラストラクチャでは、インシデントは1つの問題の1回の発生を表します。

SQLインシデントはSQL関連の問題です。問題(クリティカル・エラー)が複数回発生したとき、それぞれの発生に対してインシデントが作成されます。インシデントには日時が記録され、自動診断リポジトリ(ADR)で追跡されます。各インシデントには、ADR内で一意である数値のインシデントIDがあります。

SQLテスト・ケース・ビルダーには、コマンドラインで常時アクセスできます。Oracle Enterprise Manager Cloud Control(Cloud Control)では、SQLテスト・ケース・ページは、SQLインシデントが見つかった場合にのみ利用できます。

9.3.4.2.2 SQLテスト・ケース・ビルダーで取得される情報

SQLテスト・ケース・ビルダーは、SQL問合せおよびその環境に関する永続的な情報を取得します。

この情報には、実行中の問合せ、表と索引の定義(実際のデータではありません)、PL/SQLパッケージおよびプログラム・ユニット、オプティマイザ統計、SQL計画ベースライン、初期化パラメータの設定などがあります。Oracle Database 12c以降では、文の実行の一部としてのみ使用できる情報など、一時情報の取得や再現もSQLテスト・ケース・ビルダーで行われるようになりました。

SQLテスト・ケース・ビルダーでは、次のものがサポートされています。

  • 適応計画

    SQLテスト・ケース・ビルダーは、適応計画に関して行われた決定への入力を取得し、各決定の時点でそれらを再現します。適応計画の場合、最終プランの決定には、各バッファ統計コレクタの最終統計値で十分です。

  • 自動メモリー管理

    データベースは、各SQL操作で要求されたメモリーを自動的に処理します。ソートなどのアクションは、パフォーマンスに重大な影響を及ぼす可能性があります。SQLテスト・ケース・ビルダーでは、データベースで割り当てられたメモリーの場所とその割当て量などのメモリー・アクティビティが記録されています。

  • 動的統計

    動的統計とは、述語の選択性を見積もるために、データベースが再帰的SQL文を実行して表のブロックの小さいランダム・サンプルをスキャンする最適化手法です。異なるデータベース上の動的統計の再収集では、必ずしも同じ結果(データの消失時間など)が生成されるわけではありません。問題を再現するには、SQLテスト・ケース・ビルダーでソース・データベースから動的統計の結果をエクスポートします。テスト・データベースでは、SQLテスト・ケース・ビルダーによって、動的統計を再収集するのではなくソース・データベースから取得した同じ値を再利用します。

  • 複数の実行のサポート

    SQLテスト・ケース・ビルダーでは、問合せの複数の実行の間に累積された動的情報を取得できます。この機能は自動再最適化において重要です。

  • コンパイル環境およびバインド値の再現

    コンパイル環境設定は、問合せ最適化コンテキストの重要な一部です。ソース・データベースで問題の問合せが実行された際には、ユーザーが変更したデフォルトではない設定がSQLテスト・ケース・ビルダーで取得されます。デフォルトではないパラメータ値が使用されている場合、SQLテスト・ケース・ビルダーは、問合せを実行する前に、その同じ値を再構築します。

  • オブジェクトの統計履歴

    オブジェクトの統計履歴は、統計値の変更によって計画に変更が生じたかどうかを確認する場合に役に立ちます。DBMS_STATSは、履歴をデータ・ディクショナリ内に格納します。SQLテスト・ケース・ビルダーは、エクスポートの間にこの統計データをステージング表に格納します。インポートの間には、SQLテスト・ケース・ビルダーによって、統計履歴のデータがステージング表からターゲット・データベースに自動的にリロードされます。

  • 文の履歴

    文の履歴は、適応カーソル共有、静的フィードバックおよびカーソル共有の不具合に関する問題の診断の際に重要です。この履歴には、実行計画とコンパイル統計および実行統計が含まれます。

関連項目:

親トピック: SQLテスト・ケース・ビルダーの概念

9.3.4.2.3 SQLテスト・ケース・ビルダーの出力

SQLテスト・ケース・ビルダーの出力は、環境と必要なすべてのオブジェクトの再作成に必要なコマンドが格納された一連のファイルです。

SQLテスト・ケース・ビルダーでは、デフォルトで次のディレクトリにファイルが格納されます。ここでのincnumはインシデント番号を指し、runnumは実行番号を指します。 

$ADR_HOME/incident/incdir_incnum/SQLTCB_runnum

たとえば、有効な出力ファイル名は次のようになります。

$ORACLE_HOME/log/diag/rdbms/dbsa/dbsa/incident/incdir_2657/SQLTCB_1

次の例に示すように、SQL_TCB_DIRという名前のディレクトリ・オブジェクトを作成し、プロシージャDBMS_SQLDIAG.EXPORT_SQL_TESTCASEを実行することで、SQLテスト・ケース・ビルダー・ファイルの格納先となる特定のディレクトリを指定することもできます。 

CREATE OR REPLACE DIRECTORY SQL_TCB_DIR '/tmp';

DECLARE  
tc CLOB;
BEGIN 
  DBMS_SQLDIAG.EXPORT_SQL_TESTCASE (
    directory => 'SQL_TCB_DIR',   
    sql_text  => 'select * from hr_table',   
    testcase  => tc);
END;

ノート:

データベース管理者は、ディレクトリ・オブジェクトSQL_TCB_DIRで指定されたオペレーティング・システム・ディレクトリに対する読取りおよび書込みアクセス権限を持っている必要があります。

DBMS_SQLDIAG.EXPORT_SQL_TESTCASEプロシージャのtestcase_nameパラメータを使用してテスト・ケースの名前を指定することもできます。テスト・ケース名は、SQLテスト・ケース・ビルダーによって生成されるすべてのファイルの接頭辞として使用されます。

テスト・ケース名を指定しない場合、SQLテスト・ケース・ビルダーによって、次の形式のデフォルト・テスト・ケース名が使用されます。

oratcb_connectionId_sqlId_sequenceNumber_sessionId

ここで、connectionIdはデータベース接続ID、sqlIdはSQL文ID、sequenceNumberは内部順序番号、sessionIdはデータベース・セッションIDです。

DBMS_SQLDIAG.EXPORT_SQL_TESTCASEプロシージャのctrlOptionsパラメータを使用してSQLテスト・ケース・ビルダーの出力に含める追加情報を指定することもできます。ctrlOptionsパラメータに指定できるオプションの一部を次に示します。

  • compress: このオプションは、SQLテスト・ケース・ビルダー出力ファイルをzipファイルに圧縮するために使用します。

  • diag_event: このオプションは、SQLテスト・ケース・ビルダー出力に含めるトレース情報のレベルを指定するために使用します。

  • problem_type: このオプションは、SQLテスト・ケース・ビルダーのテスト・ケースの問題タイプを割り当てるために使用します。たとえば、テスト・ケースがパフォーマンス回帰の問題に関連している場合は、problem_typeオプションにPERFORMANCEの値を割り当てることができます。

次の例に示すように、V$SQL_TESTCASESビューを問い合せることで、SQLテスト・ケース・ビルダーによって生成されたすべてのテスト・ケースに関する情報を表示できます。 


select testcase_name, sql_text from v$sql_testcases;

TESTCASE_NAME                           SQL_TEXT
-------------------------------------   ----------------------
oratcb_0_am8q8kudm02v9_1_00244CC50001   select * from hr_table

ノート:

V$SQL_TESTCASESビューには、SQL_TCB_DIRという名前のSQLテスト・ケース・ビルダーのルート・ディレクトリ・オブジェクトが存在する必要があります。Oracle Autonomous Database環境では、プロビジョニング中にこのディレクトリ・オブジェクトが各PODに自動的に作成されます。オンプレミス・データベースの場合は、SQLテスト・ケース・ビルダーのルート・ディレクトリ・オブジェクトSQL_TCB_DIRを明示的に作成する必要があり、作成しないとV$SQL_TESTCASESビューに情報が表示されません。データベース管理者は、ディレクトリ・オブジェクトSQL_TCB_DIRで指定されたオペレーティング・システム・ディレクトリに対する読取りおよび書込みアクセス権限を持っている必要があります。

関連項目:

親トピック: SQLテスト・ケース・ビルダーの概念

9.3.4.3 SQLテスト・ケース・ビルダーのユーザー・インタフェース

SQLテスト・ケース・ビルダーにアクセスするには、Cloud Controlを使用するか、コマンドラインでPL/SQLを使用します。

この項では、次の項目について説明します。

親トピック: SQLテスト・ケース・ビルダーを使用したテスト・ケースの作成

9.3.4.3.1 SQLテスト・ケース・ビルダーのグラフィカル・インタフェース

Cloud Control内では、インシデント・マネージャ・ページまたはサポート・ワークベンチ・ページからSQLテスト・ケース・ビルダーにアクセスできます。

この項では、次の項目について説明します。

親トピック: SQLテスト・ケース・ビルダーのユーザー・インタフェース

9.3.4.3.1.1 インシデント・マネージャへのアクセス

データベース・ホーム・ページの「インシデントと問題」セクションから、インシデント・マネージャに移動できます。

インシデント・マネージャにアクセスするには:

  1. 適切な資格証明を使用してCloud Controlにログインします。

  2. 「ターゲット」メニューの下で、「データベース」を選択します。

  3. データベース・ターゲットのリストで、管理対象のOracle Databaseインスタンスのターゲットを選択します。

  4. データベースの資格証明の入力を求められた場合は、実行するタスクに必要な最小限の資格証明を入力します。

  5. インシデントと問題セクションで、調査するSQLインシデントを特定します。

    次の例のように、ORA 600エラーはSQLインシデントです。

    incidents_and_problems.gifの説明は次にあります
    図incidents_and_problems.gifの説明

  6. インシデントの概要をクリックします。

    「インシデント・マネージャ」の「問題の詳細」ページが表示されます。

    problem_details.gifの説明は次にあります
    図problem_details.gifの説明

    表にリストされたインシデントを含む「サポート・ワークベンチ」ページが表示されます。

9.3.4.3.1.2 サポート・ワークベンチへのアクセス

「Oracleデータベース」メニューから、サポート・ワークベンチに移動できます。

サポート・ワークベンチにアクセスするには:

  1. 適切な資格証明を使用してCloud Controlにログインします。

  2. 「ターゲット」メニューの下で、「データベース」を選択します。

  3. データベース・ターゲットのリストで、管理対象のOracle Databaseインスタンスのターゲットを選択します。

  4. データベースの資格証明の入力を求められた場合は、実行するタスクに必要な最小限の資格証明を入力します。

  5. 「Oracle Database」メニューから、「診断」→「サポート・ワークベンチ」を選択します。

    表にリストされたインシデントを含む「サポート・ワークベンチ」ページが表示されます。

9.3.4.3.2 SQLテスト・ケース・ビルダーのコマンドライン・インタフェース

DBMS_SQLDIAGパッケージは、SQLテスト・ケース・ビルダーに関連するタスクを実行します。

このパッケージは、SQLテスト・ケース・ビルダー用の様々なサブプログラムで構成されます。次の表にその一部を示します。

表9-11 DBMS_SQLDIAGパッケージ内のSQLテスト・ケース・ファンクション

プロシージャ 説明

EXPORT_SQL_TESTCASE

SQLテスト・ケースをユーザー指定のディレクトリにエクスポートします。

EXPORT_SQL_TESTCASE_DIR_BY_INC

引数として渡されたインシデントIDに対応するSQLテスト・ケースをエクスポートします。

EXPORT_SQL_TESTCASE_DIR_BY_TXT

引数として渡されたSQLテキストに対応するSQLテスト・ケースをエクスポートします。

IMPORT_SQL_TESTCASE

SQLテスト・ケースをスキーマにインポートします。

REPLAY_SQL_TESTCASE

SQLテスト・ケースの再現を自動化します。

EXPLAIN_SQL_TESTCASE

SQLテスト・ケースについて記述します。

関連項目:

DBMS_SQLDIAGパッケージについてさらに学習するには、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください

親トピック: SQLテスト・ケース・ビルダーのユーザー・インタフェース

9.3.4.4 SQLテスト・ケース・ビルダーの実行

Cloud Controlを使用してSQLテスト・ケース・ビルダーを実行できます。

前提条件

このチュートリアルでは、次のことが前提となっています。

  • 内部エラーが発生する次のEXPLAIN PLAN文をユーザーshとして実行します。 

    EXPLAIN PLAN FOR
  SELECT unit_cost, sold
  FROM   costs c,
         ( SELECT /*+ merge */ p.prod_id, SUM(quantity_sold) AS sold
           FROM   products p, sales s
           WHERE  p.prod_id = s.prod_id
           GROUP BY p.prod_id ) v
  WHERE  c.prod_id = v.prod_id;

  • データベース・ホーム・ページのインシデントと問題セクションに、内部エラーによって生成されるSQLインシデントが表示されます。

  • 「インシデント・マネージャへのアクセス」の説明に従って、「インシデントの詳細」ページにアクセスします。

SQLテスト・ケース・ビルダーを実行するには:

  1. 「インシデント」タブをクリックします。

    問題の詳細ページが表示されます。

    problem_details_summary.gifの説明は次にあります
    図problem_details_summary.gifの説明

  2. インシデントの概要をクリックします。

    インシデントの詳細ページが表示されます。

    incident_details.gifの説明は次にあります
    図incident_details.gifの説明

  3. 「ガイドされた解決」で、「診断データの表示」をクリックします。

    「インシデントの詳細: incident_number」ページが表示されます。

    incident_details_num.gifの説明は次にあります
    図incident_details_num.gifの説明

  4. 「アプリケーション情報」セクションで、「追加の診断」をクリックします。

    「追加の診断」サブページが表示されます。

    additional_diagnostics.gifの説明は次にあります
    図additional_diagnostics.gifの説明

  5. 「SQLテスト・ケース・ビルダー」を選択して、「実行」をクリックします。

    「ユーザー処理を実行」ページが表示されます。

    run_user_action.gifの説明は次にあります
    図run_user_action.gifの説明

  6. サンプリング割合を選択し(オプション)、「送信」をクリックします。

    処理が完了すると、「確認」ページが表示されます。

    sqltcb_confirmation.gifの説明は次にあります
    図sqltcb_confirmation.gifの説明

  7. 「SQLテスト・ケース・ビルダーの出力」に説明されている場所にあるSQLテスト・ケース・ファイルにアクセスします。

9.4 問題の報告

Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージを作成、編集およびアップロードできます。カスタム・インシデント・パッケージにより、Oracleサポート・サービスに送信する診断データを詳細に制御できます。

関連項目:

「Oracle Databaseの障害診断インフラストラクチャについて」

親トピック: 問題の診断と解決

9.4.1 インシデント・パッケージ

インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造に診断データを収集できます。

親トピック: 問題の報告

9.4.1.1 インシデント・パッケージについて

診断データをカスタマイズしてOracleサポート・サービスにアップロードするには、最初に、インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造にデータを収集します。

パッケージは自動診断リポジトリ(ADR)に格納されているメタデータの集合で、ADR内外の診断データファイルやその他のファイルを指し示します。パッケージを作成するときは、そのパッケージに追加する問題を1つ以上選択します。次に、サポート・ワークベンチによって、選択した問題に関連する問題情報、インシデント情報および診断データ(トレース・ファイル、ダンプなど)がパッケージに自動的に追加されます。1つの問題に対して多数のインシデント(同じ問題の多数の発生)が存在する場合があるため、デフォルトでは、各問題の最初の3つと最後の3つのインシデントのみがパッケージに追加され、発生から90日を超えるインシデントは除外されます。このデフォルトの数は、サポート・ワークベンチの「インシデント・パッケージング構成」ページで変更できます。

パッケージが作成されたら、あらゆるタイプの外部ファイルをパッケージに追加し、パッケージから選択したファイルを削除し、重要なデータを削除するパッケージ内の選択したファイルを編集できます。パッケージの内容を追加および削除する場合は、パッケージのメタデータのみが変更されます。

診断データをOracleサポート・サービスにアップロードする準備ができたら、最初に、パッケージのメタデータで参照されるすべてのファイルを含めてZIPファイルを作成します。次に、Oracle Configuration Managerを使用してそのZIPファイルをアップロードします。

ノート:

Oracle Configuration Managerをインストールしていないか、適切に構成していない場合は、My Oracle Supportを使用してZIPファイルを手動でアップロードする必要があります。

9.4.1.2 インシデント・パッケージ内の関係付けられた診断データについて

問題を診断するには、問題に直接関連する診断データのみでなく、直接関連するデータと相関する診断データも調べる必要がある場合があります。

診断データは、時間、プロセスIDまたはその他の基準によって関係付けることができます。たとえば、インシデントの検証では、そのインシデントの5分後に発生したインシデントの検証も役立つ場合があります。同様に、インシデントの診断データには、インシデント発生時に実行されていたOracle Databaseプロセスのトレース・ファイルが含まれていることは明確ですが、元のプロセスに関連する他のプロセスのトレース・ファイルを含めることが役に立つ場合もあります。

このため、問題とそれに関連するインシデントがパッケージに追加されるときは、同時に、関連するトレース・ファイルとともに関係付けられたインシデントが追加されます。

パッケージの物理ファイルを作成する過程で、サポート・ワークベンチはインシデント・パッケージング・サービスを要求してパッケージをファイナライズします。ファイナライズとは、パッケージ内のインシデントに時間で関係付けられた追加のトレース・ファイル、および他の診断情報(アラート・ログ、ヘルス・チェッカ・レポート、SQLテスト・ケース、構成情報など)をパッケージに追加することを意味します。そのため、ZIPファイル内のファイル数が、サポート・ワークベンチでパッケージ・コンテンツとして表示されたファイルの数より多くなる場合があります。

インシデント・パッケージング・サービスは一連のルールに従って、既存のパッケージ・データに関係付けるADR内のトレース・ファイルを決定します。一部のルールは、Cloud Controlの「インシデント・パッケージング構成」ページで変更できます。

当初のパッケージ・データと関係付けられた追加データには機密情報が含まれている可能性があるため、Oracleサポート・サービスにアップロードする前に、このような機密情報を含むファイルを削除または編集することが重要です。このため、サポート・ワークベンチでは、パッケージをファイナライズするコマンドを独立した操作として実行できます。パッケージを手動でファイナライズした後は、パッケージ・コンテンツを検証し、ファイルを削除または編集してから、ZIPファイルを生成してアップロードできます。

ノート:

パッケージのファイナライズは、パッケージがクローズして変更不可になることではありません。ファイナライズしたパッケージには、引続き診断データを追加できます。また、同じパッケージを複数回ファイナライズすることもできます。ファイナライズするたびに、関係付けられた新しいデータが追加されます。

9.4.1.3 クイック・パッケージングとカスタム・パッケージングについて

サポート・ワークベンチには、インシデント・パッケージを作成してアップロードする方法として、クイック・パッケージング方法とカスタム・パッケージング方法があります。

クイック・パッケージング—最小限のステップがある自動化された方法で、ガイド付きワークフロー(ウィザード)に編成されています。1つの問題を選択してパッケージ名と説明を入力し、パッケージ・コンテンツのアップロードを即時に実行するか、指定の日時に実行するかをスケジュールします。サポート・ワークベンチでは、問題に関連する診断データを自動的にパッケージに追加してファイナライズし、ZIPファイルを作成してアップロードします。この方法では、パッケージ・ファイルを追加、編集または削除したり、SQLテスト・ケースなどの他の診断データを追加することはできません。ただし、この方法は、初期障害診断データをOracleサポート・サービスにアップロードする最も簡単かつ迅速な方法です。クイック・パッケージングは、「問題の調査、報告および解決について」で説明しているワークフローで使用される方法です。

クイック・パッケージングが完了した後、ウィザードで作成されたパッケージはそのまま残ります。このパッケージは、カスタム・パッケージング操作を使用して後で変更し、手動で再アップロードできます。

カスタム・パッケージング—ステップが多く、より詳細な手動の方法です。これは、パッケージング・プロセスの詳細な制御を行うエキスパートのサポート・ワークベンチ・ユーザーを対象としています。カスタム・パッケージングでは、1つ以上の問題のある新規パッケージを作成、または1つ以上の問題を既存のパッケージに追加できます。これらの各種の操作を新規または更新されたパッケージで実行でき、これには次の操作が含まれます。

  • 問題やインシデントを追加または削除できます。

  • パッケージに対してトレース・ファイルを追加、編集または削除できます。

  • 任意のタイプの外部ファイルを追加または削除できます。

  • その他の診断データ(SQLテスト・ケースなど)を追加できます。

  • パッケージを手動でファイナライズしてからパッケージ・コンテンツを表示して、機密データを編集または削除する必要があるか、ファイルを削除してパッケージ・サイズを縮小する必要があるかを決定できます。

これらの操作には、Oracleサポートに送信する診断情報が十分であることを確認するまで、数日間かかる場合があります。

カスタム・パッケージングでは、ZIPファイルの作成とOracleサポートへのアップロードの要求を、2つの独立したステップとして実行できます。各ステップは、即時に実行するか、日時をスケジュールして実行できます。

9.4.1.4 相関パッケージについて

相関パッケージは、関連する問題に対して診断データのパッケージングおよびアップロードのための手段を提供します。

データベース・インスタンスの問題は、他のデータベース・インスタンスまたはOracle Automatic Storage Managementインスタンスに関連する問題がある場合があります。データベース・インスタンスの問題に対するパッケージ(メイン・パッケージ)を作成およびアップロードした後、関連する問題についての相関パッケージを作成およびアップロードできます。これは、サポート・ワークベンチのカスタム・パッケージング・ワークフローでのみ実行できます。

9.4.2 カスタム・パッケージングを使用した問題のパッケージ化とアップロード

サポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージ(パッケージ)を作成およびアップロードできます。アップロードする前に、診断データ・ファイルをパッケージから手動で追加、編集、および削除できます。

カスタム・パッケージングを使用して問題をパッケージ化およびアップロードするには:

  1. 「サポート・ワークベンチ」ホームページにアクセスします。

    手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。

  2. (オプション)パッケージに含める各問題について、問題に関連付けられているサービス・リクエスト番号(SR#)を指定します(ある場合)。指定するには、各問題について次のステップを実行します。

    1. 「サポート・ワークベンチ」ホームページの下部にある「問題」サブページで、問題を選択して「表示」をクリックします。

      ノート:

      問題のリストに対象の問題がみつからない場合、または問題数が多くてスクロールできない場合は、「表示」リストから期間を選択して「実行」をクリックします。対象の問題を選択して「表示」をクリックします。

      問題の詳細ページが表示されます。

    2. SR#ラベルの横にある「編集」をクリックし、サービス・リクエスト番号を入力して、「OK」をクリックします。

      「問題の詳細」ページにサービス・リクエスト番号が表示されます。

    3. ページの上部にあるロケータ・リンクで「サポート・ワークベンチ」をクリックし、「サポート・ワークベンチ」ホームページに戻ります。

      problem_details_breadcrumb.gifの説明が続きます
      図problem_details_breadcrumb.gifの説明

  3. 「サポート・ワークベンチ」ホームページで、パッケージ化する問題を選択して「パッケージ」をクリックします。

    「パッケージング・モードの選択」ページが表示されます。

    ノート:

    パッケージング・プロセスでは、関係付けられた追加の問題を自動的に選択してパッケージに追加できます。関係付けられた問題の例には、選択した問題の数分後に発生した問題があります。詳細は、「インシデント・パッケージ内の関係付けられた診断データについて」を参照してください。

  4. 「カスタム・パッケージング」オプションを選択して「続行」をクリックします。

    「カスタム・パッケージング: パッケージの選択」ページが表示されます。

    package_create_select.gifの説明が続きます
    図package_create_select.gifの説明

  5. 次のいずれかの操作を行います。

    • 新規パッケージを作成するには、「新規パッケージの作成」オプションを選択し、パッケージ名と説明を入力して「OK」をクリックします。

    • 選択した問題を既存のパッケージに追加するには、「既存パッケージからの選択」オプションを選択し、更新するパッケージを選択して「OK」をクリックします。

    「パッケージのカスタマイズ」ページが表示されます。選択するパッケージ・タスクのセレクションに加え、パッケージに含まれている問題およびインシデントが表示されます。新しいパッケージまたは更新した既存パッケージに対して実行できます。

    package_details.gifの説明が続きます。
    図package_details.gifの説明

  6. (オプション)「パッケージング・タスク」セクションで、リンクをクリックして1つ以上のパッケージング・タスクを実行します。または、「パッケージのカスタマイズ」ページとそのサブページにある他のコントロールを使用して、パッケージを操作します。完了後に「パッケージのカスタマイズ」ページに戻ります。

    いくつかの一般的なパッケージング・タスクの手順については、「インシデント・パッケージの表示と変更」を参照してください。

  7. 「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「Oracleサポートに送信」ヘッダー下にある「コンテンツ準備の終了」をクリックしてパッケージをファイナライズします。

    パッケージに含まれるファイルのリスト(または部分的なリスト)が表示されます。(これには少し時間がかかる場合があります。)リストには、相関診断情報を含むかどうかを識別し、終了プロセスによって追加されたファイルが含まれます。

    パッケージのファイナライズの定義の概要については、「インシデント・パッケージ内の関係付けられた診断データについて」を参照してください。

  8. 「ファイル」をクリックして、パッケージ内のファイルをすべて表示します。リストを検証して、公開できない機密データのファイルがあるかどうかを確認します。該当するファイルが見つかった場合は、それらのファイルを除外(削除)または編集します。

    ファイルを編集および削除する手順については、「インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)」および「インシデント・パッケージ・ファイルの削除」を参照してください。

    ファイルの内容を表示するには、ファイルの表の右側の列にある眼鏡アイコンをクリックします。ホスト資格証明を入力します(要求された場合)。

    ノート:

    通常、トレース・ファイルはOracle内部でのみ使用します。

  9. 「アップロード・ファイルの生成」をクリックします。

    「アップロード・ファイルの生成」ページが表示されます。

  10. 「全体」または「増分」オプションを選択して、全パッケージのZIPファイルまたは増加分パッケージのZIPファイルを生成します。

    全パッケージのZIPファイルの場合は、常にパッケージのすべてのコンテンツ(元のコンテンツおよび関係付けられたすべてのデータ)がZIPファイルに追加されます。

    増加分パッケージのZIPファイルの場合は、同じパッケージのZIPファイルが最後に作成された時点以降に新規追加または変更された診断情報のみがZIPファイルに追加されます。たとえば、パッケージに対して生成された物理ファイルにトレース・ファイルが最後に追加された時点以降にトレース情報がそのトレース・ファイルに追加された場合は、そのトレース・ファイルが増加分パッケージのZIPファイルに追加されます。逆に、パッケージに対して最後にアップロードした時点以降にトレース・ファイルを変更していない場合、そのトレース・ファイルは増加分パッケージのZIPファイルに追加されません。

    ノート:

    パッケージに対してアップロード・ファイルが作成されていない場合、「増分」オプションは使用不可になります。

  11. ファイル作成を即時実行するか、後の日時に実行するかをスケジュールして(「即時」または「後で」を選択)、「発行」をクリックします。

    ファイル作成ではシステム・リソースを大量に使用する場合があるため、ファイルの作成は、システム使用量が少ない時期にスケジュールすることをお薦めします。

    「処理中」ページが表示され、ZIPファイルが作成されます。処理が完了すると、確認ページが表示されます。

    ノート:

    ZIPファイルが作成されると、パッケージは自動的にファイナライズされます。

  12. 「OK」をクリックします。

    「パッケージのカスタマイズ」ページに戻ります。

  13. 「Oracleに送信」をクリックします。

    「アップロード・ファイルの表示/送信」ページが表示されます。

  14. (オプション)相関パッケージを作成してオラクル社に送信するには、「相関パッケージの送信」リンクをクリックします。

    「相関パッケージの作成、編集およびアップロード」を参照してください。相関パッケージに対する作業が完了した後、ページの上部にある「パッケージの詳細」リンクをクリックし、「パッケージのカスタマイズ」をクリックし、次に、再度「Oracleに送信」をクリックして、「アップロード・ファイルの表示/送信」ページに戻ります。

  15. アップロードするZIPファイルを選択して「Oracleに送信」をクリックします。

    「Oracleに送信」ページが表示されます。選択したZIPファイルが表にリストされます。

  16. 要求されたMy Oracle Support情報を入力します。「新規サービス・リクエスト(SR)の作成」の横にある「はい」または「いいえ」を選択します。「はい」を選択すると、ドラフトのサービス・リクエストが作成されます。この場合は、後でMy Oracle Supportにログインして、サービス・リクエストの詳細を入力する必要があります。「いいえ」を選択した場合は、既存のサービス・リクエスト番号を入力します。

  17. アップロードを即時または後の日時にスケジュールして、「発行」をクリックします。

    「処理中」ページが表示されます。アップロードが正常に完了した場合は、確認ページが表示されます。アップロードが完了できなかった場合は、エラー・ページが表示されます。エラー・ページには、ZIPファイルをOracleに手動でアップロードするように要求するメッセージが表示される場合があります。その場合の手順については、Oracleサポート・サービス担当者に問い合せてください。

  18. 「OK」をクリックします。

    「アップロード・ファイルの表示/送信」ページに戻ります。「送信時刻」列で、アップロードしたファイルのステータスをチェックします。

    ノート:

    サポート・ワークベンチでは、Oracle Configuration Managerを使用して物理ファイルをアップロードします。Oracle Configuration Managerがインストールされていなかったり、適切に構成されていないと、アップロードに失敗する場合があります。失敗した場合は、ファイルをOracleサポート・サービスに手動でアップロードするように要求するメッセージが、パッケージのZIPファイルへのパスとともに表示されます。アップロードは、My Oracle Supportを使用して手動で実行できます。

    Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。

  19. (オプション)相関パッケージを作成およびアップロードします。

    手順については、「相関パッケージの作成、編集およびアップロード」を参照してください。

関連項目:

親トピック: 問題の報告

9.4.3 インシデント・パッケージの表示と変更

カスタム・パッケージング方法を使用してインシデント・パッケージを作成した後は、Oracleサポート・サービスへのアップロード前に、そのパッケージのコンテンツを表示または変更できます。

さらに、クイック・パッケージング方法を使用して診断データをパッケージ化してアップロードした後は、サポート・ワークベンチで作成したパッケージのコンテンツを表示または変更して、パッケージを再アップロードできます。パッケージを変更するには、パッケージ・タスクの選択対象から選択しますが、それらのほとんどは「パッケージのカスタマイズ」ページで使用できます。

関連項目:

親トピック: 問題の報告

9.4.3.1 パッケージの詳細の表示

「パッケージの詳細」ページには、パッケージ内のインシデント、トレース・ファイルおよびその他のファイルに関する情報が含まれており、アクティビティ・ログを表示してパッケージに追加できます。

パッケージの詳細を表示するには:

  1. 「サポート・ワークベンチ」ホームページにアクセスします。

    手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。

  2. 「パッケージ」をクリックして「パッケージ」のサブページを表示します。

    自動診断リポジトリ(ADR)に現時点で格納されているパッケージのリストが表示されます。

  3. (オプション)表示するパッケージの数を減らすには、リストの上部にある「検索」フィールドにテキストを入力して「実行」をクリックします。

    パッケージ名に検索テキストが含まれているパッケージがすべて表示されます。パッケージの完全なリストを表示するには、「検索」フィールドからテキストを削除し、「実行」を再度クリックします。

  4. 「パッケージ名」列で、対象のパッケージのリンクをクリックします。

    「パッケージの詳細」ページが表示されます。

9.4.3.2 「パッケージのカスタマイズ」ページへのアクセス

「パッケージのカスタマイズ」ページでは、各種のパッケージング・タスク(問題の追加および削除、パッケージ・ファイルの追加、削除およびスクラブ(編集)、パッケージのZIPファイルの生成およびアップロードなど)を実行します。

「パッケージのカスタマイズ」ページにアクセスするには:

  1. 「パッケージの詳細の表示」で説明しているように、特定のパッケージの「パッケージの詳細」ページにアクセスします。
  2. 「パッケージのカスタマイズ」をクリックします。

    「パッケージのカスタマイズ」ページが表示されます。

9.4.3.3 インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)

サポート・ワークベンチを使用すると、インシデント・パッケージ内の1つ以上のファイルを編集できます。

この作業は、ファイル内の機密データを削除または上書きする場合に必要です。パッケージ・ファイルを編集するには、最初にパッケージから宛先ディレクトリにファイルをコピー・アウトし、テキスト・エディタまたは他のユーティリティを使用して編集してから、そのファイルをパッケージにコピーし直して、元のパッケージ・ファイルを上書きします。

次の手順では、パッケージがすでに作成されて診断データが格納されていることを前提としています。

インシデント・パッケージ・ファイルを編集するには:

  1. 対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。

    手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

  2. 「パッケージング・タスク」セクションで、「ユーザー・データのスクラブ」ヘッダー下にある「コンテンツ編集のためのファイルのコピー・アウト」をクリックします。

    ホスト資格証明を要求された場合は、資格証明を入力し、「OK」をクリックします。

    ファイルのコピー・アウト・ページが表示されます。ファイルをコピーできるホスト名が表示されます。

  3. 次のいずれかを実行して、ファイルの宛先ディレクトリを指定します。

    • 「宛先フォルダ」フィールドにディレクトリ・パスを入力します。

    • 「宛先フォルダ」フィールドの横にある拡大鏡アイコンをクリックして、次のステップを実行します。

      1. ホスト資格証明がプロンプトで要求された場合は、ファイルのコピー・アウト先のホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。

        「参照および選択: ファイルまたはディレクトリ」ウィンドウが表示されます。

      2. 対象の宛先ディレクトリを選択して「選択」をクリックします。

        「参照および選択: ファイルまたはディレクトリ」ウィンドウがクローズし、選択したディレクトリへのパスが「ファイルのコピー・アウト」ページの「宛先フォルダ」フィールドに表示されます。

  4. 「コピー・アウトするファイル」で、対象のファイルを選択して「OK」をクリックします。

    ノート:

    対象のファイルが見つからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「OK」をクリックします。

    「パッケージのカスタマイズ」ページに戻ると、コピー・アウトされたファイルをリストした確認メッセージが表示されます。

  5. テキスト・エディタまたは他のユーティリティを使用して、ファイルを編集します。

  6. 「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「ユーザー・データのスクラブ」ヘッダー下にある「コンテンツ置換えのためのファイルのコピー・イン」をクリックします。

    ファイルのコピー・イン・ページが表示されます。コピーしたファイルが表示されます。

  7. コピー・インするファイルを選択して「OK」をクリックします。

    ファイルがパッケージにコピー・インされて、既存のファイルが上書きされます。「パッケージのカスタマイズ」ページに戻ると、コピー・インされたファイルをリストした確認メッセージが表示されます。

9.4.3.4 インシデント・パッケージへの外部ファイルの追加

インシデント・パッケージには、任意のタイプの外部ファイルを追加できます。

外部ファイルをインシデント・パッケージに追加するには:

  1. 対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。

    手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

  2. 「ファイル」リンクをクリックして「ファイル」サブページを表示します。

    このページでは、パッケージに対してファイルを追加または削除できます。

  3. 「外部ファイルの追加」をクリックします。

    外部ファイルの追加ページが表示されます。これには選択したファイルからホスト名が表示されます。

  4. 次のいずれかを実行して、追加するファイルを指定します。

    • 「ファイル名」フィールドに、ファイルへのフルパスを入力します。

    • 「ファイル名」フィールドの横にある拡大鏡アイコンをクリックして、次のステップを実行します。

      1. ホスト資格証明がプロンプトで要求された場合は、外部ファイルが存在するホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。

      2. 「参照および選択: ファイルまたはディレクトリ」ウィンドウで必要なファイルを選択し、「選択」をクリックします。

        「参照および選択」ウィンドウがクローズし、選択したファイルへのパスが「外部ファイルの追加」ページの「ファイル名」フィールドに表示されます。

  5. 「OK」をクリックします。

    「パッケージのカスタマイズ」ページに戻ると、「ファイル」サブページが表示されます。これで、選択したファイルがファイル・リストに表示されます。

9.4.3.5 インシデント・パッケージ・ファイルの削除

インシデント・パッケージから任意のタイプのファイルを1つ以上削除できます。

インシデント・パッケージ・ファイルを削除するには:

  1. 対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。

    手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

  2. 「ファイル」リンクをクリックして「ファイル」サブページを表示します。

    パッケージに含まれているファイルのリストが表示されます。

    パッケージの物理ファイルをまだ生成していない場合、すべてのパッケージ・ファイルがリストに表示されます。すでに物理ファイルを生成している場合、ファイル・リストの上部に「表示」リストが表示されます。ここで、増分パッケージのコンテンツのみを表示するか、パッケージの内容すべてを表示するかを選択できます。デフォルトではパッケージの内容の増分を表示します。このデフォルト設定では、パッケージの物理ファイルが最後に生成されたとき以降に作成または変更されたパッケージ・ファイルのみが表示されます。すべてのパッケージ・ファイルを表示するには、「表示」リストから「全パッケージ・コンテンツ」を選択します。

  3. 削除するファイルを選択して「除外」をクリックします。

    ノート:

    対象のファイルが見つからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「削除」をクリックします。

9.4.3.6 インシデント・パッケージのアクティビティ・ログの表示と更新

サポート・ワークベンチでは、インシデント・パッケージごとにアクティビティ・ログが保持されます。

パッケージに対して実行したほとんどのアクティビティ(ファイルの追加や削除、パッケージのZIPファイルの作成など)はログに記録されます。独自のノートをログに追加することもできます。特に、これは、複数のデータベース管理者がパッケージを使用している場合に役立ちます。

インシデント・パッケージのアクティビティ・ログを表示および更新するには:

  1. 対象のインシデント・パッケージの「パッケージの詳細」ページにアクセスします。

    手順については、「パッケージの詳細の表示」を参照してください。

  2. 「アクティビティ・ログ」リンクをクリックして、「アクティビティ・ログ」サブページを表示します。

    アクティビティ・ログが表示されます。

  3. 自分のコメントをアクティビティ・ログに追加するには、「コメント」フィールドにテキストを入力して、「コメントの追加」をクリックします。

    コメントがリストに追加されます。

9.4.4 相関パッケージの作成、編集およびアップロード

Oracleサポート・サービスにパッケージをアップロードした後、1つ以上の相関パッケージを作成およびアップロードできます。

データベース・ホームページの「関連アラート」セクションにクリティカル・アラートが表示されている場合は上記をお薦めします。相関パッケージは、メイン・パッケージと呼ばれる元のパッケージと関連付けられています。メイン・パッケージには、データベース・インスタンス内で発生した問題が含まれます。相関パッケージには、他のインスタンス(Oracle ASMインスタンスやその他のデータベース・インスタンス)で発生した問題や、メイン・パッケージにある問題に関連する問題が含まれます。相関パッケージは、関連するインスタンスにそれぞれ1つのみ存在できます。

相関パッケージを作成、編集およびアップロードするには:

  1. メイン・パッケージの「パッケージの詳細」ページを表示します。

    手順については、「パッケージの詳細の表示」を参照してください。

  2. 「パッケージの詳細」ページ上で「パッケージのカスタマイズ」をクリックします。

  3. 「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションの「追加の診断データ」で、「相関パッケージの作成/更新」をクリックします。

  4. 「相関パッケージ」ページの「相関パッケージ」で、インシデントのあるインスタンスを1つ以上選択して「作成」をクリックします。

    確認メッセージが表示され、新規に作成された相関パッケージのパッケージIDが「ID」列に表示されます。

  5. 相関パッケージを作成したインスタンスを選択し、「コンテンツ準備の終了」をクリックします。

    確認メッセージが表示されます。

  6. (オプション)次のステップで相関パッケージを表示および編集します。

    1. パッケージIDをクリックしてパッケージを表示します。

      資格証明を要求された場合は、「ログイン」をクリックします。

    2. 「パッケージの詳細」ページで「ファイル」をクリックしてパッケージ内のファイルを表示します。

    3. 「パッケージのカスタマイズ」をクリックして、「インシデント・パッケージの表示と変更」に記載されている目的のカスタマイズ・タスクを実行します。

  7. アップロードするそれぞれの相関パッケージについて、「アップロード・ファイルの生成」をクリックします。

  8. オラクル社に送信するそれぞれの相関パッケージについて、「Oracleに送信」をクリックします。

    ノート:

    「Oracleに送信」が使用できない場合は、そのインスタンスに対して関連付けられたインシデントはありません。

関連項目:

親トピック: 問題の報告

9.4.5 相関パッケージの削除

相関パッケージは、そのパッケージを作成したターゲットのサポート・ワークベンチで削除します。

たとえば、Oracle ASMインスタンス・ターゲットに対して相関パッケージを作成した場合は、そのOracle ASMインスタンスのサポート・ワークベンチにアクセスします。

相関パッケージを削除するには:

  1. 相関パッケージを作成したターゲットのサポート・ワークベンチにアクセスします。

    ヒント:

    サポート・ワークベンチのページ下部の「関連リンク」セクションを参照してください。または、「サポート・ワークベンチを使用した問題の表示」を参照してください

  2. 「パッケージ」をクリックして「パッケージ」のサブページを表示します。
  3. リストから、相関パッケージを検索します。パッケージの説明を表示し、相関パッケージであることを確認します。
  4. パッケージを選択して「削除」をクリックします。
  5. 確認ページで「はい」をクリックします。

関連項目:

親トピック: 問題の報告

9.4.6 インシデント・パッケージのプリファレンスの設定

インシデント・パッケージのプリファレンスを設定できます。インシデント・パッケージのプリファレンスの例には、インシデント情報を保持する日数や、各問題のパッケージに含める最初と最後のインシデント数などがあります。

デフォルトでは、問題のインシデントが多数存在する場合、最初の3つと最後の3つのインシデントのみがパッケージ化されます。これらまたはその他のインシデント・パッケージのプリファレンスは、Cloud ControlまたはADRCIユーティリティを使用して変更できます。

Cloud Controlを使用してインシデント・パッケージのプリファレンスを設定するには:

  1. 「サポート・ワークベンチ」ホームページにアクセスします。

    手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。

  2. ページの下部にある「関連リンク」セクションで、「インシデント・パッケージング構成」をクリックします。

    「インシデント・パッケージング構成の表示」ページが表示されます。「ヘルプ」をクリックして、このページの設定の説明を表示します。

  3. 「編集」をクリックします。

    「インシデント・パッケージング構成の編集」ページが表示されます。

  4. 設定を編集し、「OK」をクリックして変更を適用します。

関連項目:

親トピック: 問題の報告

9.5 問題の解決

この項では、SQL修復アドバイザやデータ・リカバリ・アドバイザなどのアドバイザ・ツール、およびリソース・マネージャおよび関連APIなどのリソース管理ツールを使用してデータベースの問題を解決する方法について説明します。

  • SQL修復アドバイザを使用したSQLエラーの修復
    まれなケースで、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文の修復を試みることができます。
  • データ・リカバリ・アドバイザを使用したデータ破損の修復
    データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。
  • 過剰なシステム・リソースを使用するSQL文の実行計画の隔離
    Oracle Database 19c以上では、SQL隔離インフラストラクチャ(SQL隔離)を使用して、リソース・マネージャによって終了されOracleデータベース内の過剰なシステム・リソースを使用するSQL文の実行計画を隔離できます。個々のSQL文には複数の実行計画がある場合があり、隔離された実行計画を使用しようとするとそのSQL文は実行できなくなるため、データベースのパフォーマンスの低下を防ぐことができます。

親トピック: 問題の診断と解決

9.5.1 SQL修復アドバイザを使用したSQLエラーの修復

ほとんど発生しませんが、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文を修復できます。

親トピック: 問題の解決

9.5.1.1 SQL修復アドバイザについて

SQL修復アドバイザは、重大なエラーが発生してSQL文が失敗した場合に実行します。

このアドバイザによって、文が分析され、多くの場合、文を修復するためにパッチの適用が推奨されます。リコメンデーションを実装すると、適用されたSQLパッチによって、問合せオプティマイザで将来実行する場合の代替実行計画が選択され、失敗が回避されます。

Cloud Control、またはDBMS_SQLDIAGパッケージのサブプログラムを使用して、SQL修復アドバイザを実行できます。

9.5.1.2 Cloud Controlを使用したSQL修復アドバイザの実行

Cloud Controlのサポート・ワークベンチの「問題の詳細」ページからSQL修復アドバイザを実行できます。

通常、これを実行するのは、SQL文に起因するクリティカル・エラーの通知をすでに受け取り、「問題の調査、報告および解決について」で説明したワークフローに従っている場合です。

Cloud Controlを使用してSQL修復アドバイザを実行するには:

  1. 失敗したSQL文に関連する問題の「問題の詳細」ページにアクセスします。

    手順については、「サポート・ワークベンチを使用した問題の表示」を参照してください。

  2. 「調査と解決」セクションの「解決」ヘッダーで、「SQL修復アドバイザ」をクリックします。

    advisor_access1.gifの説明が続きます
    図advisor_access1.gifの説明

  3. 「SQL修復アドバイザ」ページで次のステップを実行します。

    1. 必要な場合は現在のタスク名を変更し、必要に応じてタスクの説明を入力し、アドバイザ・タスクのオプションの時間制限を変更またはクリアし、設定を調整してアドバイザを即時に実行するか、後の日時に実行するかをスケジュールします。

    2. 「送信」をクリックします

    「処理中」ページが表示されます。その少し後に「SQL修復結果」ページが表示されます。

    sql_repair_advisor_results.gifの説明が続きます
    図sql_repair_advisor_results.gifの説明

    「SQLパッチ」列のチェック・マークは、推奨事項があることを示します。この列にチェック・マークがない場合は、SQL修復アドバイザがSQL文に対してパッチを提示できなかったことを意味します。

    ノート:

    「SQL修復結果」ページが表示されない場合は、表示するために次のステップを実行します。

    1. データベース・ホームページに移動します。

    2. 「パフォーマンス」メニューから、「アドバイザ・ホーム」を選択します。

    3. 「アドバイザ・セントラル」ページの「結果」リストで、SQL修復アドバイザの最新エントリを探します。

    4. そのエントリを選択して「結果の表示」をクリックします。

  4. 推奨事項がある場合は、「SQLパッチ」列にチェック・マークが表示されます。推奨事項を参照するには、「表示」をクリックします。

    「修復の推奨」ページに、文に対する推奨パッチが表示されます。

  5. 「実装」をクリックします。

    「SQL修復結果」ページに戻り、確認メッセージが表示されます。

  6. (オプション)「SQLワークシートを使用して検証」をクリックして、SQLワークシートの文を実行し、パッチによって文が正常に修復したことを検証します。

9.5.1.3 DBMS_SQLDIAGパッケージのサブプログラムを使用したSQL修復アドバイザの実行

DBMS_SQLDIAGパッケージのサブプログラムを使用してSQL修復アドバイザを実行できます。

通常、これを実行するのは、SQL文に起因するクリティカル・エラーの通知を受け取り、「問題の調査、報告および解決について」で説明したワークフローに従っている場合です。

SQL修復アドバイザを実行するには、DBMS_SQLDIAGパッケージのサブプログラムであるCREATE_DIAGNOSIS_TASKを使用して診断タスクを作成し、EXECUTE_DIAGNOSIS_TASKを使用してその診断タスクを実行します。SQL修復アドバイザは、最初に重大なエラーを再現し、次にACCEPT_SQL_PATCHサブプログラムを使用して適用できるSQLパッチの形式での対処方法の生成を試みます。

ノート:

Oracle Database 19c以上では、単一のサブプログラムSQL_DIAGNOSE_AND_REPAIRを使用することで、診断タスクの作成、診断タスクの実行、および指定されたSQL文のSQLパッチ推奨の受入もできます。したがって、SQL_DIAGNOSE_AND_REPAIRサブプログラムは、CREATE_DIAGNOSIS_TASK、EXECUTE_DIAGNOSIS_TASKおよびACCEPT_SQL_PATCHサブプログラムの機能をすべて実行できます。

DBMS_SQLDIAGパッケージのサブプログラムを使用してSQL修復アドバイザを実行するには:

  1. 問題が発生したSQL文の特定

    重大なエラーが発生した次のSQL文について考えてみます。

    DELETE FROM t t1
WHERE t1.a = 'a' AND
      ROWID <> (SELECT MAX(ROWID)
                FROM t t2
                WHERE t1.a = t2.a AND
                      t1.b = t2.b AND
                      t1.d = t2.d)

    SQL修復アドバイザを使用して、この重大なエラーを修復します。

  2. 診断タスクの作成

    DBMS_SQLDIAG.CREATE_DIAGNOSIS_TASKを実行します。オプションのタスク名、アドバイザ・タスクのオプションの時間制限、および問題のタイプを指定できます。次の例では、SQLテキストを指定し、タスク名をerror_task、問題のタイプをDBMS_SQLDIAG.PROBLEM_TYPE_COMPILATION_ERRORと指定しています。 

    DECLARE
  rep_out   CLOB;
  t_id      VARCHAR2(50);
BEGIN
  t_id := DBMS_SQLDIAG.CREATE_DIAGNOSIS_TASK (
           sql_text => 'DELETE FROM t t1
                        WHERE t1.a = ''a'' AND
                              ROWID <> (SELECT MAX(ROWID)
                                        FROM t t2
                                        WHERE t1.a = t2.a AND
                                              t1.b = t2.b AND
                                              t1.d = t2.d)',
           task_name => 'error_task',
           problem_type => DBMS_SQLDIAG.PROBLEM_TYPE_COMPILATION_ERROR);

  3. 診断タスクの実行

    SQL修復アドバイザの対処方法生成および分析フェーズを実行するには、CREATE_DIAGNOSIS_TASKで戻されたタスクIDを使用して、DBMS_SQLDIAG.EXECUTE_DIAGNOSIS_TASKを実行します。多少の遅延後に、SQL修復アドバイザに戻ります。SQL修復アドバイザは、その実行の一環として検索結果の記録を残し、この記録には、SQL修復アドバイザのレポート機能を使用してアクセス可能です。 

    DBMS_SQLDIAG.EXECUTE_DIAGNOSIS_TASK (t_id);

  4. 診断タスクのレポートの生成

    診断タスクの分析には、DBMS_SQLDIAG.REPORT_DIAGNOSIS_TASKを使用してアクセスします。SQL修復アドバイザは、対処方法を検出できた場合、SQLパッチを推奨します。SQLパッチは、SQLプロファイルと類似していますが、SQLプロファイルとは異なり、コンパイル・エラーまたは実行エラーに対処するために使用します。 

    rep_out := DBMS_SQLDIAG.REPORT_DIAGNOSIS_TASK (t_id, DBMS_SQLDIAG.TYPE_TEXT);
DBMS_OUTPUT.PUT_LINE ('Report : ' ||  rep_out);
END;
/

  5. パッチの適用

    レポートでパッチが推奨されている場合は、DBMS_SQLDIAG.ACCEPT_SQL_PATCHを実行してパッチを受け入れることができます。このプロシージャは、引数としてタスク名を使用します。 

    EXECUTE DBMS_SQLDIAG.ACCEPT_SQL_PATCH(task_name => 'error_task', task_owner => 'SYS', replace => TRUE);

  6. パッチのテスト

    パッチを受け入れたため、SQL文を再実行できます。今回は重大なエラーが発生しなくなります。この文でEXPLAIN PLANを実行すると、計画を生成するためにSQLパッチが使用されたことが示されます。 

    DELETE FROM t t1
WHERE t1.a = 'a' AND
      ROWID <> (SELECT max(rowid)
                FROM t t2
                WHERE t1.a = t2.a AND
                      t1.b = t2.b AND
                      t1.d = t2.d);

関連項目:

DBMS_SQLDIAGパッケージのサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: SQL修復アドバイザを使用したSQLエラーの修復

9.5.1.4 Cloud Controlを使用したSQLパッチの表示、無効化または削除

SQL修復アドバイザでSQLパッチを適用した後、Cloud Controlを使用して、それを表示してその存在を確認することや、無効化または削除することもできます。パッチを無効化または削除する理由の1つに、後続リリースのOracle Databaseをインストールすることで、パッチ適用済SQL文のエラーの原因となっていた不具合が修正されている場合があります。

Cloud Controlを使用してSQLパッチを表示、無効化または削除するには:

  1. Cloud Controlのデータベース・ホームページにアクセスします。
  2. 「パフォーマンス」メニューから「SQL」を選択し、次に、「SQL計画管理」を選択します。

    「SQL計画管理」ページが表示されます。

  3. 「SQLパッチ」をクリックして、「SQLパッチ」サブページを表示します。

    「SQLパッチ」サブページに、データベース内のすべてのSQLパッチが表示されます。

  4. 関連するSQLテキストを検証して、特定のパッチを検索します。

    SQLテキストをクリックして、その文の完全なテキストを表示します。SQLテキストを表示した後、「戻る」をクリックします。

  5. 「SQLパッチ」サブページでパッチを無効化するには、パッチを選択して「無効化」をクリックします。

    確認メッセージが表示され、パッチのステータスがDISABLEDに変更されます。後でパッチを再び有効にするには、パッチを選択して「有効化」をクリックします。

  6. パッチを削除するには、パッチを選択して「削除」をクリックします。

    確認メッセージが表示されます。

9.5.1.5 DBMS_SQLDIAGパッケージのサブプログラムを使用したSQLパッチの無効化または削除

SQL修復アドバイザでSQLパッチを適用した後、DBMS_SQLDIAGパッケージのサブプログラムを使用してそれを無効化または削除できます。パッチを無効化または削除する理由の1つに、後続リリースのOracle Databaseをインストールすることで、パッチ適用済SQL文のエラーの原因となっていた不具合が修正されている場合があります。

DBMS_SQLDIAGパッケージのサブプログラムを使用してSQLパッチを無効化するには:

ステータス値DISABLEDによって無効にするパッチの名前を指定して、プロシージャDBMS_SQLDIAG.ALTER_SQL_PATCHを実行します。

次の例では、SQLパッチsql_patch_12345を無効にします。 

EXEC DBMS_SQLDIAG.ALTER_SQL_PATCH('sql_patch_12345', 'STATUS', 'DISABLED');

DBMS_SQLDIAGパッケージのサブプログラムを使用してSQLパッチを削除するには:

削除するパッチの名前を指定して、プロシージャDBMS_SQLDIAG.DROP_SQL_PATCHを実行します。パッチ名は、EXPLAIN PLANセクションから取得することも、ビューDBA_SQL_PATCHESを問い合せて取得することもできます。

次の例では、SQLパッチsql_patch_12345を削除します。 

EXEC DBMS_SQLDIAG.DROP_SQL_PATCH('sql_patch_12345');

関連項目:

親トピック: SQL修復アドバイザを使用したSQLエラーの修復

9.5.1.6 DBMS_SQLDIAGパッケージのサブプログラムを使用したパッチのエクスポートとインポート

SQL修復アドバイザを使用して作成されたパッチは、DBMS_SQLDIAGパッケージのサブプログラムを使用して、あるシステムからエクスポートし別のシステムにインポートできます。

パッチは、ステージング表を使用して、あるシステムからエクスポートして別のシステムにインポートできます。SQL診断セットの場合と同様に、ステージング表に挿入する操作はパックと呼ばれ、ステージング表のデータからパッケージを作成する操作はアンパックと呼ばれます。

DBMS_SQLDIAGパッケージのサブプログラムを使用してパッチをエクスポートおよびインポートするには:

  1. DBMS_SQLDIAG.CREATE_STGTAB_SQLPATCHをコールして、ユーザーSHが所有するステージング表を作成します。 

    EXEC DBMS_SQLDIAG.CREATE_STGTAB_SQLPATCH(
    table_name          =>  'STAGING_TABLE',
    schema_name         =>  'SH');

  2. DBMS_SQLDIAG.PACK_STGTAB_SQLPATCHを1回以上コールして、ステージング表にSQLパッチのデータを書き込みます。この場合、現行のスキーマ所有者が所有するステージング表に、DEFAULTカテゴリ内のすべてのSQLパッチのデータをコピーします。 

    EXEC DBMS_SQLDIAG.PACK_STGTAB_SQLPATCH(
    staging_table_name  =>  'STAGING_TABLE');

  3. この場合、現行のスキーマ所有者が所有するステージング表には、1つのSQLパッチSP_FIND_EMPLOYEEのみがコピーされます。 

    EXEC DBMS_SQLDIAG.PACK_STGTAB_SQLPATCH(
    patch_name          =>  'SP_FIND_EMPLOYEE',
    staging_table_name  =>  'STAGING_TABLE');

    その後、データポンプ、インポート・コマンドとエクスポート・コマンド、またはデータベース・リンクのいずれかを使用して、ステージング表を別のシステムに移動できます。

  4. DBMS_SQLDIAG.UNPACK_STGTAB_SQLPATCHをコールして、ステージング表内のパッチ・データから、新しいシステムにSQLパッチを作成します。この場合、ステージング表に格納されているSP_FIND_EMPLOYEEパッチのデータ内の名前を'SP_FIND_EMP_PROD'に変更します。 

    exec dbms_sqldiag.remap_stgtab_sqlpatch(
   old_patch_name      =>  'SP_FIND_EMPLOYEE',
   new_patch_name      =>  'SP_FIND_EMP_PROD',

関連項目:

DBMS_SQLDIAGパッケージのサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: SQL修復アドバイザを使用したSQLエラーの修復

9.5.2 データ・リカバリ・アドバイザを使用したデータ破損の修復

データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。

データ・リカバリ・アドバイザはEnterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)、状態モニターおよびRMANユーティリティに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。

データ・リカバリ・アドバイザの使用方法の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。この項では、サポート・ワークベンチからアドバイザにアクセスする方法について説明します。

データ・リカバリ・アドバイザは、データ破損またはその他のデータ障害に関連するヘルス・チェックの結果を表示する場合にサポート・ワークベンチによって自動的に推奨され、サポート・ワークベンチからアクセスできます。データ・リカバリ・アドバイザは「アドバイザ・セントラル」ページからも使用できます。

Cloud Controlでデータ・リカバリ・アドバイザにアクセスするには:

  1. Cloud Controlのデータベース・ホームページにアクセスします。

    データ・リカバリ・アドバイザを使用できるのは、SYSDBAとして接続している場合のみです。

  2. 「Oracle Database」メニューから、「診断」を選択し、次に、「サポート・ワークベンチ」を選択します。

  3. 「チェッカ結果」をクリックします。

    チェッカ結果サブページが表示されます。

    dra_access_2.gifの説明が続きます
    図dra_access_2.gifの説明

  4. 1つ以上のデータ破損結果を選択して、「リカバリ・アドバイザの起動」をクリックします。

関連項目:

データ・リカバリ・アドバイザの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

親トピック: 問題の解決

9.5.3 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

Oracle Database 19c以上では、SQL隔離インフラストラクチャ(SQL隔離)を使用して、リソース・マネージャによって終了されOracleデータベース内の過剰なシステム・リソースを使用するSQL文の実行計画を隔離できます。個々のSQL文には複数の実行計画がある場合があり、隔離された実行計画を使用しようとするとそのSQL文は実行できなくなるため、データベースのパフォーマンスの低下を防ぐことができます。

  • SQL文の実行計画の隔離について
    SQL隔離インフラストラクチャ(SQL隔離)を使用して、リソース・マネージャによって終了されOracleデータベース内の過剰なシステム・リソースを使用するSQL文の実行計画を隔離できます。SQL文の隔離された実行計画は再実行できなくなるため、データベースのパフォーマンスの低下を防ぐことができます。
  • SQL文の実行計画に対する隔離構成の作成
    これらのDBMS_SQLQパッケージ・ファンクション(CREATE_QUARANTINE_BY_SQL_IDまたはCREATE_QUARANTINE_BY_SQL_TEXT)のいずれかを使用して、SQL文の実行計画について隔離構成を作成できます。
  • 隔離構成での隔離しきい値の指定
    SQL文の実行計画について隔離構成を作成した後、DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して、隔離しきい値を指定できます。いずれかのリソース・マネージャしきい値が、SQL文の隔離構成で指定された隔離しきい値以下である場合、その隔離構成で指定された実行計画を使用すると、SQL文は実行できなくなります。
  • 隔離構成の有効化と無効化
    DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して隔離構成を有効化または無効化できます。隔離構成は、作成時にデフォルトで有効になります。
  • 隔離構成の詳細の表示
    DBA_SQL_QUARANTINEビューを問い合せることで、すべての隔離構成の詳細を取得できます。
  • 隔離構成の削除
    使用されていない隔離構成は、53週間後に自動的にパージまたは削除されます。DBMS_SQLQ.DROP_QUARANTINEプロシージャを使用して隔離構成を削除することもできます。DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して、隔離構成の自動削除を無効にできます。
  • SQL文の隔離された実行計画の詳細の表示
    V$SQLビューとGV$SQLビューを問い合せることで、SQL文の隔離された実行計画について詳細を取得できます。
  • あるデータベースから別のデータベースへの隔離構成の転送
    DBMS_SQLQパッケージのサブプログラム(CREATE_STGTAB_QUARANTINE、PACK_STGTAB_QUARANTINEおよびUNPACK_STGTAB_QUARANTINE)を使用して、あるデータベースから別のデータベースに隔離構成を転送できます。
  • 例: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離
    この例では、リソース・マネージャを使用して構成されたリソース使用制限を超えた場合に、SQL文の実行計画がどのように隔離されるかを示します。

親トピック: 問題の解決

9.5.3.1 SQL文の実行計画の隔離について

SQL隔離インフラストラクチャ(SQL隔離)を使用して、リソース・マネージャによって終了されOracleデータベース内の過剰なシステム・リソースを使用するSQL文の実行計画を隔離できます。SQL文の隔離された実行計画は再実行できなくなるため、データベースのパフォーマンスの低下を防ぐことができます。

リソース・マネージャを使用して、SQL文に対してシステム・リソース消費の上限(リソース・マネージャしきい値)を構成できます。リソース・マネージャは、リソース・マネージャしきい値を超えるSQL文を終了します。以前のOracle Databaseリリースでは、リソース・マネージャによって終了されたSQL文は、再実行された場合、リソース・マネージャによってその再実行が許可され、リソース・マネージャしきい値を超えると再度終了されます。したがって、このようなSQL文を再実行できると、システム・リソースの浪費になります。

Oracle Database 19c以上では、SQL隔離を使用して、リソース・マネージャによって終了されたSQL文の実行計画を、再実行できないように自動的に隔離できます。SQLの隔離情報は、データ・ディクショナリに定期的に永続化されます。リソース・マネージャがSQL文を終了すると、文が隔離されるまでに数分かかる場合があります。

ノート:

各種エディションおよびサービスでサポートされる機能の詳細は、『Oracle Databaseライセンス情報ユーザー・マニュアル』を参照

さらに、SQL隔離を使用すると、DBMS_SQLQパッケージのサブプログラムを使用して様々なシステム・リソースの消費に対するしきい値(リソース・マネージャしきい値と同様)を指定することにより、SQL文の実行計画の隔離構成も作成できます。これらのしきい値は、隔離しきい値と呼ばれます。いずれかのリソース・マネージャしきい値が、SQL文の隔離構成で指定された隔離しきい値以下である場合、その隔離構成で指定された実行計画を使用すると、SQL文は実行できなくなります。

次のステップに従って、DBMS_SQLQパッケージのサブプログラムを使用してSQL文の実行計画について隔離しきい値を手動で設定します。

  1. SQL文の実行計画について隔離構成を作成します
  2. 隔離構成に隔離しきい値を指定します

DBMS_SQLQパッケージのサブプログラムを使用して、隔離構成に関連する次の操作を実行することもできます。

  • 隔離構成の有効化または無効化
  • 隔離構成の削除
  • あるデータベースから別のデータベースへの隔離構成の転送

ノート:

  • 隔離構成は、SQL文の実行計画に固有です。2つの異なるSQL文が同じ実行計画を使用する場合は、同じ隔離構成を共有しません。

  • 実行計画は、リソース・マネージャによって終了される固有のSQL文に対して隔離されます。したがって、SQL文に対して隔離された実行計画は、リソース・マネージャによってまだ終了されていない別のSQL文に対して隔離されません。

  • SQL文の実行計画について隔離構成が作成されていない場合、または隔離構成に隔離しきい値が指定されていない場合、SQL文の実行計画は、リソース・マネージャしきい値のいずれかを超えたことでリソース・マネージャによって終了されると自動的に隔離されます。

たとえば、SQL文の実行時間を10秒(リソース・マネージャしきい値)に制限するリソース・マネージャのリソース・プランを考えてみます。SQL文Q1は、このリソース・プランがアプリケーションであるとします。Q1の実行時間が10秒を超えると、リソース・マネージャによって終了されます。次に、SQL隔離によって、実行計画に固有のQ1の隔離構成が作成され、実行時間10秒が隔離しきい値として隔離構成に保存されます。

同じ実行計画を使用してQ1が再度実行され、リソース・マネージャしきい値が10秒である場合、Q1の実行には10秒以上かかるため、SQL隔離では、隔離しきい値10秒を参照し、Q1が最終的にリソース・マネージャによって終了されると判断して、Q1の実行を許可しません。

リソース・マネージャしきい値が5秒に変更され、Q1が同じ実行計画を使用して再度実行される場合、Q1の実行には10秒以上かかるため、SQL隔離では、隔離しきい値10秒を参照し、Q1が最終的にリソース・マネージャによって終了されると判断して、Q1の実行を許可しません。

リソース・マネージャしきい値が15秒に変更され、Q1が同じ実行計画を使用して再度実行される場合、SQL隔離では、隔離しきい値10秒を参照し、Q1の実行には10秒以上かかると判断しますが、Q1の実行が15秒以内に完了する可能性があるため、Q1の実行を許可します。

ノート:

隔離しきい値はSQL文の実行計画に固有で、SQL文とその実行計画が超えるリソース・マネージャしきい値に基づいてSQL隔離によって自動的に設定されます。DBMS_SQLQパッケージのサブプログラムを使用して、SQL文の特定の実行計画について隔離しきい値を手動で設定することもできます。

9.5.3.2 SQL文の実行計画に対する隔離構成の作成

DBMS_SQLQパッケージ・ファンクション(CREATE_QUARANTINE_BY_SQL_IDまたはCREATE_QUARANTINE_BY_SQL_TEXT)のいずれかを使用して、SQL文の実行計画について隔離構成を作成できます。

次の例では、SQL文(SQL IDが8vu7s907prbgr)の実行計画(ハッシュ値が3488063716)の隔離構成を作成します。 

DECLARE
    quarantine_config VARCHAR2(30);
BEGIN
    quarantine_config := DBMS_SQLQ.CREATE_QUARANTINE_BY_SQL_ID(
                            SQL_ID => '8vu7s907prbgr', 
                            PLAN_HASH_VALUE => '3488063716');
END;
/

実行計画を指定しないか、それをNULLとして指定すると、固有の隔離構成がすでに作成されている実行計画を除き、SQL文のすべての実行計画に隔離構成が適用されます。

次の例では、SQL文(SQL IDが152sukb473gsk)のすべての実行計画について隔離構成を作成します。 

DECLARE
    quarantine_config VARCHAR2(30);
BEGIN
    quarantine_config := DBMS_SQLQ.CREATE_QUARANTINE_BY_SQL_ID(
                            SQL_ID => '152sukb473gsk');
END;
/

次の例では、SQL文'select count(*) from emp'のすべての実行計画について隔離構成を作成します。 

DECLARE
    quarantine_config VARCHAR2(30);
BEGIN
    quarantine_config := DBMS_SQLQ.CREATE_QUARANTINE_BY_SQL_TEXT(
                            SQL_TEXT => to_clob('select count(*) from emp'));
END;
/

CREATE_QUARANTINE_BY_SQL_IDファンクションとCREATE_QUARANTINE_BY_SQL_TEXTファンクションでは、隔離構成の名前が返されます。これは、DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用してSQL文の実行計画について隔離しきい値を指定するために使用できます。

9.5.3.3 隔離構成での隔離しきい値の指定

SQL文の実行計画について隔離構成を作成した後、DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して、隔離しきい値を指定できます。いずれかのリソース・マネージャしきい値が、SQL文の隔離構成で指定された隔離しきい値以下である場合、その隔離構成で指定された実行計画を使用すると、SQL文は実行できなくなります。

DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して、次のリソースの隔離しきい値を隔離構成に指定できます。

  • CPU時間

  • 経過時間

  • I/O (MB単位)

  • 物理I/O要求の数

  • 論理I/O要求の数

次の例では、隔離構成SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4に対して、CPU時間に指定された隔離しきい値が5秒で、経過時間が10秒です。 

BEGIN
    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'CPU_TIME',
       PARAMETER_VALUE => '5');

    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'ELAPSED_TIME',
       PARAMETER_VALUE => '10');
END;
/

この隔離構成で指定された実行計画を使用してSQL文が実行され、CPU時間のリソース・マネージャしきい値が5秒以下または経過時間が10秒以下である場合、SQL文は実行できなくなります。

ノート:

いずれかのリソース・マネージャしきい値が、SQL文の隔離構成で指定された隔離しきい値以下である場合、その隔離構成で指定された実行計画を使用すると、SQL文は実行できなくなります。

隔離構成の隔離しきい値の問合せ

DBMS_SQLQ.GET_PARAM_VALUE_QUARANTINEファンクションを使用して隔離構成の隔離しきい値を問い合せることができます。次の例では、隔離構成SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4のCPU時間消費について隔離しきい値が返されます。 

DECLARE
    quarantine_config_setting_value VARCHAR2(30);
BEGIN
    quarantine_config_setting_value := 
        DBMS_SQLQ.GET_PARAM_VALUE_QUARANTINE(
              QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
              PARAMETER_NAME  => 'CPU_TIME');
END;
/

隔離構成からの隔離しきい値の削除

PARAMETER_VALUEの値としてDBMS_SQLQ.DROP_THRESHOLDを指定することで、隔離構成から隔離しきい値を削除できます。次の例では、隔離構成SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4からCPU時間消費の隔離しきい値を削除します。 

BEGIN
    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'CPU_TIME',
       PARAMETER_VALUE => DBMS_SQLQ.DROP_THRESHOLD);
END;
/

関連項目:

DBMS_SQLQ.ALTER_QUARANTINEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

9.5.3.4 隔離構成の有効化と無効化

DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して、隔離構成を有効または無効にできます。隔離構成は、作成時にデフォルトで有効になります。

次の例では、SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4という名前の隔離構成を無効にします。 

BEGIN
    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'ENABLED',
       PARAMETER_VALUE => 'NO');
END;
/

次の例では、SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4という名前の隔離構成を有効にします。 

BEGIN
    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'ENABLED',
       PARAMETER_VALUE => 'YES');
END;
/

関連項目:

DBMS_SQLQ.ALTER_QUARANTINEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

9.5.3.5 隔離構成の詳細の表示

DBA_SQL_QUARANTINEビューを問い合せることで、すべての隔離構成の詳細を取得できます。

DBA_SQL_QUARANTINEビューには、各隔離構成に関する次の情報が表示されます。

  • 隔離構成名
  • 隔離構成が適用されるSQL文
  • 隔離構成が適用される実行計画のハッシュ値
  • 隔離構成のステータス(有効または無効)
  • 隔離構成の自動パージのステータス(はい、またはいいえ)
  • 隔離構成で指定されている隔離しきい値:
    • CPU時間
    • 経過時間
    • I/O (MB単位)
    • 物理I/O要求の数
    • 論理I/O要求の数
  • 隔離構成が作成された日時
  • 隔離構成が最後に実行された日時

関連項目:

DBA_SQL_QUARANTINEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

9.5.3.6 隔離構成の削除

使用されていない隔離構成は、53週間後に自動的にパージまたは削除されます。DBMS_SQLQ.DROP_QUARANTINEプロシージャを使用して隔離構成を削除することもできます。DBMS_SQLQ.ALTER_QUARANTINEプロシージャを使用して、隔離構成の自動削除を無効にできます。

次の例では、隔離構成SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4の自動削除を無効にします。 

BEGIN
    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'AUTOPURGE',
       PARAMETER_VALUE => 'NO');
END;
/

次の例では、隔離構成SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4の自動削除を有効にします。 

BEGIN
    DBMS_SQLQ.ALTER_QUARANTINE(
       QUARANTINE_NAME => 'SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4',
       PARAMETER_NAME  => 'AUTOPURGE',
       PARAMETER_VALUE => 'YES');
END;
/

次の例では、隔離構成SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4を削除します。 

BEGIN
    DBMS_SQLQ.DROP_QUARANTINE('SQL_QUARANTINE_3z0mwuq3aqsm8cfe7a0e4');
END;
/

関連項目:

DBMS_SQLQパッケージのサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

9.5.3.7 SQL文の隔離された実行計画の詳細の表示

V$SQLビューとGV$SQLビューを問い合せることで、SQL文の隔離された実行計画について詳細を取得できます。

V$SQLビューとGV$SQLビューの次の列には、SQL文の実行計画の隔離情報が示されます。

  • SQL_QUARANTINE: この列には、SQL文の実行計画に対する隔離構成の名前が示されます。

  • AVOIDED_EXECUTIONS: この列には、実行計画の隔離後にそのSQL文の実行計画の実行を防いだ回数が示されます。

関連項目:

V$SQLビューとGV$SQLビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

9.5.3.8 あるデータベースから別のデータベースへの隔離構成の転送

DBMS_SQLQパッケージのサブプログラム(CREATE_STGTAB_QUARANTINE、PACK_STGTAB_QUARANTINEおよびUNPACK_STGTAB_QUARANTINE)を使用して、あるデータベースから別のデータベースに隔離構成を転送できます。

たとえば、テスト・データベースで隔離構成をテストし、それらが適切に機能したことを確認したとします。その後、これらの隔離構成を本番データベースにロードできます。

次の例では、DBMS_SQLQパッケージのサブプログラムを使用してあるデータベース(ソース・データベース)から別のデータベース(宛先データベース)に隔離構成を転送するステップを説明します。

  1. SQL*Plusを使用して、管理権限があるユーザーとしてソース・データベースに接続し、DBMS_SQLQ.CREATE_STGTAB_QUARANTINEプロシージャでステージング表を作成します。

    次の例では、TBL_STG_QUARANTINEというステージング表を作成します。 

    BEGIN
  DBMS_SQLQ.CREATE_STGTAB_QUARANTINE (
    staging_table_name => 'TBL_STG_QUARANTINE');
END;
/

  2. 宛先データベースに転送する隔離構成をステージング表に追加します。

    次の例では、QUARANTINE_CONFIG_という名前で始まるすべての隔離構成をステージング表TBL_STG_QUARANTINEに追加します。 

    DECLARE
  quarantine_configs NUMBER;
BEGIN
  quarantine_configs := DBMS_SQLQ.PACK_STGTAB_QUARANTINE(
                            staging_table_name => 'TBL_STG_QUARANTINE',
                            name => 'QUARANTINE_CONFIG_%');
END;
/

    DBMS_SQLQ.PACK_STGTAB_QUARANTINEファンクションでは、ステージング表に追加された隔離構成の数が返されます。

  3. Oracle Data Pump Exportユーティリティを使用して、ステージング表TBL_STG_QUARANTINEをダンプ・ファイルにエクスポートします。

  4. ソース・データベース・システムから宛先データベース・システムにダンプ・ファイルを転送します。

  5. 宛先データベース・システムで、Oracle Data Pump Importユーティリティを使用して、ステージング表TBL_STG_QUARANTINEをダンプ・ファイルから宛先データベースにインポートします。

  6. SQL*Plusを使用して、管理権限があるユーザーとして宛先データベースに接続し、インポートしたステージング表から隔離構成を作成します。

    次の例では、インポートしたステージング表TBL_STG_QUARANTINEに格納されているすべての隔離構成に基づいて、宛先データベースに隔離構成を作成します。 

    DECLARE
  quarantine_configs NUMBER;
BEGIN
  quarantine_configs := DBMS_SQLQ.UNPACK_STGTAB_QUARANTINE(
                            staging_table_name => 'TBL_STG_QUARANTINE');
END;
/

    DBMS_SQLQ.UNPACK_STGTAB_QUARANTINEファンクションでは、宛先データベースで作成された隔離構成の数が返されます。

関連項目:

DBMS_SQLQパッケージのサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

9.5.3.9 例: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離

この例では、リソース・マネージャを使用して構成されたリソース使用制限を超えた場合に、SQL文の実行計画がどのように隔離されるかを示します。

  1. リソース・マネージャを使用して、ユーザーHRによって実行されるSQL文の実行時間制限(3秒)を指定します。

    次のコードは、DBMS_RESOURCE_MANAGERパッケージのサブプログラムを使用して複雑なリソース・プランを作成することによって、次の操作を実行します。

    • コンシューマ・グループTEST_RUNAWAY_GROUPを作成します。
    • ユーザーHRをTEST_RUNAWAY_GROUPコンシューマ・グループに割り当てます。
    • 実行時間が3秒を超えるとSQL文を終了するリソース・プランLIMIT_RESOURCEを作成します。
    • LIMIT_RESOURCEリソース・プランをTEST_RUNAWAY_GROUPコンシューマ・グループに割り当てます。 
    connect / as sysdba

begin

  -- Create a pending area
  dbms_resource_manager.create_pending_area();

  -- Create a consumer group 'TEST_RUNAWAY_GROUP'
  dbms_resource_manager.create_consumer_group (
    consumer_group => 'TEST_RUNAWAY_GROUP',
    comment        => 'This consumer group limits execution time for SQL statements'
  );

  -- Map the sessions of the user 'HR' to the consumer group 'TEST_RUNAWAY_GROUP' 
  dbms_resource_manager.set_consumer_group_mapping(
    attribute      => DBMS_RESOURCE_MANAGER.ORACLE_USER,
    value          => 'HR',
    consumer_group => 'TEST_RUNAWAY_GROUP'
  );

  -- Create a resource plan 'LIMIT_RESOURCE'
  dbms_resource_manager.create_plan(
    plan    => 'LIMIT_RESOURCE',
    comment => 'Terminate SQL statements after exceeding total execution time'
  );

  -- Create a resource plan directive by assigning the 'LIMIT_RESOURCE' plan to 
  -- the 'TEST_RUNAWAY_GROUP' consumer group
  -- Specify the execution time limit of 3 seconds for SQL statements belonging to 
  -- the 'TEST_RUNAWAY_GROUP' group
  dbms_resource_manager.create_plan_directive(
    plan             => 'LIMIT_RESOURCE',
    group_or_subplan => 'TEST_RUNAWAY_GROUP',
    comment          => 'Terminate SQL statements when they exceed the' || 
                        'execution time of 3 seconds',
    switch_group     => 'CANCEL_SQL',
    switch_time      => 3,
    switch_estimate  => false
  );

  -- Allocate resources to the sessions not covered by the currently active plan 
  -- according to the OTHER_GROUPS directive
  dbms_resource_Manager.create_plan_directive(
    plan              => 'LIMIT_RESOURCE',
    group_or_subplan  => 'OTHER_GROUPS',
    comment           => 'Ignore'
  );

  -- Validate and submit the pending area
  dbms_resource_manager.validate_pending_area();
  dbms_resource_manager.submit_pending_area();

  -- Grant switch privilege to the 'HR' user to switch to the 'TEST_RUNAWAY_GROUP' 
  -- consumer group
  dbms_resource_manager_privs.grant_switch_consumer_group('HR',
                                                          'TEST_RUNAWAY_GROUP',
                                                          false);
  
  -- Set the initial consumer group of the 'HR' user to 'TEST_RUNAWAY_GROUP'
  dbms_resource_manager.set_initial_consumer_group('HR',
                                                   'TEST_RUNAWAY_GROUP');

end;
/

-- Set the 'LIMIT_RESOURCE' plan as the top plan for the Resource Manager
alter system set RESOURCE_MANAGER_PLAN = 'LIMIT_RESOURCE' scope = memory;

-- Unlock the HR user and assign it the DBA role
alter user hr identified by hr_user_password account unlock;
grant dba to hr;

-- Flush the shared pool
alter system flush shared_pool;

  2. HRユーザーとしてOracleデータベースに接続し、実行時間制限の3秒を超えるSQL文を実行します。 

    select count(*)
from employees emp1, employees emp2,
     employees emp3, employees emp4,
     employees emp5, employees emp6, 
     employees emp7, employees emp8,
     employees emp9, employees emp10
where rownum <= 100000000;

    SQL文は実行時間制限の3秒を超えるとリソース・マネージャによって終了され、次のエラー・メッセージが表示されます。

    ORA-00040: active time limit exceeded - call aborted

    SQL文の実行計画が隔離リストに追加されるため、再度実行できなくなります。

  3. SQL文を再度実行します。

    SQL文の実行計画が隔離されているため、次のエラー・メッセージが表示されてSQL文は即時に終了します。

    ORA-56955: quarantined plan used

  4. v$sqlビューとdba_sql_quarantineビューを問い合せて、SQL文の隔離された実行計画の詳細を表示します。

    • v$sqlビューを問い合せます。v$sqlビューには、SQL文の各種統計(隔離統計を含む)に関する情報が表示されます。 

      select sql_text, plan_hash_value, avoided_executions, sql_quarantine 
from v$sql 
where sql_quarantine is not null;

      この問合せの出力は次のようになります。

      
SQL_TEXT                               PLAN_HASH_VALUE   AVOIDED_EXECUTIONS   SQL_QUARANTINE
------------------------------------   ---------------   ------------------   ------------------------------------
select count(*)                        3719017987        1                    SQL_QUARANTINE_3uuhv1u5day0yf6ed7f0c
from employees emp1, employees emp2, 
     employees emp3, employees emp4, 
     employees emp5, employees emp6,
     employees emp7, employees emp8, 
     employees emp9, employees emp10
where rownum <= 100000000;

      sql_quarantine列には、SQL文の実行計画に対する隔離構成の自動生成名が示されます。

    • dba_sql_quarantineビューを問い合せます。dba_sql_quarantineビューには、SQL文の実行計画の隔離構成に関する情報が表示されます。 

      select sql_text, name, plan_hash_value, last_executed, enabled 
from dba_sql_quarantine;

      この問合せの出力は次のようになります。

      
SQL_TEXT                               NAME                                   PLAN_HASH_VALUE   LAST_EXECUTED                  ENABLED
------------------------------------   ------------------------------------   ---------------   ----------------------------   -------
select count(*)                        SQL_QUARANTINE_3uuhv1u5day0yf6ed7f0c   3719017987        14-JAN-19 02.19.01.000000 AM   YES
from employees emp1, employees emp2, 
     employees emp3, employees emp4, 
     employees emp5, employees emp6,
     employees emp7, employees emp8, 
     employees emp9, employees emp10
where rownum <= 100000000;

      name列には、SQL文の実行計画に対する隔離構成の自動生成名が示されます。

  5. 例の環境をクリーン・アップします。

    次のコードは、この例で作成されたすべてのデータベース・オブジェクトを削除します。

    connect / as sysdba

begin
  for quarantineObj in (select name from dba_sql_quarantine) loop
    sys.dbms_sqlq.drop_quarantine(quarantineObj.name);
  end loop;
end;
/

alter system set RESOURCE_MANAGER_PLAN = '' scope = memory;

execute dbms_resource_manager.clear_pending_area();
execute dbms_resource_manager.create_pending_area();
execute dbms_resource_manager.delete_plan('LIMIT_RESOURCE');
execute dbms_resource_manager.delete_consumer_group('TEST_RUNAWAY_GROUP');
execute dbms_resource_manager.validate_pending_area();
execute dbms_resource_manager.submit_pending_area();

関連項目:

親トピック: 過剰なシステム・リソースを使用するSQL文の実行計画の隔離