プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド
12c (12.2.1.1.0)
E77226-02
目次へ移動
目次

前
前へ
次
次へ

問合せログの管理

Oracle BIサーバーには、問合せアクティビティを個々のユーザー・レベルでロギングする機能があります。ロギングは、品質保証テスト、デバッグおよびOracleサポート・サービスによるトラブルシューティングで使用します。本番モードでは、通常、問合せロギングは無効にされています。

問合せログ・ファイルの名前はnqquery.logで、次の場所にあります。

BI_DOMAIN/servers/obisn/logs

Oracle BIサーバーの問合せロギングはユーザー・レベルで追跡されます。ユーザー・コミュニティ全体を追跡すると、リソースが集中的に使用されます。

注意:

本番システムでは、ターゲットを絞ったユーザー・コミュニティのみを対象に問合せロギングを有効にすることをお薦めします。本番システムでは、使用状況トラッキングを本番レベルのロギング機能として使用できます。詳細は、「使用状況トラッキングの管理」を参照してください。

ユーザー名が明らかにテスト・ユーザーを示しており、問合せロギングが有効であることが確認されている場合のみ、ユーザーをテストしてください。このようなユーザーのロギングが有効な場合、ユーザーにはsales_admin_with_logging、sales_dev_with_logging、sales_test_with_loggingなどの名前を付けることが推奨されているため、ユーザーを簡単に識別できます。なお、本番の管理者ログインは、使用可能なリソースに負担がかかるため、問合せロギングを有効にしないでください。

次のものについても、問合せロギングを無効にします。

この項では、次の項目について説明します。

問合せロギングの構成

この項では、問合せログのサイズの設定、ロギング・レベルの選択およびユーザーの問合せログの有効化について説明します。

問合せロギングによって非常に大きなログ・ファイルが作成されるため、デフォルトでは、ロギング・システムは無効化されています。ロギングを有効にすることで、リポジトリが正しく構成されているかどうかのテスト、システム上でのアクティビティの監視、パフォーマンスの問題の解決またはOracleサポート・サービスの支援が可能となります。ロギングが必要なユーザーごとに、システム上の問合せロギングを有効にする必要があります。そのためには、Oracle BI管理ツールを使用します。

問合せロギング・レベルの設定

収集されるデータ問合せログの量をユーザーごとに構成できます。

ユーザーの問合せロギング・レベルの設定の説明に従って、個々のユーザーの問合せロギング・レベルを有効にできます。グループのロギング・レベルは構成できません。

特定のユーザーのロギング・レベルは、セッション変数によって上書きされます。たとえば、管理者のロギング・レベルが4で、セッション変数のロギング・レベルがリポジトリ内でデフォルト0(ゼロ)と定義される場合、管理者のロギング・レベルは0になります。

ロギング・レベルは、組織に適したロギングの量に基づいて設定します。一般の操作の場合、通常、ロギングは無効です(ロギング・レベルは0に設定されています)。ロギングを有効にする場合は、1または2のロギング・レベルを選択します。この2つのレベルは、管理者による使用を目的としています。

問合せの一時的なログ・レベルを設定することで、パフォーマンスやデータの問題を診断できます。Oracle BIプレゼンテーション・サービスの「詳細設定」タブで、「高度なSQL句」セクションに接頭辞句を追加することで、SELECT文の問合せロギングを有効にできます。SELECT文の例を次に示します。

SELECT year, product, sum(revenue) FROM time, products, facts; 

接頭辞」フィールドで、次のようにロギング・レベル5を指定できます。

Set Variable LOGLEVEL=5;

この問合せでは、基礎となるLOGLEVEL変数の値にかかわらず、ロギング・レベル5が使用されます。

注意:

3以上のロギング・レベルは、Oracleサポート・サービスの支援を受ける場合のみ使用してください。

次の表は、問合せロギング・レベルを示しています。

ロギング・レベル 記録される情報

レベル0

ロギングは行われません。

レベル1

