ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Fusion Middlewareの管理
12c (12.1.2)
E47968-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

13 問題の診断

この章では、問題を解決したり、解決のためにOracleサポートに送信したりできるように、Oracle Fusion Middleware診断フレームワークを使用して問題に関する情報の収集および管理をする方法について説明します。

この章の構成は、次のとおりです。

13.1 診断フレームワークの理解

Oracle Fusion Middlewareには、問題の検出、診断および解決を支援する診断フレームワークが含まれています。特に対象としている問題は、コードのバグ、メタデータの破損、顧客データの破損、スレッドのデッドロック、一貫性のない状態に起因する障害などのクリティカル・エラーです。

クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断ログ(ログ・ファイルなど)が即座に取得され、その番号でタグ付けされます。データは、自動診断リポジトリ(ADR)に格納されます。ADRでは、後でデータをインシデント番号によって取得し、分析することができます。

診断フレームワークの目標は、次のとおりです。

診断フレームワークに組み込まれているテクノロジは次のとおりです。

13.1.1 インシデントと問題について

クリティカル・エラーを円滑に診断および解決するために、診断フレームワークには、問題とインシデントという、Oracle Fusion Middlewareの2つの概念が導入されています。

問題とは、クリティカル・エラーです。クリティカル・エラーは、内部エラーなどのサーバー・エラーとして発生します。問題はADRで追跡されます。各問題には、問題を説明する文字列である問題キーがあります。これには、エラー・コード(XXX-nnnnnという形式)と、場合によってはエラー固有の他の値が含まれます。

インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントにはタイムスタンプが付与され、ADRで追跡されます。それぞれのインシデントは数字のインシデントIDで識別されます。このインシデントIDは、ADRホーム内で一意です。インシデントが発生すると、診断フレームワークでは次の処理を実行します。

  • インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。

  • そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。

  • インシデント・ダンプをインシデントとともにADRに登録します。

13.1.1.1 インシデントのフラッド制御

問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。そのため、診断フレームワークでは、特定のしきい値に達したときにインシデントの生成に対してフラッド制御を適用します。フラッド制御インシデントは、ADRに記録されないインシデントです。かわりに、診断フレームワークによって、WARNINGレベルのメッセージがログ・ファイルに書き込まれ、oracle.dfw.incident.Incidentオブジェクトが返されます。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。

デフォルトでは、問題キーが同じインシデントが60分以内に6件以上発生すると、それ以降、問題キーが同じインシデントはフラッド制御されます。この値はMBeanを使用して変更できます(第13.3項を参照)。

13.1.2 診断フレームワークのコンポーネント

次の各項目で、診断フレームワークの主要コンポーネントについて説明します。


注意:

診断フレームワーク、特に自動診断リポジトリを使用するには、管理対象サーバーにOracle JRFが適用されている必要があります。Oracle JRFが適用されていれば、各管理対象サーバーに対して次のディレクトリが存在します。

DOMAIN_HOME/SERVERS/server_name/adr

ディレクトリが存在しない場合は、次のいずれかの手順を実行します。

  • 第19.3.1項の説明に従って、Oracle JRFを適用します。

  • Oracle JRFが適用されている場合は、第2.8.1項で説明しているように、ノード・マネージャのプロパティstartScriptEnabledがtrueに設定されていることを確認して、サーバーを再起動します。

13.1.2.1 自動診断リポジトリ

自動診断リポジトリ(ADR)は、追跡データやダンプなどのOracle Fusion Middleware診断データ用のファイルベースの階層リポジトリです。Oracle Fusion Middlewareのコンポーネントでは、インシデント・データはすべてADRに格納されます。それぞれのOracle WebLogic Serverでは、ADR内の自身のホーム・ディレクトリのサブディレクトリに診断データが格納されます。たとえば、それぞれの管理対象サーバーおよび管理サーバーにはADRホーム・ディレクトリがあります。

ADRのルート・ディレクトリは、ADRベースと呼ばれています。デフォルトでは、ADRベースは次のディレクトリにあります。

DOMAIN_HOME/servers/server_name/adr

ADRベースの中に、複数のADRホームがある場合があります。それぞれのADRホームは、Oracle WebLogic Serverの特定のインスタンスに対し、すべてのインシデント・データのルート・ディレクトリになります。次のパスは、ADRホームの場所を示します。

ADR_BASE/diag/ofm/domain_name/server_name

図13-1は、Oracle WebLogic ServerインスタンスのADRホームのディレクトリ階層を示しています。

図13-1 Oracle Fusion MiddlewareのADRディレクトリ構造

図13-1の説明が続きます
「図13-1 Oracle Fusion MiddlewareのADRディレクトリ構造」の説明

ADRホームのサブディレクトリには、次の情報が含まれています。

  • alert: XML形式のアラート・ログ。

  • incident: 複数のサブディレクトリを格納できるディレクトリ。それぞれのサブディレクトリには、当該のインシデントの名前が付けられます。サブディレクトリの名前はincdir_nで、このnはインシデントの番号を表しています。それぞれのサブディレクトリには、そのインシデントのみに関する情報および診断ダンプが格納されます。

  • (others): ADRホームのその他のサブディレクトリ。インシデント・パッケージなどの情報が格納されます。


注意:

ADRでは、インシデントをパッケージ化する際に、製品IDとしてドメイン名を使用し、インスタンスIDとしてサーバー名を使用します。ただし、いずれかの名前が30文字を超える場合は、ADRは名前の一部を切り捨てます。また、ドル記号($)と空白文字はアンダースコアに置き換えられます。

13.1.2.2 診断ダンプ

診断ダンプは、特定の診断情報を取得およびダンプします。この処理は、インシデントが作成された時点では自動で、管理者が要求した時点では手動で行われます。インシデント作成の一環として実行される場合、ダンプは一連のインシデント診断データに含まれます。診断ダンプには、JVMスレッド・ダンプ、JVMクラス・ヒストグラム・ダンプ、DMSメトリック・ダンプなどがあります。診断ダンプのリストについては、表13-7を参照してください。

13.1.2.3 管理MBean

診断フレームワークには、診断フレームワークの構成に使用できるMBeanが用意されています。たとえば、フラッド制御を有効化または無効化したり、指定された期間内に問題キーが同じインシデントが何回発生できるかを構成できます。管理MBeanを使用して診断フレームワークを構成する方法の詳細は、第13.3項を参照してください。

また、MBeanを使用すると、インシデントの問合せおよび作成を行ったり、使用可能な診断ダンプ・タイプのリストを検索したり、個々の診断ダンプを実行することができます。

13.1.2.4 診断フレームワーク用WLSTコマンド

診断フレームワークには、問題およびインシデントに関する情報の表示、インシデントの作成、特定のダンプの実行および一連の診断ダンプ・タイプの問合せに使用できるWLSTコマンドが用意されています。詳細は、次を参照してください。

13.1.2.5 ADRCIコマンドライン・ユーティリティ

ADRコマンド・インタプリタ(ADRCI)は、問題を調査し、初期障害診断データをパッケージ化してOracleサポートにアップロードするという処理を、コマンドライン環境ですべて実行できるユーティリティです。またADRCIを使用して、ADR内のダンプ・ファイルの名前を表示したり、コンテンツ・フィルタを指定して(または未指定で)XMLタグが取り除かれた状態でアラート・ログを表示することもできます。

ADRCIは次のディレクトリにインストールされています。

(UNIX) ORACLE_HOME/bin
(Windows) ORACLE_HOME\bin

ADRCIコマンドライン・ユーティリティの使用の詳細は、次の各項を参照してください。


関連項目:

  • 『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」

  • 『Oracle Database管理者ガイド』の「診断データの管理」

13.2 診断フレームワークの動作

診断フレームワークは、それぞれのサーバーでアクティブであり、構成された事前定義のルールに基づいてエラーを自動的に検出します。Oracle Fusion Middlewareのコンポーネントおよびアプリケーションは、常に監視対象となるため、自動的に診断フレームワークの恩恵を受けることになります。

インシデントは、次の2つの方法で自動的に検出されます。

図13-2は、インシデント・ログ検出でインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント・ログ検出でインシデントが検出されたときの、インシデント・ログ検出、WLDF診断イメージMBean、ADR、およびコンポーネントまたはアプリケーションのダンプの間のやり取りを示しています。

図13-2 インシデント・ログ検出で生成されるインシデント作成

図13-2の説明が続きます
図13-2「インシデント・ログ検出で生成されるインシデント作成」の説明

図13-2で示されている手順は、次のとおりです。

  1. インシデント検出ログ・フィルタは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。

  2. アプリケーションまたはコンポーネントは、java.util.logging APIを使用して、メッセージをログに記録します。

  3. ODLログ・ハンドラは、メッセージをインシデント検出ログ・フィルタに渡します。

  4. インシデント・ログ検出フィルタは、ログ・メッセージを検証し、コンポーネントの診断ルールに基づいて、インシデントを作成するかどうかを判断します。診断ルールによりインシデントを作成する必要があると示された場合、ADRにインシデントが作成されます。

  5. ODLログ・ハンドラは、ログ・メッセージをログ・ファイルに書き込み、制御をアプリケーションに戻します。

    ODLログ・ハンドラは、ログ・メッセージをログ・ファイルに書き込み、制御をOracle WebCenter Portalに戻します。

    インシデントが作成されると、次のようなメッセージがログ・ファイルに書き込まれます。

    [2013-05-28T11:05:34.603-07:00] [wls_server_1] [NOTIFICATION] [DFW-40101] [oracle.dfw.incident] [tid: [ACTIVE].ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 66217af9-247f-4344-94a9-14f90e75a586-000e093f,0] An incident has been signalled with the incident facts: [problemKey=MDS-50500 [MANUAL] incidentSource=MANUAL incidentTime=Tue May 28 11:05:34 PDT 2013 errorMessage=MDS-50500 executionContextId=null]

  6. 診断フレームワークは、コンポーネントの診断ルールで示される診断ダンプを実行します。

  7. 診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。

  8. 診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。

  9. WLDFは、ADRに診断イメージを書き込みます。

図13-3は、WLDF監視および通知システムでインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント通知リスナー、WLDF監視および通知システム、WLDF診断イメージMBeanの間の情報のやり取りを示しています。

図13-3 WLDF監視および通知で生成されるインシデント作成

図13-3の説明が続きます
図13-3「WLDF監視および通知で生成されるインシデント作成」の説明

図13-3で示されている手順は、次のとおりです。

  1. インシデント通知リスナーは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。

  2. Oracle Fusion Middleware診断フレームワークは、WLDFにJMX通知リスナーを登録します。リスナーは、WLDF監視および通知システムからのイベントをリスニングします。ここで処理される通知は、oracle.dfw.wldfnotificationタイプのみです。

  3. システム内のなんらかが原因となって、構成されたWLDF監視がトリガーされ、インシデント通知リスナーに通知が送信されます。通知には、監視をトリガーする原因となったデータについて記述したイベント情報が含まれます。

  4. 診断フレームワークにより、ADRにインシデントが作成されます。

  5. 診断フレームワークは、診断ルールで示される診断ダンプを実行します。

  6. 診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。

  7. 診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。

  8. WLDFは、ADRに診断イメージを書き込みます。

13.3 診断フレームワークの構成

診断フレームワークの一部の設定を構成できます。また、インシデントを作成するようにWLDF監視および通知を構成することもできます。次の各項目で、診断フレームワークを構成する方法を説明します。

