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

8 Oracle Business Intelligenceの問題の診断および解決

この章では、Fusion Middleware Controlやログ・ファイルなどのツールを使用してOracle Business Intelligenceの問題を診断および解決する方法について説明します。

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

8.1 使用可能な診断ツール

Oracle Business Intelligenceには、表8-1に示されているとおり、問題の原因と解決策を見つけるのに役立つ様々な診断ツールが用意されています。

表8-1 診断ツール

ツール 説明 参照先

Fusion Middleware Controlの「概要」ページ

システムに関する最近の問題を表示できます。

第2.2.3項「Oracle Business Intelligenceシステム・コンポーネントを管理するためのFusion Middleware Controlの使用」

パフォーマンス・メトリック

パフォーマンスに影響を及ぼすメトリックを表示できます。

第7.1項「サービス・レベルの監視」

Fusion Middleware Controlの「診断」ページ

問題を深く調べてログ・ファイルを表示および構成できます。

第8.2.1項「ログ情報、エラー・メッセージおよびアラートを表示するためのFusion Middleware Controlの使用」

第8.2.2.1項「ログ・ファイルのローテーション・ポリシーを構成しログ・レベルを指定するためのFusion Middleware Controlの使用」

使用状況トラッキング

データベースの最適化、集計の戦略、ユーザーや部門が利用したリソースに基づく課金など、様々な方法で利用できる使用状況トラッキングの統計情報を生成できます。

第9.1項「使用状況トラッキングについて」

カタログ・オブジェクトのレポート

Oracle BIプレゼンテーション・カタログのオブジェクトの詳細を知ることができます。

第17.9項「カタログ・マネージャを使用したカタログ・データを表示するためのレポートの作成」

整合性チェック・マネージャ

リポジトリの有効性をチェックできます。

『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリまたはビジネス・モデルの整合性のチェックに関する項

モデル・チェック・マネージャ

Oracle BI Summary Advisorおよび集計の永続性エンジンに影響を及ぼす可能性のある問題のモデルについてチェックできます。

『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のモデル・チェック・マネージャを使用した問題のモデルについてのチェックに関する項

ODBC/JDBCプロシージャ

Oracle BIサーバーに関する診断情報を取得できます。

第8.6項「ODBC/JDBCプロシージャを使用したOracle BIサーバーの診断の取得」

8.2 診断ログ・ファイルの表示と構成

次の項で説明するように、診断ログ・ファイルを表示したり、診断ログ・ファイルおよびファイル内の情報に影響する設定を構成したりできます。

8.2.1 ログ情報、エラー・メッセージおよびアラートを表示するためのFusion Middleware Controlの使用

Fusion Middleware Controlログ・ビューアを使用して、Oracle Business Intelligenceコンポーネントのログ・エントリを検索して表示できます。ログ・ファイルを検索するとログ・メッセージが見つかり、たとえば、特定の日付範囲、ユーザー、ユーザー・トランザクションまたはメッセージのレベル(エラー、警告、通知など)をターゲットとするフィルタを適用できます。Fusion Middleware Controlログ・ビューアから、ログ・ファイル全体を表示することもできます。

エラー・メッセージと警告のログ・エントリが複数のログ・ファイルにまたがって生成される場合、その追跡は困難です。しかし、複数のログ・ファイルにわたる特定のユーザー・トランザクションのログ情報を表示することが可能です。トランザクション・レベルのロギングでは、実行コンテキストID(ECID)と呼ばれる一意のトランザクションIDを、ユーザー・リクエストに応答して生成されるすべてのログおよびエラー・メッセージに関連付けています。このロギングによって、基となる問題の原因を迅速に診断できます。ただし、ログ内のメッセージによっては(たとえば、サーバーの起動や停止のシステム・メッセージ)、トランザクション属性を持ちません。クライアント・リクエストに関連するすべてのログ・メッセージは、トランザクション属性を持ちます。

この手順を始める前に、第3.2項「Oracle Business Intelligenceの構成設定を更新するためのFusion Middleware Controlの使用」で説明している情報について確認しておいてください。

Fusion Middleware Controlを使用してログ情報、エラー・メッセージおよびアラートを表示するには:

  1. Business Intelligenceの「概要」ページに移動します。詳細は、第2.2.3項「Oracle Business Intelligenceシステム・コンポーネントを管理するためのFusion Middleware Controlの使用」を参照してください。

  2. 「診断」ページの「ログ・メッセージ」タブを表示します。

    この要素のページレベルのヘルプにアクセスするには、ページの「ヘルプ」ボタンをクリックします。

  3. 次のリストを表示します。

    • 「最新のエラー」領域の最新のエラー

    • 「最新の警告」領域の最新の警告

  4. すべてのログ・ファイルの表示/検索およびコンポーネント別のログ・ファイルの表示/検索の下のリンクを選択して、すべてのログ・ファイルのメッセージまたは指定されたコンポーネントのログ・ファイルのメッセージを表示します。次のリンクのページレベル・ヘルプにアクセスするには、ページの「ヘルプ」ボタンをクリックします。

    • ログ・ビューアを使用するログ・ファイルの検索

    • プレゼンテーション・サービス・ログ

    • サーバー・ログ

    • スケジューラ・ログ

    • JavaHostログ

    • クラスタ・コントローラ・ログ

    • アクション・サービス・ログ

    • セキュリティ・サービス・ログ

    • 管理者サービス・ログ

    Fusion Middleware Controlでは、選択に応じた「ログ・メッセージ」ページにメッセージが表示されます。

  5. 適切な検索基準を入力して、対応するエラー・メッセージを表示します。

    メッセージをECID別に表示するには、「関連メッセージの表示」をクリックし、「ECID(実行コンテキストID)ごと」を選択します。

  6. 1つ以上の行を選択して、選択されているメッセージのログ・ファイル・エントリの詳細を表示します。

    ログ・ビューアに表示される要素の詳細は、Fusion Middlewareのヘルプを参照してください。

8.2.2 ログ・ファイルのローテーション・ポリシーの構成とログ・レベルの指定

ログ・ファイルのサイズと経過時間に基づいて、新しいログ・ファイルを作成する必要があるタイミングを決定する基準を構成できます。ログ・ファイルに保存するメッセージのレベルを決定するログ・レベルも指定できます。

この項には次のトピックが含まれます:

Oracle BI Systems Management APIのメソッドを使用した構成設定の変更の詳細は、第23章「Oracle BI Systems Management APIの概要」を参照してください。

8.2.2.1 ログ・ファイルのローテーション・ポリシーを構成しログ・レベルを指定するためのFusion Middleware Controlの使用

この手順を始める前に、第3.2項「Oracle Business Intelligenceの構成設定を更新するためのFusion Middleware Controlの使用」で説明している情報について確認しておいてください。

