| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 11g リリース1(11.1.1) B63029-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 11g リリース1(11.1.1) B63029-03 |
|
前 |
次 |
この章では、Oracle Business Intelligenceの使用状況トラッキングを管理する方法について説明します。Oracle BIサーバーは、使用状況トラッキング・データの収集をサポートしています。使用状況トラッキングが有効な場合、Oracle BIサーバーは各問合せの使用状況トラッキング・データを収集し、統計を使用状況トラッキング・ログ・ファイルに書き込むか、データベース表に直接挿入します。ログ・ファイルに書き込むより、直接挿入することを強くお薦めします。
以前のバージョンの使用状況トラッキングからアップグレードしている場合は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』の使用状況トラッキングに関する項を参照してください。
|
注意: Oracle BI Summary Advisor機能は、使用状況トラッキング機能と連携しています。Summary Advisorは、使用状況トラッキングの直接挿入とのみ連携して機能します。 Oracle BI Summary Advisorは、Oracle Business IntelligenceをOracle Exalytics Machineで実行している場合にのみ使用できます。Summary Advisor機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のOracle BI Summary Advisorを使用した集計の問合せ候補の識別に関する項を参照してください。 |
この章の内容は次のとおりです。
Oracle BIサーバーではcの累積をサポートしています。BIサーバーは、詳細な問合せレベルで使用状況を追跡します。
使用状況トラッキングを有効にすると、すべての問合せの統計がデータベース表に挿入されるか、使用状況トラッキング・ログ・ファイルに書き込まれます。直接挿入を使用する場合は、使用状況トラッキング・データがリレーショナル・データベース表に直接挿入されます。直接挿入を使用して統計をデータベース表に書き込むことをお薦めします。
BIサーバーが起動すると、メタデータ内の列名が、使用状況トラッキング表内の有効な列のリストに対して検証されます。次のイベントが発生します。
列名。データベース表内の列とメタデータ内の列が一致しない場合、挿入のデータベース・エラーが発生します。
Varchar長。メタデータ内の長さと表で設定されている長さが一致しない場合、nqserver.logファイルにエラーが書き込まれ、使用状況トラッキングが無効になります。
|
注意: Oracle Business Intelligenceインストールの次の場所に、サンプルの使用状況トラッキング実装が提供されています。 ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\sample\usagetracking |
直接挿入は、使用状況トラッキングの設定における推奨方法です。この項では、直接挿入を設定する方法および次の内容について説明します。
使用状況トラッキングの直接挿入を使用する前に、使用状況トラッキングの統計を格納するデータベースを設定する必要があります。リポジトリ作成ユーティリティ(RCU)をターゲット・データベースで実行して必要な統計スキーマを作成する必要があります。
通常は、RCUで作成したスキーマがすでに含まれている、Oracle Business Intelligenceで使用するためにインストールしたデータベースを統計データベースとして使用します。使用状況トラッキング用にRCUで作成した表の名前はS_NQ_ACCTです。
このデータベースは、Oracle BIリポジトリの物理レイヤーにもインポートする必要があります。
使用状況トラッキングの統計データベースを設定するには:
選択した外部データベースでリポジトリ作成ユーティリティを実行します。Oracle Business Intelligenceで使用するためにインストールしたデータベースを使用状況トラッキングの統計用に使用する場合は、RCUで作成したスキーマがすでに含まれているため、この手順をスキップできます。
管理ツールを開き、このデータベースを物理レイヤーにインポートします。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
リポジトリを保存して閉じます。
Fusion Middleware Controlを使用してリポジトリをアップロードし、問合せに使用できるようにします。詳細は、第10.2項「リポジトリをアップロードしOracle BIプレゼンテーション・カタログの場所を設定するためのFusion Middleware Controlの使用」を参照してください。
新しい(アップグレードでない)インストールに直接挿入を設定するには、Fusion Middleware ControlでシステムMBeanブラウザを使用します。
システムMBeanブラウザを使用して使用状況トラッキングの直接挿入を設定するには:
Fusion Middleware Control MBeanブラウザを表示します。
詳細は第2.4.2項「Fusion Middleware Control MBeanブラウザの表示」を参照してください。
「アプリケーション定義のMBean」、oracle.biee.admin、Domain: bifoundation_domainの順に開きます。
ドメインを次のとおりにロックします。
BIDomainを開き、group=ServiceのBIDomain MBeanを選択します。
「操作」タブを表示します。
「ロック」リンクをクリックします。
BIDomain.BIInstance.ServerConfigurationを開き、BIDomain.BIInstance.ServerConfiguration MBeanを選択します。
UsageTrackingCentrallyManaged属性がtrueに設定されていることを確認します。UsageTrackingCentrallyManagedがfalseに設定されている場合は、次のパラメータは、システムMBeanブラウザではなく、各Oracle BIサーバー・コンピュータ上のNQSConfig.INIファイルを使用して管理します。
SummaryAdvisorTableName
SummaryStatisticsLogging
UsageTrackingConnectionPool
UsageTrackingDirectInsert
UsageTrackingEnabled
UsageTrackingPhysicalTableName
UsageTrackingEnabled属性をtrueに設定して使用状況トラッキングを有効にします。
UsageTrackingDirectInsert属性をtrueに設定して直接挿入を有効にします。
Oracle BIリポジトリの物理レイヤーに表示されているように、UsageTrackingPhysicalTableName属性を、問合せ統計情報を収集するための完全修飾データベース表の名前に設定します。例:
"My_DB"."DEV_BIPLATFORM"."S_NQ_ACCT"
Oracle BIリポジトリの物理レイヤーに表示されているように、UsageTrackingConnectionPool属性を、問合せ統計データベースの完全修飾接続プールの名前に設定します。例:
"My_DB"."Usage Connection Pool"
|
注意: 使用状況トラッキングの挿入が行われるためには、バックエンド・データベースへの書込み権限を持つユーザーIDで接続プールを構成する必要があります。また、接続タイプが国際データをサポートすることもお薦めします。 |
変更を適用したら、次のとおりにドメインのロックを解除します。
oracle.biee.admin、Domain:bifoundation_domain、BIDomainの下にあるgroup=ServiceのBIDomain MBeanに戻ります。
「操作」タブを表示します。
コミット操作のいずれかをクリックします。
Oracle Business Intelligenceの「概要」ページを開き、「再起動」をクリックします。
顧客のアップグレードについて、使用状況トラッキング・パラメータはデフォルトで集中管理されません。前述の手順で説明したように、UsageTrackingCentrallyManagedをtrueに設定し、システムMBeanブラウザを使用してパラメータを更新することも、NQSConfig.INIを使用して使用状況トラッキング・パラメータを管理することもできます。
これらのパラメータの集中管理が無効になっている場合に、NQSConfig.INIで使用状況トラッキングの直接挿入を有効にするには、次の手順を実行します。
Oracle BIサーバー・コンピュータで、NQSConfig.INIファイルをテキスト・エディタで開きます。このファイルは次の場所にあります:
ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
編集する前に、ファイルのバップアップ・コピーを作成します。
[USAGE_TRACKING]セクションで、次のパラメータを更新します。
ENABLEをYESに設定します。
DIRECT_INSERTをYESに設定します。
Oracle BIリポジトリの物理レイヤーに表示されているように、PHYSICAL_TABLE_NAMEを、問合せ統計情報を収集するための完全修飾データベース表の名前に設定します。例:
PHYSICAL_TABLE_NAME = "My_DB"."DEV_BIPLATFORM"."S_NQ_ACCT";
Oracle BIリポジトリの物理レイヤーに表示されているように、CONNECTION_POOLを、問合せ統計データベースの完全修飾接続プールの名前に設定します。例:
CONNECTION_POOL = "My_DB"."Usage Connection Pool";
|
注意: 使用状況トラッキングの挿入が行われるためには、バックエンド・データベースへの書込み権限を持つユーザーIDで接続プールを構成する必要があります。また、接続タイプが国際データをサポートすることもお薦めします。 |
ファイルを保存して閉じます。
Oracle BIサーバーを再起動します。
複数のOracle BIサーバー・インスタンスがある場合は、すべてのOracle BIサーバー・インスタンスについて、各NQSConfig.INIファイルでこれらの手順を繰り返します。
前述の設定パラメータに加えて、次のオプションのパラメータもNQSConfig.INIファイルの使用状況トラッキング・セクションで更新できます。
BUFFER_SIZE。このパラメータは、挿入文のバッファリング用にBIサーバーが割り当てるメモリー量を示します。このようなバッファにより、BIサーバーは複数の挿入文を1つのトランザクションに含めて発行でき、使用状況トラッキング挿入のスループットが向上します。また、通常の分析では使用状況トラッキング挿入を待つ必要がないため、問合せの平均レスポンス時間も向上します。サーバー・コンピュータ上の使用可能なメモリーとメモリーの使用状況に応じて、この値を調整します。
BUFFER_TIME_LIMIT_SECONDS。このパラメータは、使用状況トラッキング・サブシステムが挿入文の発行を試行するまでの、挿入文がバッファ内に存続する最大時間を示します。この時間制限によって、静止状態が長く続いていても、BIサーバーは挿入文をすぐに発行できます。
NUM_INSERT_THREADS。このパラメータは、バッファから挿入文を削除し、それを使用状況トラッキング・データベースに挿入するスレッドの数を示します。読取りと挿入で接続プールがそれぞれ別の場合、挿入スレッド数は、通常、接続プール内の最大接続設定に等しくなります。
MAX_INSERTS_PER_TRANSACTION。このパラメータは、使用状況トラッキング・サブシステムが、1つのトランザクションの一部として発行を試みる挿入文の最大数を示します。この値が大きくなるほど、使用状況トラッキング挿入が長時間にわたって行われ、潜在的なスループットが増します。ただし、値が大きいと、デッドロックが原因でトランザクションが失敗する可能性も増します。BUFFER_TIME_LIMIT_SECONDSに小さい値を指定すると、トランザクション当たりの挿入数を制限できます。
使用状況トラッキングの構成パラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。
使用状況トラッキングの構成には、ログ・ファイル収集という方法もあります。この機能もサポートされていますが、使用状況トラッキングの情報を収集するには、直接挿入を使用することをお薦めします。詳細は、第9.2項「使用状況トラッキングの情報を収集するための直接挿入の設定」を参照してください。
次の項では、使用状況トラッキングのログ・ファイル収集を構成する方法について説明します。ログ・ファイル・パラメータを構成する前に、NQSConfig.INIファイルの使用状況トラッキング・セクションでENABLEパラメータをYESに設定する必要があります(または、使用状況トラッキングの集中管理が有効な場合は、システムMBeanブラウザを使用して、BIDomain.BIInstance.ServerConfiguration MBeanのUsageTrackingEnabled属性をtrueに設定します)。使用状況トラッキングの構成パラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。
この項には次のトピックが含まれます:
NQSConfig.INIファイルの使用状況トラッキング・セクション内のSTORAGE_DIRECTORYパラメータによって、使用状況トラッキング・ログ・ファイルの場所が決まります。使用状況トラッキングが有効だが記憶域フォルダが指定されていない場合、ソフトウェアのインストール・フォルダ内のログ・フォルダ(たとえば、\OBI11g\logs)にファイルが書き込まれます。
現在のファイルは定期的にディスクに書き込まれ、新しいファイルが作成されます。CHECKPOINT_INTERVAL_MINUTESパラメータは、使用状況トラッキング・データがディスクにフラッシュされる頻度を制御し、FILE_ROLLOVER_INTERVAL_MINUTESパラメータは、現在の使用状況トラッキング・ログ・ファイルを閉じて、新しいファイルを作成する頻度を制御します。
使用状況トラッキングが有効な場合、すべての問合せが使用状況トラッキング・ログ・ファイルに記録されます。これにより、大量の使用可能記憶域が必要になる可能性があります。たとえば、各問合せのデータ出力が平均300バイトで、1秒当たり10件の問合せが1日当たり8時間にわたって行われるものとします。この結果、1日当たり約83 MBの使用状況トラッキング・データが記憶域に書き込まれます。この例を年中無休の運用に拡張すると、1日当たり約0.25 GBの記憶域になります。
BIサーバーは、指定の場所に存在する使用状況トラッキング・ログ・ファイルのサイズや数量に制限を設けていません。自分で十分な領域が使用可能であることを確認し、古い使用状況トラッキング・ファイルを削除またはアーカイブする必要があります。
使用状況トラッキング・ログ・ファイルのファイル名の形式はNQAcct.yyyymmdd.hhmmss.logで、yyyyはファイルが作成されたタイムスタンプの年、mmは月、ddは日、hhは時間、mmは分、ssは秒を表します。たとえば、使用状況トラッキング・ログ・ファイルが2010年2月12日07:15:00 a.m.に作成された場合、ファイル名はNQAcct.20100212.071500.logです。指定のロールオーバー間隔の後、このファイルはディスクにフラッシュされて閉じ、現在の日付とタイムスタンプに基づく新しいログ・ファイルが作成されます。
使用状況トラッキング・ログ・ファイルは、セミコロン( ; )で区切られた形式のテキスト・ファイルです。論理SQLテキストにカンマが含まれているため、列区切りとしてセミコロンが使用されます。データの各行の終わりは行送りで区切られます。
使用状況トラッキング・データの一意キーとして保証されたものはありませんが、通常は、ユーザー名、ノードID、開始タイムスタンプおよび問合せテキストの組合せで十分です。Query_Keyを一意キーとして使用できますが、Query_Keyは直接挿入でのみ使用できます。
使用状況トラッキング・ログ・ファイルからデータを抽出し、それを適切な形式のリレーショナル・データベース表にロードする上で参考になるサンプル・スクリプトについては、第9章「使用状況トラッキングの管理」を参照してください。各列の内容の詳細は、第9.4項「使用状況トラッキング・データの説明」も参照してください。
表9-1は、使用状況トラッキング出力ファイルの形式を示しています。
表9-1 使用状況トラッキング出力ファイルの形式
| 列番号 | 列名 | データ型 | 最大データ・サイズ | NULL値可能 |
|---|---|---|---|---|
|
1 |
ユーザー名 |
Varchar |
128 |
いいえ |
|
2 |
リポジトリ名 |
Varchar |
128 |
いいえ |
|
3 |
サブジェクト・エリア名 |
Varchar |
128 |
いいえ |
|
4 |
ノードID |
Varchar |
15 |
いいえ |
|
5 |
開始タイムスタンプ |
Char(タイムスタンプ) |
19 |
いいえ |
|
6 |
開始日 |
Char(yyyy-mm-dd) |
10 |
いいえ |
|
7 |
開始時間 |
Char(hh:mm) |
5 |
いいえ |
|
8 |
終了タイムスタンプ |
Char(タイムスタンプ) |
19 |
いいえ |
|
9 |
終了日 |
Char(yyyy-mm-dd) |
10 |
いいえ |
|
10 |
終了時間 |
Char(hh:mm) |
5 |
いいえ |
|
11 |
問合せテキスト |
Varchar |
1024 |
いいえ |
|
12 |
成功インジケータ |
Integer |
4 |
いいえ |
|
13 |
行数 |
Integer |
4 |
はい |
|
14 |
合計時間(秒) |
Integer |
4 |
はい |
|
15 |
コンパイル時間(秒) |
Integer |
4 |
はい |
|
16 |
データベース問合せ数 |
Integer |
4 |
はい |
|
17 |
累積データベース時間(秒) |
Integer |
4 |
はい |
|
18 |
累積データベース行 |
Integer |
4 |
はい |
|
19 |
キャッシュ・インジケータ |
Char |
1 |
いいえ |
|
20 |
問合せソース |
Varchar |
30 |
いいえ |
|
21 |
プレゼンテーション・カタログ・パス |
Varchar |
250 |
いいえ |
|
22 |
ダッシュボード名 |
Varchar |
150 |
はい |
表9-1は、スキーマの説明です。次のリストは、整数データ型およびタイムスタンプ列の詳細な説明です。
整数型。出力ファイル内のデータはすべて、文字列形式です。列12 - 18のデータは、テキスト表現の整数値として出力されます。したがって、整数よりVarchar(10)列のような動作をします。たとえば、行カウントが100万行の場合、出力ファイルの列13(行カウント)には1000000が表示されます。データは4バイトの内部整数値を表すにもかかわらず、これは7バイトのデータに相当します。
列12の成功インジケータの値0は、問合せの成功を示します。ゼロ以外のすべての値は、失敗を示します。現在、次の失敗インジケータが定義されています。
1はタイムアウトを示します。
2は行制限違反を示します。
3は不明なエラーを示します。
後続の整数列は、成功インジケータ(列12)が問合せの成功(値0)を示している場合のみ有効です。
タイムスタンプ列。開始タイムスタンプ列と終了タイムスタンプ列は、論理問合せが開始および終了したときの実時間(ローカル時間)を示します。各値は、SQL-92タイムスタンプに相当する19バイトの文字データです。形式は、yyyy-mm-dd-hh:mm:ssです。関連する開始日列および終了日列には、対応するタイムスタンプの日付部分のみが含まれます(yyyy-mm-dd形式)。関連する開始時間列と終了時間列には、対応するタイムスタンプの時間と分の部分のみが含まれます(char hh:mm形式)。
使用状況トラッキングが有効な場合、BIサーバーはすべての問合せについて使用状況トラッキング・データを収集します。しかし、このデータは、チェックポイントと呼ばれるユーザー指定の間隔でのみディスクに書き込まれます。デフォルト設定では、チェックポイントは5分ごとです。
NQSConfig.INIファイル内でこの値を変更できますが、間隔を短くするとオーバーヘッドが増し、値をあまり小さくすると、サーバーのパフォーマンスに影響する可能性があります。大きな値に設定すると、BIサーバーが万一異常停止したときに失われる使用状況トラッキング・データの量が多くなります。
BIサーバーは、使用状況トラッキング・ファイルのロールオーバーを定期的に開始します。ロールオーバーは、現在の使用状況トラッキング・ログ・ファイルを閉じ、後続のデータを書き込むための新しいファイルを作成して開くことで行われます。ロールオーバーが発生する頻度を、ロールオーバー間隔と言います。デフォルトのロールオーバー間隔は240分(4時間ごと)です。
閉じられた使用状況トラッキング・ログ・ファイルは、分析で使用できます。ロールオーバー間隔を短くすると、使用状況トラッキング・ログ・ファイルを分析ですぐに使用できますが、余分なオーバーヘッドがかかります。
チェックポイント間隔がロールオーバー間隔以上の場合は、ロールオーバーのみが明示的に発生します。古い使用状況トラッキング・ログ・ファイルが閉じられた場合のみ、チェックポイントが暗黙で発生します。
表9-2は、S_NQ_ACCT使用状況トラッキング表内の各列の説明です。該当する場合は、データ型と長さも示されています。
表9-2で説明している時間に関連したいくつかの列には、加算または減算によってその正確な値を求められると推測できるものがあります。たとえば、END_TSからSTART_TSを引けば、TOTAL_TIME_SECを求められるように思われるかもしれません。次の理由により、これらの列を使用しても正確な値は求められません。
様々なプロセスが並列に実行されており、その処理速度はBIサーバーにかかる負荷およびデータベースのパフォーマンスに応じて異なります。サーバーベースの処理は、軽いか集中的であるかのどちらかになります。
すべての接続が使用中の場合、問合せはキューで処理を待機します。そのタイミングは、BIサーバーの負荷と構成に応じて異なります。
表9-2 S_NQ_ACCTの使用状況トラッキング・データ
| 列 | 説明 |
|---|---|
|
CACHE_IND_FLG |
デフォルトはNです。 Yは問合せのキャッシュ・ヒットを示し、Nはキャッシュ・ミスを示します。 |
|
COMPILE_TIME_SEC |
問合せのコンパイルにかかった時間(秒単位)です。この表で説明しているように、COMPILE_TIME_SECの秒数はTOTAL_TIME_SECに含まれます。 |
|
CUM_DB_TIME_SEC |
BIサーバーが論理問合せのかわりにバックエンド物理データベースを待機した合計時間(秒単位)です。 |
|
CUM_NUM_DB_ROW |
バックエンド・データベースから返された合計行数です。 |
|
END_DT |
論理問合せが完了した日付です。 |
|
END_HOUR_MIN |
論理問合せが完了した時間(時間と分)です。 |
|
END_TS |
論理問合せが終了した日付と時間です。開始タイムスタンプと終了タイムスタンプも、リソースが使用可能になるまでの問合せの待機時間を表します。 注意: 問合せの終了前に、問合せを発行しているユーザーがページから移動すると、最終的なフェッチは行われず、3600というタイムアウト値が記録されます。しかし、タイムアウトの前にユーザーがページに戻ると、その時点でフェッチが完了し、これがend_ts時間として記録されます。 |
|
ERROR_TEXT |
デフォルトはNullです。Varchar(250) バックエンド・データベースからのエラー・メッセージです。この列は、 |
|
NODE_ID |
BIサーバーが実行されているコンピュータのホスト名です。 |
|
NUM_CACHE_HITS |
デフォルトはNullです。Number(10,0)です。 DB2の場合、データ型と長さはDecimal(10,0)です。 問合せに対してキャッシュ結果が返された回数を示します。 |
|
NUM_CACHE_INSERTED |
デフォルトはNullです。Number(10,0)です。 DB2の場合、データ型と長さはDecimal(10,0)です。 問合せによってキャッシュ・エントリが生成された回数を示します。 |
|
NUM_DB_QUERY |
論理問合せリクエストを満たすためにバックエンド・データベースに対して発行された問合せの数です。成功した問合せ(SuccessFlag = 0)の場合、この値は1以上です。 |
|
PRESENTATION_NAME |
デフォルトはNullです。Varchar(128) Oracle BIプレゼンテーション・カタログの名前です。 |
|
QUERY_BLOB |
データ型は、SQLServerを使用している場合は 論理SQL文全体が切り捨てられることなく含まれています。 |
|
QUERY_KEY |
デフォルトはNullです。Varchar(128)です。 Oracle Business Intelligenceによって論理SQL文から生成されたMD5ハッシュ・キーです。 |
|
QUERY_SRC_CD |
リクエストのソース(たとえば、ドリルまたはレポート)です。 |
|
QUERY_TEXT |
Varchar(1024)です。 問合せで発行されたSQL文です。 この列の長さはALTER TABLEコマンドで変更できますが、この列に書き込まれるテキストは、物理レイヤーで定義されているサイズに常に切り捨てられます。リポジトリ管理者は、この列の長さを、バックエンド物理データベースでサポートされている最大問合せ長より大きな値に設定しないでください。 たとえば、Oracle Databaseでは最大4000のVarcharを使用できますが、4000文字ではなく4000バイトに切り捨てられます。このため、マルチバイト・キャラクタ・セットを使用している場合、使用しているキャラクタ・セットと文字に応じて、実際の最大文字列サイズの文字数が異なります。 |
|
REPOSITORY_NAME |
問合せがアクセスするリポジトリの名前です。 |
|
ROW_COUNT |
問合せクライアントに返される行数です。 注意: 大量のデータが問合せから返される場合、すべてのデータがユーザーに表示されるまで、この列には移入されません。 |
|
IMPERSONATOR_USER_NAME |
デフォルトはNullです。Varchar(128) 偽装ユーザーのユーザー名です。リクエストが偽装ユーザーとして実行されない場合、値はNULLです。 |
|
SAW_DASHBOARD |
ダッシュボードのパス名です。問合せがダッシュボードを通じて発行されなかった場合、値はNULLです。 |
|
SAW_DASHBOARD_PG |
デフォルトはNullです。Varchar(150) ダッシュボード内のページ名です。リクエストがダッシュボード・リクエストでない場合、値はNULLです。 |
|
SAW_SRC_PATH |
分析するOracle BIプレゼンテーション・カタログ内のパス名です。 |
|
START_DT |
論理問合せが発行された日付です。 |
|
START_HOUR_MIN |
論理問合せが発行された時間(時間と分)です。 |
|
START_TS |
論理問合せが発行された日時です。 |
|
SUBJECT_AREA_NAME |
アクセスされるビジネス・モデルの名前です。 |
|
SUCCESS_FLG |
次のリストで定義される、問合せの完了ステータスです。
|
|
TOTAL_TIME_SEC |
クライアントが分析へのレスポンスを待機している間に、BIサーバーが問合せの処理に要した時間(秒単位)です。TOTAL_TIME_SECには、COMPILE_TIME_SECの時間が含まれます。 この設定は、第8.4.1.1項「問合せのロギング・レベルの設定」で説明されている、nqquery.logファイル内のレスポンス時間と同じです。 |
|
USER_NAME |
問合せを発行したユーザーの名前です。 |
表9-3は、S_NQ_DB_ACCT表の説明です。これは、S_NQ_ACCTに格納されている論理問合せに対応する物理SQL情報を提供することで、使用状況トラッキング表を補足しています。S_NQ_DB_ACCTには、S_NQ_ACCTへの逆方向の外部キー・リレーションシップがあります。
表9-3 S_NQ_DB_ACCTの使用状況トラッキング・データ
| 列 | 説明 |
|---|---|
|
END_DT |
物理問合せが完了した日付です。 |
|
END_HOUR_MIN |
物理問合せが完了した時間(時間と分)です。 |
|
END_TS |
物理問合せが終了した日付と時間です。開始タイムスタンプと終了タイムスタンプも、リソースが使用可能になるまでの問合せの待機時間を表します。 |
|
ID |
一意の行IDです。 |
|
LOGICAL_QUERY_ID |
Varchar2(50)です。 S_NQ_ACCT表の論理問合せを参照します。 |
|
QUERY_BLOB |
データ型は、SQLServerを使用している場合は 物理SQL文全体が切り捨てられることなく含まれています。 |
|
QUERY_TEXT |
Varchar(1024)です。 問合せで発行されたSQL文です。 |
|
ROW_COUNT |
問合せクライアントに返される行数です。 |
|
TIME_SEC |
物理問合せの実行時間です。 |
|
START_DT |
物理問合せが発行された日付です。 |
|
START_HOUR_MIN |
物理問合せが発行された時間(時間と分)です。 |
|
START_TS |
物理問合せが発行された日時です。 |