13.3.1 診断フレームワークの設定の構成

次の設定を構成できます。

  • ログ・ファイルを使用したインシデントの検出の有効化または無効化

  • フラッド制御およびフラッド制御のパラメータ設定の有効化または無効化

これらの設定を構成するには、診断フレームワークMBean DiagnosticConfigを使用します。次に、MBeanのObjectNameを示します。

oracle.dfw:type=oracle.dfw.jmx.DiagnosticsConfigMBean,name=DiagnosticsConfig

表13-1は、DiagnosticConfig MBeanの属性と各パラメータの説明を示しています。

表13-1 診断フレームワークのDiagnosticConfig MBeanの属性

属性 説明

DumpSamplingIdleWhenHealthy

システムが健全な場合にダンプ・サンプリングを有効にするかどうかを決定します。デフォルトで、これはtrueに設定されています(インシデントが発生するまで、ダンプ・サンプリングは有効ではありません)。

DumpSamplingMinimumHealthyPeriod

インシデントが発生した後、ダンプ・サンプリングが有効になるまでの時間(秒数)。デフォルトは259200秒(72時間)です。

floodControlEnabled

フラッド制御を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

フラッド制御は、手動で作成されたインシデントには適用されません。

floodControlIncidentCount

フラッド制御で制御されるまでに、floodControlIncidentTimeoutPeriodで指定された期間内に作成できる、問題キーが同じインシデントの数を設定します。デフォルトは5です。

フラッド制御が有効になっていて、同じ問題キーのインシデントの数がこのカウントを超えると、インシデントが作成されなくなります。ただし、診断フレームワークは、WARNINGレベルのメッセージをログ・ファイルに書き込みます。

floodControlIncidentTimeoutPeriod

フラッド制御で制御されるまでに、floodControlIncidentCountで指定された数の、問題キーが同じインシデントを作成できる期間を設定します。デフォルトは60分です。

incidentCreationEnabled

インシデント作成を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

logDetectionEnabled

ログ・ファイルを使用したインシデントの検出を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

maxTotalIncidentSize

すべてのインシデントに割り当てられる最大合計サイズを設定します。この制限に達すると、すべてのインシデントで使用される領域がこのパラメータで指定される量より小さくなるまで、最も古いインシデントから順にパージされます。

デフォルトは500MBです。インシデントの作成時にこの制限を超えた場合は、インシデントの作成が完了したときに、最も古いインシデントからパージされていきます。

reservedMemoryKB

OutOfMemoryErrorが検出されたときに解放される予約済メモリーの量。

診断フレームワークの起動時に、プライベートで使用されるメモリーが512 KB割り当てられます。診断フレームワークにより、サーバーにOutOfMemoryErrorが発生したことが検出されると、そのメモリーのブロックを解放して、インシデントの作成に進みます。

デフォルトは512KBです。

uncaughtExceptionDetectionEnabled

Javaベースの捕えられていない例外ハンドラを有効にします。これが有効のときに捕えられていない例外が検出されると、インシデントが作成されます。有効化する場合はtrue、無効化する場合はfalseと指定します。

デフォルトはtrueです。

useExternalCommands

スレッド・ダンプの実行に外部JVMコマンドを使用するかどうかを示します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

次の例は、Fusion Middleware ControlシステムMBeanブラウザを使用してこれらの設定を構成する方法を示しています。

  1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。

    「システムMBeanブラウザ」ページが表示されます。

  2. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

  3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

  4. 「アプリケーション定義のMBean」ペインで「MBean情報の表示」を開くと、サーバー名が表示されます。

    次に、「システムMBeanブラウザ」ページを示します。

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

  5. 表13-1に一覧表示されている属性の値を変更するには、「値」フィールドで値を入力または選択します。

  6. 「適用」をクリックします。

13.3.2 カスタム診断ルールの構成

ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム診断ルールを構成できます。

カスタム診断ルールは、特定の形式の.xmlファイル(この項の後半の例を参照)を作成することにより作成します。ファイルは次のいずれかの場所に保存する必要があります。

  • ドメイン全体に適用されるルールの場合

    DOMAIN_HOME/config/fmwconfig/dfw

  • 特定のサーバーに適用されるルールの場合

    DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw

ファイル名には次の形式を使用する必要があります。

name.xml
appname#name.xml

この形式では、appnameは、ルールが適用されるアプリケーションの名前です。appnameは、デプロイされたアプリケーションの正確な名前である必要があります。nameは、指定するルールの名前です。appnameを指定しないと、ルールはサーバー全体に適用されます。たとえば、次のルールはmyAppアプリケーションに適用されます。

myApp#custom_rule.xml

カスタム診断ルール・ファイルには、ルールを定義するために次のような要素を含めることができます。

  • ログ検出条件(オプション)

    ルールが登録されているサーバーまたは指定されたアプリケーションに適用される診断ログ内でチェックする条件のセットを、logDetectionConditions要素内に定義できます。条件に一致するログ・メッセージが検出されると、インシデントが作成され、問題の特定に役立つ診断情報が取得されます。デフォルトでは、すべてのINCIDENT_ERRORメッセージが検出され、それらに対してインシデントが作成されます。また、特定のコンポーネントに対して、特定のメッセージを検出するルールを構成することもできます。

    次の例は、4つのログ検出条件を定義するカスタム診断ルール・ファイルの一部を示しています。1つ以上の条件がtrueの場合、インシデントが作成されます。

    <?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
  <logDetectionConditions>
      <condition messageSeverity="INCIDENT_ERROR"/> 
      <condition messageSeverity="ERROR" component="jrfServer_admin"/> 
      <condition messageSeverity="ERROR" module="test.servletA"/> 
      <condition messageId="FMW-40300"/> 
    </logDetectionConditions>

    使用できる条件の説明は、表13-2を参照してください。

  • 処理ルール

    インシデントの作成にサーバー・ルールまたはアプリケーション・ルールが関わっている場合に評価される処理ルールを定義できます。たとえば、インシデントの作成にMyAppアプリケーションが関わっている場合、MyAppアプリケーションに関連付けられたすべてのルールが評価されます。どの場合にも、アプリケーションにかかわらず、サーバー全体に対するルールは常に評価されます。

    処理ルールは次の2つの部分から構成されます。

    • デフォルト・アクション(オプション)。指定されている場合は、インシデントの作成中に常に実行されます。アクションとは、実行する診断ダンプとオプションの引数のリストです。

      次に、デフォルト・アクション・セットの例を示します。

      <defaultActions>
      <dumpAction name="odl.logs">
        <argument name="timestamp" value="INCIDENT_TIME" valueType="fact"/>
      </dumpAction>
      <dumpAction name="dms.metrics"/>
    </defaultActions>

      使用できるオプションの引数の説明は、表13-3を参照してください。

    • 条件ベースのアクション。これは、条件がtrueと評価された場合にのみ実行されます。各<rule>要素は、名前属性および子<ruleCondition>要素と子<ruleActions>要素から構成されます。<ruleActions>要素には、1つ以上のdumpAction要素が含まれます。<ruleCondition>要素属性のリストは、表13-4を参照してください。

      1つの<rule>要素内に複数の<condition>要素が指定されている場合、すべての条件がtrueに評価される場合にのみdumpActionが実行されます。

      次に、条件ベースのアクション・ルールの例を示します。MESSAGE_IDがDFW-99997の場合、条件がtrueと評価され、jvm.classhistogramダンプが実行されます。

      <processingRules>
      <rule name="OOME">
        <ruleCondition>
          <condition name="MESSAGE_ID" value="DFW-99997"/>
        </ruleCondition>
        <ruleActions>
          <dumpAction name="jvm.classhistogram"/>
        </ruleActions>
      </rule>
    </processingRules>

表13-2に、ログ検出条件を作成するために使用できる属性を示します。

表13-2 LogDetectionConditions要素の条件

条件 説明

messageSeverity

メッセージが記録されたログ・レベル。(これはODLログ・ファイルでのMESSAGE_LEVELフィールドです。)例: INCIDENT_ERROR、ERROR

messageId

メッセージのID。(これはODLログ・ファイルでのMESSAGE_IDフィールドです。)例: DFW-99997

component

コンポーネント名。(これはODLログ・ファイルでのCOMPONENT_IDフィールドです。)例: oracle.mds

module

メッセージを生成したモジュールの名前。(これはODLログ・ファイルでのMODULE_IDフィールドです。)

ODLログ・ファイル・フィールドの説明は、表12-1を参照してください。

表13-3に、<defaultActions>要素に対して使用できるオプションの引数を示します。

表13-3 defaultActions要素に対するオプションの引数

引数 説明

name

引数の名前。

value

引数の値。

type

引数のタイプ。有効な値は、次のとおりです。

  • literal: このタイプを指定した場合は、引数のリテラル値が使用されます。これはデフォルトです。

  • fact: このタイプを指定した場合は、値はINCIDENT_TIMEまたはECIDである必要があります。

  • context: このタイプを指定した場合は、値はDMS実行コンテキストでの値の名前である必要があります。DMS実行コンテキストの詳細は、『パフォーマンスのチューニング』のDMS実行コンテキストに関する説明を参照してください。

表13-4に、<ruleCondition>要素属性を示します。

表13-4 ruleCondition要素の属性

要素 説明

name

属性の名前を指定します。有効な値はvalueTypeに依存します。

  • valueTypeがfactの場合は、有効な値はCOMPONENT_ID、MODULE_IDまたはMESSAGE_IDです。

  • valueTypeがcontextの場合は、値はDMS実行コンテキストでの値の名前である必要があります。DMS実行コンテキストの詳細は、『パフォーマンスのチューニング』のDMS実行コンテキストに関する説明を参照してください。

operator

演算子。有効な値は、EQ、EQNoCase、NE、Contains、StartsWith、EndsWith、LT、GT、LE、GEです。デフォルトはEQです。

値では大/小文字が区別されます。

value

比較するリテラル値。

datatype

データ型。有効な値はStringまたはIntegerです。デフォルトはStringです。

値では大/小文字が区別されます。

valueType

引数のタイプ。

  • fact

  • context

カスタム診断ルールを作成してロードする手順は次のとおりです。

  1. カスタム・ルールを含むファイルを作成します。

    サンプル・カスタム・ルール・ファイルを次に示します。

    <?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
 
     
    <logDetectionConditions>
      <condition messageSeverity="INCIDENT_ERROR"/> 
           // detect all message logged at level INCIDENT_ERROR
      <condition messageSeverity="ERROR" component="jrfServer_admin"/> 
          // detect all "jrfServer_admin" component messages logged at level ERROR
      <condition messageSeverity="ERROR" module="test.servletA"/> 
          // detect all "test.servlet" module messages logged at level ERROR
      <condition messageId="FMW-40300"/> 
          // detect message "FMW-40300"
    </logDetectionConditions>
    
    <defaultActions>
      <dumpAction name="odl.logs">
        <argument name="timestamp" value="INCIDENT_TIME" valueType="fact"/>
      </dumpAction>
      <dumpAction name="dms.metrics"/>
    </defaultActions>
 
    <processingRules>
      <rule name="OOME">
        <ruleCondition>
          <condition name="MESSAGE_ID" value="DFW-99997"/>
        </ruleCondition>
        <ruleActions>
          <dumpAction name="jvm.classhistogram"/>
        </ruleActions>
      </rule>
    </processingRules>
 
