Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 11g リリース1(11.1.1) B63029-01 |
|
前 |
次 |
Oracle BI Serverは、使用状況トラッキング・データの収集をサポートしています。使用状況トラッキングが有効な場合、Oracle BI Serverは各問合せの使用状況トラッキング・データを収集し、統計を使用状況トラッキング・ログ・ファイルに書き込むか、データベース表に直接挿入します。ログ・ファイルに書き込むより、直接挿入することを強くお薦めします。
注意: Oracle Business Intelligenceインストールの次の場所に、サンプルの使用状況トラッキング実装が提供されています。ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\sample\usagetracking |
以前のバージョンの使用状況トラッキングからアップグレードしている場合は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』の使用状況トラッキングに関する項を参照してください。
この章の内容は、次のとおりです。
Oracle BI Serverでは使用状況トラッキングの累積統計をサポートしており、これは、データベースの最適化、集計計画、使用するリソースに基づくユーザーや部門への請求など、様々な形で使用できます。BI Serverは、詳細な問合せレベルで使用状況を追跡します。
使用状況トラッキングを有効にすると、すべての問合せの統計がデータベース表に挿入されるか、使用状況トラッキング・ログ・ファイルに書き込まれます。直接挿入を使用する場合は、使用状況トラッキング・データがリレーショナル・データベース表に直接挿入されます。直接挿入を使用して統計をデータベース表に書き込むことをお薦めします。
BI Serverが起動すると、メタデータ内の列名が、使用状況トラッキング表内の有効な列のリストに対して検証されます。次のイベントが発生します。
列名。データベース表内の列とメタデータ内の列が一致しない場合、挿入のデータベース・エラーが発生します。
Varchar長。メタデータ内の長さと表で設定されている長さが一致しない場合、nqserver.logファイルにエラーが書き込まれ、使用状況トラッキングが無効になります。
この項の項目は次のとおりです。
直接挿入は、使用状況トラッキングの設定における推奨方法です。直接挿入を設定するには、NQSConfig.INIファイルの使用状況トラッキング・セクションで次のパラメータを更新します。
ENABLE。使用状況トラッキングを有効にするには、このパラメータをYES
に設定します。
DIRECT_INSERT。このパラメータは、問合せ統計をデータベース表に直接挿入するか、ファイルに書き込んで後でロードするかを決定します。直接挿入を有効にするには、このパラメータをYES
に設定します。
PHYSICAL_TABLE_NAME。問合せ統計情報を表に挿入するには、表の名前と、表にアクセスするときに使用する接続プール(CONNECTION_POOLパラメータを参照)を提供する必要があります。
完全修飾された物理表名は、4つのコンポーネント(データベース名、カタログ名、スキーマ名および表名)で構成されます。各コンポーネントは二重引用符(")で囲み、ピリオド(.)で区切ります。物理表名は、完全修飾する必要があります。この完全修飾された物理表名は、ロードされたリポジトリの物理レイヤー内の表名に一致する必要があります。Oracle Business Intelligenceリポジトリ内の使用状況トラッキング表の物理表名の例を、次に示します。
PHYSICAL_TABLE_NAME = "Oracle BI Usage"."Catalog"."dbo"."S_NQ_ACCT" ;
この例では、Oracle BI Usage
はデータベース・コンポーネントを表し、Catalog
はカタログ・コンポーネントを表し、dbo
はスキーマ・コンポーネントを表し、S_NQ_ACCT
は表名を表します。
CONNECTION_POOL。完全修飾された接続プール名は、2つの部分(データベース名および接続プール名)で構成されます。各部分は二重引用符(")で囲み、ピリオド(.)で区切ります。完全修飾された接続プール名は、ロードされたリポジトリの物理レイヤー内の接続プール名に一致する必要があります。たとえば、Oracle Business Intelligenceリポジトリ内の次の接続プール名を見てみましょう。
CONNECTION_POOL = "Oracle BI Usage"."Connection Pool" ;
この例では、Oracle BI Usage
はデータベース・コンポーネントを表し、Connection Pool
は実際の接続プール名を表します。
使用状況トラッキングの挿入が行われるためには、バックエンド・データベースへの書込み権限を持つユーザーIDで接続プールを構成する必要があります。
注意: 接続タイプが国際データをサポートすることをお薦めします。 |
接続プールの構成については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
BUFFER_SIZE。このパラメータは、挿入文のバッファリング用にBI Serverが割り当てるメモリー量を示します。このようなバッファにより、BI Serverは複数の挿入文を1つのトランザクションに含めて発行でき、使用状況トラッキング挿入のスループットが向上します。また、通常の分析では使用状況トラッキング挿入を待つ必要がないため、問合せの平均レスポンス時間も向上します。サーバー・コンピュータ上の使用可能なメモリーとメモリーの使用状況に応じて、この値を調整します。
BUFFER_TIME_LIMIT_SECONDS。このパラメータは、挿入文がバッファ内に存続する最大時間を示します。この時間を過ぎると、使用状況トラッキング・サブシステムによって挿入文の発行が試みられます。この時間制限によって、静止状態が長く続いていても挿入文をすぐに発行できます。
NUM_INSERT_THREADS。このパラメータは、バッファから挿入文を削除し、それを使用状況トラッキング・データベースに挿入するスレッドの数を示します。読取りと挿入で接続プールがそれぞれ別の場合、挿入スレッド数は、通常、接続プール内の最大接続設定に等しくなります。
MAX_INSERTS_PER_TRANSACTION。このパラメータは、使用状況トラッキング・サブシステムが、1つのトランザクションの一部として発行を試みる挿入文の最大数を示します。この値が大きくなるほど、使用状況トラッキング挿入が長時間にわたって行われ、潜在的なスループットが増します。ただし、値が大きいと、デッドロックが原因でトランザクションが失敗する可能性も増します。BUFFER_TIME_LIMIT_SECONDS
に小さい値を指定すると、トランザクション当たりの挿入数を制限できます。
使用状況トラッキングの構成パラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。
使用状況トラッキングの構成には、ログ・ファイル収集という方法もあります。この機能もサポートされていますが、使用状況トラッキングの情報を収集するには、直接挿入を使用することをお薦めします。詳細は、第9.1.1項「使用状況トラッキングの情報を収集するための直接挿入の設定」を参照してください。
次の項では、使用状況トラッキングのログ・ファイル収集を構成する方法について説明します。ログ・ファイル・パラメータを構成する前に、NQSConfig.INIファイルの使用状況トラッキング・セクションでENABLE
パラメータをYES
に設定して、使用状況トラッキングを有効にする必要があります。使用状況トラッキングの構成パラメータの詳細は、付録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日当たり約.25 GBの記憶域になります。
BI Serverは、指定の場所に存在する使用状況トラッキング・ログ・ファイルのサイズや数量に制限を設けていません。自分で十分な領域が使用可能であることを確認し、古い使用状況トラッキング・ファイルを削除またはアーカイブする必要があります。
使用状況トラッキング・ログ・ファイルのファイル名の形式は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.2項「使用状況トラッキング・データの説明」を参照してください。
表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 Serverはすべての問合せについて使用状況トラッキング・データを収集します。しかし、このデータは、チェックポイントと呼ばれるユーザー指定の間隔でのみディスクに書き込まれます。デフォルト設定では、チェックポイントは5分ごとです。
NQSConfig.INIファイル内でこの値を変更できますが、間隔を短くするとオーバーヘッドが増し、値をあまり小さくすると、サーバーのパフォーマンスに影響する可能性があります。大きな値に設定すると、BI Serverが万一異常停止したときに失われる使用状況トラッキング・データの量が多くなります。
BI Serverは、使用状況トラッキング・ファイルのロールオーバーを定期的に開始します。ロールオーバーは、現在の使用状況トラッキング・ログ・ファイルを閉じ、後続のデータを書き込むための新しいファイルを作成して開くことで行われます。ロールオーバーが発生する頻度を、ロールオーバー間隔と言います。デフォルトのロールオーバー間隔は240分(4時間ごと)です。
閉じられた使用状況トラッキング・ログ・ファイルは、分析で使用できます。ロールオーバー間隔を短くすると、使用状況トラッキング・ログ・ファイルを分析ですぐに使用できますが、余分なオーバーヘッドがかかります。
チェックポイント間隔がロールオーバー間隔以上の場合は、ロールオーバーのみが明示的に発生します。古い使用状況トラッキング・ログ・ファイルが閉じられた場合のみ、チェックポイントが暗黙で発生します。
表9-2は、使用状況トラッキング表内の各列の説明です。該当する場合は、データ型と長さも示されています。
表9-2 使用状況トラッキング・データ
列 | 説明 |
---|---|
CACHE_IND_FLG |
デフォルトはNです。 Yは問合せのキャッシュ・ヒットを示し、Nはキャッシュ・ミスを示します。 |
COMPILE_TIME_SEC |
問合せのコンパイルにかかった時間(秒単位)です。 |
CUM_DB_TIME_SEC |
BI Serverが論理問合せのかわりにバックエンド物理データベースを待機した合計時間(秒単位)です。 |
CUM_NUM_DB_ROW |
バックエンド・データベースから返された合計行数です。 |
END_DT |
論理問合せが完了した日付です。 |
END_HOUR_MIN |
論理問合せが完了した時間(時間と分)です。 |
END_TS |
論理問合せが終了した日付と時間です。開始タイムスタンプと終了タイムスタンプも、リソースが使用可能になるまでの問合せの待機時間を表します。 注意: 問合せの終了前に、問合せを発行しているユーザーがページから移動すると、最終的なフェッチは行われず、3600というタイムアウト値が記録されます。しかし、タイムアウトの前にユーザーがページに戻ると、その時点でフェッチが完了し、これがend_ts時間として記録されます。 |
ERROR_TEXT |
デフォルトはNullで、Varchar(250)です。 バックエンド・データベースからのエラー・メッセージです。この列は、 |
NODE_ID |
BI Serverが実行されているコンピュータのホスト名です。 |
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 Presentation Catalogの名前です。 |
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 Presentation Catalog内のパス名です。 |
START_DT |
論理問合せが発行された日付です。 |
START_HOUR_MIN |
論理問合せが発行された時間(時間と分)です。 |
START_TS |
論理問合せが発行された日時です。 |
SUBJECT_AREA_NAME |
アクセスされるビジネス・モデルの名前です。 |
SUCCESS_FLG |
次のリストで定義される、問合せの完了ステータスです。
|
TOTAL_TIME_SEC |
クライアントが分析へのレスポンスを待機している間に、BI Serverが問合せの処理に要した時間(秒単位)です。この設定は、第8.4.1.1項「問合せのロギング・レベルの設定」で説明されている、nqquery.logファイル内のレスポンス時間と同じです。 |
USER_NAME |
問合せを発行したユーザーの名前です。 |