Fusion Middleware Controlを使用して、ログ・ファイルのローテーション・ポリシーを構成し、ログ・レベルを指定するには:

  1. Business Intelligenceの「概要」ページに移動します。詳細は、第2.2.3項「Oracle Business Intelligenceシステム・コンポーネントを管理するためのFusion Middleware Controlの使用」を参照してください。

  2. 「診断」ページの「ログ構成」タブを表示します。

  3. 「構成をロックして編集」をクリックして、変更を実行できるようにします。

  4. このページのヘルプ・トピックの説明を参照して、各要素を設定します。

    たとえば、使用するログ・レベルを指定したり、場合によってはその粒度を設定したりできます。

    次のオプションのページレベル・ヘルプにアクセスするには、ページの「ヘルプ」ボタンをクリックします。

    ログ構成

    • 「最大ファイル・サイズ」オプション

    • 「ログの最長保存期間」オプション

    問合せログ

    • 「最大ファイル・サイズ」オプション

    • 「ログの最長保存期間」オプション

    デフォルト・ログ・レベル

    コンポーネント固有のログ・レベル

  5. 「適用」をクリックしてから、「変更のアクティブ化」をクリックします。

  6. Business Intelligenceの「概要」ページに戻り、「再起動」をクリックします。

8.2.2.2 追加のログ・ファイル設定の手動での変更

Fusion Middleware Controlで変更できるログ・ファイル設定に加えて、手動で変更できる設定もあります。コンポーネントのログ構成ファイル内の様々な要素を使用して、その設定を変更します。


注意:

変更が後で上書きされる可能性があるため、1つのコンポーネントの診断ログ構成ファイルを編集することはしないでください。詳細は、第3.4項「構成設定を更新するためのテキスト・エディタの使用」を参照してください。

この手順を開始する前に、第3.4項「構成設定を更新するためのテキスト・エディタの使用」の情報を理解しておく必要があります。

ログ・ファイル形式を構成する設定を手動で変更するには:

  1. 第8.3.2項「診断ログ構成ファイルの概要とその位置」の説明に従って、コンポーネントのログ構成ファイルを開きます。

  2. ログ・ファイル形式を指定するFormat要素を追加する必要があるセクションを見つけます。デフォルトはODL-TEXTです。

    Fusion Middleware Controlログ・ビューアを使用してOracle Business Intelligenceのログ・ファイルを表示および検索するには、ファイルがODL-Text形式またはODL-XML形式である必要があります。

  3. 次の例に示すように、必要な要素とその祖先要素を追加します。

    <server>
   <ServerInstance>
      <Log>
         <Format>ODL-TEXT</Format>
      </Log>
   </ServerInstance>
</server>

    JavaHostサーバー診断ログ構成ファイルの例は、例8-2を参照してください。

  4. 変更内容を保存し、ファイルを閉じます。

  5. Oracle Business Intelligenceを再起動します。

8.2.3 ログ・ビューアを使用した問題の診断

Fusion Middleware Controlのログ・ビューアを使用して、Oracle Business Intelligenceシステムでの問題の解決に役立つ可能性があるメッセージを探すことができます。

ログ・ビューアを使用して問題を診断するには:

  1. Fusion Middleware Controlが表示されます。

  2. bifoundationドメインを右クリックして、「ログ」、「ログ・メッセージの表示」を選択します。

    「ログ・メッセージ」ページが表示されます。ログ・ビューアがすべてのログ・ファイルから行を収集し、このページに表示します。行をフィルタして、関心のあるものを表示できます。

  3. リストのフィルタを開始するには、検索基準を入力して関心のあるメッセージを探します。

    • 特定の日付の前後にエラーが発生したことがわかっている場合は、「日付範囲」を「時間間隔」に設定します。フィルタの開始および終了の日付を選択します。

    • エラーが繰り返し発生している場合は、「日付範囲」を「最新」に設定します。「日」を選択して、1や3などの数字を指定します。

    • 「メッセージ・タイプ」には、次の「インシデント・エラー」、「エラー」、「警告」および「通知」を選択します。返されるメッセージの数が多すぎる場合は、「通知」を選択解除して、エラーと警告のみを表示します。

      「通知」を選択する利点は、Oracle Business Intelligenceシステムの動作内容がわかることで、異常が発生したのがいつかを特定するのに役立てることができます。

  4. Oracle Business Intelligenceのメッセージをフィルタするには、次のようにします。

    1. 「フィールドの追加」をクリックし、「モジュール」を選択して、「追加」をクリックします。

    2. 「モジュール」が「次を含む」に設定されていることを確認して、次の値を入力します。

      oracle.bi.management

      この値は、Oracle Business Intelligenceのシステム管理のためのすべてのログ・エントリが由来するJavaパッケージの名前を指定します。

  5. 「検索」をクリックします。

    このページには、診断中の問題に関係するエラーおよび警告を含め、条件に合うすべてのログ・メッセージがリストされます。

  6. ログ・メッセージのコピーを保存するには、「メッセージをファイルにエクスポート」をクリックし、「Oracle診断ログ・テキスト(.txt)として」または必要に応じてその他の形式を選択します。

ログ・メッセージを表示すると、「メッセージ」列に、何の操作がいつ行われたかが表示されます。いつサーバーが再起動されたか、構成の変更が行われたかなど、重要な情報を知ることができます。「ログ・ファイル」列の値を使用すると、書込み先のファイルがわかり、Oracle Business Intelligenceの動作の手がかりとなります。たとえば、nqserver.logの値はOracle BIサーバーとの相互作用を示し、sawlog5.logの値はプレゼンテーション・サービスとの相互作用を示します。

ログ・メッセージを表示して、何が特定の状況の原因となったかを確認できます。たとえば、Fusion Middleware Controlで別のリポジトリを指定するという変更を行ったのに、プレゼンテーション・サービスではそのリポジトリを表示できないとします。ログ・メッセージを表示すると、管理対象サーバーをホストし、新規リポジトリのコピー先となるコンピュータのメモリーが不足していることを示すエラー・メッセージが見つかります。先のエラー・メッセージは、管理サーバーがリポジトリの変更をレポートし、その変更を管理対象サーバーに同期しようとしたことを示します。

8.3 診断ログ・ファイルとログ構成ファイルについて

この項では、診断ログ・ファイルと診断ログ構成ファイルについて説明します。内容は次のとおりです。

8.3.1 診断ログ・ファイルの概要とその位置

診断ログ・ファイルは、Oracle Business Intelligence Serverによって生成されるメッセージ情報を格納するためのファイルです。これらのログ・ファイルは、次の場所に保存されています。

ORACLE_INSTANCE\diagnostics\logs\component_type\coreapplication