</diagnosticRules>

  2. 拡張子.xmlを含む名前を付けて、ファイルを保存します。ルールがアプリケーションに適用される場合は、ファイル名の前にapp_name#を付けます。ファイルを次のいずれかの場所に保存します。

    DOMAIN_HOME/config/fmwconfig/dfw
DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw

  3. WLSTコマンドreloadCustomRulesを使用して、ルールをロードします。次の例は、myAppアプリケーションに適用されるcustomrules.xmlルールをロードします。

    reloadCustomRules(name='myApp#customrules.xml')

    ドメイン内のすべてのルール、または特定のサーバーに関連するすべてのルールを再ロードできます。次の例は、wls_server1サーバーに対するすべてのルールを再ロードします。

    reloadCustomRules(server='wls_server1')

    reloadCustomRulesコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のreloadCustomRulesに関する説明を参照してください。

13.3.3 問題抑制の構成

一定の状況では、特定の問題キーに基づいてインシデントの作成を抑制する必要がある場合があります。たとえば、開発環境で、サーブレットを開発しているときに、コードを調整すると捕えられていない例外が多数生成されることがあります。これにより、不要なインシデントが作成されます。

診断フレームワークによって、フィルタ条件と一致する問題でインシデントが作成されないように問題抑制フィルタを構成できます。

問題抑制フィルタを構成する場合は、マッチするパターンを表す正規表現を使用します。java.util.regexクラスを使用して、正規表現とのマッチが行われます。次に例を示します。

  • 次の正規表現では、インシデントがMDS-5000で始まる問題キーとマッチされます。

    MDS-5000.*

  • 次の正規表現は、テキストOutOfMemoryを含む問題とマッチします。正規表現では大/小文字が区別されるため、テキストoutofmemoryを含む問題とはマッチしません。

    .*OutOfMemory.*

DiagnosticConfig MBeanを使用すると、フィルタを追加および削除したり、フィルタ・リストまたは1つのフィルタの詳細を取得できます。

表13-5は、構成中の問題抑制フィルタの操作および属性とそれぞれの説明を示しています。

表13-5 問題抑制フィルタのDiagnosticConfig MBeanの操作および属性

操作および属性 説明

操作:

addProblemKeyFilter(filter_pattern)

新しい問題抑制フィルタを追加します。マッチするパターンを表す正規表現に渡します。次に例を示します。

addProblemKeyFilter(".*OutOfMemory.*)

属性:

getProblemKeyFilters()

構成済の問題抑制フィルタのリストを返します。次に例を示します。

getProblemKeyFilters()

操作:

getProblemKeyFilter(filterID)

特定IDに関連するフィルタ・パターンを返します。次に例を示します。

getProblemKeyFilter(id)

IDを検索するには、getProblemKeyFilters()操作を使用します。

操作:

removeProblemKeyFilter(filterID)

任意のフィルタIDに関連するフィルタ・パターンを削除します。次に例を示します。

removeProblemKeyFilter(id)

問題抑制フィルタを構成する手順は次のとおりです。

  1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。

    「システムMBeanブラウザ」ページが表示されます。

  2. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

  3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

  4. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。

  5. addProblemKeyFilterをクリックします。操作: addProblemKeyFilterページが、次の図のように表示されます。

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

  6. 「値」に、マッチするパターンを表す正規表現を入力します。たとえば、開発環境では、java.lang.IllegalStateExceptionというJava例外が報告されたときにインシデントが作成されないようにフィルタを追加する必要がある場合があります。この場合、次のように入力します。

    ".*[java.lang.IllegalStateException].*"

  7. 「起動」をクリックします。

  8. 「戻る」をクリックし、「アプリケーション定義のMBean」ページに戻ります。

removeProblemKeyFilter操作を使用すると、フィルタを削除できます。

getProblemKeyFilter操作にフィルタIDを渡すと、特定のフィルタを取得できます。

また、次のようにgetProblemKeyFilters属性を使用すると、フィルタのリストを取得できます。

  1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。

    「システムMBeanブラウザ」ページが表示されます。

  2. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

  3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

  4. 「アプリケーション定義のMBean」ペインで、「属性」タブを選択します。

  5. ProblemKeyFiltersをクリックします。

    問題抑制フィルタのリストが表示されます。

13.3.4 診断フレームワーク用のWLDF監視および通知の構成

Oracle Fusion Middlewareでは、監視および通知の一連のルールが含まれているWLDF診断モジュールを構成します。そのルールは、特定の一連のクリティカル・エラーを検出し、それらのエラーが発生するたびにインシデントを作成するためのものです。このモジュールはモジュールFMWDFWと呼ばれ、次の一連の監視条件が含まれます。

名前 説明

Deadlock

複数のJavaスレッドで、Java Monitorオブジェクトを使用する際に循環ロック・チェーンがあります。

StuckThread

Oracle WebLogic ServerのExecuteThread。Oracle WebLogic ServerのStuckThreadMaxTimeパラメータで指定された時間より多くの期間、ブロックされているかビジー状態です。

UncheckedException

このカテゴリには、未チェックの例外、実行時の例外、およびNullPointerException、StackOverflowError、OutOfMemoryErrorなどのOracle WebLogic ServerのExecuteThreadで捕捉されたエラーがすべて含まれます。

診断モジュールには、oracle.dfw.wldfnotificationタイプの、構成されたWLDF JMX通知FMWDFW-notificationも含まれます。このWLDF JMX通知は、インシデントを作成するために、独自のWLDF監視条件で再利用することもできます。

  1. 第2.3.1項の説明に従って、管理コンソールを表示します。

  2. 左ペインで、「診断」を開き、「診断モジュール」を選択します。

    「診断モジュールのサマリー」ページが表示されます。

  3. 「Module-FMWDFW」をクリックします。

    「Module-FMWDFWの設定」ページが表示されます。

  4. 次の図に示す「監視と通知」タブを選択します。

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

  5. 「監視」タブを選択し、「新規」をクリックします。

    「監視の作成」ページが表示されます。

  6. 「ウォッチ名」に、監視の名前を入力します。

    任意の名前を入力できます。または、次の形式を使用し、診断フレームワークでカスタム・メッセージIDが使用されるようにすることができます。

    message-id#[application_name]#any_text

    メッセージIDは、1から6文字の接頭辞と1から6桁の数字で構成されます。アプリケーション名はオプションです。次に例を示します。

    WLS-40500#My_Watch_Name

    次の例では、アプリケーション名testappを使用します。

    WLS-40501#testapp#My_Watch_Name

    診断フレームワークでは、インシデント問題キーの構成時にメッセージIDをインシデント・メッセージIDとして使用します。

  7. 「監視のタイプ」で、タイプを選択します(「サーバー・ログ」など)。

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

  9. 「現在の監視ルール」で式を作成します。たとえば、式(SEVERITY = 'Error') AND (MSGID = 'BEA-000337')を作成する手順は、次のとおりです。

    1. 「式の追加」をクリックします。

    2. 「メッセージ属性」で、「重大度」を選択します。

    3. 「演算子」で、=を選択します。

    4. 「値」に、ERRORと入力します。

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

    6. 「式の追加」をクリックします。

    7. 「メッセージ属性」で、MSGIDを選択します。

    8. 「演算子」で、=を選択します。

    9. 「値」に、BEA-000337と入力します。

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

    11. 「監視の作成」ページで、選択されている演算子がANDであることを確認します。

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

  11. アラーム・タイプを選択して、「次へ」をクリックします。

  12. 「通知」で、FMWDFW-notificationを選択し、これを「選択済み」ボックスに移動します。

  13. 「終了」をクリックします。

監視の作成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監視ルールの式の作成に関する説明を参照してください。

13.4 問題の調査、報告および解決

この項では、WLSTコマンドおよびADRCIコマンドとRemote Diagnostic Agent (RDA)を使用して、問題(クリティカル・エラー)を調査および報告し、場合によっては問題を解決する方法について説明します。初めに、実行する必要がある典型的な一連の作業をまとめたロードマップを示します。次の項目について説明します。

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

一般的に、問題の調査、報告および解決は、クリティカル・エラーの発生から始まります。この項では、そのワークフローの概要について説明します。

図13-4は、問題を調査、報告および解決するためのタスクを示しています。

図13-4 問題調査のフロー

図13-4の説明が続きます
「図13-4 問題調査のフロー」の説明

次に、図13-4に示しているワークフローについて説明します。

  1. システム、コンポーネントまたはアプリケーションが想定どおりに機能していないことがわかります。たとえば、パフォーマンスに問題があることがわかったり、アクセスしようとしているアプリケーションでエラーが報告されているとユーザーから報告があった場合などです。

  2. 観察された症状に関連する可能性のある問題およびインシデントが作成されているかどうかを確認します。

    1. 一連の問題を確認するには、 第13.4.2.1項の説明に従って、WLSTのlistProblemsコマンドを使用します。

    2. 問題が作成されている場合、第13.4.2.2項の説明に従って、listIncidentsコマンドを使用して、特定の問題に関連するインシデントを一覧表示します。

  3. インシデントが作成されていない場合は、ステップ4に進みます。インシデントが作成されている場合は、ステップ5に進みます。

  4. 問題に関連しているインシデントを確認できない場合は、createIncidentコマンドを使用してインシデントを手動で作成し、問題の診断情報を取得することができます。

    ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要がある場合は、インシデントを作成することを検討してください。ログ・ファイルとその中のメッセージを表示できます。直面している問題に関連すると思われるメッセージがあったら、createIncidentコマンドでそのメッセージIDを使用できます。

    インシデントの作成の詳細は、第13.4.6.1項を参照してください。

  5. 特定のインシデントの詳細を確認するには、第13.4.2.2項の説明に従って、showIncidentコマンドを使用します。このコマンドを実行すると、関連するメッセージID、インシデントの時刻、ECID、インシデントで生成されたファイルなど、インシデントに関する情報が一覧表示されます。

  6. 第13.4.2.2項の説明に従って、getIncidentFileコマンドを使用して、インシデントのファイルの内容を表示します。その内容には、問題の原因を導き出し、その解決に役立つ情報が含まれる可能性があります。

  7. インシデントのファイルの内容が問題の解決に役立たなかった場合、追加のダンプを実行して詳細な診断情報を確認できます。たとえば、パフォーマンスの問題に直面した場合は、dms.metricsダンプを実行します。使用可能なダンプおよびその実行方法の詳細は、第13.4.4項を参照してください。

  8. それでも問題が解決できない場合は、RDAレポートとともにインシデントをパッケージ化して、Oracleサポートにお送りください。インシデントのパッケージ化およびRDAレポートの生成の詳細は、第13.4.6.3項および第13.4.7項を参照してください。

13.4.2 問題およびインシデントの確認

次の各項で説明するように、WLSTコマンドライン・ユーティリティを使用して、一連の問題、インシデントのリスト、および特定のインシデントの詳細を確認できます。

13.4.2.1 問題の確認

一連の問題を確認するには、次の形式でWLSTのlistProblemsコマンドを実行します。

listProblems([adrHome] [,server])

listProblemsコマンドを実行すると、ADRホームの問題が一覧表示されます。それぞれの問題では、IDが一意です。

listProblems()
Problem Id      Problem Key
        1       BEA-101020 [HTTP]

13.4.2.2 インシデントの確認

次の形式でWLSTのlistIncidentsコマンドを実行して、すべての使用可能なインシデントまたは特定の問題に関連するインシデントをリストできます。

listIncidents([id], [ADRHome])

たとえば、すべてのインシデントのリストを表示するには、次のコマンドを使用します。

listIncidents()
Incident Id     Incident Time                   Problem Key
        2       Tue May 28 11:05:59 PDT 2013    MDS-50500 [MANUAL]
        1       Tue May 28 11:02:22 PDT 2013    MDS-50500 [MANUAL]

特定の問題に関連するインシデントを確認するには、次のコマンドを使用します。

listIncidents(id='1')
Incident Id     Incident Time                   Problem Key
        2       Tue May 28 11:05:59 PDT 2013    MDS-50500 [MANUAL]
        1       Tue May 28 11:02:22 PDT 2013    MDS-50500 [MANUAL]

特定のインシデントの詳細を確認するには、次の形式でWLSTのshowIncidentコマンドを使用します。

showIncident(id, [adrHome] [,server])

たとえば、インシデント1の詳細を確認するには、次のコマンドを使用します。

showIncident(id='1')
Incident Id: 1
Problem Id: 1
Problem Key: MDS-50500 [MANUAL]
Incident Time:Tue May 28 11:02:22 PDT 2013
Error Message Id: MDS-50500
Execution Context:
Flood Controlled: false
Dump Files :
   readme.txt
   jvm_threads10_i1.txt
   dms_metrics11_i1.txt
   dfw_samplingArchive13_i1.JVMThreadDump.txt
   dfw_samplingArchive13_i1.readme.txt
   odl_logs14_i1.txt

インシデントのファイルの内容を確認するには、次の形式でWLSTのgetIncidentFileコマンドを使用します。

getIncidentFile(id, name [,outputFile] [,adrHome] [,server])

たとえば、ファイルodl_logs4_i1.dmpの内容を確認するには、次のコマンドを使用します。

getIncidentFile(id='1', name='odl_logs14_i1.txt',outputFile='/tmp/odl_logs4_i1_dmp.output')

このコマンドは、出力をファイルodl_logs4_i1_dmp.outputに書き込みます。

13.4.2.3 インシデントの問合せ

listIncidentsコマンドでは特定の問題IDまたは特定のサーバーに関連するインシデントが表示されますが、リストをそれ以上絞り込むことはできません。WLSTのqueryIncidentsコマンドは、ドメイン内の1つ以上のサーバー、またはすべてのサーバーに渡って、特定の属性の値を問い合せることができます。たとえば、インシデント作成時やECIDで問い合されます。

式にはインシデント属性、演算子、および文字列が次の形式で含まれます。

attribute operator "string"

問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。

次のインシデント属性がサポートされています。

  • TIMESTAMP: インシデントの作成時刻。fromおよびto演算子を使用して、時間の範囲を指定できます。日付の形式はYYYY-MM-DD HH:MMです。

  • ECID: 実行コンテキストID

  • PROBLEM_KEY: 問題キー

  • MSG_FACILITY: エラー・メッセージ機能(ORAやOHSなど)。

  • MSG_NUMBER: メッセージID (600など)。

カスタム・インシデント属性もサポートされています。たとえば、TRACEID、APP、URI、AND DSIDがサポートされています。さらに、インシデントのreadme.txtファイルに示されるコンテキスト値がサポートされています。たとえば、DFW_APP_NAMEおよびDFW_USER_NAMEがサポートされています。

次の演算子がサポートされています。

  • equals

  • notEqual

  • startsWith

  • endsWith

  • contains

  • isNull

  • notNull

たとえば、ドメイン内のすべてのサーバーのすべてのインシデントに対して、ECID f19wAgN000001を問い合せることができます。

queryIncidents(query="ECID equals f19wAgN000001")

次の例では、2013年4月1日と2013年4月15日の間に発生したすべてのインシデントに対して、サーバーwls_server_1を問合せています。

 queryIncidents(query="TIMESTAMP from '2013-04-01 00:00'AND TIMESTAMP to '2013-04-15 00:00'", 
servers=["wls_server_1"])

このコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のqueryIncidentsに関する説明を参照してください。

13.4.3特定の問題キーの分析

診断フレームワークは、未処理の例外について明確に定義された一連の問題キーを提供します。これらの例外は、既存のWLDF監視のUncheckedException、または診断フレームワークのjava.lang.Thread.UncaughtExceptionHandlerという捕えられていない例外ハンドラのいずれかによって検出されます。これまで、診断フレームワークは、同一タイプの問題に様々な形式で問題キーを生成していました。表13-6は、これらの問題キーとそれらを使用して問題を調査する方法について説明しています。

表13-6 捕えられていない例外の問題キー

例外 問題キー 説明

java.lang.OutOfMemoryError

DFW-99997 [java.lang.OutOfMemoryError]

すべてのjava.lang.OUtOfMemoryErrorインシデントで使用されます。このタイプの各インシデントによって、jvm.classhistogramダンプが実行されます。ダンプは、ロードされたクラスのインスタンスと関連オブジェクトの数に関する統計を取得します。

このダンプの内容を確認し、JVMメモリーに何がロードされたかを理解するための効率的な手がかりとなる情報を見つけてください。また、dms.metricsダンプは、全体的なJVMメモリーに関する統計を記録します。

java.sql.SQLException

DFW-99996 [ora-code|java.sql.SQLException]][package.class.method][app-name]

