ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド
11g リリース1(11.1.1)
B63029-01
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

9 使用状況トラッキングの管理

Oracle BI Serverは、使用状況トラッキング・データの収集をサポートしています。使用状況トラッキングが有効な場合、Oracle BI Serverは各問合せの使用状況トラッキング・データを収集し、統計を使用状況トラッキング・ログ・ファイルに書き込むか、データベース表に直接挿入します。ログ・ファイルに書き込むより、直接挿入することを強くお薦めします。


注意:

Oracle Business Intelligenceインストールの次の場所に、サンプルの使用状況トラッキング実装が提供されています。

ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\sample\usagetracking


以前のバージョンの使用状況トラッキングからアップグレードしている場合は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』の使用状況トラッキングに関する項を参照してください。

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

9.1 使用状況トラッキングの設定

Oracle BI Serverでは使用状況トラッキングの累積統計をサポートしており、これは、データベースの最適化、集計計画、使用するリソースに基づくユーザーや部門への請求など、様々な形で使用できます。BI Serverは、詳細な問合せレベルで使用状況を追跡します。

使用状況トラッキングを有効にすると、すべての問合せの統計がデータベース表に挿入されるか、使用状況トラッキング・ログ・ファイルに書き込まれます。直接挿入を使用する場合は、使用状況トラッキング・データがリレーショナル・データベース表に直接挿入されます。直接挿入を使用して統計をデータベース表に書き込むことをお薦めします。

BI Serverが起動すると、メタデータ内の列名が、使用状況トラッキング表内の有効な列のリストに対して検証されます。次のイベントが発生します。

この項の項目は次のとおりです。

9.1.1 使用状況トラッキングの情報を収集するための直接挿入の設定

直接挿入は、使用状況トラッキングの設定における推奨方法です。直接挿入を設定するには、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.2 使用状況トラッキングの情報を収集するためのログ・ファイルの設定

使用状況トラッキングの構成には、ログ・ファイル収集という方法もあります。この機能もサポートされていますが、使用状況トラッキングの情報を収集するには、直接挿入を使用することをお薦めします。詳細は、第9.1.1項「使用状況トラッキングの情報を収集するための直接挿入の設定」を参照してください。

次の項では、使用状況トラッキングのログ・ファイル収集を構成する方法について説明します。ログ・ファイル・パラメータを構成する前に、NQSConfig.INIファイルの使用状況トラッキング・セクションでENABLEパラメータをYESに設定して、使用状況トラッキングを有効にする必要があります。使用状況トラッキングの構成パラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。

この項の項目は次のとおりです。

9.1.2.1 出力場所の選択

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は、指定の場所に存在する使用状況トラッキング・ログ・ファイルのサイズや数量に制限を設けていません。自分で十分な領域が使用可能であることを確認し、古い使用状況トラッキング・ファイルを削除またはアーカイブする必要があります。


注意:

記憶域が十分でないと、使用状況トラッキング・データが失われる可能性があります。BI Serverで使用状況トラッキング出力ファイルのアクセス中にエラーが発生すると、使用状況トラッキング統計の収集が即時に中止され、nqserver.logと、Windows上のWindowsイベント・ログにエラー・メッセージが送信されます。追加の記憶域が使用可能になっても、サーバーが再起動されるまで、使用状況トラッキング統計の収集は再開されません。

9.1.2.2 ファイル・ネーミング規則

使用状況トラッキング・ログ・ファイルのファイル名の形式はNQAcct.yyyymmdd.hhmmss.logで、yyyyはファイルが作成されたタイムスタンプの年、mmは月、ddは日、hhは時間、mmは分、ssは秒を表します。たとえば、使用状況トラッキング・ログ・ファイルが2010年2月12日07:15:00 a.m.に作成された場合、ファイル名はNQAcct.20100212.071500.logです。指定のロールオーバー間隔の後、このファイルはディスクにフラッシュされて閉じ、現在の日付とタイムスタンプに基づく新しいログ・ファイルが作成されます。

9.1.2.3 出力ファイルの形式

使用状況トラッキング・ログ・ファイルは、セミコロン( ; )で区切られた形式のテキスト・ファイルです。論理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形式)。

9.1.2.4 パフォーマンスに関する考慮事項

使用状況トラッキングが有効な場合、BI Serverはすべての問合せについて使用状況トラッキング・データを収集します。しかし、このデータは、チェックポイントと呼ばれるユーザー指定の間隔でのみディスクに書き込まれます。デフォルト設定では、チェックポイントは5分ごとです。

NQSConfig.INIファイル内でこの値を変更できますが、間隔を短くするとオーバーヘッドが増し、値をあまり小さくすると、サーバーのパフォーマンスに影響する可能性があります。大きな値に設定すると、BI Serverが万一異常停止したときに失われる使用状況トラッキング・データの量が多くなります。

BI Serverは、使用状況トラッキング・ファイルのロールオーバーを定期的に開始します。ロールオーバーは、現在の使用状況トラッキング・ログ・ファイルを閉じ、後続のデータを書き込むための新しいファイルを作成して開くことで行われます。ロールオーバーが発生する頻度を、ロールオーバー間隔と言います。デフォルトのロールオーバー間隔は240分(4時間ごと)です。

閉じられた使用状況トラッキング・ログ・ファイルは、分析で使用できます。ロールオーバー間隔を短くすると、使用状況トラッキング・ログ・ファイルを分析ですぐに使用できますが、余分なオーバーヘッドがかかります。

チェックポイント間隔がロールオーバー間隔以上の場合は、ロールオーバーのみが明示的に発生します。古い使用状況トラッキング・ログ・ファイルが閉じられた場合のみ、チェックポイントが暗黙で発生します。

9.2 使用状況トラッキング・データの説明

表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)です。

バックエンド・データベースからのエラー・メッセージです。この列は、SUCCESS_FLG(詳細は、この表の後述のエントリを参照)が0(ゼロ)以外の値に設定されている場合のみ適用されます。複数のメッセージは連結され、BI Serverによって解析されません。

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を使用している場合はntextで、ORACLE、DB2またはTERRADATAデータベースを使用している場合はCLOBです。

論理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

次のリストで定義される、問合せの完了ステータスです。

  • 0 - 問合せがエラーを発生せずに正常終了しました。

  • 1 - 問合せがタイムアウトしました。

  • 2 = 行制限を越えたために問合せが失敗しました。

  • 3 = その他の理由で問合せが失敗しました。

TOTAL_TIME_SEC

クライアントが分析へのレスポンスを待機している間に、BI Serverが問合せの処理に要した時間(秒単位)です。この設定は、第8.4.1.1項「問合せのロギング・レベルの設定」で説明されている、nqquery.logファイル内のレスポンス時間と同じです。

USER_NAME

問合せを発行したユーザーの名前です。