Oracle Business Intelligenceでは、次の診断ログ・ファイルが使用されます。

  • プレゼンテーション・サービス

    • \CatalogCrawler\sawcatalogcrawlerlogsysn.log - カタログ・クローラのログ・ファイル。Fusion Middleware Controlログ・ビューアで検索できません。

    • sawlogn.log - 診断ログ出力の最新部分に相当し、Fusion Middleware Controlログ・ビューアで検索できる、プレゼンテーション・サービスのログ・ファイル。

    プレゼンテーション・サービスのロギングの詳細は、第8.5項「Oracle BIプレゼンテーション・サービスのロギング」を参照してください。

  • Oracle BIサーバー

    • nqquery<n>.log - Oracle BIサーバー問合せログ。Fusion Middleware Controlログ・ビューアで検索できません。

      <n> = 日付とタイムスタンプ(例: nqquery-20101209-2135.log)

    • nqserver<n>.log - Oracle BIサーバー・メイン診断ログ。Fusion Middleware Controlログ・ビューアで検索できます。

      <n> = 日付とタイムスタンプ(例: nqserver-20101209-2135.log)

    • nqsadmintool.log - Oracle BI管理ツールのログ。

    • Oracle BIサーバー・ユーティリティ - たとえば、biserverxmlexecやequalizerpdsも、実行時に独自のログを生成します。

  • JavaHost

    • jh-n.log - JavaHost Serverのメイン診断ログ。Fusion Middleware Controlログ・ビューアで検索できます。

      <n> = 日付とタイムスタンプ(例: jh-20100909-2135.log)

  • Oracle BIスケジューラ

    • nqscheduler-<n>.log - Oracle BIスケジューラのログ・ファイル。Fusion Middleware Controlログ・ビューアで検索できます。

      <n> = 日付とタイムスタンプ(例: nqscheduler-20100909-2135.log)

  • クラスタ・コントローラ

    • nqcluster-yyyyMMdd-hhmm.log - Oracle BIクラスタ・コントローラの診断ファイル。Fusion Middleware Controlログ・ビューアで検索できます。

      <n> = 日付とタイムスタンプ(例: nqcluster-20100909-2135.log)

  • BI JEEログ(アクション・サービスおよびセキュリティ・サービス)。次のログ・ファイルは両方とも、Fusion Middleware Controlログ・ビューアで検索できます。

    • AdminServer-diagnostic.log

    • bi_server1-diagnostic.log

  • アップグレード

    Oracle Business Intelligenceのアップグレードのログ・ファイルは、次の場所に作成されます。

    ORACLE_HOME\upgrade\logs

    アップグレード・ログ・ファイルの詳細は、Oracle Fusion Middleware Oracle Business Intelligenceアップグレード・ガイドを参照してください。これらのファイルは、Fusion Middleware Controlログ・ビューアで検索できません。


注意:

ログ・ファイルnqcluster-yyyyMMdd-hhmm.log、nqscheduler-<n>.logおよびnqserver<n>.logについては、ファイルにログ記録されるメッセージにタイムゾーンを設定できません。メッセージは、グリニッジ標準時(GMT)でファイルにログ記録されます。Fusion Middleware Controlログ・ビューアでメッセージを表示する際は、ローカルのタイムゾーンでメッセージが表示されます。

8.3.2 診断ログ構成ファイルの概要とその位置

診断ログ構成ファイルは、Oracle Business Intelligenceの診断ログ・ファイルへの出力を制御します。


注意:

変更が後で上書きされる可能性があるため、1つのコンポーネントの診断ログ構成ファイルを編集することはしないでください。詳細は、第3.4項「構成設定を更新するためのテキスト・エディタの使用」を参照してください。

Oracle Business Intelligenceのログ構成ファイルは、次の場所に保存されています。

ORACLE_INSTANCE\config\component_type\bi_component_name

例:

  • \OPMN\opmn\opmn.xml

  • \OracleBIClusterControllerComponent\coreapplication_obiccs1\ccslogconfig.xml

  • \OracleBIJavaHostComponent\coreapplication_obijh1\logging_config.xml

  • \OracleBIPresentationServicesComponent\coreapplication_obips1\instanceconfig.xml

  • \OracleBISchedulerComponent\coreapplication_obisch1\instanceconfig.xml

  • \OracleBIServerComponent\coreapplication_obis1\logconfig.xml

診断ログ構成ファイルの形式について

診断ログ構成ファイルは、見かけは多少異なる場合がありますが、ODL(Oracle Diagnostic Log)標準に準拠します。

例8-1と例8-2は、Oracle Business Intelligenceの2つのログ構成ファイルを示しています。

例8-1 BIサーバー診断ログ構成ファイルの形式

<server>
   <ServerInstance>
      <Log>
         <MaximumFileSizeKb>10000</MaximumFileSizeKb>
         <MaximumLogAgeDay>60</MaximumLogAgeDay>
         <Format>ODL-TEXT</Format>
            <Level>
               <IncidentError>1</IncidentError>
               <Error>1</Error>
               <Warning>16</Warning>
               <Notification>1</Notification>
               <Trace>16</Trace>
            </Level>
      </Log>
      <UserLog>
         <MaximumFileSizeKb>10000</MaximumFileSizeKb>
         <MaximumLogAgeDay>10</MaximumLogAgeDay>
         <Format>ODL-TEXT</Format>
      </UserLog>
   </ServerInstance>
</server>

例8-2 JavaHost Server診断ログ構成ファイルの形式

<?xml version = '1.0' encoding = 'utf-8'?>
<logging_configuration>
   <log_handlers>
      <log_handler name='odl-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
      <property name='path' value='C:\oracle_bi_ee_BIFNDNPTPSNT0911060426S-Release\jhlogs\javahost.log'/>
      <property name='maxFileSize' value='1000000'/>
      <property name='maxLogSize' value='5000000'/>
      </log_handler>
   </log_handlers>
   <loggers>
      <logger name='saw' level='NOTIFICATION:1' useParentHandlers='false'>         <handler name='odl-handler'/>
      </logger>
   </loggers>
</logging_configuration>

Oracle Business Intelligenceコンポーネントは、ログ構成ファイル内のサーバー固有の設定を使用して、診断ログ・ファイルを制御します。例:

  • Oracle BIプレゼンテーション・サービス・ログ構成ファイル

    - writerClassId設定によって、sawlog.logファイルに書き込まれるメッセージが構成されます。

  • Oracle BIサーバー・ログ構成ファイル

    - Log設定によって、nqserver.logファイルに書き込まれるメッセージが構成されます。

    詳細は、第8.3.5項「システム・ログ内のメッセージ」を参照してください。

    - UserLog設定によって、nqquery.logファイルに書き込まれるメッセージが構成されます。

    詳細は、第8.4項「問合せログの管理」を参照してください。

  • Oracle BIスケジューラ・ログ構成ファイル

    - Log設定によって、nqscheduler.logファイルに書き込まれるメッセージが構成されます。

  • JavaHost Serverログ構成ファイル

    - log_handlers要素とサブ要素では、ログ・ファイルのローテーション・ポリシーを構成してログ・ファイル名とその位置を指定できます。

    - loggers要素とサブ要素では、JavaHost Serverログ・レベルを標準のODL(Oracle Diagnostic Log)ログ・レベルにマップすることによって、Javaコンポーネント(JavaHost Server)のログ・レベルを適切に処理できます。

