| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース2 (11.1.2) B71702-01 |
|
 前 |
 次 |
この章では、Oracle Dynamic Monitoring Service(DMS)の概要および使用できる機能を示します。
Oracle Dynamic Monitoring Service(DMS)を使用すると、Oracle Fusion MiddlewareコンポーネントでOracle Enterprise Managerなどの管理ツールにコンポーネントのパフォーマンス、状態および進行中の動作に関するデータを提供できます。Fusion MiddlewareコンポーネントはDMSにデータをプッシュし、DMSは異なるコンポーネントの範囲でそのデータを公開します。特に、DMSは、Oracle WebCache、Oracle HTTP Server(OHS)、Oracle Application Development Framework(ADF)、WebLogic診断フレームワーク(WLDF)およびJDBCによって使用されます。DMSは、メトリック、トレース・イベントおよびシステム・パフォーマンスを測定および報告し、これらのコンポーネントのコンテキスト相関サービスを提供します。
この項では、次の内容に関連する共通のDMSの用語および概念を定義します。
表5-1に、DMSトレースおよびイベントの用語のリストを示します。
表5-1 DMSトレースおよびイベントの用語
| DMSの用語 | 定義 |
|---|---|
|
条件 |
条件は、条件フィルタのロジックです。条件で定義されたルールに基づいて、フィルタを通過するイベントを決定します。各条件フィルタにはゼロか1つのルート条件がありますが、ANDまたはOR引数を含めて複合条件を作成できます。単一のルート条件を使用して、比較的複雑なルールを示すことができます。 次の2つのタイプの条件が存在します。
条件の使用の詳細は、第5.7項「DMSトレースおよびイベント」を参照してください。 |
|
宛先 |
宛先は、渡されるイベントに対応するメカニズムを実装します。たとえば、ファイルにイベントのログを記録できる宛先、JRockitフライト・レコーダにイベントの変換されたコピーを送信できる宛先、MBeanのデータとして着信イベントから収集された情報をレンダリングする宛先などがあります。 |
|
イベント・ルート |
イベント・ルートは、フィルタを宛先に接続します。イベント・ルートを有効または無効にできます。特定のフィルタでアクティブにするイベント・トレースは、そのフィルタに1つ以上のイベント・ルートが存在して有効である必要があります。 |
|
フィルタ |
イベント・トレース・フィルタは、すべての使用可能なDMSランタイム・イベントのサブセットを選択的に渡します。渡されるイベントとブロックされるイベントを決定するルールとともにフィルタを構成できます。 たとえば、次の目的でフィルタを定義できます。
フィルタの使用の詳細は、第5.7項「DMSトレースおよびイベント」を参照してください。 |
|
リスナー |
DMSリスナーは、宛先とも呼ばれます。詳細は、第5.7.2項「宛先の構成」を参照してください。 |
DMSナウンはパフォーマンス・データを編成します。センサーは、関連付けられたメトリックとともに、ナウンに従って階層に編成されます。ナウンを使用すると、ファイル・システムのディレクトリ構造と同様の方法で、DMSメトリックを編成できます。たとえば、ナウンは、クラス、メソッド、オブジェクト、キュー、接続、アプリケーション、データベース、その他の測定の対象を表すことができます。
ナウン・タイプは、収集対象となるメトリックのセットを表す名前です。
ナウン名は、デリミタを含まない単純な文字列です。たとえば、BasicBinomialはナウン名です。ナウンのフルネームは、ナウン名にネームスペースとローカルパートを付けて構成されます。ナウン名の前に、その親のフルネームとデリミタが付きます。/dmsDemo/BasicBinomial/"{http://mynamespace/}JAXWSHelloService"はナウンのフルネームです。
センサー名は、「.」や派生を含まない単純な文字列です。たとえば、computeSeries、loopsおよびlastComputedはセンサー名です。
センサーのフルネームは、そのセンサーが関連付けられたナウンの名前、デリミタ、センサー名で構成されます。たとえば、/dmsDemo/BasicBinomial/computeSeries、/dmsDemo/BasicBinomial/loops、/dmsDemo/BasicBinomial/lastComputedなどです。
DMSメトリック名は、センサー名、「.」、メトリックで構成されます。たとえば、computeSeries.time、loops.countおよびlastComputed.valueは有効なDMSメトリック名です。
|
注意: 接尾辞.time、.countおよび.valueは変更できません。ただし、センサー名およびナウン名は必要に応じて変更可能です。 |
DMSの名前はできるだけ簡潔にしてください。また、ナウンやセンサーの名前を定義する場合は、特殊文字(空白、スラッシュ、ピリオド、カッコ、カンマ、制御文字など)を使用しないでください。
表5-2に、DMSの名前の中で特殊文字のかわりに使用する代替文字を示します。
表5-2 DMSの名前の中で特殊文字のかわりに使用する代替文字
| 文字 | DMSの代替文字 |
|---|---|
|
空白文字 |
アンダースコア: |
|
ピリオド: |
アンダースコア: |
|
制御文字 |
アンダースコア: |
|
より小さい: |
開きカッコ: |
|
より大きい: |
閉じカッコ: |
|
アンパサンド: |
カレット: |
|
二重引用符: |
バッククォート: |
|
一重引用符: |
バッククォート: |
|
注意: Oracle Fusion Middlewareには、組込みメトリックがいくつか用意されています。Oracle Fusion Middlewareの組込みメトリックが、このDMSネーミング規則に常に従っているとはかぎりません。 |
ナウンおよびナウン・タイプのネーミングに次の規則が使用されます。
ナウン名は一意である必要があります。
ナウンには、特定のエンティティを識別する名前を付けてください。
ナウン・タイプには、収集対象となるメトリックのセットを明確に表す名前を使用する必要があります。たとえば、Servletというナウン・タイプは、そのナウンで特定のサーブレットに固有のメトリックを収集することを示します。
ナウン・タイプ名は、他のDMSの名前と区別するために大文字で始めてください。同じタイプのナウンはすべて、同じセンサーのセットを持ちます。
ナウンのネーミング方式では階層のルートに「/」を使用し、各ナウンがルート、または親ナウンの下にあるコンテナとして機能します。
DMS センサーは、パフォーマンス・データを測定します。このセンサーによって、メトリックのセットの定義および収集が可能になります。メトリックには、センサーに常に含まれるものとオプションとして含まれるものがあります。
DMSには3種類のSensorがあります。
DMS PhaseEventセンサーは、コード内の特定セクションの開始から終了までにかかる時間を測定します。あるメソッドまたはコード・ブロックの処理にかかる時間を追跡する場合は、PhaseEventセンサーを使用します。
DMSでは、PhaseEventセンサーの処理にかかる平均時間、最大時間、最小時間など、PhaseEventに関連するオプションのメトリックを計算できます。
表5-3に、PhaseEventセンサーで使用可能なメトリックを示します。
表5-3 DMS PhaseEventセンサーのメトリック
| メトリック | 説明 |
|---|---|
|
|
フェーズ デフォルトのメトリック: |
|
|
プロセスの開始以降にフェーズ オプションのメトリック |
|
|
フェーズ オプションのメトリック |
|
|
フェーズ オプションのメトリック |
|
|
フェーズ オプションのメトリック |
|
|
DMS統計の収集時にフェーズ オプションのメトリック |
|
|
プロセスの開始以降に、フェーズ オプションのメトリック |
DMSイベント・センサーは、システム・イベントをカウントします。継続時間の短いシステム・イベントを追跡する場合や、イベントの継続時間よりもイベントの発生が重要な場合は、DMSイベント・センサーを使用します。
表5-4に、イベント・センサー関連のメトリックを示します。
DMS 状態センサーは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。サポートされている型は、integer、double、longおよびobjectです。システムのステータス情報を追跡する場合や、イベントに関係のないメトリックが必要な場合は、状態センサーを使用します。たとえば、状態センサーを使用して、キューの長さ、プール・サイズ、バッファ・サイズまたはホスト名を追跡します。状態センサーには、事前に計算された値を割り当てます。
表5-5に、状態センサーのメトリックを示します。状態センサーは、デフォルトのメトリックvalueおよびオプションのメトリックをサポートします。オプションのminValueメトリックおよびmaxValueメトリックは、状態センサーが(integer型、double型、long型などの)数値のJavaプリミティブを表す場合にのみ適用されます。
表5-5 DMS状態センサーのメトリック
| メトリック | 説明 |
|---|---|
|
|
デフォルト: |
|
|
オプションのメトリック |
|
|
起動後の オプションのメトリック |
|
|
起動後のこの オプションのメトリック |
次のリストは、DMSセンサーのネーミング規則を示しています。
センサー名は、簡潔で説明的なものにしてください。冗長になるのを避けるため、センサー名には、ナウン名の一部やナウン・タイプを含めないようにします。
Sensor名には、個々のメトリックの値を含めないでください。
センサーを説明するために複数の単語を組み合せる必要がある場合は、最初の単語は小文字で、以降の単語は大文字で始めます。たとえば、computeSeriesのようになります。
一般に、センサー名に「/」を使用することは避けてください。ただし、「/」を含む名前を使用することに意味がある場合もあります。ナウン名またはセンサー名に「/」を使用した場合は、そのセンサーをDMSメソッドの文字列で使用する際に、かわりのデリミタとして、パスにまったく存在しない「,」や「_」などを使用する必要があります。そうすることで、「/」はデリミタではなく、ナウン名またはセンサー名の一部であることが正しく認識されるようになります。
たとえば、次のような名前の子ナウンがあるとします。
examples/jsp/num/numguess.jsp
これは、次のような文字列を使用して検索できます。
,default,WEBs,defaultWebApp,JSPs,example/jsp/num/numguess.jsp,service
この場合のデリミタは「,」です。
EventセンサーおよびPhaseEventセンサーの名前は、英単語を動詞+名詞という形式で組み合せて定義します。たとえば、activateInstanceやrunMethodのようになります。PhaseEventによって関数、メソッドまたはコード・ブロックを監視する場合は、実行されるタスクをできるだけ明確に反映した名前を使用します。
状態センサーの名前には名詞を使用します。場合によっては、この状態センサーで追跡する値の内容を説明する形容詞が前に付きます。たとえば、lastComputed、totalMemory、port、availableThreads、activeInstancesのようになります。
混乱を避けるため、.time、.value、.avgなどの文字列をセンサー名に使用しないでください。表5-3、表5-4および表5-5に示したとおり、これらはセンサー・メトリックの名前であるためです。
DMS機能をすべての認証されたJava EEサーバーで使用できます。これには、実行時機能およびサポートしているコマンドの両方が含まれます。また、DMSのいくつかの機能がJSEアプリケーションおよびスタンドアロンCアプリケーションで動作します。
詳細は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlのOracle Fusion Middlewareの動作保証マトリックスを参照してください。
DMSは、次の機能で構成されます。
DMSメトリック - DMSメトリック機能は、パフォーマンス測定および他の便利な状態メトリックでコードのインスツルメンテーションを行うために他のOracle Fusion Middlewareコンポーネントでも使用されるJavaおよびC APIを用意しています。このメトリック機能は、導出したメトリックおよびメトリックにアクセスするツールを計算する集計言語も用意しています。
実行コンテキスト - 実行コンテキストは、Oracleスタック全体の特定のコンテキスト構造のメンテナンスおよび伝播をサポートします。すべてのOracleコードで一貫して使用できるコンテキスト構造を作成すると、診断データのコンポーネント間および製品間の相関関係の潜在性が高まります。詳細は、第5.6項「DMS実行コンテキスト」を参照してください。
イベントおよびトレース - イベント・トレースにより、再起動しないでライブ・トレースを構成できます。Oracle Fusion Middleware製品の使用中に更新されたDMSメトリックは、DMSイベント・トレース機能でトレースされる場合があります。システムは、トレースを容易にするだけではなくDMSアクティビティから起動する可能性がある他の機能もサポートするよう設計されています。
図5-1は、DMSのコンポーネントおよび他のOracle Fusion Middlewareコンポーネントとの対話方法を示しています。矢印は、コンポーネント間の情報フローの方向を示しています。
開発者、システム管理者およびサポート・アナリストがシステム・パフォーマンスの分析やシステム・ステータスの監視を実行できる情報を収集するため、Oracle Fusion Middlewareコンポーネントは、DMSメトリックでインスツルメンテーションを行います。Fusion Middleware Controlオンライン・ヘルプは、特定のメトリックごとの情報を示します。メトリック情報のアクセスの詳細は、第4.2.1項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示」を参照してください。
Oracle Fusion Middlewareメトリックは、様々なソースおよび場所から発生します。これには、MBean属性およびDMSメトリックが含まれます。また、Oracle HTTP ServerおよびOracle WebCacheなどの非Java EEサーバーからも発生します。
次の各項では、DMSメトリックを表示する様々なツールの使用方法について説明します。
スパイ・サーブレットは、JRF拡張インストールでデフォルトでデプロイされるDMSアプリケーションの一部です。http://<host>:<port>/dms/Spyからスパイ・サーブレットが起動します。WebLogicのデフォルト・ポートは7001です。
DMSアプリケーションのWebアーカイブ・ファイルはdms.warで、dms.jar: oracle_common/modules/oracle.dms_11.1.1/dms.warと同じディレクトリにあります。
詳細は、第4.6項「DMSスパイ・サーブレット」を参照してください。
|
注意: スパイ・サーブレットはWebアプリケーションの |
WebLogic診断フレームワーク(WLDF)を使用して、DMSメトリックMBeanからDMSメトリックを収集できます。WLDFを使用して、MBeanの属性値の変更も監視できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』のメトリック・コレクションのハーベスタの構成に関する項を参照してください。
DMSには、WLSTでメトリックを表示する次の3つのコマンドがあります。
| 使用するコマンド | 操作 |
|---|---|
|
displayMetricTableNames |
使用できるメトリック表の名前を示します。 |
|
displayMetricTables |
DMSメトリック表の内容を示します。 |
|
dumpMetrics |
内部形式でメトリックを表示します。dumpMetricsコマンドの有効な形式には、RAW、XMLおよびPDMLがあります。 |
これらのコマンドは、テキスト出力を表示して、スクリプトの処理に使用できる構造化オブジェクトまたは単一の値も戻します。
これらのコマンドの使用の詳細は、次の項を参照してください。
Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのDMSカスタムWLSTコマンド
メトリックにアクセスする標準ベースの手段を提供するため、DMSはMBeanを通じてメトリックを公開します。ランタイムMBeanサーバーで入力された各ナウンにMBeanが作成および登録されます。ナウンに含まれるDMSセンサーがMBeanの属性として公開されます。MBeanとしてDMSメトリックを公開すると、管理者はJConsole(Java監視および管理コンソール)などのツールを使用でき、他のJava Management Extension(JMX)クライアントはDMSメトリックにアクセスできます。
5.5項に示すとおり、MBeanはWLDF(WebLogic診断フレームワーク)などの他のOracle診断ソフトウェアと統合することもできます。ナウン名およびナウン・タイプは、メトリックMBeanオブジェクト名の名前およびタイプ・プロパティとして公開されます。MBeanドメイン名はoracle.dmsです。オブジェクト名はDMSナウン階層も反映します。
|
注意: JConsoleを使用すると、DMSで生成されたMBeanをJava EEサーバーでローカルまたはリモートに表示できます。DMSは、有効なナウン・タイプを持つ各Java DMSナウンのMBeanを生成します。非Java EEコンポーネントのメトリックおよびナウン・タイプを持たないDMSナウンのMBeanは生成しません。ナウンに含まれる各DMSメトリックがメトリックMBeanの属性にマップされます。 |
Oracle Fusion Middlewareは、コンポーネントのパフォーマンス、状態および進行中の動作に関するデータを自動的および継続的に測定します。メトリックが自動的に有効になるので、オプションの設定やメトリックを収集する余分な構成の実行は必要ありません。詳細は、第4.2.1項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示」を参照してください。
次の内容を表示するため、IBM WebSphereで次のコマンドを使用できます。
| 使用するコマンド | 操作 |
|---|---|
|
OracleDMS.displayMetricTableNames() |
使用できるメトリック表の名前を示します。 |
|
OracleDMS.displayMetricTables() |
DMSメトリック表の内容を示します。 |
|
OracleDMS.dumpMetrics() |
内部形式でメトリックを表示します。有効な形式には、RAW、XMLおよびPDMLがあります。 |
IBM WebSphereの使用の詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドのIBM WebSphereのOracle Fusion Middlewareの管理に関する項を参照してください。
WebLogic診断フレームワーク(WLDF)には、特定の条件でMBean属性を収集および監視できる診断機能が用意されています。これにより、条件がトリガーされた場合に環境のアクティビティの監視と電子メールおよびJMX通知の作成を事前に行う手段が提供されます。
次の手順は、WLDFを構成してWebLogic管理コンソールで電子メール通知を送信する方法を示しています。
「診断」画面から既存の診断モジュールを選択するか、新しい診断モジュールを作成します。
「監視と通知」タブをクリックします。
「新規」をクリックします。
監視名を入力して、「次へ」をクリックします。
監視ルールのテキストを入力して、「次へ」をクリックします。
(${ServerRuntime//[NOUNTYPE]oracle.dms:name=/starWars/alliance,type=NounType//forceBalance_value} = 'BAD')
「手動リセットのアラームを使用する」を選択して、「次へ」をクリックします。手動リセット・オプションは、電子メールがトリガーされた後にWebLogic管理コンソールを使用して監視をリセットする必要があることを意味します。
電子メール通知タイプを選択して、「終了」をクリックします。
また、WLDFを構成して、オフラインの格納および分析のためにMBeanデータを収集できます。特定のMBean属性を収集するためにWLDF診断モジュールを構成してこれを実施し、WebLogic管理コンソールを使用して実行できます。
WLDFを使用したMBeanデータの収集および監視の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。
DMS実行コンテキストは、リクエスト(HTTPまたはRMIリクエストなど)を一意に識別してシステム内での動向を追跡できるメカニズムです。リクエストの遂行に含まれる連携しているFusion Middlewareコンポーネントの間でコンテキスト情報を通信できる手段も提供します。
リクエストまたはルート・タスクを完了するために調整されるサブタスクのツリーのルートが単一のリクエスト(またはタスク)で構成できることを考慮して、DMS実行コンテキストが開発されています。リクエストおよび関連するサブタスクの次の例を検討してください。
ブラウザから直接Oracle WebLogic Serverに送信されるHTTPリクエスト
Oracle WebLogic Serverのルート・タスクのみ
リバース・プロキシとして動作するOracle HTTP ServerからOracle WebLogic Serverに送信されるHTTPリクエスト
Oracle HTTP Serverのルート・タスク
Oracle WebLogic Serverの単一のサブタスク
リバース・プロキシとして動作するOracle HTTP ServerからOracle WebLogic Serverに送信され、リクエストを遂行するためにOracle WebLogic Serverから2つのリモートWebサービスの呼出しが必要になるHTTPリクエスト
Oracle HTTP Serverのルート・タスク
Oracle WebLogic Serverの単一のサブタスク
Webサービスごとの合計2つのサブタスク
DMS実行コンテキストは、次の内容で構成されます。
一意の識別子のECID
実行コンテキストID(ECID)は新しいルート・タスクごとに一意で、ルート・タスクに関連するタスクのツリーで共有されます。
リレーションシップ識別子のRID
リレーションシップID(RID)は、タスクのツリーで各タスクの場所を示す順序付けされた数値の集合です。先頭の数値は通常ゼロです。先頭の数値の1は、全体のサブタスク・ツリー内でサブタスクの場所を追跡できないことを示します。
グローバル関連データをOracle Fusion Middlewareコンポーネントで共有できる名前/値ペアのセット
次の3つのシナリオは、HTTPリクエストがリバース・プロキシとして動作するOracle HTTP ServerからOracle WebLogic Serverに送信され、Oracle WebLogic Serverから2つのリモートWebサービスの呼出しが必要になる場合のECIDおよびRIDの使用方法を示しています。
Oracle HTTP Serverのルート・タスク
新しいECID = B5C094FA...BE4AE8
ルートRID = 0
Oracle WebLogic Serverの単一のサブタスク
同じECID = B5C094FA...BE4AE8
サブタスクRID = 0:1
Webサービスごとの合計2つのサブタスク
起動される最初のWebサービス
同じECID = B5C094FA...BE4AE8
サブタスクRID = 0:1:1
起動される2番目のWebサービス
同じECID = B5C094FA...BE4AE8
サブタスクRID = 0:1:2
サーバー間のログ・メッセージを関連付けると、DMS実行コンテキストの最も直接的な利点がわかります。ロギングのOracle標準形式には、ECID専用フィールドが含まれます。エラー・レベルのログ・メッセージからの読込みなどでECIDを確認した後、そのECIDを含むメッセージのログ・ファイルを問い合せて、タスクに関連する他のすべてのログ・メッセージを検索できます。
コマンドを使用する非常に特殊なケースの例を次に示します。
displayLogs(ecid="B5C094FA...BE4AE8");
この例では、ECID B5C094FA...BE4AE8を含むメッセージのログ・ファイルが表示されます。
図5-2は、DMS実行コンテキストを相互に通信するために連携するコンポーネントを示しています。コンポーネントを参照する矢印は、受信コンテキスト情報を検証するプロトコルを示します。外側の矢印は、コンテキスト情報が追加されるプロトコルを示します。単一のコンポーネントが自身にリクエストを送信し、そのリクエストにコンテキスト情報を渡すことできます。
Oracle Fusion Middleware 11gリリース1(11.1.1.3.0)以降、DMSは次のイベントを選択的にトレースできます。
DMSセンサー・ライフサイクル・イベント(状態センサー、イベント・センサーおよびフェーズ・センサーの作成、更新、削除)
コンテキスト・イベント(開始、停止)
HTTPイベント(開始、停止)
これらのタイプのイベントのトレースおよび処理方法を制御する構成がdms_config.xmlファイルに記録されます。DMSトレース構成は、次の3つに分類されます。
フィルタ構成
特定のイベントを選択するルールを定義します。
宛先構成
イベントの使用方法を定義します。
イベント・ルート構成
使用するフィルタおよび接続する宛先を定義します。
フィルタを1つ以上の宛先に関連付けることができるので、管理者は一度フィルタ・ルールを定義して1つ以上の異なる宛先で処理されるすべての使用可能なイベントの結果サブセットを利用できます。
実行時にDMS構成MBeanまたはWLSTコマンドを使用して、構成を変更できます。このため、特定の期間に発生する問題の診断や特定の基準セットを使用した特定の時間の特定のデータの収集にDMSトレース機能が非常に役立ちます。
詳細は、『Oracle Fusion Middleware管理者ガイド』のWLSTを使用した選択的トレースの構成に関する項を参照してください。
次のタイプのフィルタ・ルールがサポートされます。
イベント・タイプ条件
イベントがPHASE_SENSORのSTARTまたはSTOPからトリガーされているかどうかを識別するために使用されます。
コンテキスト・タイプ条件
コンテキストに値(「USER」など)が含まれる作業単位からイベントが生成されたかどうかを識別するために使用されます。
ナウン・タイプ条件
ナウンが特定のタイプ(JDBC_CONNECTIONなど)のセンサーからイベントがトリガーされたかどうかを識別するために使用されます。
上記の条件の論理ANDおよびORの組合せ
構成は、各サーバーのdms_config.xmlファイルに記録されます。コマンドライン・インタフェース(CLI)コマンドおよびイベント構成Mbeanを使用して、実行時にMBeanを更新できます。スレッド・セーフの非アトミックの方法で構成の更新が実行中のシステムに適用されます。
DMSイベント構成MBeanのオブジェクト名は、oracle.dms.event.config:name=DMSEventConfigMBean,type=JMXEventConfigです。
システムのDMSイベント構成の現在の状態を確認するには、次のコマンドを使用します。
listDMSEventConfiguration([server=<server>])
出力結果は次のようになります。
Event routes:
FILTER : auto662515911
DESTINATION : destination1
ENABLED : true
FILTER : filter0
DESTINATION : q
ENABLED : true
Filters with no event route:
Fred
Destinations with no event route:
des4
フィルタは、トレースに検討するイベントを選択するルールを定義します。
次の例は、JDBC操作に関連するすべてのイベントを選択するフィルタの追加方法を示しています。
addDMSEventFilter(id='myJDBCFilter', props={'condition': 'NOUNTYPE sw JDBC_'})
または
addDMSEventFilter(id='myJDBCFilter', props={'condition': 'NOUNTYPE startsWith JDBC_'})
このフィルタは、JDBC操作に関連するすべてのDMSセンサーの更新が名前が「JDBC_」で始まるタイプのナウンに実行されると仮定します。
ルールを変更する必要がある場合、次の例のようにフィルタを更新できます。
updateDMSEventFilter(id="myJDBCFilter", props={'condition': 'NOUNTYPE startsWith JDBC_ OR NOUNTYPE startsWith MDS_'});
Oracle Fusion Middleware 11.1.1.6.0から、次の短縮された便利な演算子が追加されています。演算子は、短縮名または詳細名のいずれかを使用して指定できます。
アンダースコアが付いている演算子は非推奨になっているため、大文字と小文字の両方を使用するODL形式をお薦めします。たとえば、not_equalsはnotEqualsまたはneになります。古い形式でも機能しますが、推奨されていません。
| ナウン・タイプ演算子 | |
|---|---|
|
equals、eq |
notEquals、ne |
|
contains |
in |
|
startsWith、sw |
|
| コンテキスト演算子 | |
|---|---|
|
equals、eq |
notequals、ne |
|
isnull |
isnotnull |
|
startswith、sw |
contains |
|
lt |
gt |
例:
addDMSEventFilter(id='mdsbruce', name='MyFilter', props={'condition':
'NOUNTYPE eq MDS_Connections AND CONTEXT user ne bruce'})
addDMSEventFilter(id='mdsbruce', name='MyFilter', props={'condition':
'NOUNTYPE equals MDS_Connections AND CONTEXT user notequals bruce'})
フィルタのルール(条件プロパティ)を示すために使用される構文の詳細は、WebLogic Scripting Toolコマンド・リファレンスまたはコマンド・ヘルプを参照してください。
宛先は、イベントに対応するロジックをカプセル化します。たとえば、基本の宛先でイベントのログを記録し、異なる宛先でイベントを変換して別のシステムに渡して追加処理を実行できます。
次の例は、イベントのログを記録する宛先の追加方法を示しています。
addDMSEventDestination(id="myLoggerDestination", class="oracle.dms.trace2.runtime.LoggerDestination", props={"loggerName":"myLogger"});
宛先の追加だけではイベントのログを記録できないので、イベント・ルートを使用してフィルタと宛先を関連付け、イベント・ルートを有効(デフォルト)にする必要があります。
使用できる宛先のタイプおよび構成オプションを第5.7.2項に示します。次の例は、既存の宛先の編集方法を示しています。
updateDMSEventDestination(id="myLoggerDestination", props={"loggerName":"myTraceLogger"});
次の例は、上記で作成されたフィルタおよび宛先の結合方法を示しています。
addDMSEventRoute(filterid='myJDBCFilter', destinationid='myLoggerDestination')
明示的なフィルタIDを使用しないでaddDMSEventRouteを起動できます。これらのシナリオでは、すべてのイベントがフィルタなしで宛先に渡されます。
フィルタまたは宛先を削除するには、フィルタまたは宛先に関連するイベント・ルートを無効になっていても最初に削除する必要があります。たとえば、myJDBCFilterを削除する場合、次の例に示すように、前の例で作成したイベント・ルートを最初に削除してからフィルタを削除する必要があります。
removeDMSEventRoute(filterid='myJDBCFilter', destinationid='myLoggerDestination') removeDMSEventFilter(id='myJDBCFilter')
第5.7.1.3項のように2つの個別のコマンドではなく単一のコマンドを使用して、フィルタおよびそのフィルタに基づくイベント・ルートを作成できます。ただし、イベント・ルートで使用される宛先が事前に定義されている必要があります。
enableDMSEventTrace (destinationid='myLoggerDestination', condition='NOUNTYPE starts_with JDBC_')
上記の例で、enableDMSEventTraceは、指定された条件でフィルタを自動的に作成し、新しいフィルタおよび指定された宛先を使用してイベント・ルートを作成および有効化できます。次に、出力例を示します。
Filter "auto605449842" using Destination "myLoggerDestination" added, and event-route enabled for server "AdminServer"
DMSは、次のタイプの宛先を提供します。
|
説明 |
LoggerDestinationは、各イベントを関連するロガーに書き込みます。 |
|
実装クラス |
oracle.dms.trace2.runtime.LoggerDestination |
|
プロパティ |
|
|
|
イベントが書き込まれるODLロガーの名前。 |
ロガー宛先のインスタンスは、イベントをFINERログ・レベルの名前が付いたロガーに書き込みます。
loggerNameプロパティにロガーの名前を指定しますが、必ずしもロガーをlogging.xmlに示す必要はありません。ロガー名がlogging.xmlで明示的に名前が付けられているロガーを示す場合、そのロガーは静的ロガーと呼ばれます(第5.7.2.1.1項を参照してください)。ロガー名がlogging.xmlで明示的に名前が付けられていないロガーを示す場合、そのロガーは動的ロガーと呼ばれます(第5.7.2.1.2項を参照してください)。
デフォルト構成の使用: デフォルト構成は、LoggerDestinationを確認してロガー宛先を定義します。この特定のインスタンスはイベント・ルートの一部を構成しないので、アクティブではありません。便宜上提供され、動的ロガーを使用します。
ロガーは、ログの記録が示されるオブジェクトです。ログ・ハンドラは、ログの記録がログ・ファイルに書き込まれるオブジェクトです。
DMSトレース・データが書き込まれるログ・ファイルを完全に制御するには、logging.xmlのロガー宛先の名前のロガーを定義します。これを実行すると、ログ・ファイルの名前、最大サイズ、形式、ファイル・ローテーションおよびポリシーを明示的に定義できます。
次の例のようなコマンドを使用して構成を更新することをお薦めします。
setLogLevel(logger="myTraceLogger", level="FINER", addLogger=1); configureLogHandler(name="my-trace-handler", addToLogger=["myTraceLogger"], path="/tmp/myTraceLogFiles/trace", maxFileSize="10m", maxLogSize="50m", handlerType="oracle.core.ojdl.logging.ODLHandlerFactory", addHandler=1, useParentHandlers=0); configureLogHandler(name="my-trace-handler", propertyName="useSourceClassandMethod", propertyValue="false", addProperty=1);
ロギング構成の詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルおよび診断データの管理に関する項を参照してください。
オプションのプロパティuseSourceClassandMethodを使用してFALSEに設定すると、「SRC_CLASS」および「SRC_METHOD」が各メッセージに表示されなくなり、ファイルの出力時間が短縮されてパフォーマンスがわずかに改善します。
静的ロガーの場合、useParentHandlersパラメータをFALSEに設定することを検討してください。そうしない場合、重複したイベント・メッセージが[server]-diagnostics.logにログとして記録され、ログの問合せに表示されます。
ロガーの出力の解釈の詳細は、第5.7.3項「DMSイベント出力の理解」を参照してください。
名前が付いたロガーにlogging.xmlに定義されたハンドラが関連付けられていない場合、サーバーのデフォルトのログ出力ディレクトリにあるファイルに書き込むハンドラ・オブジェクトがロガー宛先によって動的に作成されます。(ロガー宛先のインスタンスは、イベントをFINERログ・レベルの名前が付いたロガーに書き込みます。)ファイル名は、ロガー名の後に「-event.log」が付きます。たとえば、第5.7.2.1.1項の例では、DMSイベントは「myTraceLogger-event.log」に書き込まれます。
logging.xmlファイルは、一般的に次のプラットフォームの場所のいずれかにあります。
| プラットフォーム | サーバー | 場所 |
|---|---|---|
|
Oracle WebLogic Server |
AdminServer |
ORACLE_HOME/Middleware/user_projects/domains/base_domain/config/fmwconfig/servers/AdminServer/logging.xml |
|
WAS ND |
OracleAdminServer |
ORACLE_HOME/Middleware/was_profiles/DefaultTopology/DefaultServer/config/cells/DefaultCell/nodes/<nodename>/servers/OracleAdminServer/fmwconfig/logging.xml |
ロガー宛先のロガーおよびハンドラがlogging.xmlに定義されている場合、displayLogs()コマンドを利用して、手動で特定または検索することなくログに記録されたトレース・データに適切にアクセスできます。
例:
myTraceLoggerのすべてのログ・メッセージを表示するには、次のコマンドを実行します。
displayLogs(query='MODULE equals myTraceLogger')
ECIDが「0000HpmSpLWEkJQ6ub3FEH194kwB000004」のmyTraceLoggerのログ・メッセージのみを表示するには、次のコマンドを実行します。
displayLogs(query='MODULE equals myTraceLogger and ECID equals 0000HpmSpLWEkJQ6ub3FEH194kwB000004')
最後の10分のECIDが「0000HpmSpLWEkJQ6ub3FEH194kwB000004」のmyTraceLoggerのログ・メッセージのみを表示するには、次のコマンドを実行します。
displayLogs(query='MODULE equals myTraceLogger and ECID equals 0000HpmSpLWEkJQ6ub3FEH194kwB000004', last=10)
動的ロガーのすべてのログ・メッセージを表示するには、ログのファイル名を含める必要があります。
displayLogs(disconnected=1, log=DOMAIN_ROOT+"/servers/AdminServer/logs/myTraceLogger-event.log")
|
説明 |
MBean Creatorの宛先を使用すると、WLDF、JConsoleなどを使用したアクセスのためにナウンがMBeanとしてアクセス可能になり、属性としてそのメトリックを公開します。 |
|
実装クラス |
oracle.dms.jmx.MetricMBeanFactory |
デフォルト構成の使用: MBean Creatorの宛先のインスタンスが構成されてデフォルトでアクティブになり、サーバーに作成されたすべてのナウンのMBeanが作成されます。
この宛先タイプのインスタンスをナウン・タイプのルールに基づくフィルタに関連付けると、管理者が指定するナウン・タイプのみをMBeanとして公開できます。
実行時にMBean Creatorの宛先に関連付けられた構成を変更できますが、このタイプの宛先の再初期化プロセスがパフォーマンスに影響する可能性があることを理解する必要があります。そのため、頻繁な実行時の再構成は推奨されていません。
WebLogic診断フレームワーク(WLDF)を使用すると、MBean Creator宛先で公開されるDMSメトリックを収集できます。WLDFの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。
ナウン名およびナウン・タイプは、メトリックMBeanオブジェクト名の名前およびタイプ・プロパティとして公開されます。MBeanドメイン名はoracle.dmsです。オブジェクト名はDMSナウン階層も反映します。
たとえば、ナウンのフルパス名は次のとおりです。
/oracle/dfw/ofm/base_domain/AdminServer
ナウン・タイプはDFW_Incidentで、ナウンを表すMBeanのオブジェクト名は次のとおりです。
oracle.dms:Location=AdminServer,name=/oracle/dfw/ofm/base_domain/AdminServer,type=DFW_Incident
|
説明 |
HTTPリクエスト・トラッカの宛先は、アクティブなHTTPリクエストのリストを保持し、リクエストを他の診断フレームワーク(DFW)コンポーネントでアクセス可能にします。 |
|
実装クラス |
oracle.dms.event.HTTPRequestTrackerDestination |
|
プロパティ |
|
|
|
追跡から除外されるヘッダー名のカンマ区切りのリスト |
デフォルト構成の使用: HTTPリクエスト・トラッカ宛先のインスタンスはデフォルトで有効です。生成されるDFWインシデントの場合、アクティブなHTTPリクエストのリストが自動的にダンプされるので、管理者は障害と特定のリクエストを相互に関連付けることができます。
HTTPリクエストごとに次の情報がダンプされます。
URI(/webcenter/homeなど)
リクエストの開始時間
ECID
問合せ文字列
HTTPヘッダー
HTTPリクエスト・トラッカが有効ではない場合、HTTPリクエスト・ダンプが次の内容を出力します。
HTTP Requests are not being tracked. To enable HTTP request tracking enable the DMS oracle.dms.event.HTTPRequestTrackerDestination in dms_config.xml
HTTPリクエスト・トラッカに保持される情報に手動でアクセスできます。HTTPリクエスト情報を報告するダンプを実行するには、サーバーの接続時に次のようにWLST executeDumpコマンドを使用できます。
> executeDump(name="http.requests") Active Requests: StartTime: 2009-12-14 02:24:41.870 ECID: 0000IMChyqEC8xT6uBf9EH1B9X9^000009,0 URI: /myApp/Welcome.jsp QueryString: Headers: Host: myHost.myDomain.com:7001 Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate Cookie: ORA_MOS_LOCALE=en%7CGB; s_nr... Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
JRockitフライト・レコーダ(JFR)は、JRockit JVM.の実行時ステータスおよび動作に関する情報を記録します。JFRは、サード・パーティ・イベントを報告できるAPIも公開します。JFRは、JRockit R28以上で使用できます。
DMSは独立してトレースし、JFRはサーバーで実行されているアクション全体の表示部分のみをトレースします。JFRとDMSの統合は、次に示すように管理者と開発者が使用できる診断情報を拡張します。
アプリケーション・レベル・イベントおよびJVMレベル・イベントを1つの手順として報告できるので、タイムスタンプだけに基づいて個別のログ・ファイルからこのようなイベントを結合する必要がなくなります(同時に作成されるイベントを正確に順序付けできるほど迅速に動作しない場合があります)。
任意にJVMから遡及して最近のDMSアクティビティをダンプできます。
JVMを正常に終了させる致命的なエラーの場合、最近のDMSおよびJVMイベントをディスクにダンプできます。
DMS ECIDを使用すると、JFR記録期間に同じリクエストに関連するアクティビティ(作業単位)を相互に関連付けることができます。
DMS ECIDを使用すると、JFRで記録される単一および一連のイベントに関連するすべてのシステムの診断情報を収集できます。
DMSナウン・タイプは、JFR InstantEventイベント・タイプに関連付けられます。
ナウン・タイプのJFRイベント・タイプの名前は、接尾辞「 state」の付いたナウン・タイプの名前になります。
ナウン・タイプのJFRイベント・タイプのパスは、「dms/」、プロデューサ名、イベント・タイプ名の順に付けられます。
イベント・センサーは、値をナウン・タイプのJFRイベント・タイプに提供しません。
ナウン・タイプのJFRイベントの値を表5-6に示します。
表5-6 ナウン・タイプのJFRイベントの値
| 値の名前 | 説明 | リレーショナル | 注意 |
|---|---|---|---|
|
ECID |
アクションに関連付けられた実行コンテキストID(ECID)。 |
はい |
|
|
RID |
アクションに関連付けられたRID。 |
はい |
|
|
<ナウン・タイプ>名 |
ナウンのフルパス。 |
このフィールドは、ナウンのフルパスに移入されます。フィールドの名前は、noun_typeを使用してそのタイプのナウンで測定されているすべてのオブジェクトが適切に分類されていると仮定します。 |
|
|
<state-sensor-name> |
状態センサーの値。 |
いいえ |
ナウンに属する各状態センサーは、これらの値のいずれかを即時イベントに提供します。各ナウンに複数の値が存在する場合があります。 |
|
イベント名 |
更新されたイベント・センサーの名前(それ以外の場合はnull)。 |
いいえ |
DMSイベント・センサーが更新された回数を記録するには、イベント名フィールドが必要です(イベント・センサーは値をイベント・タイプに提供しません)。 |
DMSフェーズ・センサーは、JFR DurationEventイベント・タイプに関連付けられます。
特定のナウン・タイプのナウンに属しているフェーズ・センサーのJFRイベント・タイプの名前は、後にフェーズ・センサーの名前が付けられるナウン・タイプの名前になります。
ナウン・タイプのJFRイベントのパスは、「dms/」、プロデューサ名、イベント・タイプ名の順に付けられます。
期間イベントの値は上記のようになります(sensorName値を除きます)。たとえば、フェーズ・イベントの「停止」がフェーズ・イベントの親ナウンの状態情報を含むJFRに報告されるJFR期間イベントになります。
いくつかのDMSオブジェクトにより、インテグレータで説明を追加できます。DMSオブジェクトの説明は、次のように使用されます。
ナウン・タイプの説明は、JFRイベント・タイプの作成に使用されます。
状態およびイベント・センサーの説明は適用されず、適用される場所はありません。
フェーズ・センサーの説明がJFRイベント・タイプに適用されます。
表5-7は、第5.7.2.4.1項で説明されているルールの例を示しています。
表5-7 動的に導出されたプロデューサおよびイベントの例
| DMS | JRockitフライト・レコーダ(JFR) |
|---|---|
|
ナウン・タイプ:
ナウン・パス:
センサー:
各値の説明は次のとおりです。 P: フェーズ・センサー S : 状態センサー E : イベント・センサー |
プロデューサ名: JDBC プロデューサ名は、ナウン・パスの先頭のコンポーネントに基づいています。 イベント・タイプ1 イベント・タイプ名: <ナウン・タイプ> State イベント・タイプ・パス: dms/<ナウン・パスの先頭のコンポーネント>/<ナウン・タイプ>/_State フィールド:
|
|
プロデューサ名: JDBC イベント・タイプ2 イベント・タイプ名: イベント・タイプ・パス:
フィールド:
|
|
|
プロデューサ名: JDBC イベント・タイプ3 イベント・タイプ名: イベント・タイプ・パス:
フィールド:
|
|
|
プロデューサ名: JDBC イベント・タイプ4 イベント・タイプ名: イベント・タイプ・パス:
フィールド:
|
|
|
ナウン・タイプ: webcenter_lifecycle ナウン・パス:
センサー:
各値の説明は次のとおりです。 P: フェーズ・センサー S : 状態センサー E : イベント・センサー |
プロデューサ名: webcenter イベント・タイプ1 イベント・タイプ名: フィールド:
|
|
プロデューサ名: webcenter イベント・タイプ2 イベント・タイプ名: フィールド:
|
表5-8は、DMSイベントを構成するフィールドを示しています。フィールド要素は「:」で区切られますが、いくつかの例外があります。実際のイベント文字列のフィールドの位置を示すため、サンプルのイベントが用意されています。
表5-8 イベント・フォーマットの説明
| アプリケーション・イベント | フィールド番号 | 名前 | 説明 |
|---|---|---|---|
|
すべて |
1 |
バージョン番号 |
イベント形式のバージョン番号 例: v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp |
|
すべて |
2 |
イベント時間 |
イベントが発生した時間 例: v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp |
|
すべて |
3 |
ソース・オブジェクト・タイプ |
次の項目を含むイベントを生成するためにアクションが実行されたオブジェクトのタイプ
例: v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp |
|
すべて |
4 |
アクション・タイプ |
このイベントを生成したアクションのタイプ。特定のソース・オブジェクト・タイプは、次の各アクション・タイプのイベントを必ずしも生成しません。
例: v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp |
|
ナウン |
5 |
ナウン・タイプ |
ナウン・タイプの名前 例: v1:1281344803506:NOUN:CREATE:JDBC_Connection:/JDBC/JDBC Data Source-0/CONNECTION_1 |
|
6 |
ナウン・パス |
センサーが属するナウンを識別するフルパス 例: v1:1281344803506:NOUN:CREATE:JDBC_Connection:/JDBC/JDBC Data Source-0/CONNECTION_1 |
|
|
すべてのセンサー・タイプ |
5 |
ナウン・タイプ |
このセンサーが属するナウン・タイプの名前 例: v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086 |
|
6 |
センサー名 |
センサーの名前 例: v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069 |
|
|
7 |
ナウン・パス |
センサーが属するナウンを識別するフルパス 例: v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069 |
|
|
フェーズ・センサー・タイプ |
8 |
開始トークン |
フェーズの開始トークン。 例: v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069 |
|
9 |
停止トークン |
フェーズの終了トークン。 例: v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069 |
|
|
状態センサー・タイプ |
8 |
状態値タイプ |
次の項目を含む状態センサーで保持される値のタイプ
例: v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086 |
|
9 |
状態値 |
文字列形式で表される状態の値。 例: v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086 |
|
|
HTTPリクエスト |
5 |
URI |
Uniform Resource Identifier(URI)は、リクエストを適用するリソースを識別します。 例: v1:1280737382889:HTTP_REQUEST:START:/myWebApp/showEmployees v1:1280737384058:HTTP_REQUEST:STOP:/myWebApp/showEmployees |
|
実行コンテキスト |
5 |
ECID、RID |
カンマで区切られたECIDおよびRIDで構成されるコンテキスト識別子。 実行コンテキスト・イベントでは、4番目のイベント・フィールド・セパレータ(「:」)の後の最初の文字から始まる完全な部分文字列にECIDおよびRID識別子を記録します。コンテキスト識別子に「:」が含まれる可能性があるので、イベント・フィールド・セパレータとして解釈しないようにしてください。 例: v1:1280737384058:EXECUTION_CONTEXT:STOP:bc4fd0668f79d507:367c127f:12a23f2013c:-8000-0000000000000f73,0 |
DMSメトリックを使用すると、アプリケーションのパフォーマンスに影響を与える可能性があります。メトリックを追加する場合、次の内容を検討してください。
高分解能クロックを使用したDMSの精度の向上
デフォルトでは、DMSはPhaseEvent中に時間間隔を測定する際、システム・クロックを使用します。デフォルト・クロックのレポート精度は、ApacheなどのCプロセスではマイクロ秒、Javaプロセスではミリ秒です。パフォーマンス測定の精度向上のために、DMSはオプションで高分解能クロックをサポートしており、時間間隔をレポートする際の値をユーザーが選択できます。デフォルト・クロックを使用する場合よりも正確にPhaseEventの時間を測定する必要があるとき、またはシステムのデフォルト・クロックが分解能の要件に満たないときは、高分解能クロックを使用してください。
システム・クロックは、必ずしも精度が示すほど正確である必要はありません。たとえば、ミリ秒で時間を報告するシステム・クロックは、ミリ秒単位で動作(変化)しない場合があります。かわりに、次の例のように最大15ミリ秒要する場合があります。
表5-10 デフォルトのシステム・クロック時間と実際の時間(ミリ秒)
| 実際の時間 | システム時間 |
|---|---|
|
12:00:00.000 |
12:00:00.000 |
|
12:00:00.001 |
12:00:00.000 |
|
12:00:00.002 |
12:00:00.000 |
|
[...] |
|
|
12:00:00.014 |
12:00:00.000 |
|
12:00:00.015 |
12:00:00.015 |
|
12:00:00.016 |
12:00:00.015 |
表5-10は、実際の時間12:00:00.002から12:00:00.014に実行される12ミリ秒の期間のフェーズがゼロのシステム時間で計算されることを示しています。同様に、12:00:00.014から12:00:00.016に実行される2ミリ秒の期間のフェーズは、15ミリ秒の期間のシステム時間で報告されます。
|
注意: これらの動作は、一部のオペレーティング・システムでより明白になります。システム・クロックの動作期間より短い個々の期間の分析に注意してください。DMSを構成して高分解能クロックを使用すると、DMSに高分解能のフェーズ・センサーのアクティブ化が記録されますが、正確性は基盤システムによって制限されます。 |
Javaの時間を報告するDMSクロックの構成
高分解能クロックを選択すると、クロックを変更したサーバーで実行されているすべてのアプリケーションに対してクロックが変更されます。プロセスの起動オプションを制御するoracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを使用して、DMSクロックおよびレポートの値をグローバルに設定します。
たとえば、デフォルトの値で高分解能クロックを使用するには、Javaコマンドラインで次のプロパティを設定します。
-Doracle.dms.clock=highres
|
注意: 高分解能クロックを使用する場合、デフォルトの値はFusion Middleware Controlが予期している値(ミリ秒)と異なります。高分解能クロックを使用しているときに、Fusion Middleware Controlを正しく表示する必要がある場合は、単位のプロパティを次のように設定します。 -Doracle.dms.clock.units=msecs |
表5-11に、oracle.dms.clockプロパティでサポートされる値を示します。
表5-12に、oracle.dms.unitsプロパティでサポートされる値を示します。
表5-11 oracle.dms.clockプロパティの値
| 値 | 説明 |
|---|---|
|
DEFAULT |
デフォルト・クロックを使用することを指定します。デフォルト・クロックの場合、DMSはJavaコール デフォルト・クロックの単位のデフォルト値は、MSECSです。 |
|
HIGHRES |
Java Highresクロックは |
表5-12 oracle.dms.clock.unitsプロパティの値
| 値 | 説明 |
|---|---|
|
MSECS |
時間がミリ秒に変換され、msecsとしてレポートされることを指定します。ミリ秒は10-3秒です。 注意: これはデフォルト・クロックのデフォルト値です。 |
|
USECS |
時間がマイクロ秒に変換され、usecsとしてレポートされることを指定します。マイクロ秒は10-6秒です。 |
|
NSECS |
時間がナノ秒に変換され、nsecsとしてレポートされることを指定します。ナノ秒は10-9秒です。 注意: これは高分解能クロックのデフォルト値です。 |
高分解能のDMSクロックを使用するときは、次の点に注意してください。
oracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを設定する際には、大文字と小文字を自由に組み合せて、選択した値を指定することができます(大/小文字の区別はありません)。たとえば、高分解能クロックを選択する場合、highres、HIGHRES、HighResのどれも有効です。
DMSは、起動時にプロパティ値をチェックします。表5-11に示されていない値でクロック・プロパティを設定すると、デフォルト・クロックが使用されます。oracle.dms.clockプロパティを設定していない場合も、デフォルト・クロックが使用されます。
クロック単位のプロパティが表5-12に示されていない値に設定されている場合、指定したクロックのデフォルトの単位が使用されます。