クライアント・アプリケーションから発行されたSQL文が記録されます。次のものも記録されます。

  • 物理問合せのレスポンス時間 - バックエンド・データベースで問合せが処理されるのにかかった時間。

  • 物理問合せの数 - バックエンド・データベースで処理された問合せの数。

  • 累積時間 - リクエストに関するすべての物理問合せの合計時間(すべてのバックエンド・データベース処理時間とDB接続時間の合計)。

  • DB接続時間 - バックエンド・データベースへの接続にかかった時間。

  • 問合せキャッシュの処理 - キャッシュからの論理問合せの処理にかかった時間。

  • 経過時間 - プレゼンテーション・サービスに論理問合せが発行されてからユーザーに結果が返されるまでに経過した時間。経過時間には、プレゼンテーション・サービスに論理問合せが発行されてから論理問合せの準備が開始されるまでにかかるわずかな時間も含まれるため、レスポンス時間より短くなることはありません。この時間の差が非常に短い場合は、経過時間とレスポンス時間は等しくなります。

  • レスポンス時間 - 論理問合せの準備、実行および最新レコードのフェッチにかかった時間。これは、「使用状況トラッキング・データの説明」に記載されているように、使用状況トラッキングで記録されるTOTAL_TIME_SECに一致します。

  • コンパイル時間 - 論理問合せのコンパイルにかかった時間。

  • 各問合せについて、問合せのステータス(成功、失敗、終了またはタイムアウト)、ユーザーID、セッションIDおよびリクエストIDが記録されます。

  • BIサーバーの合計時間 — 問合せ実行のみにBIサーバーで要した時間(つまり、コンパイル時間でない)。

レベル2

レベル1で記録されるすべてのものが記録されます。

加えて、各問合せについて、リポジトリ名、ビジネス・モデル名、サブジェクト・エリア名、物理データベースに対して発行されたSQL文、キャッシュに対して発行された問合せ、物理データベースに対する問合せとキャッシュに対して発行された問合せからそれぞれ返された行数、およびクライアント・アプリケーションに返される行数が記録されます。

レベル3

レベル2で記録されるすべてのものが記録されます。

加えて、キャッシュをシードする予定だった問合せがキャッシュに挿入されなかった場合、既存のキャッシュ・エントリを消去して現在の問合せ用の領域を作成する場合、および完全一致のヒット・ディテクタを更新できなかった場合、論理問合せ計画のログ・エントリが追加されます。

Oracleサポート・サービスの支援がない場合は、このレベルを選択しないでください。

レベル4

レベル3で記録されるすべてのものが記録されます。

加えて、問合せ実行計画が記録されます。Oracleサポート・サービスの支援がない場合は、このレベルを選択しないでください。

レベル5

レベル4で記録されるすべてのものが記録されます。

加えて、実行計画内の様々な時点における中間の行数が記録されます。Oracleサポート・サービスの支援がない場合は、このレベルを選択しないでください。

レベル6および7

使用されません。

ユーザーの問合せロギング・レベルの設定

ユーザーごとに問合せデータの量を構成できます。

ユーザーの問合せロギング・レベルを設定するには:

  1. Oracle BI管理ツールで、「管理」→「アイデンティティ」を選択します。

    「Identity Manager」ダイアログが表示されます。

  2. 問合せロギング・レベルを設定するユーザーの名前をダブルクリックします。

    「ユーザー」ダイアログが表示されます。

  3. ロギング・レベル」フィールドの横の「」または「」の矢印をクリックして、ロギング・レベルを設定します。

    ユーザーの問合せロギングを無効にするには、ロギング・レベルを0に設定します。

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

ログ・ビューアの使用

問合せログを表示するには、Oracle Business Intelligenceのログ・ビューア・ユーティリティ(またはテキスト・エディタ)を使用します。

問合せログ内の各エントリには、問合せを発行したユーザーの名前、問合せが開始されたセッションのセッションIDおよび個々の問合せのリクエストIDのタグが付けられています。

ログ・ビューア・ユーティリティの実行

ログ・ビューア・ユーティリティを使用すると、特定のログ・ファイルを検索および確認できます。

ログ・ビューア・ユーティリティ(UNIXのORACLE_HOME/bi/bifoundation/server/bin)を実行するには、コマンド・プロンプトを開き、nqlogviewerと引数の組合せを入力します。構文は次のとおりです。