サブクラスを含むjava.sql.SQLExceptionタイプのすべての例外に使用されます。診断フレームワークは、例外エラー・メッセージからOracleエラー・コードの抽出を試み、成功した場合はそのコードを問題キーに使用します。失敗した場合は、例外名を使用します。

例外に関連するテキストを確認し、データベースで実行されなかった操作などの詳細を取得します。さらに、SQLエラー・コードの詳細で追加情報を確認できます。

その他すべて

DFW-99998 [exception-name][package.class.name][app-name]

固有の方法では処理されないその他すべての例外タイプ(java.lang.NullPointerException、java.io.IOException、java.lang.StringIndexOutOfBoundsExceptionなど)で使用されます。

例外に関連付けられたテキストを確認し、障害の理由などの詳細を取得します。問題キーのソース行で障害の場所が示されている可能性があります。

13.4.4 診断ダンプの処理

問題が疑われる場合、組込みの診断ダンプを利用して、問題の診断に役立つ詳細な診断結果を報告できます。診断ダンプは、診断データを出力および記録する手段を提供します。診断データは、Oracle Fusion Middlewareのコンポーネント、アプリケーションおよびインフラストラクチャに関する問題を診断する際に有益な情報になります。これらのダンプからの出力は、Oracle Fusion Middlewareに関する問題を診断するために、顧客およびOracleサポートが使用することを想定しています。

診断ダンプは、次のように実行します。

  • 手動。次の各項で説明するように、WLSTコマンドを使用します。

    たとえば、Java EEアプリケーションがハングしてデッドロックが疑われる場合には、jvm.threadsダンプを使用して一連のスレッドを取得できます。

  • 自動。診断フレームワークがクリティカル・エラーを検出してインシデントを作成した場合、または管理者がインシデントを作成した場合。

13.4.4.1 診断ダンプの一覧表示

管理対象サーバーで使用可能な診断ダンプのリストを検索するには、次の形式でWLSTのlistDumpsコマンドを実行します。

listDumps([appName] [,server])

たとえば、wls_server1で使用可能なダンプを一覧表示するには、次のコマンドを使用します。

listDumps(server='wls_server1')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help(domainRuntime)
dfw.samplingArchive
dms.configuration
dms.ecidctx
dms.metrics
http.requests
jvm.classhistogram
jvm.threads
mds.MDSInstancesDump
odl.activeLogConfig
odl.logs
odl.quicktrace
opss.diagTest
opss.identityStoreUserRoleApiConfig
opss.securityContext
wls.image
 
Use the command describeDump(name=<dumpName>) for help on a specific dump.

表13-7は、Oracle Fusion Middlewareで定義される診断ダンプ操作とその説明を記載したものです。

表13-7 診断ダンプ操作

ダンプ操作 説明

dms.ecidctx

特定の実行コンテキストID (ECID)が指定されている場合は、それに関連付けられたデータ。そうでない場合は、使用可能なすべてのECIDに関連付けられたデータ。

dms.metrics

ダイナミック・モニタリング・サービス(DMS)メトリック。これらのメトリックについては、『パフォーマンスのチューニング』のダイナミック・モニタリング・サービス(DMS)に関する説明を参照してください。

http.requests

現在アクティブなHTTPリクエストのサマリー。

jvm.classhistogram

JVMクラス・ヒストグラム。その出力内容は、JVMベンダーによって異なります。

jvm.flightRecording

アクティブなJRockitフライト・レコーダの記録。

jvm.threads

JVMで実行中のスレッド、および完全なスレッド・ダンプを実行中のスレッドに関する統計サマリー。

mds.MDSInstancesDump

現在のJVMの各MDSインスタンスに関する情報。

odl.activeLogConfig

アクティブなJavaロギング構成。

odl.logs

ECIDまたは時間範囲で関連付けられる診断ログの内容。

odl.quicktrace

クイック・トレース・メッセージ

wls.image

WLDFサーバー・イメージ・ダンプ。

13.4.4.2 診断ダンプの説明の表示

WLSTのdescribeDumpコマンドを使用して、ダンプを実行する際の構文など、特定のダンプの説明を表示できます。目的のダンプの名前を指定します。たとえば、dms.metricsダンプの説明を表示するには、次のコマンドを使用します。

describeDump(name='dms.metrics')
Name: dms.metrics
Description: Dumps DMS (Dynamic Monitoring Service) metrics.
Run Mode: asynchronous
Mandatory Arguments: 
Optional Arguments:
    Name        Type     Description
    dump        STRING   How much to dump
    servers     STRING   Server names
    names       STRING   Name of DMS noun or metric
    format      STRING   Format of the dump output; raw or xml
    nountypes   STRING   Type of DMS noun

13.4.4.3 ダンプの実行

問題を検出して追加の診断データを収集する場合、指定したダンプに対してexecuteDumpコマンドを起動します。それぞれのダンプには、必須またはオプション、あるいはその両方の引数があります。特定のダンプの引数やその指定方法を確認するには、第13.4.4.2項の説明に従って、describeDumpコマンドを使用します。

次の例では、名前がdms.metricsでインシデントIDが1のダンプを実行し、それをファイルdumpout.txtに書き込んでいます。

executeDump(name='dms.metrics', outputFile='/tmp/dumpout.txt', id='1')
Dump file dms_metrics1_i1.dmp added to incident 1

このコマンドは、ダンプ出力をインシデント1に関する情報に書き込みます。インシデント1に対してshowIncidentコマンドを実行すると、出力結果にはdms_metrics1_i1.dmpが含まれます。

13.4.5 診断ダンプ・サンプリングの構成と使用

診断ダンプ・サンプリングは、指定された間隔で診断ダンプの出力を取得します。定期的な間隔でサンプルを取得する診断ダンプ・サンプリングにより、低速なWebリクエストなどの問題や、これらのリクエストのどこで処理が実行されているなどを特定できます。

この項の内容は次のとおりです。

13.4.5.1 診断ダンプ・サンプリングの理解

すべての診断ダンプ・サンプリングは、指定した間隔で、バックグラウンドで実行されます。デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプがサンプリング用に構成されています。ただし、インシデントが生成されるまでこれらはアクティブではありません。インシデントが生成されると、デフォルトで72時間、アクティブになります。