8.3.3 ログ・ファイル・メッセージのカテゴリとレベルの概要

ログ・ファイル・メッセージのカテゴリとレベルによって、ログ・ファイルに書き込まれるメッセージの詳細度と重要度のレベルが決まります。Fusion Middleware Controlを使用すると、logconfig.xmlファイル内のこれらの設定を制御できます。

Oracle Business Intelligenceのログ・ファイル内の各メッセージ・カテゴリは、1 - 32の間の固有のデフォルト値に設定されており、ログ・レベル以下のレベルのメッセージのみが記録されます。

表8-2は、ログ・ファイル・メッセージのカテゴリを示しています。

表8-2 ログ・ファイル・メッセージのカテゴリ・レベル

カテゴリ:レベル 説明

IncidentError:1

原因不明の重大な問題が発生しました。問題を解決するには、Oracleサポート・サービスに問い合せてください。

パフォーマンスには影響ありません。

Error:1

システム管理者による対応が必要な問題が発生しました。

パフォーマンスには影響ありません。

Warning:1

エラーの発生を回避するための確認を必要とし、場合によっては対応が必要となる処理が実行されたか、状況が検出されました。

パフォーマンスには影響ありません。

Notification:1

通常のアクションまたはイベントのレポートが発生しました。ログイン完了などのユーザー操作や、ログ・ファイルのローテーションなどの自動操作です。

パフォーマンスには影響ありません。

Notification:16

構成関連のメッセージが生成されたか、問題が発生しました。

パフォーマンスへの影響はわずかです。本番環境でこのレベルを広範囲にわたって有効にしても、ソフトウェアのパフォーマンスに大きな影響はありません。

Trace:1

デバッグやパフォーマンス監視に使用されるトレースまたはデバッグ・メッセージが書き込まれました。通常、このメッセージには詳細なイベント・データが含まれており、内部の実装の詳細がわからなくても理解できます。

パフォーマンスに少し影響します。このレベルは、ソフトウェアに関する問題をデバッグするために、本番環境で広範囲にわたって有効にすることもできます。このレベルのロギングを有効にすると、パフォーマンスに少し影響する場合がありますが、ソフトウェアが使用できなくなるほどではありません。

Trace:16

かなり詳細なトレースまたはデバッグ・メッセージが書き込まれました。メッセージは明確に記述されており、製品に関する豊富な知識を持つOracleサポート・サービスの技術者であれば、内部の実装の詳細を完全に把握していなくても理解できます。

パフォーマンスに大きく影響します。このレベルは、ソフトウェアの問題をデバッグする特別な状況を除いて、本番環境では有効にしないでください。

Trace:32

非常に詳細なトレースまたはデバッグ・メッセージが書き込まれました。このソフトウェアを使用し、メッセージを生成するサブシステムの実装の詳細を十分に把握しているOracle開発者を対象としています。

パフォーマンスに非常に大きな影響があります。このレベルは本番環境では有効にしないでください。開発者がテスト環境または開発環境でこのソフトウェアをデバッグするときのみ使用してください。

次のログ構成ファイルの例の場合、Notificationメッセージ・カテゴリではレベル1のメッセージのみが記録されます。ログ・レベルが0に設定されている場合、そのメッセージ・カテゴリでは何も記録されません。

   <Level>
      <IncidentError>1</IncidentError>
      <Error>1</Error>
      <Warning>1</Warning>
      <Notification>1</Notification>
      <Trace>1</Trace>
    </Level>

ログ・ファイル内のデフォルト設定を手動で変更することは避けてください。変更する場合は、Fusion Middleware Controlを使用します。詳細は、第8.2.2.1項「ログ・ファイルのローテーション・ポリシーを構成しログ・レベルを指定するためのFusion Middleware Controlの使用」を参照してください。

8.3.4 ログ・ファイル・ローテーション

ログ・ファイル・ローテーションとは、ログ・ファイルが指定されたしきい値や日付を超えたときに新しいログ・ファイルが作成されることを言います。例として、Oracle BIスケジューラのコンポーネント・ログ構成ファイルのMaximumFileSizeKb設定を考えてみましょう。この設定で指定されるサイズをログ・ファイルが超えると、既存のスケジューラ・ログ・ファイルの名前が変更され、新しいログ・ファイルが作成されます。また、MaximumLogAgeDayの設定より古いログ・ファイル日付も削除されます。

Oracle BIコンポーネントはそれぞれ異なるログ・ファイル名を持ち、ログ構成ファイルの設定が異なります。たとえば、スケジューラのファイル・ネーミング規則は次のとおりです。

  • nqscheduler.log - 最新のログ・ファイル。

  • nqscheduler-<n>.log - 名前が変更された、以前のログ・ファイル。

    <n> = 日付とタイムスタンプ(例: nqscheduler-20100909-2135.log)

詳細は、第8.2.2.1項「ログ・ファイルのローテーション・ポリシーを構成しログ・レベルを指定するためのFusion Middleware Controlの使用」を参照してください。

8.3.5 システム・ログ内のメッセージ

Oracle BIサーバーでは、構成設定に基づいてnqserver.logファイルにメッセージが書き込まれます。このログ・ファイルへのメッセージの書込みに加えて、UNIXシステムのシステム・ログ・ファイルに、特定の重大なメッセージも書き込まれます。システム・ログ・ファイルに書き込まれるメッセージの種類は、次のとおりです。

  • BIサーバーが起動できない場合(たとえば、別のサーバーがすでに起動しているため)、システム・ログ・ファイルには次のようなメッセージが書き込まれます。

    @1%lsおよびポート@2%ls上で別のサーバーがすでに実行されています。

  • メモリーの問題が発生した場合、システム・ログ・ファイルには次のようなメッセージが書き込まれます。

    低断片化ヒープを有効にできませんでした。

  • コンピュータのハード・ディスクがいっぱいの場合、システム・ログ・ファイルには次のようなメッセージが書き込まれます。

    ディスクの空き容量不足です。

8.4 問合せログの管理

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

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

ORACLE_INSTANCE\diagnostics\logs\component_type\bi_component_name

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


注意:

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

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

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

この項には次のトピックが含まれます:

8.4.1 問合せロギングの構成

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

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

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

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

特定のユーザーのロギング・レベルは、セッション変数によって上書きされます。たとえば、管理者のロギング・レベルが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サポート・サービスの支援を受ける場合のみ使用してください。

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