nqlogviewer [-u user_name] [-f log_input_filename]
          [-o output_result_filename]
          [-s session_ID] [-r request_ID]

この構文では:

  • user_nameは、Oracle Business Intelligenceリポジトリ内のユーザーの名前です。このパラメータによって、エントリの範囲が特定のユーザーに限定されます。このパラメータを指定しないと、問合せロギングが有効なすべてのユーザーが表示されます。

  • log_input_filenameは、コンテンツが取得される既存のログ・ファイルの名前です。このパラメータは必須です。

  • output_result_filenameは、ログの出力が保存されるファイルの名前です。ファイルがすでに存在する場合、ファイルに結果が追加されます。ファイルが存在しない場合は、新しいファイルが作成されます。この引数を指定しないと、出力はモニター画面に送信されます。

  • session_IDは、ユーザー・セッションのセッションIDです。BIサーバーでは、セッションの開始時に、各セッションに一意のIDが割り当てられます。このパラメータによって、ログ・エントリの範囲が指定のセッションIDに限定されます。このパラメータを指定しないと、すべてのセッションIDが表示されます。

  • request_IDは、個々の問合せのリクエストIDです。BIサーバーでは、問合せの開始時に、各問合せに一意のIDが割り当てられます。このパラメータによって、ログ・エントリの範囲が指定のリクエストIDに限定されます。このパラメータを指定しないと、すべてのリクエストIDが表示されます。

    リクエストIDはアクティブなリクエスト間で一意ですが、セッションを通じて一意であるとはかぎりません。リクエストIDは循環方式で作成され、リクエストがクローズされたりセッションの実行に長時間かかったりする場合には、リクエストIDが再利用されます。

セッション・マネージャを通じてユーザー名、セッションIDおよびリクエストIDを見つけることもできます。詳細は、『Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。

管理者は、プレゼンテーション・サービスの「管理」ページの「セッションの管理」オプションを使用して、問合せログを表示できます。

ログ・レコードの解析

いくつかの問合せ情報を記録し、ログ・ビューアを起動すると、ログを分析できます。レベル1および2のログ・エントリは、通常、自明です。

ログ・エントリは、基礎となるデータベースを担当するデータベース管理者(DBA)が、データベースを調整して最適な問合せパフォーマンスを実現するうえでの手がかりになります。問合せログは、BIサーバーを使用するアプリケーションの精度の確認にも役立ちます。

ログは、次のセクションに分かれています。

  • SQLリクエスト - このセクションには、クライアント・アプリケーションから発行されたSQL文が示されます。この情報を使用して、同じアプリケーションまたは別のアプリケーションから問合せを再実行できます。

  • 一般の問合せ情報 - このセクションには、リポジトリ、ビジネス・モデル、および問合せが実行されたサブジェクト領域が示されます。この情報は、今後のアプリケーション開発やシステム管理における優先順位を設定するために使用可能な、問合せの使用状況に関する統計を収集する目的で使用できます。

  • データベース問合せ - このセクションは、"Sending query to the database named <data_source_name>"というエントリで開始します(ここで、<data_source_name>は、BIサーバーが接続しているデータソースの名前です)。複数のデータベース問合せを1つ以上のデータソースに送信できます。各問合せはログ内の1つのエントリに相当します。

    データベース問合せセクションには、基礎となるデータベースに送信されたSQL文の記録など、様々な用途があります。記録されたこのSQL文を使用してデータベースに対して問合せを直接実行することで、パフォーマンス・チューニング、結果の検証またはその他のテストを行うことができます。この情報を使用して、問合せを受けている表を調べて、集計ナビゲーションが予測どおりに動作していることを確認することもできます。基礎となるデータベースの構造を理解している場合は、効果的な集計表や索引の構築など、パフォーマンス向上の手がかりにもなります。

  • 問合せのステータス - ログ内の問合せ成功のエントリは、問合せが正常終了したか失敗したかを示します。失敗した問合せをログで検索して、失敗の原因を判断できます。たとえば、特定の時間帯のすべての問合せが、データベースの停止時間が原因で失敗することがあります。