デフォルト・ダンプ・サンプリングに対する設定を変更し、また表13-7に示したダンプ操作およびアプリケーション固有のダンプに対して新しいサンプリング定義を作成できます。サンプリング間隔やサーバーなどについて異なる設定を指定して、同じ診断ダンプに対して複数のサンプリング定義を構成できます。

各診断ダンプ・サンプリングに対して、診断フレームワークにより、指定された数のサンプルが保存されます。上限に達すると、最も古いサンプルからパージされます。サーバーの停止時にはすべてのサンプルがパージされます。

表13-8に、デフォルトで構成されているダンプ・サンプリングの設定を示します。

表13-8 デフォルトの診断ダンプ・サンプリング構成

ダンプ名 サンプリング間隔 保存される最大サンプル数

jvm.threads

60秒

10

jvm.classhistogram

30分

5

診断フレームワークにより、インシデントが作成されるたびに(エラー検出またはインシデントの手動作成により)、ダンプ・サンプルの取得がトリガーされます。また、ダンプ・サンプルの内容を取得することもできます(第13.4.5.4項を参照)。

ダンプ・サンプル・アーカイブは、テキストまたはzipファイルとして取得できます。

  • テキスト: デフォルトでは、診断ダンプ・サンプルはテキスト形式で1つのアーカイブ・ファイルに連結されます。アーカイブ・ファイル内では、各サンプルはASCIIヘッダーとフッターによりラップされます。ヘッダーには、サンプルを生成した診断ダンプのタイムスタンプと名前が含まれます。ヘッダーとフッターの両方に、アーカイブ内のサンプルの数と、その特定のサンプルの番号が含まれます。次に例を示します。

    $$$=== BEGIN OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$
Fri Sep 07 07:00:00 PDT 2013

<text of dump sampling> 
 
$$$=== END OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$

  • Zip: 連結ファイルのかわりにzipファイルを返すように、診断ダンプ・サンプリングを構成できます。zipファイルには、使用可能なすべてのダンプ・サンプル・ファイルが含まれます。この形式では、出力が連結に適していないバイナリ形式である診断ダンプや、テキスト形式で出力を生成するダンプがサポートされます。またこの形式では、サンプルを含むアーカイブのサイズも縮小できます。

    次の例は、zipファイルの内容を示しています。

    unzip -l jvm_dump.zip
Archive:  jvm_dump.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
   508780  08-21-13 07:25   dfw_samplingArchive1065570966467923683.JVMThreadDump.dmp
      840  08-21-13 07:25   dfw_samplingArchive7749640004639161119.readme.txt
 --------                   -------
   509620                   2 files

ダンプ・サンプルの取得時には、テキストまたはzipファイルに加え、診断フレームワークによりREADMEファイルが生成されます。READMEファイルには、アーカイブ内の各ダンプ・サンプルの行番号(テキスト形式の場合)または個々のファイル名(zip形式の場合)のリストが含まれます。また、各サンプルのタイムスタンプおよびアーカイブに対する索引も含まれます。

ダンプ・サンプル・ファイルには次の形式で名前が付けられます。

dfw_dumpArchivennn.Sampling_Name.{txt]|zip}

ここで、nnnは、診断フレームワークにより割り当てられる一意の番号です。

たとえば、次はJVMThreadDumpに対するダンプ・サンプル・ファイルの例です。

dfw_dumpArchive17394218037.JVMThreadDump.txt

READMEファイルには次の形式で名前が付けられます。

dfw_dumpArchivennn.readme.txt

ここで、nnnは、診断フレームワークにより割り当てられる一意の番号です。

すべてのサンプリングは、頻度に対応する、次の間隔で開始するようにスケジュールされます。たとえば、サンプリングが午後12:05:13に構成され、頻度が5秒の場合、サンプルは午後12:05:15に収集されます。これにより、同じ頻度の一連のサンプリングが同時に実行されるようになります。また、システム・クロックが同期化されていれば、異なるマシン上でもすべてのサンプルが同時に取得されます。


注意:

WLSTダンプ・サンプリング・コマンドを実行するには、管理サーバーに接続している必要があります。

13.4.5.2 ダンプ・サンプリングの構成

次の各項で説明しているように、追加のダンプ・サンプリングを作成し、既存のダンプ・サンプリングを更新し、ダンプ・サンプリングを削除し、ダンプ・サンプリングを有効化または無効化できます。

13.4.5.2.1 デフォルト・サンプルのアクティブ化

デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプは、インシデントが発生するまでアクティブではありません。インシデントが発生すると、デフォルトで72時間、アクティブになります。

MBean DumpSamplingIdleWhenHealthyをfalseに設定することにより、インシデントが発生しなくてもダンプがアクティブになるように、動作を変更できます。

システムの健全性を判定するために費やす時間を変更するには、DumpSamplingMinimumHealthyPeriod MBeanの値を変更します。

診断フレームワークMBeanの値の変更の詳細は、第13.3.1項を参照してください。

13.4.5.2.2 ダンプ・サンプリングの作成

表13-7に示したダンプおよびアプリケーション固有のダンプに対して、ダンプ・サンプリングを作成できます。ダンプ・サンプリングを作成するには、WLSTコマンドaddDumpSampleを使用します。addDumpSampleコマンドでは、次の構文を使用します。

addDumpSample(sampleName="sample_name", diagnosticDumpName="dump_name",
 [appName="application_name",] samplingInterval=num_seconds,
 rotationCount=num_samples, [dumpedImplicitly={true|false},]
 [toAppend={true|false},] [args={"arg_name" : "value"},] 
 [server="server_name"])

たとえば、wls_server1サーバーに対して、http.requestsダンプに対するダンプ・サンプリングを作成し、サンプリング間隔を300秒、繰返し回数を10サンプルに設定するには、次のように指定します。

addDumpSample(sampleName="HTTPSampling", diagnosticDumpName="http.requests", samplingInterval=300, rotationCount=10, server="wls_server1")

HTTPSampling is added

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のaddDumpSampleに関する説明を参照してください。

13.4.5.2.3 ダンプ・サンプリング設定の変更

WLSTコマンドupdateDumpSampleを使用することにより、既存のダンプ・サンプリングの設定を変更できます。updateDumpSampleコマンドでは、次の構文を使用します。

updateDumpSample(sampleName="sample_name",  
[        appName="application_name",] samplingInterval=num_seconds, 
         rotationCount=num_samplings, [dumpedImplicitly={true|false},] 
[        toAppend={true|false},] [args={"arg_name" : "value"},] 
[        server="server_name"])

たとえば、サンプリング間隔を200に、繰返し回数を5に変更して、ダンプ・サンプリングHTTPSamplingを変更するには、次のように指定します。

updateDumpSample(sampleName="HTTPSampling", samplingInterval=200,
                   rotationCount=5, server="wls_server1")

HTTPSampling is updated

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のupdateDumpSampleに関する説明を参照してください。

13.4.5.2.4 ダンプ・サンプリングの削除

WLSTコマンドremoveDumpSampleを使用することにより、既存のダンプ・サンプリングを削除できます。removeDumpSampleコマンドでは、次の構文を使用します。

removeDumpSample(sampleName="sample_name", [server="server_name"])

たとえば、ダンプ・サンプリングHTTPSamplingを削除するには、次のように指定します。

removeDumpSample(sampleName="HTTPSampling", server="wls_server1")

Removed HTTPSampling

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のremoveDumpSampleに関する説明を参照してください。

13.4.5.2.5 すべてのダンプ・サンプリングの有効化または無効化

WLSTコマンドenableDumpSamplingを使用することにより、すべてのダンプ・サンプリングを有効化または無効化できます。このコマンドは、構成済のすべてのダンプ・サンプリングに影響します。enableDumpSamplingコマンドでは、次の構文を使用します。

enableDumpSampling(enable={true|false}, [server="server_name"])

serverパラメータは、管理サーバーに接続している場合にのみ有効です。serverパラメータを指定しないと、管理サーバーに対してダンプ・サンプリングが無効化されます。

たとえば、管理サーバーに対してダンプ・サンプリングを無効化するには、次のように指定します。

enableDumpSampling(enable=false)

Dump sampling disabled

ダンプ・サンプリングが有効化されているのかどうかを確認するには、WLSTコマンドisDumpSamplingEnabledを使用します。isDumpSamplingEnabledコマンドでは、次の構文を使用します。

isDumpSamplingEnabled([server="server_name"])

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のenableDumpSamplingおよびisDumpSamplingEnabledに関する説明を参照してください。

13.4.5.3 ダンプ・サンプリングのリスト

WLSTコマンドlistDumpSamplesを使用することにより、ダンプ・サンプリングをリストできます。すべてのダンプ・サンプリング、指定したダンプ・サンプリングまたは特定のサーバーに関連付けられているすべてのダンプ・サンプリングをリストできます。listDumpSamplesコマンドでは、次の構文を使用します。

listDumpSample([sampleName="sample_name",] [server="server_name"])

たとえば、wls_server1サーバーに関連付けられているすべてのダンプ・サンプリングをリストするには、次のように指定します。

listDumpSamples(server="wls_server1")
Name              : JVMThreadDump
Dump Name         : jvm.threads
Application Name  : 
Sampling Interval : 30
Rotation Count    : 20
Dump Implicitly   : true
Append Samples    : true
Dump Arguments    : context=true, timing=true, progressive=true, depth=20, threshold=30000
 
Name              : JavaClassHistogram
Dump Name         : jvm.classhistogram
Application Name  : 
Sampling Interval : 1800
Rotation Count    : 5
Dump Implicitly   : false
Append Samples    : true
Dump Arguments    :

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistDumpSampleに関する説明を参照してください。

13.4.5.4 ダンプ・サンプリング出力の取得

ダンプ・サンプルの出力を取得するには、次の各項で説明するように、WLSTコマンドexecuteDumpまたはgetSamplingArchivesを使用します。

13.4.5.4.1 executeDumpコマンドを使用したダンプ・サンプルの取得

WLSTコマンドexecuteDumpを使用し、dfw.samplingArchiveダンプを指定することにより、ダンプ・サンプルを取得できます。このコマンドは、すべてのデフォルト・サンプル・アーカイブ、および一時的な場所にあり、dumpImplicitly=trueパラメータが指定されているダンプ・サンプルを収集し、1つのファイルに連結します。このコマンドは、ダンプ・サンプルの詳細を含むREADMEファイルも返します。

executeDumpコマンドでは、次の構文を使用します。