表8-3 問合せロギング・レベル

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

レベル0

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

レベル1

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

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

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

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

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

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

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

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

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

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

レベル2

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

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

レベル3

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

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

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

レベル4

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

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

レベル5

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

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

レベル6および7

使用されません。

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

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

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

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

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

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

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

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

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

8.4.2 ログ・ビューアの使用

問合せログを表示するには、Oracle Business Intelligenceのログ・ビューア・ユーティリティ(またはテキスト・エディタ)を使用します。問合せログ内の各エントリには、問合せを発行したユーザーの名前、問合せが開始されたセッションのセッションIDおよび個々の問合せのリクエストIDのタグが付けられています。

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

ログ・ビューア・ユーティリティ(Windowsの\MW_HOME\ORACLE_HOME\bifoundation\server\bin\nqlogviewer.exe)を実行するには、コマンド・プロンプトを開き、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 Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。

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

8.4.2.2 ログ・レコードの解析

いくつかの問合せ情報を記録し、ログ・ビューアを起動すると、ログを分析できます。レベル1および2のログ・エントリは、通常、自明です。ログ・エントリは、基礎となるデータベースを担当するデータベース管理者(DBA)が、データベースを調整して最適な問合せパフォーマンスを実現するうえでの手がかりになります。問合せログは、BIサーバーを使用するアプリケーションの精度の確認にも役立ちます。

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

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

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

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

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

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

8.5 Oracle BIプレゼンテーション・サービスのロギング

この項では、特にプレゼンテーション・サービスにおけるロギングについて説明します。内容は次のとおりです。

Oracle Business Intelligenceのロギングの一般情報は、第8.3項「診断ログ・ファイルとログ構成ファイルについて」を参照してください。

8.5.1 Oracle BIプレゼンテーション・サービスのロギング機能の使用

デフォルトでは、Oracle BIプレゼンテーション・サービスは、すべてのエラー・イベントと、十分な重要性のある情報イベントや警告イベントを記録するように構成されています。サーバーの起動や停止が、重要な情報イベントの例です。ログ・ファイルには、sawlogxx.logという名前が付けられます。xxは、増分する値に置き換えられます。

発生する特定の問題をデバッグするために、ロギング・レベルを増やして、デフォルト構成より多くの情報を記録することができます。たとえば、Oracle BIプレゼンテーション・サービスの特定の接続問題をデバッグする場合は、saw.odbcログ・ソースのみ、最大ロギングを増やすことができます。これにより、このコンポーネントの詳細なロギングが追加されますが、他のイベントによる詳細なロギングでログがいっぱいになることはありません。Oracle BIプレゼンテーション・サービスのすべての構成情報は、instanceconfig.xmlファイルからロードされます。


注意:

ロギングはパフォーマンスに影響するため、特定の問題を診断する場合を除いて、本番実装でロギングを増やさないでください。

8.5.2 Oracle BIプレゼンテーション・サービスのロギング・レベルの設定


注意:

Oracle BIプレゼンテーション・サービスのロギング・レベルを設定する機能は、Oracle BI EE 11.1.1.7.10以降のバージョンには適用されますが、それより前のバージョンでは使用できない場合があります。Oracle BI EE 11.1.1.7.10の詳細は、「11.1.1.7.10の新機能」を参照してください。

プレゼンテーション・サービスの「管理」ページのオプションを使用してロギング・レベルを変更します。

プレゼンテーション・サービスのロギング・レベルを設定するには:

  1. グローバル・ヘッダーで「管理」をクリックします。

  2. 「メンテナンスとトラブルシューティング」領域の「ログ構成の再ロード」で、使用するロギング・レベルを選択します。

  3. 「ログ構成の再ロード」をクリックすると、プレゼンテーション・サービスを再起動しなくても変更を有効にできます。

    プレゼンテーション・サービスを停止して再起動しても、変更は引き続き有効です。

  4. 「セッションの管理」リンクをクリックして「セッションの管理」ページを表示します。

  5. セッションごとに、適切なレベルを表の「ログ・レベル」列に指定します。

    更新後のレベルは、そのセッションに対して即時有効になります。レベルを選択する際、必ず重大度の値をプレゼンテーション・サービスですべてのメッセージに指定されている値以下にします。

8.5.3 Oracle BIプレゼンテーション・サービス構成ファイルの構造

例8-3は、構成ファイルの構造を示しています。各ノードのカーディナリティは大カッコ内に示します。

例8-3 instanceconfig.xmlファイル内のログ・セクションの構造

Logging [1..1]
Writers [0..1]
Writer [0..1]
WriterClassGroups [0..1]
Filters [0..1]
FilterRecord [0..n]

例8-4は、4つのライターを含むinstanceconfig.xmlファイルの例を示しています。

例8-4 4つのライターが含まれるinstanceconfig.xmlファイル

<?xml version="1.0" ?>
<Server>
. . . . . . .
<Logging>
<Writers>
<Writer implementation="FileLogWriter" name="Global File Logger"
writerClassId="1" dir="{%ORACLE_BIPS_INSTANCE_LOGDIR%}" filePrefix="sawlog"
maxFileSizeKb="10000" filesN="10" fmtName="ODL-Text" ODLLogFilePath="{%ORACLE_BIPS_INSTANCE_LOGDIR%}/diagnostic.log"/>
<Writer implementation="CoutWriter" name="Global Output Logger"
writerClassId="2" />
<Writer implementation="EventLogWriter" name="Event Logger"
writerClassId="3" />
<Writer implementation="CrashWriter" name="CrashWriter"
writerClassId="4"
/>
</Writers>
<WriterClassGroups>
<WriterClassGroup name="All">1,2,3,4</WriterClassGroup>
<WriterClassGroup name="File">1</WriterClassGroup>
<WriterClassGroup name="Console">2</WriterClassGroup>
<WriterClassGroup name="EventLog">3</WriterClassGroup>
<WriterClassGroup name="Crash">4</WriterClassGroup>
</WriterClassGroups>
<Filters>
<FilterRecord writerClassGroup="Console" path = "saw" information="1" warning="31" error="31" trace="0" incident_error="32" />
<FilterRecord writerClassGroup="File" path = "saw" information="1" warning="31" error="31" trace="0" incident_error="32" />
<FilterRecord writerClassGroup="File" path="saw.mktgsqlsubsystem.joblog" information="1" warning="2" error="31" trace="0" incident_error="32"/>
<FilterRecord writerClassGroup="File" path="saw.httpserver.request"
information="16" warning="32" error="32" trace="0" incident_error="32"/>
<FilterRecord writerClassGroup="File" path="saw.httpserver.response"
information="16" warning="32" error="32" trace="0" incident_error="32"/>
</Filters>
</Logging>
</Server>

表8-4は、構成階層内の各ノードの説明を示しています。

表8-4 Oracle BIプレゼンテーション・サービス・ログ構成ファイルの要素

要素 属性 説明

Writers

なし

ライター構成が含まれます。

この構成は起動時にロードされます。

Writer

なし

ライターを構成します。

Writer

disableCentralControl

(オプション)このエントリがFusion Middleware Controlによって更新されないように指定します。デフォルト値はtrueです。

Writer

implementation

次の実装が定義されています。

  • FileLogWriter。ディスク・ファイルに書き込みます。

  • CoutWriter。標準出力に書き込みます。

  • EventLogWriter。Windowsイベント・ログまたはUNIX syslogに書き込みます。

  • CrashWriter。Windowsのみの機能で、プレゼンテーション・サービスが特定のソース・ファイルと行番号からのログを試みると、クラッシュ・ダンプ・ファイルに書き込みます。

    ログ記録可能であっても回復可能ではないエラー(たとえば、NQTESTの失敗)に関する情報を得るために、本番環境で使用されます。

    注意: サーバーが不安定な状態になる可能性があるため、この実装の使用には注意が必要です。この実装は、テスト・システムでごくまれに診断目的でのみ使用します。

    WindowsでCrashWriterを使用するには、適切なバージョンのdbghelp.dll(6.0.17.0以上)が必要です。

    適切なdbghelp.dllは、support/windows/system32にあります。

    このDLLをWINNT/system32またはmain/binディレクトリに配置します。

    登録は必要ありません。

Writer

name

ライターの一意の名前です。

Writer

writerClassId

1 - 10の範囲の整数値を指定します。この値は、ロギングを許可または禁止するために、フィルタで使用されます。

個々のライターはそれぞれ一意の値を持つ必要があり、その値が後でフィルタ構成で使用されます。

異なるライターが同じクラスIDを持つこともありますが、その場合、フィルタでそれらのライターを区別することはできません。

Writer

fmtName

(オプション)ログ・メッセージの形式を指定します。有効な値は次のとおりです。

  • デフォルト10gスタイル。識別の見出しを使用してメッセージを書式設定します。

  • ODL-TEXT。Oracle診断テキスト形式でメッセージを書式設定します。

  • ODL-XML。Oracle診断XML形式でメッセージを書式設定します。

この属性を設定しないと、ログ・メッセージはデフォルト形式で表示されます。デフォルト形式は、ファイル・ログ・ライターの場合は10g形式で、コンソールの場合はODL-TEXTです。

例は、第8.5.4項「ログ・メッセージの形式例」を参照してください。

Writer(FileLogWriter固有の属性)

dir

ログ・ファイルが作成されるディレクトリを指定します。

Writer(FileLogWriter固有の属性)

ODLLogFilePath

Fusion Middleware Controlがログ・ビューアに表示するファイルを指定します。

Writer(FileLogWriter固有の属性)

maxFileSizeKb

ログ・ファイルの最大サイズをKB単位で指定します。

ファイル・サイズの上限に達するとファイルは閉じられ、新しいログ・ファイルが作成されます。

Writer(FileLogWriter固有の属性)

filePrefix

ログ・ファイルの接頭辞を指定します。

Writer(FileLogWriter固有の属性)

filesN

ログ・ファイルの最大数を指定します。

この値を超えると、最初のファイルが削除され、再び作成されます。ログ出力が起動し、最初のファイルの先頭に書き込みが実行されます。

Writer(EventLogWriter固有の属性)

winSource

ログに記録されるイベントのイベント・ログ・ソースを指定します。

Writer(CrashWriter固有の属性)

file

ダンプ・ファイル・パスを指定します。

Windowsの場合、ダンプ・ファイルはbin/coredumpsに作成され、プレゼンテーション・サービスは実行を続けます。

Writer(CrashWriter固有の属性)

line

ダンプ・ファイルの行番号です。

WriterClassGroups

なし

ライター・クラスの定義が含まれます。ライター・クラスは、ライター・クラスIDのグループです。

WriterClassGroup(クラスIDのカンマ区切りのリストを子テキストとして含む。)

name

WriterClassGroupの名前を指定します。

Filters

なし

フィルタ構成が含まれます。

FilterRecord

writerClassGroup

このレコードが適用されるライターのグループを指定します。WriterClassGroupは通常、WriterClassGroupsセクションであらかじめ定義されています。

FilterRecord

disableCentralControl

(オプション)このエントリがFusion Middleware Controlによって更新されないように指定します。デフォルト値はtrueです。

FilterRecord

path

ログ・ソース・パスを指定します。SOAP情報のロギングを有効にするには、次の値を入力します。

saw.httpserver.request.soaprequest

現在のフィルタ・レコードは、パスで識別されるソフトウェア・コンポーネントとそのすべてのサブコンポーネントに適用されます。

FilterRecord

情報

対応するメッセージ・タイプの重大度を指定する整数が含まれます。

指定の値より重大度が低いメッセージのみが記録されます。

FilterRecord

警告

対応するメッセージ・タイプの重大度を指定する整数が含まれます。

指定の値より重大度が低いメッセージのみが記録されます。

FilterRecord

エラー

対応するメッセージ・タイプの重大度を指定する整数が含まれます。

指定の値より重大度が低いメッセージのみが記録されます。

FilterRecord

trace

対応するメッセージ・タイプの重大度を指定する整数が含まれます。

指定の値より重大度が低いメッセージのみが記録されます。

FilterRecord

incident_error

対応するメッセージ・タイプの重大度を指定する整数が含まれます。

指定の値より重大度が低いメッセージのみが記録されます。

8.5.4 ログ・メッセージの形式例

Writer要素のfmtName属性により、ログ・メッセージは、デフォルト(10g形式)、ODL-TEXT、ODL-XMLのいずれかの形式になります。これらの形式のエントリの例を、次に示します。

例8-5は、デフォルト形式を示しています。

例8-5 デフォルト形式

デフォルト形式の場合、次のように、識別の見出しを伴うメッセージが生成されます。

Type: Information
Severity: 30
Time: Wed Jul 26 11:22:20 2006
File: project\sawserver\sawserver.cpp
Line: 399
Properties: ThreadID-2552
Location: 
             saw.sawserver
             saw.sawserver.initializesawserver
             saw.sawserver
Oracle BI Presentation Services has started successfully.

例8-6は、ODL-TEXT形式を示しています。

例8-6 ODL-TEXT形式

短縮形式の場合、次のように、識別の見出しを伴わない省略された形式でメッセージが生成されます。

[timestamp] [component id] [messagetype:level] [message-id] [module id] ([field-name: field-value])* message-text [[
supplemental-detail
]]