executeDump(name="dfw.samplingArchive",outputFile="filename"

outputFileパラメータに対しては、テキスト・ファイルまたはzipファイルを指定できます。zipファイルを指定する場合は、引数zipOutput=trueを使用する必要があります。

dumpImplicitly=falseパラメータが構成されているダンプ・サンプリングについては、その内容を収集するには、オプションのdfw.samplingArchive引数sampleNameを指定する必要があります。次に例を示します。

executeDump(name='dfw.samplingArchive', args={'sampleName' : 'JavaClassHistogram'})

詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のexecuteDumpに関する説明を参照してください。

13.4.5.4.2 getSamplingArchivesコマンドを使用したダンプ・サンプルの取得

WLSTコマンドgetSamplingArchivesを使用することにより、ダンプ・サンプリングを取得できます。このコマンドはすべてのダンプ・サンプルを、個々のダンプ・サンプル・ファイルとREADMEファイルを含むzipファイルに収集します。この方法は、バイナリ形式のダンプを扱う場合に特に有用です。

getSamplingArchivesコマンドでは、次の構文を使用します。

getSamplingArchives([sampleName="sample_name"] [,outputFile="filename" [,server="server_name"])

たとえば、サンプリングJavaClassHistogramに対するダンプ・サンプルを取得するには、次のコマンドを使用します。

getSamplingArchives(sampleName="JavaClassHistogram", outputFile="/tmp/sampling.zip")

次の例は、zipファイルの内容を示しています。

unzip -l /tmp/sampling.zip
Archive:  /tmp/sampling.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
  6241768  04-27-13 11:19   dfw_samplingArchive8680976839106379444.JavaClassHistogram.dmp
      552  04-27-13 11:19   dfw_samplingArchive7861027727509995202.readme.txt
 --------                   -------
  6242320                   2 files

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のgetSamplingArchivesに関する説明を参照してください。

13.4.6 インシデントの管理

診断フレームワークでは、自動で作成されるか手動で作成されるかに関係なく、インシデントが格納されます。Oracle Fusion Middlewareには、インシデントのレポートの処理に役立ち、それらのインシデントをパッケージ化してOracleサポートに送信するツールが用意されています。各項目で説明する内容は次のとおりです。

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

システムで生成された問題(内部で生成されたクリティカル・エラー)は、自動診断リポジトリ(ADR)に自動的に追加されます。それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできます。また場合によっては、問題を解決することもできます。これらはすべて、第13.4項で説明されているワークフローに記載されています。

ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要があるものの、診断フレームワークでインシデントが自動的に作成されていない場合は、インシデントを手動で作成することを検討してください。

インシデントを手動で作成するには、WLSTコマンドのcreateIncidentを使用します。インシデントは、時間、メッセージID、影響領域またはECIDを基準に指定できます。ここで、インシデントの内容を調べたり、Oracleサポートに送信してさらなる分析を依頼することができます。

たとえば、メッセージIDに基づいてインシデントを手動で作成する手順は、次のとおりです。

  1. 第12.3.2項の説明に従って、ログ・ファイルを検索します。直面している問題に関連すると疑われるメッセージがあったら、インシデントを作成するときにそのメッセージIDを使用できます。

  2. 次のコマンドを使用してWLSTを起動し、管理対象サーバーに接続して、管理対象サーバー・インスタンスにナビゲートします。

    java weblogic.WLST
connect('username', 'password', 'localhost:7001')
cd('servers/server_name')

  3. 次の形式でcreateIncidentコマンドを使用して、インシデントを作成します。

    createIncident([adrHome] [,incidentTime] [,messageId] [,ecid] [,appName]
  [,description] [,server])

    たとえば、メッセージIDがMDS-50500のエラーを基準としてインシデントを作成するには、次のコマンドを使用してメッセージIDを指定し、ユーザーおよびOracleサポートがインシデントを追跡しやすいように、インシデントの説明を入力します。

    createIncident(messageId='MDS-50500', description='sample incident')
Incident Id: 1
Problem Id: 1
Problem Key: MDS-50500 [MANUAL]
Incident Time:Tue May 28 11:02:22 PDT 2013
Error Message Id: MDS-50500
Execution Context:null
Flood Controlled: false
Dump Files :
   jvm_threads10_i1.txt
   dms_metrics11_i1.txt
   dfw_samplingArchive13_i1.JVMThreadDump.txt
   dfw_samplingArchive13_i1.readme.txt
   odl_logs14_i1.txt

    サーバーを指定しないと、インシデントは接続されているサーバーから情報を収集します。サーバーを指定するには、次の例に示すようにserverオプションを使用します。

    createIncident(messageId='MDS-50500', description='sample incident', server='wls_server1')
)

    adrHomeオプションを指定しないと、インシデントは接続されているサーバーに作成されます。たとえば、管理サーバーに接続している場合、インシデントは管理サーバーのadrHomeに作成されます。

    診断フレームワークはコマンドを評価して、適切な診断ダンプを起動します。インシデントおよび診断ダンプはADRに書き込まれます。それぞれの診断ダンプは、その出力結果をインシデントに書き込みます。

    第13.4.2.2項で説明するように、インシデントに関する情報を表示できます。

    第13.4.4項で説明するように、ダンプに情報を表示できます。

13.4.6.2 集計インシデントの作成

複数のインシデントがあり、それを1つのインシデントにまとめる場合は、WLSTのcreateAggregatedIncidentコマンドを使用できます。たとえば、選択的なトレースを使用した場合、トレース・データが含まれている結果のインシデントは複数のサーバーで生成される可能性があります。createAggregatedIncidentコマンドによって、指定する基準を満たす集計インシデントを生成できます。元のインシデントはそのままです。つまり、集計インシデントには問合せられたインシデントの複数のインシデント・ファイルのコピーが含まれています。

集計インシデントは管理サーバーのホストで作成されますが、これはドメイン内の1つ以上のサーバーまたはすべてのサーバーのインシデントを含むことができます。

インシデント属性、演算子、文字列が次の形式で含まれる式を使用して、問合せを作成できます。

attribute operator "string"

問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。

サポートされている属性と演算子の詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のcreateAggregatedIncidentに関する説明を参照してください。

各集計インシデントには、問合せから戻された各インシデントのzipファイルと、使用された問合せの詳細な説明テキストおよび各インシデントの詳細が含まれます。

たとえば、wls_server1サーバーでODL_TRACE_IDが123456を含むすべてのインシデントの集計インシデントを作成するには、次のコマンドを実行します。

createAggregatedIncident(query="ORDL_TRACE_ID equals 123456", servers="wls_server1")
Incident 55 created, containing the following incidents:
Server wls_server1
Incident Id    Problem Key                                     Incident Time
15                 TRACE [123456] [MANUAL]          Mon Apr 15 11:22:12 EDT 2013

ドメイン内のすべてのサーバー上で、ODL_TRACE_IDが123456を含むすべてのインシデントの集計インシデントを作成するには、次のコマンドを実行します。

createAggregatedIncident(query="ORDL_TRACE_ID equals 123456")
Incident 55 created, containing the following incidents:
Server wls_server1, wls_server2
Incident Id    Problem Key                                     Incident Time
15                 TRACE [123456] [MANUAL]          Mon Apr 15 11:22:12 EDT 2013

13.4.6.3 インシデントのパッケージ化

インシデントをパッケージ化して、その情報を容易にOracleサポートに送信できるようにするには、ADRコマンド・インタプリタ(ADRCI)を使用します。ADRCIユーティリティを使用すると、コマンドライン環境で問題を調査および報告できます。ADRCIにより、インシデントおよび問題の情報をzipファイルにパッケージ化して、Oracleサポートに送信できます。

ADRCIコマンドライン・ユーティリティは次のディレクトリにあります。

(UNIX) ORACLE_HOME/wlserver/server/adr
(Windows) ORACLE_HOME\wlserver\server\adr

インシデントのパッケージ化は、次の3つのプロセスに分かれています。

  1. 論理パッケージを作成します。

    このパッケージは、ADRではメタデータとしてのみ存在するため、論理的なものと示されます。論理パッケージから物理パッケージを生成するまで、その中身はありません。論理パッケージにはパッケージ番号が割り当てられ、以降のコマンドではその番号でそのパッケージを参照します。

    論理パッケージは、空のパッケージとして、あるいはインシデント番号、問題番号、問題キーまたは時間間隔を基準としたパッケージとして作成することができます。空のパッケージとしてパッケージを作成した場合は、ステップ2で診断情報を追加できます。

    インシデントを基準にパッケージを作成すると、ダンプなど、そのインシデントの診断データが含まれることになります。問題番号または問題キーを基準にパッケージを作成すると、その問題番号または問題キーを参照するインシデントのパッケージ診断データが含まれることになります。時間間隔を基準にパッケージを作成すると、その時間間隔内に発生したインシデントの診断データが含まれることになります。

  2. 診断情報をパッケージに追加します。

    インシデント番号、問題番号、問題キーまたは時間間隔を基準として論理パッケージを作成した場合は、この手順は省略できます。追加のインシデントをパッケージに追加したり、ADR内の任意のファイルをパッケージに追加することができます。空のパッケージを作成した場合は、ADRCIコマンドを使用して、インシデントまたはファイルをパッケージに追加する必要があります。

  3. 物理パッケージを生成します。

    物理パッケージを生成するコマンドを発行すると、ADRCIでは必要な診断ファイルをすべて収集し、目的のディレクトリ内のzipファイルに追加します。完全なzipファイルまたは増分zipファイルを生成できます。増分ファイルには、同じ論理パッケージでzipファイルが前回作成されてから追加または変更された診断ファイルがすべて含まれます。増分ファイルは、完全ファイルを作成した後にのみ作成可能で、いくつでも作成できます。それぞれのzipファイルには、正しい順序で分析できるように、順序番号が割り当てられます。

    zipファイルは、次の形式に従って名前が付けられます。

    packageName_mode_sequence.zip

    この形式の各項目について説明します。

    • packageNameは、問題キーの一部にタイムスタンプが続きます。

    • modeは、COM(完全)またはINC(増分)です。

    • sequenceは整数です。

たとえば、インシデントをパッケージ化するには、次の手順を実行します。

  1. 次の例に示すように、ORACLE_HOMEおよびLD_LIBRARY_PATH環境変数を設定します。

    ORACLE_HOME=ORACLE_HOME/oracle_common
LD_LIBRARY_PATH=ORACLE_HOME/wlserver/server/adr

  2. ADRCIを起動します。次に例を示します。

    ORACLE_HOME/wlserver/server/adr/adrci

  3. SET BASEコマンドを使用してADRベースを指定し、SET HOMEPATHコマンドを使用してインシデントを含むADRホームを指定します。HOMEPATHのパスは、ADRベースを基準に指定します。

    SET BASE /scratch/oracle/config/domains/wls_domain/servers/wls_server1/adr
SET HOMEPATH diag/ofm/wls_domain/wls_server1

  4. 論理パッケージを生成します。

    IPS CREATE PACKAGE INCIDENT incident_number

    たとえば、次のコマンドを実行すると、インシデント1を基準にパッケージが作成されます。

    IPS CREATE PACKAGE INCIDENT 1
Created package 1 based on incident id 1, correlation level typical

    ADRCIにより、論理パッケージに番号が割り当てられます。

  5. オプションで、論理パッケージに診断情報を追加できます。次のタイプの情報を追加できます。

    • 特定のインシデントのすべての診断情報。たとえば、次のコマンドを使用して、パッケージ化したインシデントに関連すると思われる別のインシデントを追加できます。

      IPS ADD INCIDENT incident_number PACKAGE package_number

    • ADR内にある、名前が付けられたファイル。たとえば、インシデントがアプリケーションに関連する場合、そのアプリケーションに対する.earファイルを追加できます。また、ユーザーがOracleサポートに通知するメモを記したreadmeファイルを追加することもできます。たとえば、パッケージにファイルを追加するには、次のコマンドを使用します。

      IPS ADD FILE filespec PACKAGE package_number

  6. 次のコマンドを使用して、物理パッケージを生成します。

    IPS GENERATE PACKAGE package_number IN path

    たとえば、番号1のパッケージを生成するには、次のコマンドを使用します。

    IPS GENERATE PACKAGE 1 in /tmp 
Generated package 1 in file /tmp/BEA337Web_20100223132315_COM_1.zip, mode complete

    これにより、指定されたパスに完全な物理パッケージ(zipファイル)が生成されます。

    詳細は、『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」を参照してください。

13.4.6.4 インシデントのパージ

デフォルトでは、すべてのインシデントの合計サイズが500 MBを超えると、インシデントはパージされます。この値は、第13.3.1項で説明されているように、maxTotalIncidentSize MBeanパラメータを使用して変更できます。

ADRCIコマンドを使用して、インシデントを手動でパージできます。パージは、IDまたはIDの範囲、インシデントの経過時間、またはインシデントのタイプを基準にして行えます。たとえば、経過時間が60分を超えたインシデントをパージするには、次のコマンドを使用します。

purge -age 60

『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」を参照してください。

13.4.7 RDAレポートの生成

コマンドライン診断ツールのRemote Diagnostic Agent (RDA)を使用して、ご使用の環境の全体像を把握することができます。また、RDAでは、構成やセキュリティなど、様々な項目に関する推奨事項が提供されています。これは、ユーザーとOracleサポートの問題解決を支援します。

RDAは、エンジンにより実行される、Perlプログラミング言語で作成される一連のコマンドライン診断スクリプトです。RDAはOracle環境に関する詳細情報の収集に使用され、収集されたデータは次に問題診断の支援に使用されます。また、その出力は全体的なシステム構成を確認するのに役立ちます。

RDAは、できるだけ控えめであるように設計されており、システムを変更することはありません。必要に応じて、セキュリティ・フィルタが提供されます。

RDAは次の領域の問題のトラブルシューティングに役立つ情報を収集します。

  • インストールと構成

  • パフォーマンス

  • ORA-600エラー、ORA-7445エラー、ORA-3113エラーおよびORA-4031エラー

  • アップグレード、移行およびリンク

  • Oracle Database

  • Oracle Fusion Middleware

RDAを実行するには、次のコマンドを実行します。

(UNIX) ORACLE_HOME/oracle_common/rda.sh
(Windows) ORACLE_HOME\oracle_common\rda.cmd

次に、出力の一部を示します。

 ./rda.sh
-------------------------------------------------------------------------------
S000INI: Initializes the Data Collection
-------------------------------------------------------------------------------
RDA uses the output file prefix to identify all files belonging to the same
data collection. The prefix must start with a letter and must contain only
alphanumeric characters.
 
Enter the prefix to be used for all the generated files
Hit 'Return' to accept the default (RDA)
> 
 
Enter the directory used for all the files to be generated
Hit 'Return' to accept the default
(/scratch/oracle1/Oracle/Middleware/Oracle_Home/oracle_common/rda/output)
> 
 
Do you want to keep report packages from previous runs (Y/N)?
Hit 'Return' to accept the default (N)
> 
 
Enter the Oracle home to be used for data analysis
Hit 'Return' to accept the default
(/scratch/oracle1/Oracle/Middleware/Oracle_Home)

RDAの詳細は、次の場所にあるreadmeファイルを参照してください。

(UNIX) ORACLE_HOME/oracle_common/rda/README_Unix.txt
(Windows) ORACLE_HOME\oracle_common\rda\README_Windows.txt

13.5 ヘルス・テスト・フレームワークの管理および実行

Oracle Fusion Middlewareでは、ヘルス・テスト・フレームワークが提供されています。これには、Oracle Fusion Middlewareおよびそのアプリケーションが正しく動作しているかどうかを判断し、問題があれば特定して解決するために、Oracle Fusion Middlewareおよびそのアプリケーションの特定の部分を動作させる診断テストが含まれます。

この項の内容は次のとおりです。

13.5.1 ヘルス・テスト・フレームワークの理解

ヘルス・テスト・フレームワークでは、診断テストを実行し、結果を収集して、詳細な診断レポートを生成できます。診断テストは、Oracle Fusion Middlewareのインストールまたはパッチ適用時にインストールされます。

ヘルス・テスト・フレームワークを使用して、通常のシステム・ヘルスをチェックし、システムの問題をトラブルシューティングできます。ヘルス・テスト・フレームワークのコマンドライン・インタフェースを使用して診断テストを実行するように、Oracle Fusion Middleware環境を構成できます。

診断テストを特定のエラー・メッセージと関連付けることができます。Oracle Fusion Middlewareアプリケーションが特定のエラーを、インシデントの作成をトリガーするような方法で処理する場合、そのインシデントに対するエラー・メッセージに関連付けられている診断テストが自動的に実行されます。テスト結果はインシデントに関連付けられ、エラー・メッセージを受信したユーザーが誰であるかが記録されます。診断テストは、第13.5.2項で説明するように、ファイルベース・リポジトリに保存されます。

13.5.2 ヘルス・テスト・フレームワークのファイル・リポジトリの理解

ヘルス・テスト・フレームワークは、テストおよびテスト結果をファイルベースのリポジトリに保存します。リポジトリには次の2つのプライマリ・ストアがあります。

  • TestDef: テスト定義、テスト・メタデータ、テスト・パラメータに関連するデータ、言語データファイルおよび索引ファイルが含まれます。

  • TestRun: テスト・ランと実行、レポート・ファイルおよび索引ファイルに関連するデータが含まれます。

索引ファイルは、検索および問合せ速度を向上させるために使用されます。

リポジトリは、テストの登録または実行時に指定した場所にリポジトリが存在しない場合に作成されます。

リポジトリの場所は、構成プロパティ・ファイルdiagfsconfig.propertiesで指定できます。このファイルは次の場所にあります。

MW_HOME/diagbase/dtf_filestore

デフォルトでは、ファイル・ストアは次の場所にあります。

MW_HOME/diagbase/dtf_filestore/testdef
MW_HOME/diagbase/dtf_filestore/testrun

13.5.3 ヘルス・テスト・フレームワークのコマンドラインの使用方法

次の各項で説明するように、ヘルス・テスト・フレームワークには、管理コマンド用のdfwhealthtestadminctl.shと、実行コマンド用のdfwhealthtestctl.shという2つのコマンドライン・インタフェースがあります。

13.5.3.1 dfwhealthtestadminctl.shコマンドライン

ヘルス・テスト・フレームワークには、ヘルス・テストを管理するためのdfwhealthtestadminctl.shコマンドラインがあります。これを使用して、テストを登録し、索引を再構築できます。

dfwhealthtestadmin.ctlコマンドを実行する前に、次の環境変数を設定する必要があります。

  • ORACLE_HOME: Oracleホーム

  • JAVA_HOME: Javaホーム

  • dtf_fs_diagbase: リポジトリの場所

dfwhealthtestadminctl.shコマンドラインは次の場所にあります。

ORACLE_COMMON_HOME/common/bin

コマンドライン・インタフェースの構文は、次のとおりです。

/dfwhealthtestadminctl.sh command [options]

表13-9に、ヘルス・テスト・フレームワークの管理コマンドを示します。

表13-9 ヘルス・テスト・フレームワークのdfwhealthtestadminctl.shコマンド

コマンド 説明

help

コマンドライン・ヘルプを表示します。

register

1つ以上のヘルス・テスト・フレームワーク・テストをリポジトリに登録します。

index

既存のデータ・ファイルで索引を再構築します。

13.5.3.1.1 help

コマンドのヘルプを表示します。

構文は次のとおりです。

help command

次の表に、helpコマンドのパラメータを示します。

パラメータ 説明

command

コマンドの名前。

13.5.3.1.2 register

1つ以上のテストをリポジトリに登録します。

構文は次のとおりです。

register testfile=test_xml_files | dir=test_dirs
          [validateonly={Y|N]]
          testjar=jar_file_location

次の表に、registerコマンドのパラメータを示します。

パラメータ 説明

testfile

登録する1つ以上のXMLテスト・ファイル。ファイルへのパスを指定します。複数のファイルを指定する場合は、カンマ区切りリストを使用します。

dir

登録する1つ以上のディレクトリ。ディレクトリへのパスを指定します。複数のディレクトリを指定する場合は、カンマ区切りリストを使用します。このオプションは、同じディレクトリからの複数のテストを登録する場合に使用します。

validateonly

オプション。テストを検証するだけなのか、またはテストをリポジトリにアップロードするのかを指定するブール値。有効な値は、Y(テストの検証のみ)またはN(テストのアップロード)です。

testjar

テストjarファイルの場所。

13.5.3.1.3 index

リポジトリ内のデータ・ファイルを使用して、testdefまたはtestrunリポジトリに対する索引を再構築します。

構文は次のとおりです。

index [refresh={testdef|testrun}

次の表に、indexコマンドのパラメータを示します。

パラメータ 説明

refresh=testdef

testdefリポジトリの索引をリフレッシュします。

refresh=testrun

testrunリポジトリの索引をリフレッシュします。

13.5.3.2 dfwhealthtestctl.shコマンドライン

ヘルス・テスト・フレームワークには、ヘルス・テストを実行するためのdfwhealthtestctl.shコマンドラインがあります。このコマンドラインでは、テストの実行、ランとテストのリスト、テストの説明の表示、テストのステータスの取得、およびテストまたはテスト・ランのレポートの取得を行えます。

dfwhealthtestctl.shコマンドラインは次の場所にあります。

ORACLE_COMMON_HOME/common/bin

コマンドライン・インタフェースの構文は、次のとおりです。

/dfwhealthtestctl.sh command [options]

表13-10に、ヘルス・テスト・フレームワークのdfwhealthtestctl.shコマンドを示します。

表13-10 ヘルス・テスト・フレームワークのdfwhealthtestctl.shコマンド

コマンド 説明

desctest

指定されたテストの詳細な説明を表示します。

listrun

テスト・ランをリストします。

listtest

1つ以上のテストの説明をリストします。

report

テスト・ランのレポートを抽出します。

run

1つ以上のテストを実行します。

status

テスト・ランまたは実行のステータスを取得します。

13.5.3.2.1 desctest

指定されたテストの詳細な説明を表示します。

構文は次のとおりです。

desctest {testid=testid | testname=testname}]
          [showparam={Y|N}]

次の表に、desctestコマンドのパラメータを示します。

パラメータ 説明

testid

テストのID。IDを取得するには、listtestコマンドを使用します。このパラメータまたはtestnameパラメータのいずれかを指定する必要があります。

testname

テストの名前。このパラメータまたはtestidパラメータのいずれかを指定する必要があります。

showparam

オプション。テストのパラメータを取得するかどうかを指定するブール値。有効な値はYまたはNです。

13.5.3.2.2 help

コマンドのヘルプを表示します。

構文は次のとおりです。

help command

次の表に、helpコマンドのパラメータを示します。

パラメータ 説明

command

コマンドの名前。

13.5.3.2.3 listrun

テスト・ランに対するサマリー情報を取得します。ラン名、ラン・ステータス、開始時間またはテスト名に基づいて情報を取得できます。

構文は次のとおりです。

listrun { runname=runname | testname=testname | status=status | lasthours=hours }
         [showexec={Y|N]]

次の表に、listrunコマンドのパラメータを示します。

パラメータ 説明

runname

結果を取得するランの名前。runnameを取得するには、パラメータを指定せずにlistrunコマンドを実行します。

testname

結果を取得するテストの名前。

ステータス

結果を取得するランのステータス。有効な値は、running、warningおよびsuccessです。

lasthours

結果を取得する時間数。

showexec

オプション。テストの実行を取得するかどうかを指定するブール値。有効な値はYまたはNです。

13.5.3.2.4 listtest

1つ以上のテストをリストします。ワイルドカードを使用してテストの名前を指定できます。

構文は次のとおりです。

listtest [testname=testname]
          [productcode=productcode

次の表に、helpコマンドのパラメータを示します。

パラメータ 説明

testname

1つ以上のテストの名前のカンマ区切りリスト。ワイルドカードを使用してテストの名前に一致するパターンを指定できます。

productcode

製品の名前。ワイルドカードを使用して製品の名前に一致するパターンを指定できます。

13.5.3.2.5 report

特定のテスト・ランまたは実行に対するテスト・レポートを抽出します。

構文は次のとおりです。

report { runname=runname | runid=run_id | execid=execution_id }
          [destdir=destination_directory}
          [format=HTML | XML]
          [translate={Y | N}

次の表に、reportコマンドのパラメータを示します。

パラメータ 説明

runname

ランの名前。名前を取得するには、listrunコマンドを使用します。このパラメータ、runidまたはexecidのいずれかを指定する必要があります。

runid

ランのID。IDを取得するには、listrunコマンドを使用します。このパラメータ、runnameまたはexecidのいずれかを指定する必要があります。

execid

ランの実行ID。IDを取得するには、listrunコマンドを使用します。このパラメータ、runnameまたはrunidのいずれかを指定する必要があります。

destdir

オプション。レポート・ファイルが書き込まれる宛先ディレクトリ。指定しないと、レポート・ファイルはjava.io.tmpdir/user.name/diagfwkディレクトリに抽出されます。ここで、java.io.tmpdirとuser.nameはJavaシステム・プロパティです。

format

生成されるレポートの形式。有効な値はHTMLおよびXMLです。

translate

レポートを翻訳するかどうかを指定するブール値。有効な値はYまたはNです。

13.5.3.2.6 run

指定されたテストを実行します。

run {test=testnames | productcode=codes }
     [runname=name
     [runoption=asynch]
     [input:param1=value1 param2=value2 ...
     [inputfile=filename] 
     [contextfile=context_file] 
     [moninterval=monitoring_interval] 
     [nthreads=number_of_threads] 
     [reportshowparam=show_param]

次の表に、runコマンドのパラメータを示します。

パラメータ 説明

test

1つ以上のテストの名前のカンマ区切りリスト。

単一のテスト名を指定する場合は、inputパラメータを使用して1つ以上の入力パラメータ名および値も指定できます。

このパラメータまたはproductcodeパラメータのいずれかを指定する必要があります。

productcode

実行するテストを含む1つ以上の製品に対するコード。複数の製品コードを指定するには、カンマ区切りリストを使用します。

runname

オプション。現在のランの名前。指定しないと、コマンドによりデフォルトのラン名が生成されます。

moninterval

ランのステータスがテスト・リポジトリにアップロードされる間隔(秒単位)。デフォルト値は30秒です。

nthreads

このラン内のテストを実行するために生成するパラレル・スレッドの数。デフォルト値は5です。このパラメータに対して値1を指定すると、テストはシリアルに実行されます。

runoption

オプション。テストを実行するためのオプション。有効な値はasynchであり、テストをバックグラウンドで非同期に実行します。

input

オプション。このパラメータを使用する場合は、1つ以上のパラメータ名/値ペアを指定します。次に例を示します。

domainhome=/scratch/oracle/domains/basedomain

このパラメータは、1つのテストだけを実行する場合にのみ使用できます。

inputfile

入力パラメータを含むファイルへのパス。各入力名/値ペアを、ファイル内の別々の行に指定します。各行の形式は次のとおりです。

input_param_name:input_param_value

contextfile

実行時に使用するユーザー・システム・プロパティを含むファイルへのパス。

reportshowparam

入力および出力パラメータの表示を設定します。デフォルトでは、すべてのパラメータは実行時には表示されません。パラメータを表示することを指定するには、inputまたはoutputを指定するか、両方をカンマで区切って指定します。次に例を示します。

reportshowparam=input,output

13.5.3.2.7 status

ラン名、ランIDまたは実行IDを指定して、テスト・ランのステータスを取得します。

構文は次のとおりです。

status { runname=runname | runid=run_id | execid=execution_id }
      [printtree={Y|N}

次の表に、statusコマンドのパラメータを示します。

パラメータ 説明

runname

ランの名前。ラン名を取得するには、listrunコマンドを使用します。

runid

ランのID。IDを取得するには、listrunコマンドを使用します。

execid

ランの実行ID。IDを取得するには、listrunコマンドを使用します。

printtree

ネストされているすべての条件のステータスを出力するかどうかを指定します。有効な値はYまたはNです。

13.5.4 ヘルス・テスト・フレームワークの管理

次の各項で説明するように、テストを登録し、索引を再構築できます。

13.5.4.1 リポジトリの作成およびヘルス・テスト・フレームワーク・テストの登録

リポジトリを作成するには、dfwhealthtestadminctl.sh registerコマンドを使用してテストを登録します。コマンドによりリポジトリが作成され、1つ以上のテストがリポジトリに登録されます。

リポジトリを作成してテストを登録する手順は次のとおりです。

  1. リポジトリの場所を指定するようにdtf_fs_diagbase環境変数を設定します。次に例を示します。

    setenv  dtf_fs_diagbase /scratch/Oracle/Middleware/diag

  2. リポジトリを作成し、1つのテストをリポジトリに登録する次のコマンドを実行します。

    dfwhealthtestadminctl.sh register testfile=/scratch/tests/sampleTest.xml 
                                     testjar=/scratch/tests/testjar

testfileまたはdirパラメータを使用することにより、一度に複数のテストを登録することもできます。

  • testfileパラメータを使用して複数のテストを登録するには、カンマ区切りリストまたはワイルドカードを使用できます。

    次の例は、カンマ区切りリストを使用して、2つのテストを登録します。

    dfwhealthtestadminctl.sh register testfile=/scratch/tests/sampleTest.xml,  
                                   /scratch/moretests/sampleTest.xml
                                     testjar=/scratch/tests/testjar

    次の例は、ワイルドカードを使用して、複数のテストを登録します。

    dfwhealthtestadminctl.sh register testfile=/scratch/tests/%Test.xml,  
                                     testjar=/scratch/tests/testjar

  • dirパラメータを使用して複数のテストを登録するには、カンマ区切りリストで1つ以上のディレクトリを指定します。

    次の例は、指定されたディレクトリ内のすべてのテストを登録します。

    dfwhealthtestadminctl.sh register dir=/scratch/dtf_tests

13.5.4.2 ヘルス・テスト・フレームワークの索引の再構築

索引により、ヘルス・テスト・フレームワーク・リポジトリでの検索および問合せの速度が向上します。テスト定義に関連する索引は、testdefファイル・ストアに格納されています。テスト・ランおよび実行に関連する索引は、testrunファイル・ストアに格納されています。

状況によっては、索引のリフレッシュが必要になることがあります。この場合、testdefまたはtestrunファイル・ストアを指定して、dfwhealthtestadminctl.sh indexコマンドを実行します。次の例は、testdefファイル・ストアをリフレッシュします。

dfwhealthtestadminctl.sh index refresh=testdef

13.5.5 ヘルス・テスト・フレームワークの診断テストの実行

ヘルス・テスト・フレームワークの診断テストは、次の場所にあるdfwhealthtestctl.shコマンドライン・インタフェースを使用して実行します。

ORACLE_COMMON_HOME/common/bin

テストを実行するには、第13.5.3.2.6項で説明している形式で、runコマンドを使用します。たとえば、SampleTestテストを実行するには、次のコマンドを使用します。

./dfwhealthtestctl.sh command
               [testfile=SampleTest.xml]

一度に1つまたは複数のテストを実行できます。

  • カンマ区切りリストでテスト名を指定して1つ以上のテストを実行する例

    ./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest2
Processing "run" command ...
 
Executing run ID "1340125981427" with name "TestRun_1340125981427" ...
sampleTest2 sleep for a while....
sampleTest2 done
 
Run ID "1340125981427" with name "TestRun_1340125981427" started at 06/21/2013
 10:13:01 AM and completed at 06/21/2013 10:13:04 AM. No diagnostic issues were detected.

  • テスト名にワイルドカードを使用して1つ以上のテストを実行する例

    ./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest*

  • 特定の製品に関連付けられているすべてのテストを実行する例

    ./dfwhealthtestctl.sh run productcode=idm

1つのテストのみを実行する場合は、コマンドラインまたは入力ファイルのいずれかで入力オプションを指定できます。

  • コマンドラインで入力オプションを指定するには、input:パラメータを使用します。

    ./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest,oracle.dfw.healthtest.test.sample.SampleTest2
                           input:userid=11 input:roleid=22

  • 入力ファイルで入力オプションを指定するには、ファイルを作成し、inputfileパラメータを使用して、コマンドラインでそのファイルを指定します。入力ファイルの形式は次のとおりです。

    input_parameter1:parameter_value1
input_parameter2:parameter_value2

    次に例を示します。

    userid:11
roleid:22

    次に、コマンドラインでファイルを指定します。

    ./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest
                           inputfile=/tmp/inputfile

13.5.6 ヘルス・テスト・フレームワークの診断テストの検索

dfwhealthtestctl.sh listtestコマンドを使用することにより、テストまたはランを検索できます。オプションで、テストの名前または製品コードを指定できます。

  • すべてのテストを検索するには、次のように指定します。

    ./dfwhealthtestctl.sh listtest

  • SampleTestという名前のテストを検索するには、次のように指定します。

    ./dfwhealthtestctl.sh listtest testname=SampleTest

  • ワイルドカードを使用して複数のテストを検索するには、次のように入力します。

    ./dfwhealthtestctl.sh listtest testname="S*"

  • 特定の製品に関連するすべてのテストを検索するには、次のように入力します。

    dfwhealthtestctl.sh listtest productcode=idm

13.5.7 ヘルス・テスト・フレームワーク・テストの説明の取得

dfwhealthtestctl.sh listtestコマンドを使用することにより、指定したテストの説明を取得できます。たとえば、SampleTestテストの説明とそのパラメータを取得するには、次のコマンドを使用します。

./dfwhealthtestctl.sh desctest testname="SampleTest" showparam=Y

13.5.8 ヘルス・テスト・フレームワークのテスト・ランのリスト

dfwhealthtestctl.sh listrunコマンドを使用することにより、テスト名、ラン名、ステータスまたは時間に基づいて、テスト・ランの結果を問い合せることができます。

  • テスト名を指定してテスト・ランの結果を問い合せるには、次のように指定します。

    ./dfwhealthtestctl.sh listrun testname="SampleTest"

  • ラン名を指定してテスト・ランの結果を問い合せるには、次のように指定します。

    ./dfwhealthtestctl.sh listrun runname="run_1"

  • ステータスを指定してテスト・ランの結果を問い合せることができます。たとえば、ステータスがrunningであるすべてのテストの結果を取得するには、次のように指定します。

    ./dfwhealthtestctl.sh listrun status=r

  • 過去2時間に開始されたテスト・ランの結果を問い合せるには、次のように指定します。

    ./dfwhealthtestctl.sh listrun lasthours=2

13.5.9 ヘルス・テスト・フレームワークのレポートの生成

dfwhealthtestctl.sh reportコマンドを使用することにより、ヘルス・テスト・フレームワークに対するテスト・ランのレポートを生成できます。HTMLまたはXMLレポートを生成できます。

ラン名、ランIDまたは実行IDを指定できます。

たとえば、ランIDが1330128064268のランに対するレポートをHTML形式で生成するには、次のように指定します。

dfwhealthtestctl.sh report runid=1330128064268 format=HTML
  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次