[2010-05-27T10:51:20.000-07:00] [OBIPS] [NOTIFICATION:1] [] [saw.sawserver] [ecid: 1243446680218334471555761] [tid: 2552] Oracle BI Presentation Services (OBIPS) 11.1.1.2 (Build 0) are starting up.[[
File:sawserver.cpp
Line:432
Location:
   saw.sawserver
   saw.sawserver.initializesawserver
   saw.sawserver
ecid: 1243446680218334471555761 
]]

例8-7は、ODL-XML形式を示しています。

例8-7 ODL-XML形式

xml形式の場合、次のように、XML形式のメッセージが生成されます。

<msg time="2010-05-08T18:41:05.000+00:00" 
comp_id="OBIPS" type="NOTIFICATION" level="1" msg_id="" 
module="saw.sawserver" ecid="124180446517874242628761" tid="127c"> 
<txt> Oracle BI Presentation Services has started successfully</txt> 
<suppl_detail /> 
</msg>

8.5.5 Oracle BIプレゼンテーション・サービス・メッセージの構造

プレゼンテーション・サービスによって記録される各メッセージは、表8-5に示されている様々なコンポーネントで構成されます。

表8-5 プレゼンテーション・サービス・ログ・メッセージのコンポーネント

メッセージ・コンポーネント 説明

メッセージ・テキスト

ユーザーへのログ・メッセージのテキストです。

メッセージ・タイプ

5種類(情報、警告、エラー、インシデント・エラー、トレース)のうちの1つです。

詳細は、表8-2を参照してください。

重大度

重大度は、正の整数で表されます。

値が低くなるほど、メッセージの重大度は増します。重大度が0のメッセージは最も重要なタイプのメッセージであり、重大度が32のメッセージはまったく重要ではありません。

メッセージ・プロパティ

プロパティには、他の種類の情報が含まれます。その種類はメッセージによって異なり、ユーザー名、クライアント・ブラウザのIPアドレス、スレッドIDなどが含まれる場合があります。

8.5.6 Oracle BIプレゼンテーション・サービス・ログ・フィルタ

FilterRecordで、ロギングの詳細をカスタマイズします。FilterRecordを使用して、実装(出力タイプ)とWebログのカテゴリ(インシデント・エラー、エラー、トレース、警告および情報)のロギング・レベルを指定します。

次の例では、最初の2つのFilterRecordに、次の文字列が含まれています。

path="saw"

この文字列は、情報イベントをレベル1、エラー・メッセージをレベル31などで記録します。

<FilterRecord writerClassGroup="Console" path="saw" information="1" warning="31" error="31" trace="0" incident_error="32" />
<FilterRecord writerClassGroup="File" path="saw" information="1" warning="31" error="31" trace="0" incident_error="32" />
<FilterRecord writerClassGroup="File" path="saw.mktgsqlsubsystem.joblog" information="1" warning="2" error="31" trace="0" incident_error="32"/>

この上位パスはすべてのイベントに適用されます。

前述の例の3番目のFilterRecordのように、各種タイプのイベントのログ・レベルをさらに詳細に指定する新しいFilterRecordを追加することで、FilterRecordをカスタマイズできます。この例の場合、saw.mktgsqlsubsystem.logからディスク・ファイルに情報が記録され、Marketingジョブ・イベントが生成されます。

次の例に示すように、情報レベルを1から0に変更することによって、または行をコメント・アウトすることによって、ジョブの詳細のロギングを無効にできます。

<FilterRecord writerClassGroup="Console" path="saw" information="1" warning="31" error="31" trace="0" incident_error="32" />
<FilterRecord writerClassGroup="File" path="saw" information="1" warning="31" error="31" trace="0" incident_error="32" />
<FilterRecord writerClassGroup="File" path="saw.mktgsqlsubsystem.joblog" information="1" warning="2" error="31" trace="0" incident_error="32"/>

8.5.7 エージェントに関する問題の診断

エージェントが実行に完全に失敗した場合やOracle BIスケジューラでデバッグが有効な場合には、エージェントのログ・ファイルが生成されます。

Oracle BIスケジューラのinstanceconfig.xmlファイル内でDebug要素をtrueに設定することによって、デバッグを手動で有効にできます。(詳細は、第8.3.2項「診断ログ構成ファイルの概要とその位置」を参照)。

エージェント・ログ・ファイルの場所は、Oracle BIスケジューラのinstanceconfig.xmlファイルで指定されます。(詳細は、第20.3.3.3項「エージェントのスケジューラ構成設定」を参照)。ログ・ファイルのデフォルトの場所は、Oracle BIスケジューラがインストールされるコンピュータの、Oracle Business Intelligenceインストール・ディレクトリ内のLogディレクトリです。

ログ・ファイル名の形式は、次のとおりです。

Agent-JobID-InstanceID.xxx

このファイル名の各部の内容は、次のとおりです。

  • Agentは、すべてのエージェント・ログ・ファイルの接頭辞です。

  • JobIDは、エージェントのOracle BIスケジューラ・ジョブ識別子です。

  • InstanceIDは、エージェントのOracle BIスケジューラ・インスタンス識別子です。

  • xxxは、ファイル拡張子です。

    • .errは、エージェント・エラー・ログ・ファイルを表します。

    • .logは、デバッグ・ログ・ファイルを表します。

エージェント・エラー・ログ・ファイルとデバッグ・ログ・ファイルは、実行に失敗したエージェント・インスタンスごとに、個別のファイルとして作成されます。テキスト・エディタを使用してファイルを表示できます。エントリは、通常、自明です。

エラー・ログがあるからといって、エージェントが完全に失敗したとはかぎりません。たとえば、エージェントが複数の電子メール・アドレスにコンテンツを配信するものとします。無効なアドレスがある場合や、メール・サーバーが停止している場合には、エージェントに対してエラー・ログが生成されます。

ジョブ・マネージャで、エラー・メッセージと、ジョブ・インスタンスの終了コードを表示することもできます。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionジョブ・スケジューリング・ガイドのジョブ・マネージャのインスタンス・プロパティに関する項を参照してください。終了ステータスは、正常終了した配信の数を示します。

8.6 ODBC/JDBCプロシージャを使用したOracle BIサーバーの診断の取得

この項では、ODBC/JDBCプロシージャを使用してOracle BIサーバーに関する診断情報を取得する方法について説明します。内容は次のとおりです。

8.6.1 Oracle BIサーバーのODBC/JDBCプロシージャについて

ODBC/JDBCプロシージャを使用して、Oracle BIサーバーに関する診断情報を取得することができます。これらのプロシージャは、管理ツールを実行できない非Windowsプラットフォーム上で特に有用です。

nqcmdユーティリティで、ODBCを使用してプロシージャを実行します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のnqcmdを使用したリポジトリのテストと改良に関する項を参照してください。

JDBCを使用してプロシージャを実行することもできます。JDBCを使用してOracle BIサーバーに接続する方法の詳細は、ORACLE_HOME/bifoundation/jdbcのbijdbc.jarファイルに含まれるREADME.TXTファイルを参照してください。

8.6.2 使用可能な診断カテゴリのリストの取得

最初にOBISAvailableDiagnostics()を実行して、使用可能な診断カテゴリのリストと説明を取得できます。例:

call OBISAvailableDiagnostics()

この結果は、次のように表示されます。

カテゴリ 説明

General

接続したOBISインスタンスの一般的な概要

DBInstance:DBNAME1

DBNAME1で名前が付けられたDBインスタンスに関連するすべての統計

DBInstance:DBNAMEn

DBNAMEnで名前が付けられたDBインスタンスに関連するすべての統計

LDAP:Instance1

Instance1で名前が付けられたLDAPインスタンスに関連するすべての統計

LDAP:Instancen

Instancenで名前が付けられたLDAPインスタンスに関連するすべての統計

DBConnectionPool:Instance1

Instance1で名前が付けられたDB接続プールに関連するすべての統計

DBConnectionPool:Instancen

Instancenで名前が付けられたDB接続プールに関連するすべての統計

ThreadPool:Instance1

Instance1で名前が付けられたスレッド・プールに関連するすべての統計

ThreadPool:Instancen

Instancenで名前が付けられたスレッド・プールに関連するすべての統計

Cache:Instance1

Instance1で名前が付けられたキャッシュに関連するすべての統計

Cache:Instancen

Instancenで名前が付けられたキャッシュに関連するすべての統計

「General」カテゴリを除き、カテゴリはすべて「Instance」カテゴリです。「Instance」カテゴリは、(特定の物理データベースなどの)特定のインスタンス・オブジェクトに関連する統計です。オブジェクトの複数のインスタンスを初期化した場合、category_name:instance_nameという形式で、インスタンスごとに個別のカテゴリが存在します。例については、上の表を参照してください。

ODBC/JDBCカテゴリについて次の点に注意してください。

  • 「ThreadPool」カテゴリには、DbConnection PoolMgrによって作成および管理されているスレッドからの統計のみが表示されます。

  • 「Cache」カテゴリには、Compiler CacheおよびLDAP Internal Cacheからの統計が表示されます。

8.6.3 特定の診断の実行

使用可能な診断カテゴリを取得すると、OBISDiagnostics(string)をコールして、個々のカテゴリの診断を取得できます。ここで、stringはカテゴリ名です。例:

call OBISDiagnostics('ThreadPool:orcldb_pool')

この結果は、次のように表示されます。

パラメータ名 値

CAPACITY

1000

THREAD COUNT

20

BUSY THREAD COUNT

15

ACCUMULATED REQUESTS

5

MAX STACK SIZE

100

カテゴリのスペルは正しくなければなりません。正しくない場合は、行が返されません。

次にもう1つの例を示します。

call OBISDiagnostics('General')

この結果は、次のように表示されます。

パラメータ名 値

TOTAL SESSIONS

10

QUERIES PER SEC

5

NEW LOGINS

10

ACTIVE LOGINS

7

NEW REQUESTS

30

DATA CACHE HIT PER SEC

5

NEW INIT BLOCKS

10

8.6.4 ODBC/JDBCプロシージャのパラメータについて

次の表は、各カテゴリ・タイプのパラメータ参照情報を示しています。

表8-6 「General」カテゴリのパラメータ

パラメータ名 説明

TOTAL SESSIONS

Oracle BIサーバーにクライアントを接続しているセッションの合計数。

QUERIES PER SEC

Oracle BIサーバーで完了した問合せの1秒当たりの数。

NEW LOGINS

Oracle BIサーバーが受信した新規ログイン・リクエストの合計数。

ACTIVE LOGINS

Oracle BIサーバー内でアクティブなログインの合計数。

NEW REQUESTS

Oracle BIサーバーが受信した新規実行リクエストの数。

DATA CACHE HIT PER SEC

1秒当たりのデータ・キャッシュ・ヒットの割合。

NEW INIT BLOCKS

Oracle BIサーバーが受信した新規初期化ブロック・リクエストの合計数。

表8-7 「DBInstance」カテゴリのパラメータ

パラメータ名 説明

QUERIES PER SEC

バックエンド・データベースで完了した問合せの1秒当たりの数。

FAILED QUERIES PER SEC

バックエンド・データベースで失敗した1秒当たりの問合せの数。

NEW PREPARES

バックエンド・データベースに送信された準備の数。

ROWS PER SEC

バックエンド・データベースから取得された1秒当たりの行数。

KB PER SEC

バックエンド・データベースから取得された1秒当たりのKB数。

表8-8 「LDAP」カテゴリのパラメータ

パラメータ名 説明

NEW REQUESTS

受信された新規LDAP認証リクエスト数の合計数。

NEW IMPERSONATED REQUESTS

受信された新規偽装LDAP認証リクエスト数の合計数。

ACTIVE REQUESTS

Oracle BIサーバー内でアクティブなLDAP認証リクエストの数。

表8-9 「DBConnectionPool」カテゴリのパラメータ

パラメータ名 説明

CAPACITY

データベース接続プールで許可される最大の接続数。

CONNECTION COUNT

スレッド・プールのオープン接続の現在の数。

BUSY CONNECTION COUNT

データベース接続プールで問合せを処理するために割り当てられた接続、または問合せを現在処理中の接続の数。

AVG REQUESTS PER SEC

データベース接続プールに送信された1秒当たりの平均リクエスト数。

AVG OPEN REQUESTS PER SEC

1秒当たりにオープンされる接続の平均数。他の接続がタイムアウトになったか、接続に問題があるため、新しい接続に対して接続がオープンされている可能性があります。

表8-10 「ThreadPool」カテゴリのパラメータ

パラメータ名 説明

CAPACITY

スレッド・プールで許容されるスレッドの最大数。

THREAD COUNT

スレッド・プール内の現在のスレッド数。

BUSY THREAD COUNT

作業が割り当てられている現在のスレッド数。スレッドがリソースまたはデータを待機中にブロックされたか、CPU上でアクティブに実行されている可能性があります。

ACCUMULATED REQUESTS

スレッド・プールに送信されたリクエストの合計数。

MAX STACK SIZE

スレッド・プール内のすべてのスレッドによって消費されたスタック・バイトの最大数。

表8-11 「Cache」カテゴリのパラメータ

パラメータ名 説明

CAPACITY

指定したキャッシュ・オブジェクトの合計容量。

TOTAL REQUESTS

指定したキャッシュ・オブジェクトに対する1秒当たりのリクエストの合計数。

AVG REQUESTS

指定したキャッシュ・オブジェクトに対する1秒当たりのリクエストの平均数。

AVG HITS

指定したキャッシュ・オブジェクトの1秒当たりの平均ヒット数。

AVG MISS

指定したキャッシュ・オブジェクトの1秒当たりの平均ミス数。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引