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

7 パフォーマンス・チューニングと問合せキャッシングの管理

この章では、パフォーマンス・チューニングの概要やシステム・メトリックの監視に関する情報も含めて、Oracle Business Intelligenceの問合せのパフォーマンスを向上する方法について説明します。また、問合せキャッシュを管理および使用する方法についても説明します。問合せキャッシュ機能により、Oracle BIサーバーは、問合せの結果をキャッシュ・ファイルに保存し、後で同様の問合せが要求されたときにその結果を再利用できます。キャッシュを使用すると、問合せに対するデータベース処理の回数が1回で済み、問合せを実行するたびにデータベースを処理する必要はありません。

お使いのシステムのパフォーマンス・チューニングについては、次のOracle Fusion Middlewareのリソースも参照してください。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』

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

7.1 サービス・レベルの監視

サービス・レベルを理解するには、通常、プロセスの状態を監視し、システム・メトリックを表示します。

Oracle Business Intelligenceは、ランタイム・パフォーマンスをリアルタイムで継続的に自動測定します。パフォーマンス・メトリックは自動的に有効化されるため、メトリックの収集のためにオプションを設定したり、追加の構成を実行したりする必要はありません。

特定のOracle Business Intelligenceインストール内のシステム・コンポーネントの場合、システム・メトリックをFusion Middleware Controlで参照できます。アプリケーションの実行速度の低下や停止などの問題が発生した場合、詳細なパフォーマンス情報を表示して、その問題について詳しく調べることができます。

WSLTコマンドを使用してメトリック情報を定期的にファイルに保存すると、過去のメトリック値の記録を作成できます。詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』のDMSカスタムWLSTコマンドに関する項を参照してください。

Oracle WebLogic Server管理コンソールを使用して、Javaコンポーネントのメトリックを表示することもできます。

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

7.1.1 共通パフォーマンス・メトリックを表示するためのFusion Middleware Controlの使用

「容量管理」ページの「メトリック」タブから、最もよく表示されるパフォーマンス・メトリックにアクセスできます。

Fusion Middleware Controlを使用して共通パフォーマンス・メトリックを表示するには:

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

  2. 「容量管理」ページの「メトリック」タブを表示します。

  3. 「メトリック」タブでは、レスポンス時間、負荷および信頼性に関するメトリックを表示できます。次のメトリックのページレベル・ヘルプにアクセスするには、ページの「ヘルプ」ボタンをクリックします。

    • リクエスト処理時間(ミリ秒)

    • SOAリクエスト処理時間(ミリ秒)

    • 平均問合せ時間(秒)

    • アクティブ・セッション

    • リクエスト(/分)

    • SOAリクエスト(/分)

    • プレゼンテーション・サービス・リクエスト(/秒)

    • サーバー問合せ(/秒)

    • 失敗した問合せ

    • 報告されたエラー(過去1時間)

    このタブに表示されるメトリックにより、クラスタ全体でのOracle Business Intelligenceコンポーネントの現在のレスポンス時間、負荷および信頼性を判断できます。

7.1.2 すべてのOracle Business Intelligenceメトリックを表示するためのFusion Middleware Controlの使用

Fusion Middleware Controlの「パフォーマンス・サマリー」ページから、使用可能なすべてのBusiness Intelligenceメトリックを表示してグラフを作成できます。データは、一時的にロギングされます(つまり、ロギングが開始されるのは、そのページを表示し、特定のメトリックを表示するように選択したときです)。

Fusion Middleware Controlを使用してOracle Business Intelligenceのすべてのパフォーマンス・メトリックを表示するには:

  1. ツリー・ナビゲータで、「Business Intelligence」フォルダを開き、コアアプリケーション・ノードを右クリックします。

  2. 「監視」を選択し、「パフォーマンス」を選択します。「パフォーマンス・サマリー」ページが表示され、このOracle Business Intelligenceインストールで選択されているメトリックが表示されます。


    注意:

    または、「容量管理」タブの「メトリック」ページに移動し、「システム・メトリックの完全セットを表示します」をクリックしても、「パフォーマンス・サマリー」ページを表示できます。

  3. 「パフォーマンス・サマリー」ページに表示されているメトリックをカスタマイズするには、「メトリック・パレットの表示」をクリックします。次に、該当のメトリック・カテゴリを開き、個々のメトリックを選択するか、選択を解除します。選択するメトリックが、「パフォーマンス・サマリー」ページに表示されます。

    特定のメトリックの詳細は、メトリックを右クリックし、「ヘルプ」をクリックします。

7.1.3 Javaコンポーネントのメトリックを表示するための管理コンソールの使用

Javaコンポーネントのメトリックを表示するには、管理コンソールを使用します。選択されている管理対象サーバーの「監視」タブでメトリックを表示したり、メトリック・ブラウザを使用したりできます。デプロイメントが簡易インストール・タイプに基づいている場合は、管理サーバーの「監視」タブを使用します。

「監視」タブでOracle Business Intelligenceのメトリックを表示するには:

  1. 管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  4. サーバー名(oracle_bi1やAdminServer(admin)など)をクリックします。

  5. 「 モニター 」タブをクリックします。

    このページに表示されるメトリックの詳細は、「ヘルプ」をクリックします。

管理コンソールのメトリック・ブラウザにアクセスするには:

  1. 管理コンソールにログインします。

  2. 「チャートとグラフ」で、「監視ダッシュボード」をクリックします。

  3. 「メトリック・ブラウザ」タブをクリックします。

    メトリック・ブラウザの使用の詳細は、「ヘルプ」をクリックします。

7.2 問合せのパフォーマンス・チューニングについて

この項では、Oracle BIサーバーにおいて問合せのパフォーマンスを向上する上で重要ないくつかの考慮事項について説明します。

問合せのパフォーマンス向上に使用できる方法の概要を、次に示します。

システム・コンポーネントをスケールアウトしてスループットを増加することによっても、システムの全体のパフォーマンスを向上できます。詳細は、第5章「デプロイメントのスケーリング」を参照してください。

7.3 Fusion Middleware Controlでのパフォーマンス・パラメータの設定

この項では、Fusion Middleware Controlで設定できるパフォーマンス・オプションについて説明します。

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

7.3.1 RPD更新を禁止するためのFusion Middleware Controlの使用

Fusion Middleware Controlを使用して、デフォルト・リポジトリ・ファイルへの更新を許可するか許可しないかを指定できます。このパラメータの設定は、管理ツールがオンライン・モードおよびオフライン・モードで接続されている際、リポジトリを更新できるかどうかに影響します。また、biserverxmlcliなど他のユーティリティを使用して、他のリポジトリ更新操作を実行できるかどうかにも影響します。リポジトリの更新が許可されていない場合、集計の永続性機能は使用できないことに注意してください。

リポジトリの更新を禁止すると、Oracle BIサーバーのパフォーマンスが向上します。このモードではOracle BIサーバーがロック・コントロールを処理する必要がないからです。

リポジトリの更新の禁止を選択すると、管理ツールがオンライン・モードまたはオフライン・モードでリポジトリを開くときに、リポジトリが読取り専用であるというメッセージがユーザーに通知されます。

この手順を始める前に、第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. 「RPD更新を許可しない」を選択して、リポジトリ・ファイルへの更新を禁止します。

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

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

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

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

7.3.2 ユーザー・セッションのログオフ期間を設定するための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の「概要」ページに戻り、「再起動」をクリックします。

設定を変更するためのOracle BI Systems Management API のメソッドの使用については、第22章「Oracle BI Systems Management APIの概要」を参照してください。

7.3.3 表およびピボット・テーブルのデータに対する構成オプションを設定するためのFusion Middleware Controlの使用

詳細な構成の設定は、第18.3項「ビュー内のデータの表示と処理の構成」で説明されています。

この手順を始める前に、第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. このページのヘルプ・トピックの説明を参照して、各要素を設定します。次のオプションに関するページ・レベルのヘルプにアクセスするには、ページの「ヘルプ」ボタンをクリックします。

    • 「最大ダウンロード行数」オプション

    • 「1ページ当たりに含める最大行数」オプション

    表18-1に示されているように、これらのオプションには、MaxVisibleRows要素に指定された値を超える値を設定することはできません。

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

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

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

7.3.4 表をレンダリングするために処理する最大行数を設定するためのFusion Middleware Controlの使用

表をレンダリングするためにOracle BIサーバーからフェッチして処理できる最大行数をオーバーライドできます。表の行数を減らすと、指定のユーザー・セッションで消費されるシステム・リソースが減少し、パフォーマンスが大幅に向上することがあります。

詳細な構成の設定は、第18.3項「ビュー内のデータの表示と処理の構成」で説明されています。

この値を設定する際は、次の点に注意してください。

  • この指定は、表に適用されます。ピボット・テーブルには適用されません。

  • デフォルト値は65000です。最小値は50です。最大値を超えると、表ビューのレンダリング時にサーバーからエラー・メッセージが返されます。最大値は少なくとも16ビットで、プラットフォームによって異なります。この値より大きな値の処理を試みる前に、システムのメモリーがすべて消費される可能性があります。

この手順を始める前に、第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. ページのヘルプ・トピックの説明を使用して、「表ビューをレンダリングするために処理された最大行数」オプションを設定します。50より大きな整数値を入力してください。

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

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

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

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

7.4 Oracle BIサーバーの問合せキャッシュについて

Oracle BIサーバーを構成して、問合せ結果セットのディスクベース・キャッシュをローカルに保持できます(問合せキャッシュ)。問合せキャッシュを使用すると、Oracle BIサーバーがバックエンド・データソース(OracleやDB2など)にアクセスせずに、後続の多数の問合せリクエストを処理できます。これにより通信負荷が低減されるため、問合せのレスポンス時間を大幅に短縮できます。

バックエンド・データベースで更新が発生すると、問合せキャッシュのエントリが古くなることがあります。このため、次のいずれかの方法を使用して、問合せキャッシュから定期的にエントリを削除する必要があります。

問合せキャッシングを制御するパラメータは、Fusion Middleware ControlおよびNQSConfig.INIファイル(付録A「NQSConfig.INIファイルの構成設定」を参照)にあります。詳細は、第7.7.3項「Oracle BIサーバー・キャッシュをシードするためのエージェントの使用」も参照してください。

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

7.4.1 問合せキャッシュのアーキテクチャ

問合せキャッシュは、キャッシュ記憶領域、キャッシュ・メタデータおよび問合せコンパイルでのキャッシュ検出で構成されます。

Oracle BIサーバーのキャッシュ・メタデータへのアクセスのプロセスは非常に高速です。メタデータがキャッシュ・ヒットを示す場合は、大部分の問合せ処理がなくなり、ユーザーに結果が即時に返されます。新しい結果をキャッシュに追加するプロセスは、ユーザーに返される結果には関係しません。実行中の問合せに影響するのは、キャッシュされた結果を書き込むプロセスで使用されるリソースだけです。

問合せキャッシュ・エントリは、WindowsやUNIXなどの異なるオペレーティング・システム間、および32ビットと64ビットのアーキテクチャ間で移植可能です。互換性のないキャッシュ・エントリは、自動的に削除されます。たとえば、32ビット・システムと64ビット・システムを切り替えるときに、キャッシュ・ファイルを手動で削除する必要はありません。

問合せキャッシュ・エントリは、Oracle Business Intelligenceのバージョン10.1.3.2と11g リリース1(11.1.1)など、異なるリリース間では移植不可能であることに注意してください。

キャッシングはサブリクエスト・レベルでデフォルトで発生し、SQL文によっては複数のキャッシュ・エントリが生じます。リアルタイムと過去のデータを組み合せた問合せの場合は特に、サブリクエストのキャッシングによって、パフォーマンスとキャッシュ・ヒット率が向上します。サブリクエスト・キャッシングを無効にするには、NQSConfig.INIファイルのパラメータDISABLE_SUBREQUEST_CACHINGをYESに設定します。詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。

7.4.2 キャッシングの利点

問合せを最も速く処理する方法は、大部分の処理をスキップして、あらかじめ計算された答えを使用する方法です。問合せキャッシングにより、Oracle BIサーバーは、問合せのあらかじめ計算された結果をローカル・キャッシュに保存します。別の問合せでその結果を使用できる場合、その問合せに対するすべてのデータベース処理がなくなります。これにより、平均問合せレスポンス時間が大幅に向上します。

パフォーマンスが向上すること、およびローカル・キャッシュから問合せに応えることができることにより、ネットワーク・リソースとデータベース・サーバーの処理時間も節約できます。ネットワーク・リソースを節約できるのは、中間結果がネットワーク経由でOracle BIサーバーに届けられる必要がないためです。データベース上で問合せを実行しない分、データベース・サーバーは別の処理を実行できます。データベースが課金式のシステムを使用している場合は、経費も節減できます。

キャッシュを使用して問合せに応えるもう1つの利点は、問合せ結果が複数のデータベースから取得される場合は特に、Oracle BIサーバーの処理時間が短縮されることです。問合せによっては、かなりの数の結合とソートの処理がサーバーで実行されます。問合せがあらかじめ計算されていればこの処理が回避され、サーバー・リソースを他の処理で使用することもできます。

要約すると、問合せキャッシングには、次の利点があります。

  • 問合せパフォーマンスの大幅な向上

  • ネットワーク・トラフィックの減少

  • データベース処理の低減

  • Oracle BIサーバーでの処理のオーバーヘッドの低減

7.4.3 キャッシングに伴う代償

問合せキャッシングには明らかに多くの利点がありますが、次のような代償も伴います。

  • キャッシュ用のディスク領域

  • キャッシュを管理するためのコスト

  • キャッシュされた結果が古くなる可能性

  • サーバー・コンピュータ上のCPUとディスクI/O

キャッシュ管理では、通常、利点が代償をはるかに上回ります。

次の各項で、キャッシングに伴う代償について説明します。

7.4.3.1 ディスク領域

問合せキャッシュには、専用のディスク領域が必要です。領域の大きさは、問合せのボリューム、問合せ結果セットのサイズおよびキャッシュに割り当てるために選択するディスク領域の大きさに依存します。パフォーマンスを向上するためには、ディスクをキャッシング専用で使用する必要があり、パフォーマンスと信頼性に優れたディスク・システムである必要があります。

7.4.3.2 管理タスク

キャッシングに関連する管理タスクがいくつかあります。各物理表に対して、その表内のデータの更新間隔を理解した上で、キャッシュの保持時間を適切に設定する必要があります。更新の頻度が状況によって異なる場合は、変更が発生するタイミングを追跡し、必要に応じてキャッシュを手動でパージする必要があります。キャッシュのイベント・ポーリング表を作成し、データベースに対する変更が発生するときにポーリング表を更新するようにアプリケーションを変更することで、システムをイベント駆動型にすることもできます。

Oracle BIサーバーには、プログラムでキャッシュ・エントリをパージするためのODBC拡張関数もあります。独自のスクリプトを作成して、適切なタイミングでこれらの関数を呼び出すことができます。

7.4.3.3 最新の状態のキャッシュの維持

基礎となるデータベース内のデータが変更されたときにキャッシュ・エントリがパージされないと、問合せが返す結果が最新のものでなくなる可能性があります。これが許容できるかどうかを評価する必要があります。キャッシュに多少古いデータが含まれていても、許容できる場合があります。許容できる古いデータのレベルを決定し、そのレベルを反映する一連のルールを構成(およびルールに準拠)する必要があります。

たとえば、大規模な複合企業の企業データを分析するアプリケーションがあり、企業内の様々な部門の年次サマリーを作成しているものとします。新しいデータは翌年度のサマリーにのみ影響するため、実質的には問合せに影響しません。この場合、キャッシュをパージするかどうかを決定するときに、トレードオフを考慮した上で、キャッシュにエントリを残しておくようにすることもできます。

ただし、データベースが1日に3回更新され、本日のアクティビティについて問合せを実行しているような場合は、例外です。その場合は、より頻繁にキャッシュをパージするか、場合によってはキャッシュをまったく使用しないようにすることも検討する必要があります。

また、定期的に(たとえば、1週間に1回)、データ・マートを最初から再構築するシナリオも考えられます。この例の場合、データ・マートの再構築のプロセスの一環としてキャッシュ全体をパージすることで、キャッシュ内に古いデータが残ることがなくなります。

どのような状況でも、ユーザーに返される最新でない情報として許容されるものは何であるかを評価する必要があります。

7.4.3.4 CPU使用率とディスクI/O

通常はごくわずかであるとはいえ、問合せキャッシングではCPU時間が必要であり、ディスクI/Oが増加します。ほとんどの場合、CPU使用率とディスクI/Oは微々たるものです。ディスクI/Oの増加は、問合せで大量のデータ・セットが返される場合にのみ顕著となる可能性があります。

7.4.4ユーザー間でのキャッシュの共有

特定の接続プールに対して共有ログオンが有効化されている場合は、ユーザー間でのキャッシュの共有が可能であり、ユーザーごとにキャッシュをシードする必要はありません。共有ログオンが有効ではなく、ユーザー固有のデータベース・ログオンが使用されている場合は、各ユーザーが独自のキャッシュ・エントリを生成します。

接続プールの共有ログオンの有効化については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

7.4.5 XMLデータソースのリフレッシュ間隔について

通常、XMLデータソースは頻繁にリアルタイムで更新されます。XMLデータソースのリフレッシュ間隔を設定することは、データベース表のキャッシュの永続性を設定するようなものです。リフレッシュ間隔とは、キャッシュ内の結果を使用するのではなく、XMLデータソースに対する問合せが再び直接実行されるまでの時間間隔です。このリフレッシュ間隔は、「接続プール」ダイアログの「XML」タブで指定します。

間隔のデフォルト設定は「infinite」で、これは、XMLデータ・ソースが自動的にリフレッシュされないことを意味します。

リフレッシュ間隔を設定すると、Oracle BIサーバー XML Gatewayの接続がリフレッシュされる時間間隔が次のように決定されます。

  • http://またはhttps://で始まるURLの場合、ゲートウェイは、所定の時間間隔が過ぎるとリフレッシュされます。

  • ローカル・ドライブまたはネットワーク・ドライブ上のURLの場合、ゲートウェイは、所定の時間間隔が過ぎて、システムがURLの変更を検出したときにリフレッシュされます。

XMLデータソースの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

7.4.6 グローバル・キャッシュについて

クラスタ環境では、グローバル・キャッシュと呼ばれる共有キャッシュにアクセスするようにOracle BIサーバーを構成できます。このグローバル・キャッシュは、共有ファイル・システムのストレージ・デバイスに配置されており、パージ・イベント、シード・イベント(多くの場合はエージェントによって生成されます)、およびシード・イベントと関連付けられた結果セットを保存します。シード・イベントとパージ・イベントは、論理イベント・キューとして、時間でソートされ、共有記憶域に保存されます。個々のOracle BIサーバー・ノードは、論理イベント・キューに対してプッシュおよびプルの操作を実行します。各Oracle BIサーバーでは、通常の問合せ用に独自のローカル問合せキャッシュが引き続き保持されます。

図7-1は、クラスタ環境内でのグローバル・キャッシュを示しています。ここでは、3つのOracle BIサーバー・ノードがグローバル・キャッシュを共有しています。グローバル・キャッシュには、論理イベント・キューに保持されているシード・イベントまたはパージ・イベントが保存されています。ノード2およびノード3から共有キャッシュに向かう矢印は、Oracle BIサーバー・ノード2がシード・イベントをキューにプッシュし、Oracle BIサーバー・ノード3がパージ・イベントをキューにプッシュしていることを示します。共有記憶域から各Oracle BIサーバー・ノードに向かう矢印は、各ノードが共通の場所からプルしていることを示します。これは定期的に発生し、参加しているOracle BIサーバー・ノードは、他のOracle BIサーバーによる論理イベント・キューへの更新を取得できます。

図7-1 グローバル・キャッシュ

この図については周囲のテキストで説明しています。
「図7-1 グローバル・キャッシュ」の説明

Oracle BIサーバー・ノードは、シード・イベントまたはパージ・イベントを、最初にそのキャッシュ・システムでローカルに処理します。次に、共有記憶域上のグローバル・キャッシュにイベントをプッシュします。イベントをプッシュするときに、アクティブなOracle BIサーバー・ノードは共有記憶域上の論理イベント・キューをロックして、シード・イベントまたはパージ・イベントをプッシュします。シードとパージが競合する場合は(たとえば、あるノードが問合せをシードし、別のノードが同じ問合せをパージしようとする場合)、最後のイベントが適用されます。

共有記憶域上のグローバル・キャッシュ内の論理イベント・キューは、個々のOracle BIサーバー・ノードからのシード・イベントとパージ・イベントで構成されます。キューは、イベントのタイムスタンプでソートされます。このため、クラスタに参加しているすべてのOracle BIサーバー・ノードのクロックが同期している必要があります。

各Oracle BIサーバー・ノードは、グローバル・キャッシュを定期的にポーリングして、新しいキャッシュ・エントリを調べます。このポーリングの頻度は構成可能です。共有記憶域にキューイングされている論理イベントのスナップショットがノードにプルされ、ローカルの論理イベント・キューが作成されて処理されます。


注意:

クラスタに参加しているすべてのOracle BIサーバー・ノードに対するシード・キャッシュの設定またはパージの処理はリアルタイムでは実行されず、処理にかかる時間は、あらかじめ定義されたポーリング間隔、ネットワーク・バンド幅、CPUの負荷などの複数の要因の影響を受けます。

問合せキャッシュの結果セットは大きくなりがちなため、ネットワーク・バンド幅に関する制約を受ける可能性があります。したがって、次の項目を慎重に選択する必要があります。

  • シード・キャッシュに適したキャッシュのセット

  • 共有記憶域からシード・キャッシュを取得するBIノードの時間間隔(ネットワークの混雑の回避が目的)

主要なグローバル・キャッシュ・パラメータは、Fusion Middleware Controlで構成します。その他のオプションのパラメータは、クラスタに参加している各Oracle BIサーバー・ノードのNQSConfig.INIファイルで構成します。これらのパラメータの構成の詳細は、第7.5.4項「グローバル・キャッシュ・パラメータを設定するためのFusion Middleware Controlの使用」および第7.5.5項「追加のグローバル・キャッシュ・パラメータの手動での編集」を参照してください。

シード・プロシージャまたはパージ・プロシージャは、特定のOracle BIサーバー・ノードに対して発行されます。そのOracle BIサーバーがBIクラスタ内のノードであり、グローバル・キャッシュ・パラメータがOracle BIサーバー構成ファイルで定義されている場合、シード・イベントまたはパージ・イベントは、同じクラスタ環境に参加しているすべてのOracle BIサーバー・ノードに伝播されます。

7.5 問合せキャッシングの構成

問合せキャッシュとグローバル・キャッシュのどちらに対しても、キャッシュ記憶域などのパラメータは、Fusion Middleware ControlとNQSConfig.INIファイルで構成します。古いキャッシュ・エントリのフラッシュの方針についても決める必要があります。詳細は、第7.6項「キャッシュの監視と管理」を参照してください。

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

7.5.1 問合せキャッシングを有効または無効にするためのFusion Middleware Controlの使用

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の「概要」ページに戻り、「再起動」をクリックします。

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

7.5.2 問合せキャッシュ・パラメータを設定するためのFusion Middleware Controlの使用

Fusion Middleware Controlを使用して、問合せキャッシュ内のキャッシュ・エントリの最大数と、1つのキャッシュ・エントリの最大サイズを設定できます。

この手順を始める前に、第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の「概要」ページに戻り、「再起動」をクリックします。

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

7.5.3 追加の問合せキャッシュ・パラメータの手動での編集

次のような追加の問合せキャッシュ・パラメータをNQSConfig.INIファイルに設定できます。

  • DATA_STORAGE_PATHSパラメータは、問合せキャッシュ記憶域用の1つ以上のディレクトリと、各記憶域ディレクトリの最大サイズを指定します。これらのディレクトリは、キャッシュされた問合せ結果を保存するのに使用され、キャッシュ・ヒットが発生するとアクセスされます。キャッシュ・ヒットの発生の詳細は、第7.7.1項「キャッシュ・ヒットについて」を参照してください。

    キャッシュ記憶域ディレクトリは、パフォーマンスに優れたストレージ・デバイス上に配置する必要があり、キャッシュ記憶域専用であることが理想です。キャッシュ記憶域ディレクトリがいっぱいになり始めると、最低使用頻度(LRU)のエントリが破棄されて、新しいエントリ用の領域が確保されます。

  • MAX_ROWS_PER_CACHE_ENTRYパラメータは、キャッシュ・エントリの最大行数を制御します。行数の制限は、大量の行を返すリソース集中型の問合せによるキャッシュ領域の使用を防ぐのに有効な手段です。問合せが返す行数がMAX_ROWS_PER_CACHE_ENTRYパラメータで指定される値を超える場合、問合せはキャッシュされません。

  • 通常、以前に実行した問合せからキャッシュ・ヒットが得られる場合、新しい問合せはキャッシュに追加されません。POPULATE_AGGREGATE_ROLLUP_HITSパラメータは、以前に実行した問合せの集計をロールアップしてキャッシュ・ヒットが発生した場合のこのデフォルトを上書きします。

追加の問合せキャッシュ・パラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。

7.5.4 グローバル・キャッシュ・パラメータを設定するための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の「概要」ページに戻り、「再起動」をクリックします。

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

7.5.5 追加のグローバル・キャッシュ・パラメータの手動での編集

次のような追加のグローバル・キャッシュ・パラメータをNQSConfig.INIファイルに設定できます。

  • MAX_GLOBAL_CACHE_ENTRIESパラメータは、グローバル・キャッシュ・ストア内で許可されるエントリの最大数を制御します。

  • CACHE_POLL_SECONDSパラメータは、Oracle BIサーバーがクラスタ内の他のサーバー・ノードと同期するために論理イベント・キューからプルする間隔を秒単位で指定します。

  • CLUSTER_AWARE_CACHE_LOGGINGパラメータは、グローバル・キャッシュのロギングを有効にするかどうかを制御します。この設定をYESに変更するのは、デバッグを目的とする場合のみです。

    ログ・エントリはnqquery.logにあります。このファイルは次の場所にあります:

    ORACLE_INSTANCE\diagnostics\logs\OracleBIServerComponent\coreapplication_obisn

追加のグローバル・キャッシュ・パラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。

7.6 キャッシュの監視と管理

基礎となるデータベース内の変更を管理し、キャッシュ・エントリを監視するには、キャッシュの管理方針を決める必要があります。キャッシュ・エントリの作成元である、基礎となる表内のデータが変更されたときにキャッシュ・エントリを無効化するプロセスと、不要なキャッシュ・エントリを監視、識別および削除するプロセスが必要です。

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

7.6.1 キャッシュ管理方針の選択

キャッシュ管理方針の選択は、基礎となるデータベース内のデータの変動性と、この変動を引き起こす変更の予測可能性に依存します。また、キャッシュに含まれる問合せの数と種類、およびその問合せの使用状況にも依存します。この項では、様々なキャッシュ管理方法の概要を説明します。

7.6.1.1 システムのキャッシングの無効化

システム全体のキャッシングを無効にすることで、新しいすべてのキャッシュ・エントリを停止し、既存のキャッシュを使用する新しい問合せを停止できます。キャッシングを無効にしても、キャッシュ内に保存されているエントリを失うことなく、後で有効にできます。

キャッシュ・エントリが古い疑いがあるが、そのエントリまたはキャッシュ全体をパージする前に、それが本当に古いかどうかを確認することが望まれる状況では、キャッシングの一時的な無効化の方針が役に立ちます。キャッシュに保存されているデータに依然として関連性があることが判明した場合、または問題のエントリを無事にパージした後で、キャッシュを安全に有効化できます。必要に応じて、キャッシュを再び有効化する前に、キャッシュ全体をパージするか、特定のビジネス・モデルに関連するキャッシュをパージします。

詳細は、第7.5.1項「問合せキャッシングを有効または無効にするためのFusion Middleware Controlの使用」を参照してください。

7.6.1.2 指定された物理表のキャッシングとキャッシュ永続時間

各物理表のキャッシュ可能属性を設定することで、その表に対する問合せをキャッシュに追加して、今後の問合せに答えを返すかどうかを指定できます。表のキャッシングを有効にすると、表に関係する問合せがキャッシュに追加されます。デフォルトではすべての表がキャッシュ可能ですが、「キャッシュ永続時間」の設定を使用している場合を除き、表によってはキャッシュに含める必要がない可能性があります。たとえば、毎分更新される株価データを保存している表があるものとします。「キャッシュ永続時間」の設定を使用すると、その表のエントリを59秒ごとにパージできます。

「キャッシュ永続時間」フィールドを使用して、この表のエントリを問合せキャッシュに保持する時間を指定することもできます。これは、頻繁に更新されるデータ・ソースに役立ちます。

特定の物理表のキャッシング属性を設定するには:

  1. 管理ツールの物理レイヤーで、物理表をダブルクリックします。

  2. 「物理表プロパティ」ダイアログの「一般」タブで、次のいずれかを選択します。

    • キャッシングを有効にするには、「キャッシュ可能」を選択します。

    • 表をキャッシュしないようにするには、「キャッシュ可能」の選択を解除します。

  3. キャッシュの有効期限を設定するには、「キャッシュ永続時間」を指定し、単位(日、時間、分または秒)を指定します。キャッシュ・エントリが自動的に期限切れにならないようにするには、「キャッシュ失効なし」を選択します。

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

7.6.1.3 Oracle BIサーバーのイベント・ポーリング表の構成

Oracle BIサーバーのイベント・ポーリング表には、基礎となるデータベース内の更新に関する情報が保存されます。データベース表が更新されるたびにイベント・ポーリング表に行を追加するように、アプリケーション(データ・マートにデータをロードするアプリケーションなど)を構成できます。Oracle BIサーバーは、設定された間隔でこの表をポーリングし、更新された表に対応するキャッシュ・エントリを無効にします。イベント・ポーリング表は、キャッシュ管理の唯一の方法の場合もあれば、他のキャッシュ管理方式とともに使用することもできます。イベント表は、キャッシュ・エントリの選択とパージのタイミングに関して、あまり柔軟性はありません。イベント・ポーリング表の詳細は、第7.8.1項「物理データベース上でのイベント・ポーリング表の設定」を参照してください。

7.6.2 ODBCプロシージャを使用するキャッシュのパージと保守

Oracle BIサーバーには、キャッシュ・エントリをパージするためのODBC拡張関数があります。

これらの関数の中には、抽出、変換およびロード(ETL)タスクに埋め込むのに特に役立つものがあります。たとえば、毎晩のETLの実行後に、すべてのOracle BIサーバー・キャッシュ・エントリをパージできます。ファクト表だけが変更された場合は、その表に関連するキャッシュのみをパージできます。場合によっては、特定のデータベースに関連するキャッシュ・エントリをパージする必要があります。

キャッシュをパージする権限を持つのは管理者だけです。したがって、このようなODBC拡張関数をコールするスクリプトは、管理者権限の資格証明の下で実行する必要があります。

次のODBC関数は、ODBC接続で指定されるリポジトリに関連するキャッシュ・エントリに影響します。

  • SAPurgeCacheByQuery。指定された問合せに完全に一致するキャッシュ・エントリをパージします。たとえば、次の問合せを使用すると、給与が$100,000を超えるすべての従業員の名前を取得する、1つ以上の問合せキャッシュ・エントリが得られます。

    SELECT lastname, firstname FROM employee WHERE salary > 100000;

    次のコールによって、この問合せに関連するキャッシュ・エントリがパージされます。

    Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );

  • SAPurgeCacheByTable。クライアントが接続されているリポジトリの、指定された物理表名(完全修飾)に関連するすべてのキャッシュ・エントリをパージします。

    この関数は、完全修飾された物理表名の4つのコンポーネント(データベース、カタログ、スキーマおよび表名に固有)を表す、最大で4つのパラメータを使用します。たとえば、完全修飾名がDBName.CatName.SchName.TabNameという表があるものとします。Oracle Business Intelligenceリポジトリの物理レイヤーにあるこの表に関連するキャッシュ・エントリをパージするには、スクリプト内で次のコールを実行します。

    Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );

    注意:

    Oracle BIサーバーでは、この関数内でのワイルドカードをサポートしていません。また、DBNameとTabNameをnullにすることはできません。どちらかがnullの場合は、エラー・メッセージが表示されます。

  • SAPurgeAllCache。すべてのキャッシュ・エントリをパージします。このコールの例を次に示します。

    Call SAPurgeAllCache();

  • SAPurgeCacheByDatabase。特定の物理データベース名に関連するすべてのキャッシュ・エントリをパージします。キャッシュをパージするODBCプロシージャがコールされると、レコードが返されます。この関数では、物理データベース名を表す1つのパラメータを使用し、パラメータをnullにすることはできません。このコールの構文を次に示します。

    Call SAPurgeCacheByDatabase( 'DBName' );

7.6.2.1 ODBCプロシージャ構文について

プロシージャの文字列引数の中に一重引用符がある場合は、もう1つの一重引用符を使用してエスケープする必要があります。例:

Call SAPurgeCacheByQuery('SELECT TOPN("- Currency"."Markdown %", 10) saw_0,
"XX Line"."Order No" saw_1, "- Bill-To Site"."Customer Name" saw_2, "-
Currency"."Net USD" saw_3, "- Currency"."Markdown USD" saw_4, "-
Currency"."Markdown %" saw_5 FROM "Apps 11i - XX Lines" WHERE 
("XX Line"."Open Flag" = ''Y'') AND ("Operating Unit"."Group Name" = ''Group'')
AND ("- Currency"."Net USD" >= 10000) ORDER BY saw_0');

太字の行は、''Y''および''Group''というアイテムのエスケープ文字として使用されている、追加の一重引用符を示しています。

7.6.2.2 プレゼンテーション・サービス問合せキャッシュの共有について

ユーザーがアンサーにアクセスして問合せを実行すると、プレゼンテーション・サービスは問合せの結果をキャッシュします。プレゼンテーション・サービスでは、リクエスト・キーと論理SQL文字列を使用して、キャッシュされた結果を後続の問合せが使用できるかどうかを決定します。キャッシュを共有できる場合、後続の問合せは保存されません。

  • SAGetSharedRequestKey。プレゼンテーション・サービスから論理SQL文を受け取り、リクエスト・キー値を返すODBCプロシージャ。

    このプロシージャの構文を次に示します。

    SAGetSharedRequestKey('sql-string-literal')

リクエスト・キーの値は、次の要因の影響を受けます。

  • リポジトリ物理データベース・オブジェクトで「仮想プライベート・データベース」オプションが選択されているかどうか

  • セッション変数がリポジトリ内で「セキュリティ・センシティブ」としてマークされているかどうか

プレゼンテーション・サービスは、仮想プライベート・データベースとしてマークされているデータベース・オブジェクトに対して、論理リクエストのリクエスト・キーを計算するときに、セキュリティ・センシティブな変数を考慮します。

プレゼンテーション・サービス問合せキャッシュの詳細は、第7.9項「Oracle BIプレゼンテーション・サービス・キャッシュ設定の管理」を参照してください。

7.6.2.3 結果レコードについて

キャッシュをパージするコマンドを実行すると、結果レコードが返されます。結果レコードには、2つの列が含まれています。最初の列は結果コードで、2番目の列は、パージ操作の結果を説明する短いメッセージです。表7-1は、結果レコードの例を示しています。

表7-1 問合せの結果コード

結果コード 結果メッセージ

1

SAPurgeCacheByDatabaseが正常終了しました。

59115

キャッシュが有効でないため、操作は実行されませんでした。

59116

指定されたデータベースが存在しません。

59117

指定された表が存在しません。

7.6.2.4 SAP/BWデータソースのキャッシュの保存とパージ

Microsoft Analysis Servicesでは、メンバーのキャプション名は、メンバーの一意の名前と同じです。しかし、SAP/BWデータソースでは、メンバーのキャプション名とメンバーの一意の名前は異なります。したがって、Oracle BIサーバーでは、SAP/BWメンバーの一意の名前でキャッシュ・サブシステムを保持します。このサブシステムは、デフォルトでは無効です。構成情報については、付録A「NQSConfig.INIファイルの構成設定」のMDX Member Name Cacheセクションに関する項を参照してください。

メンバーの一意の名前で問合せを受信すると、サブシステムはキャッシュを確認して、この問合せに対するキャッシュの有無を判断します。キャッシュが存在する場合、キャッシュされている一意の名前のレコードが返されます。問合せに一致するキャッシュがない場合は、SAP/BWにプロービング問合せが送信されます。

プロービング問合せは、ログ・レベルが2以上の場合にロギングされます。サーバー・ログには、サブシステムが有効かどうかといったサブシステムの状態と、開始イベントや停止イベントなどのイベントも書き込まれます。


注意:

ログ・レベルが上がるごとに、パフォーマンスに影響が及びます。ユーザーのログ・レベルを上げる際は、注意してください。

キャッシュのパージに関して、次の点に留意してください。

  • 多次元キャッシュ・エントリのサイズは、非常に大きくなる可能性があります。したがって、NQSConfig.INIファイルのMDX_MEMBER_CACHEセクションで、各メンバー・セットのサイズの制限が設定されています。

  • アップグレードの後、保持されているキャッシュの形式が一貫しているとはかぎりません。このため、ソフトウェアのアップグレードの前に、すべてのキャッシュをパージする必要があります。

  • 問合せを初めて実行するときに、キャッシュが移入されます。パフォーマンスへの影響を最小限にするために、オフピーク時にキャッシュを移入するように調整してください。


    注意:

    管理ツールでは、キューブ表を右クリックし、「メンバー・キャッシュのパージ」を選択することによって、個々のキューブ表をパージできます。これは、管理者権限を持つユーザーがオンライン・モードで実行する必要があります。

次のパージ・プロシージャは、SAP/BWデータソースに固有のものです。

  • SAPurgeALLMCNCache。すべてのSAP/BWキャッシュ・エントリをパージします。

    このプロシージャの構文を次に示します。

    SAPurgeALLIMCNCache ()

  • SAPurgeMCNCacheByCube。指定された物理キューブに関連するすべてのキャッシュ・エントリをパージします。データベース名とキューブ名は、リポジトリ・オブジェクトの外部名です。このプロシージャの構文を次に示します。

    SAPurgeMCNCacheByCube( 'DBName', 'CubeName')

表7-2は、返されるメッセージを示しています。

表7-2 SAPパージ・キャッシュのリターン・コードとメッセージ

リターン・コード 戻りメッセージ

1

SAPurgeALLMCNCacheが正常終了しました。

1

SAPurgeMCNCacheByCubeが正常終了しました。

59116

指定されたデータベースが存在しません。

注意: データベースと物理キューブの両方が間違っている場合に、この結果コードが返されます。

85025

指定された物理キューブが存在しません。

管理権限を持つユーザーのみが、ODBCパージ・プロシージャを実行できます。

7.6.3 リポジトリの変更が問合せキャッシュに及ぼす影響

Oracle Business Intelligenceリポジトリを変更すると、その変更が、キャッシュに保存されているエントリに影響することがあります。たとえば、物理オブジェクトや動的リポジトリ変数の定義を変更すると、そのオブジェクトや変数を参照しているキャッシュ・エントリが有効でなくなる場合があります。このような変更によって、キャッシュをパージする必要が生じる可能性があります。注意を要する3つのシナリオがあります。オンライン・モードで変更が行われる場合、オフライン・モードで変更が行われる場合およびリポジトリ間を切り替えている場合です。

7.6.3.1 オンライン・モード

オンライン・モードでOracle Business Intelligenceリポジトリを変更する場合、その変更がキャッシュ・エントリに影響するものであれば、変更されたオブジェクトを参照するすべてのキャッシュ・エントリが自動的にパージされます。パージは、変更をチェックインするときに発生します。たとえば、リポジトリから物理表を削除すると、その表を参照しているすべてのキャッシュ・エントリが、チェックイン時にパージされます。ビジネス・モデルとマッピング・レイヤー内でのビジネス・モデルへの変更によって、そのビジネス・モデルのキャッシュ・エントリがすべてパージされます。

7.6.3.2 オフライン・モード

オフライン・モードでOracle Business Intelligenceリポジトリを変更する場合、キャッシュに保存されている問合せに影響する変更を行い、キャッシュされた結果が古くなる可能性があります。オフライン・モードの編集時にサーバーはリポジトリをロードしないため、行われた変更がキャッシュ・エントリに影響するかどうかを判断できません。このため、オフラインでの変更の後、サーバーによってキャッシュが自動的にパージされることはありません。キャッシュをパージしないと、リポジトリが次にロードされたときに、無効なエントリが存在する可能性があります。オフラインでの変更の影響を受けるエントリがキャッシュに存在しないことが確実な場合を除いて、変更したビジネス・モデルのキャッシュをパージする必要があります。

7.6.3.3 リポジトリ間の切替え

Oracle BIサーバーの構成からリポジトリを削除する予定の場合は、リポジトリを参照するすべてのキャッシュ・エントリのキャッシュをパージする必要があります。パージしないと、キャッシュが損傷します。詳細は、第7.7.4.2項「管理ツールでのキャッシュのパージ」を参照してください。

7.6.3.4 動的リポジトリ変数の変更

動的リポジトリ変数の値は、問合せから返されるデータでリフレッシュされます。動的リポジトリ変数を定義する際には、初期化ブロックを作成するか、SQL問合せが含まれる既存の初期化ブロックを使用します。問合せを実行し、変数の値を定期的にリフレッシュする、Oracle BIサーバーのスケジュールも構成します。

動的リポジトリ変数の値が変更されると、その変数の値を参照するビジネス・モデルに関連するすべてのキャッシュ・エントリが、自動的にパージされます。値が変更された場合、リポジトリ変数のリフレッシュ間隔に達したときに、キャッシュ・エントリがパージされます。

変更された動的リポジトリ変数にビジネス・モデルが関係していない場合、キャッシュのパージは行われません。たとえば、リポジトリ変数で初期化ブロックが定義されており、リフレッシュ間隔は5分だとします。しかし、変数を参照する論理列は定義されていません。動的リポジトリ変数の値が変更された場合、変数を使用する論理列がビジネス・モデルには存在しないため、キャッシュはパージされません。

7.7 キャッシュの使用方針

問合せキャッシングの主要な利点の1つは、表面上の問合せパフォーマンスが向上することです。オフピーク時に問合せを実行し、その結果をキャッシングしてキャッシュをシードすることが重要な可能性があります。適切なシード方針は、キャッシュ・ヒットがいつ発生するかを理解している必要があります。

すべてのユーザーのキャッシュをシードするには、次の問合せでキャッシュをシードします。

SELECT User, SRs

SELECT User, SRsを使用してキャッシュをシードすると、次の問合せがキャッシュ・ヒットです。

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)

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

7.7.1 キャッシュ・ヒットについて

キャッシングが有効な場合は、各問合せが評価されて、キャッシュ・ヒットと見なされるかどうかが判断されます。キャッシュ・ヒットとは、サーバーがキャッシュを使用して問合せに答えを返すことができ、データベースにアクセスする必要がないことを意味します。Oracle BIサーバーは、問合せキャッシュを使用して、集計と同じかそれ以上のレベルで、問合せに答えを返すことができます。

キャッシュがヒットするかどうかは、多くの要因によって決まります。表7-3は、このような要因を示しています。

表7-3 キャッシュがヒットするかどうかを決定する要因

要因またはルール 説明

SELECTリスト内の列のサブセットが一致している

キャッシュ・ヒットと見なされるためには、新しい問合せのSELECTリスト内のすべての列が、キャッシュされた問合せ内に存在している必要があります。または、問合せ内の列から計算できる必要があります。

このルールはキャッシュ・ヒットの最小要件ですが、このルールを満たしていても、キャッシュ・ヒットが保証されるわけではありません。この表に記載されている他のルールも適用されます。

SELECTリスト内の列を、キャッシュされた問合せの列の式で作成できる

Oracle BIサーバーは、キャッシュされた結果の式を計算して、新しい問合せに答えを返すことができます。ただし、キャッシュされた結果にすべての列がある必要があります。次に例を示します。

SELECT product, month, averageprice FROM sales WHERE year = 2000

この問合せは、次の問合せのキャッシュをヒットします。

SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000

averagepriceが、dollarsとunitsalesから計算できるためです(averageprice = dollars/unitsales)。

WHERE句が、意味的に同じか、論理的なサブセットである

問合せがキャッシュ・ヒットと見なされるためには、WHERE句による制約が、キャッシュされた結果と同等か、キャッシュされた結果のサブセットである必要があります。

WHERE句が、キャッシュされた問合せの論理サブセットで、そのサブセットが次のいずれかの条件を満たす場合は、キャッシュ・ヒットと見なされます。

  • INリスト値のサブセット。キャッシュされた問合せのINリストに含まれる要素より、少ない要素を要求する問合せは、キャッシュ・ヒットと見なされます。次に例を示します。

    SELECT employeename, region
FROM employee, geography
WHERE region in ('EAST', 'WEST')

    この問合せは、次のキャッシュされた問合せのヒットと見なされます。

    SELECT employeename, region
FROM employee, geography
WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')

  • キャッシュされた結果より少ない(ただし同一の)OR制約が含まれている。

  • リテラル比較の論理サブセットが含まれている。次に例を示します。

    WHERE revenue < 1000

    この述語は、次の述語を使用する類似の問合せのヒットと見なされます。

    WHERE revenue < 5000

  • WHERE句がない。WHERE句がない問合せがキャッシュされている場合、他のすべてのキャッシュ・ヒット・ルールを満たす問合せは、そのWHERE句にかかわらず、キャッシュ・ヒットと見なされます。

ディメンションのみの問合せが完全一致している

問合せがディメンションのみで、問合せにファクトやメジャーが含まれない場合、キャッシュされた問合せの投影列が完全一致する場合のみ、キャッシュはヒットします。これにより、ディメンション表の論理ソースが複数ある場合の誤検出が回避されます。

特殊関数を使用する問合せが完全一致している

時系列関数(AGO、TODATE、PERIODROLLINGなど)、極限関数およびオフセット関数(OFFSETおよびFETCH)、外部集計関数、フィルタ・メトリックなどの特殊関数を含むその他の問合せも、キャッシュされた問合せ内のプロジェクション列と完全一致する必要があります。このようなケースでは、フィルタも完全一致の必要があります。

一連の論理表が一致している

キャッシュ・ヒットと見なされるためには、受信するすべての問合せが、キャッシュ・エントリと同じ論理表のセットを持つ必要があります。このルールにより、誤ったキャッシュ・ヒットが回避されます。たとえば、SELECT * FROM productは、SELECT * FROM product, salesに一致しません。

セキュリティ・セッション変数を含めて、セッション変数値が一致している

論理SQL文または物理SQL文がセッション変数を参照している場合、セッション変数値が一致している必要があります。一致していない場合、キャッシュはヒットしません。

さらに、セキュリティ・センシティブなセッション変数の値は、論理SQL文自体がセッション変数を参照していない場合であっても、リポジトリ内で定義されるセキュリティ・セッション変数値に一致している必要があります。詳細は、第7.7.1.1項「行レベルのデータベース・セキュリティを使用している場合の適切なキャッシュ結果の確認」を参照してください。

同等の結合条件

キャッシュ・ヒットと見なされるためには、新しい問合せリクエストで作成された結合済論理表が、キャッシュされた結果と同じ(またはサブセット)である必要があります。

同じDISTINCT属性

キャッシュされた問合せでは、DISTINCT処理(たとえば、SELECT DISTINCT...)により重複するレコードがない場合、キャッシュされた列に対するリクエストにも、DISTINCT処理を含める必要があります。DISTINCT処理が含まれない、同じ列へのリクエストは、キャッシュ・ミスです。

問合せに互換性のある集計レベルが含まれている

集計レベルの情報をリクエストする問合せでは、下位の集計レベルで、キャッシュされた結果を使用できます。たとえば、次の問合せは、仕入先、地域および市区レベルでの販売数量をリクエストしています。

SELECT supplier, region, city, qtysold
FROM suppliercity

次の問合せは、市区レベルでの販売数量をリクエストしています。

SELECT city, qtysold
FROM suppliercity

2番目の問合せは、最初の問合せのキャッシュ・ヒットになります。

追加の集計の制限

たとえば、列qtysoldに関する問合せがキャッシュされている場合、RANK(qtysold)のリクエストはキャッシュ・ミスになります。また、国レベルのqtysoldをリクエストする問合せは、国と地域レベルのqtysoldをリクエストする問合せから、キャッシュ・ヒットを得ることができます。

ORDER BY句がSELECTリスト内の列で構成されている

SELECTリストに含まれていない列でソートする問合せは、キャッシュ・ミスになります。

詳細なヒット検出によるキャッシュ・ミスの回避

NQSConfig.INIファイル内でパラメータUSE_ADVANCED_HIT_DETECTIONをYESに設定することで、一部のキャッシュ・ミスを回避できます。詳細なヒット検出を使用すると、ヒットするキャッシュの拡張検索を行うことができます。詳細は、「USE_ADVANCED_HIT_DETECTION」を参照してください。

7.7.1.1 行レベルのデータベース・セキュリティを使用している場合の適切なキャッシュ結果の確認

仮想プライベート・データベース(VPD)のような行レベルのデータベース・セキュリティ方針を使用している場合、返されるデータ結果は、ユーザーの認可資格証明で決まります。このため、Oracle BIサーバーは、行レベルのデータベース・セキュリティを使用しているかどうか、およびセキュリティに関係する変数を把握する必要があります。

すべてのセキュリティ・センシティブ変数を含み、照合するキャッシュ・エントリでのみキャッシュ・ヒットが起こるようにするには、データベース・オブジェクトとセッション変数オブジェクトを管理ツールで次のように適切に構成する必要があります。

  • データベース・オブジェクト。物理レイヤーにおいて、「データベース」ダイアログの「一般ー」タブで「仮想プライベート・データベース」を選択し、データ・ソースが行レベルのデータベース・セキュリティを使用していることを指定します。

    共有キャッシングで行レベルのデータベース・セキュリティを使用している場合は、セキュリティ・センシティブ変数が一致しないキャッシュ・エントリの共有を防ぐために、このオプションを選択する必要があります。

  • セッション変数オブジェクト。認証で使用する変数の場合は、「セッション変数」ダイアログで「セッション・センシティブ」を選択して、行レベルのデータベース・セキュリティ方針を使用するときに、この変数がセキュリティを区別できることを指定します。このオプションによって、キャッシュ・エントリはセキュリティ・センシティブ変数としてマークされ、受信するすべての問合せでセキュリティ・センシティブ変数を照合できます。

詳細は、次のリソースを参照してください。

  • 『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のデータベース内での行レベル・セキュリティの設定に関する項

  • 『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のセッション変数の管理に関する項

  • データベースおよびセッション変数オブジェクトの一般情報は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』

7.7.2 キャッシュを移入するための一連の問合せの実行

キャッシュ・ヒットの可能性を最大限に高める1つの方法は、一連の問合せを実行してキャッシュを移入することです。キャッシュをシードする一連の問合せを作成するときに使用する問合せの種類に関して、いくつかの推奨事項があります。

  • 共通の事前作成問合せ。よく実行される問合せや、処理に多くのリソースが必要な問合せは特に、優れたキャッシュ・シード問合せです。その結果がダッシュボードに埋め込まれる問合せは、共通問合せのよい例です。

  • 式が含まれないSELECTリスト。SELECTリストの列から式をなくすと、キャッシュ・ヒットの可能性が広がります。式が含まれるキャッシュ列は、同じ式が含まれる新しい問合せにのみ答えを返します。式が含まれないキャッシュ列は、任意の式を含むその列に対するリクエストに答えを返すことができます。たとえば、キャッシュされた次のようなリクエストがあるものとします。

    SELECT QUANTITY, REVENUE...

    これは、次のような新しい問合せに答えを返すことができます。

    SELECT QUANTITY/REVENUE...

    ただし、逆は成り立ちません。

  • WHERE句の不使用。キャッシュされた結果にWHERE句がない場合、これを使用して、プロジェクション・リストの列が含まれるSELECTリストとWHERE句のキャッシュ・ヒット・ルールを満たす問合せに、答えを返すことができます。

一般に、キャッシュのシードに最適な問合せは、データベースの処理リソースを大量に使用し、再実行される可能性がある問合せです。多くの行を返す単純な問合せでキャッシュをシードしないように注意してください。このような問合せでは(たとえば、SELECT * FROM PRODUCTS。PRODUCTSは単一のデータベース表に直接マップします)、データベース処理はほとんど必要ありません。このような問合せで問題となるのはネットワークとディスクのオーバーヘッドですが、これらはキャッシングでは軽減されません。

Oracle BIサーバーがリポジトリ変数をリフレッシュする際には、ビジネス・モデルを調べて、そのリポジトリ変数を参照しているかどうかを判断します。参照している場合は、そのビジネス・モデルのすべてのキャッシュがパージされます。詳細は、第7.6.3.4項「動的リポジトリ変数の変更」を参照してください。

7.7.3 Oracle BIサーバー・キャッシュをシードするためのエージェントの使用

エージェントを構成して、Oracle BIサーバー・キャッシュをシードできます。キャッシュをシードすることで、ユーザーが分析を実行したり、ダッシュボードに埋め込まれている分析を表示したりするときのレスポンス時間を向上できます。このデータをリフレッシュするリクエストを実行するようにエージェントをスケジュールすることで、これを実現できます。

エージェントを構成してOracle BIサーバー・キャッシュをシードするには:

  1. Oracle Business Intelligenceにログインし、「新規」を選択し、「エージェント」を選択します。

  2. 「一般」タブで、「実行者」オプションの「受信者」を選択します。パーソナライズされたキャッシュ・シードでは、各受信者のデータ可視性に基づいて、エージェントによる各受信者へのコンテンツの配信をカスタマイズします。

  3. 「スケジュール」タブで、キャッシュをシードするタイミングを指定します。

  4. 必要に応じて「条件」を選択し、条件付きリクエストを作成または選択します。たとえば、ETLプロセスがいつ完了するかを決定するビジネス・モデルがあるものとします。このビジネス・モデルに基づくレポートを使用して、キャッシュ・シードを開始する条件付きトリガーとなることができます。

  5. 「配信コンテンツ」タブで、個々のリクエスト、またはキャッシュ・シードの対象となるダッシュボード・ページ全体を選択します。ダッシュボード・ページの選択は、時間の節約になります。

  6. 「受信者」タブで、受信者である個々のユーザーまたはグループを選択します。

  7. 「送信先」タブで、すべてのユーザー送信先の選択を解除し、「Oracle BIサーバー・キャッシュ」を選択します。

  8. 右上隅にある「保存」ボタンを選択して、エージェントを保存します。

キャッシュ・シード・エージェントと他のエージェントの唯一の違いは、以前のキャッシュを自動的に消去して、ダッシュボードにアラートとして表示されないことです。

キャッシュ・シード・エージェントは、完全一致の問合せのみパージするため、古いデータが引き続き存在する可能性があります。エージェント問合せは非定型の問合せやドリルには対処しないため、キャッシング方針には常にキャッシュのパージを含める必要があります。

7.7.4 キャッシュ・マネージャの使用

キャッシュ・マネージャを使用すると、問合せキャッシュ全体に関する情報と、開いているリポジトリに関連付けられている問合せキャッシュ内の個々のエントリに関する情報を表示できます。また、特定のキャッシュ・エントリを選択し、そのエントリに対して、キャッシュされているSQL文の表示と保存、エントリのパージなど、様々な操作を実行できます。

キャッシュ・マネージャを開くには:

  1. 管理ツールのツールバーで、「管理」→「キャッシュ」を選択します。

左側のエクスプローラ・ペインの「キャッシュ」タブを選択すると、現在のリポジトリのキャッシュ・エントリ、ビジネス・モデルおよびユーザーが表示されます。関連するキャッシュ・エントリが右側のペインに反映され、上部の表示専用フィールドにエントリの総数が表示されます。

「オプション」設定を使用して、キャッシュ・エントリ情報およびその表示順序を制御できます(キャッシュ・マネージャから「編集」を選択し、「オプション」を選択するか、管理ツールのメニューから「ツール」→「オプション」→「キャッシュ・マネージャ」を選択します)。表7-4に記載されているオプションを情報に含めることができます。

表7-4 キャッシュ・オプション

オプション 説明

ユーザー

キャッシュ・エントリを生成した問合せを発行したユーザーのID。

作成

キャッシュ・エントリの結果セットが作成された時間。

最終使用

キャッシュ・エントリの結果セットが問合せに対応した最後の日時(Oracle BIサーバーが予期せず停止した後、最終使用日時が一時的に実際よりも古い値となることがあります)。

作成経過時間

このキャッシュ・エントリの結果セットを作成するのに必要な時間(秒単位)。

注意: ディスク上のキャッシュ・オブジェクト・ディスクリプタに保存されている値は、ミリ秒単位です。表示用に秒単位に変換されます。

行数

問合せによって生成された行数。

行サイズ

このキャッシュ・エントリの結果セット内の各行のサイズ(バイト単位)。

フル・サイズ

可変長の列、圧縮アルゴリズム、およびその他の要因を考慮して使用される最大サイズ。結果セットの実際のサイズはフル・サイズよりも小さくなります。

列数

このキャッシュ・エントリの結果セットの各行内の列数。

論理リクエスト

このキャッシュ・エントリに関連付けられている論理リクエスト。サブリクエストがキャッシュされている場合、この列にはサブリクエストのテキストが表示されます。

使用回数

このキャッシュ・エントリの結果セットが問合せを満たした回数(Oracle BIサーバーの起動後)。

ビジネス・モデル

キャッシュ・エントリに関連付けられているビジネス・モデルの名前。

リポジトリ

キャッシュ・エントリに関連付けられているOracle Business Intelligenceリポジトリの名前。

SQL

このキャッシュ・エントリに関連付けられているSQL文。サブリクエストがキャッシュされている場合、1つのSQL文に複数のキャッシュ・エントリが関連付けられている可能性があります。

問合せサーバー

問合せを処理したOracle BIサーバー。

ファクト表ソース

このキャッシュ・エントリの論理リクエストに関連付けられたファクト表。

リポジトリ・ツリーを開くとすべてのビジネス・モデルとキャッシュ・エントリが表示され、ビジネス・モデルを開くとすべてのユーザーとキャッシュ・エントリが表示されます。右側のペインには、階層ツリー内で選択されているアイテムに関連するキャッシュ・エントリのみが表示されます。

7.7.4.1 キャッシュ・マネージャ内でのグローバル・キャッシュ情報の表示

グローバル・キャッシュ情報を表示するには、「アクション」を選択し、「情報の表示」を選択します。表7-5は、「グローバル・キャッシュ情報」ウィンドウに表示される情報を示しています。

表7-5 グローバル・キャッシュ情報

列 説明

キャッシュ記憶域として使用できる空き容量

キャッシュ記憶域として使用できる空き領域(MB単位)です。

キャッシュ関連ファイルを含むディスクで使用される空き容量

キャッシュ関連ファイルが格納されているディスクの総使用量(MB単位)です(キャッシュ関連ファイル用に使用されている領域だけではありません)。

許容可能な最大キャッシュ・エントリ数

NQSConfig.INIファイルのMAX_CACHE_ENTRIESパラメータで指定される、キャッシュ内で可能な最大エントリ数です。

キャッシュ・エントリ結果セットごとの許容可能な最大行数

NQSConfig.INIファイルのMAX_ROWS_PER_CACHE_ENTRYパラメータで指定される、各キャッシュ・エントリの結果セットで許容される最大行数です。

現在のキャッシュ・エントリ数

グローバル・キャッシュ内の現在のエントリ数です。これらのエントリは、複数のリポジトリに関連付けられている可能性があります。

Oracle BIサーバーの起動以降にキャッシュから満足されなかった問合せ数

Oracle BIサーバーの前回の起動以降のキャッシュ・ミスです。

Oracle BIサーバーの起動以降にキャッシュから満足された問合せ数

Oracle BIサーバーの前回の起動以降のキャッシュ・ヒットです。

キャッシュ・マネージャがアクティブ・ウィンドウの状態で、[F5]キーを押すか、「アクション」→「リフレッシュ」を選択して、表示をリフレッシュします。開いているリポジトリの現在のキャッシュ・エントリと現在のグローバル・キャッシュ情報が取得されます。DSNがクラスタ化されている場合は、クラスタ内のすべてのリポジトリに関する情報が表示されます。

7.7.4.2 管理ツールでのキャッシュのパージ

キャッシュのパージは、問合せキャッシュからエントリを削除するプロセスです。キャッシュ・エントリは、次の方法でパージできます。

  • 管理ツールのキャッシュ・マネージャ機能(オンライン・モード)を使用して、手動で行います。

  • 特定の表の「物理表」ダイアログの「キャッシュ永続時間」フィールドを設定して、自動で行います。

  • Oracle BIサーバー・イベント・ポーリング表を設定して、自動で行います。

  • キャッシュ記憶域がいっぱいになったときに、自動で行います。


注意:

キャッシュのパージは、ODBC拡張関数を使用してプログラムで行うこともできます。詳細は、第7.6.2項「ODBCプロシージャを使用するキャッシュのパージと保守」を参照してください。

また、動的リポジトリ変数の値が変化するときにもキャッシュをパージできます。詳細は、第7.6.3.4項「動的リポジトリ変数の変更」を参照してください。

キャッシュ・マネージャでキャッシュ・エントリを手動でパージするには:

  1. 管理ツールを使用してオンライン・モードでリポジトリを開きます。

  2. 「管理」→「キャッシュ」を選択して、「キャッシュ・マネージャ」ダイアログを開きます。

  3. 左ペインの該当のタブを選択することによって、キャッシュ・モードまたは物理モードを選択します。

  4. エクスプローラ・ツリーを参照して、関連するキャッシュ・エントリを右ペインに表示します。

  5. パージするキャッシュ・エントリを選択し、「編集」→「パージ」を選択して、選択されているエントリを削除します。または、選択されているエントリを右クリックし、「パージ」を選択します。

    • キャッシュ・モードでは、パージするエントリを右ペインに表示されている中から選択します。

    • 物理モードでは、パージするデータベース、カタログ、スキーマまたは表を、左ペイン内のエクスプローラ・ツリーから選択します。

    キャッシュ・モードでは、次のものをパージできます。

    • 開いているリポジトリに関連する、選択されている1つ以上のキャッシュ・エントリ。

    • 指定されたビジネス・モデルに関連する、選択されている1つ以上のキャッシュ・エントリ。

    • ビジネス・モデル内の指定されたユーザーに関連する、選択されている1つ以上のキャッシュ・エントリ。

    物理モードでは、次のものをパージできます。

    • 選択されている1つ以上のデータベースに関連する、すべての表のすべてのキャッシュ・エントリ。

    • 選択されている1つ以上のカタログに関連する、すべての表のすべてのキャッシュ・エントリ。

    • 選択されている1つ以上のスキーマに関連する、すべての表のすべてのキャッシュ・エントリ。

    • 選択されている1つ以上の表に関連する、すべてのキャッシュ・エントリ。

パージによって、選択されているキャッシュ・エントリと関連するメタデータが削除されます。キャッシュの表示を更新するには、「アクション」→「リフレッシュ」を選択するか、[F5]キーを押します。

7.8 イベント・ポーリング表によるキャッシュ・イベントの処理

Oracle BIサーバー・イベント・ポーリング表(イベント表)は、1つ以上の物理表が更新されたことをOracle BIサーバーに通知する手段として使用できます。イベント表に追加される各行は、本番データベース内の本番表に対して発生する更新など、単一の更新イベントを表します。Oracle BIサーバー・キャッシュ・システムは、イベント表を読み込み(ポーリング)、物理表の情報を行から抽出し、その物理表を参照する古いキャッシュ・エントリをパージします。

イベント表は、Oracle BIサーバーがアクセス可能なリレーショナル・データベース上に存在する物理表です。専用のデータベースにあるか、他の表も含まれるデータベースにあるかにかかわらず、固定のスキーマ(表7-6を参照)が必要です。通常は、管理ツールの物理レイヤーでのみ公開され、「物理表」ダイアログ内でOracle BIサーバー・イベント表として識別されます。

イベント表の使用は、古いキャッシュ・エントリを無効化する最も正確な手段の1つであり、多くの場合、最も信頼できる方法です。ただし、データベース表が更新されるたびに、イベント表を移入する必要があります。また、ポーリング間隔の間はキャッシュが必ずしも最新の状態ではないため、キャッシュ内のデータが古い可能性が常にあります。詳細は、第7.8.3項「Oracle BIサーバー・イベント・ポーリング表の移入」を参照してください。

イベント表を更新する一般的な方法は、データベースを移入する、抽出およびロードのスクリプトまたはプログラムに、SQLのINSERT文を指定する方法です。INSERT文によって、物理表が変更されるたびに1つの行がイベント表に追加されます。このプロセスが配置され、Oracle Business Intelligenceリポジトリ内でイベント表が構成されると、キャッシュの無効化が自動的に行われます。イベント表を更新するスクリプトが、表に対する変更を正確に記録しているかぎり、指定されたポーリング間隔で、古いキャッシュ・エントリが自動的にパージされます。

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

7.8.1 物理データベース上でのイベント・ポーリング表の設定

各物理データベース上に物理イベント・ポーリング表を構成して、データベース内の変更を監視できます。独自のデータベースでイベント表を構成することもできます。イベント表は、データベース内の表が変更されるたびに更新されます。

イベント・ポーリング表がOracle Databaseにある場合は、管理ツールの物理レイヤーで、イベント表をその独自のデータベース・オブジェクトで構成する必要があります。次に、イベント・ポーリング表の「データベース」ダイアログの「機能」タブで、機能PERF_PREFER_IN_LISTSの選択が解除されていることを確認します。このガイドラインに従うことで、リスト内で許容される最大式数を超えるエラーが回避されます。

イベント・ポーリング表を作成するには、リポジトリ作成ユーティリティ(RCU)を実行し、物理データベース内にBusiness Intelligence Platform (BIPLATFORM)スキーマを作成します。RCUによってS_NQ_EPTという名前のイベント・ポーリング表が作成されます。リポジトリ作成ユーティリティの実行の詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

イベント表は、表7-6に示す構造である必要があります。イベント表の配置場所によっては、一部の列にnull値を格納できます。列の名前は、表7-6に記載されている列名に一致する必要があります。表示されているデータ・タイプは、Oracle Database用です。

表7-6 イベント・ポーリング表の列名

イベント表の列 データ型 説明

CATALOG_NAME

VARCHAR2

更新された物理表が位置するカタログの名前。

イベント表が、更新された物理表と同じデータベース内にない場合のみ、CATALOG_NAME列を移入します。それ以外の場合は、null値に設定します。

DATABASE_NAME

VARCHAR2

更新された物理表が位置するデータベースの名前。これは、管理ツールの物理レイヤーで定義されるときのデータベースの名前です。たとえば、物理データベースの名前が11308Productionで、管理ツールに表示される場合のデータベース名がSQL_Productionの場合、イベント表内のポーリングされる行には、データベース名としてSQL_Productionが含まれている必要があります。

イベント表が、更新された物理表と同じデータベース内にない場合のみ、DATABASE_NAME列を移入します。それ以外の場合は、null値に設定します。

OTHER_RESERVED

VARCHAR2

将来の拡張に備えて予約されています。この列は、null値に設定する必要があります。

SCHEMA_NAME

VARCHAR2

更新された物理表が位置するスキーマの名前。

イベント表が、更新された物理表と同じデータベース内にない場合のみ、SCHEMA_NAME列を移入します。それ以外の場合は、null値に設定します。

TABLE_NAME

VARCHAR2

更新された物理表の名前。この名前は、管理ツールの物理レイヤーで表に対して定義されている名前に一致している必要があります。

null値は指定できません。

UPDATE_TS

DATE

イベント表に対する更新が発生する日時。これは、イベント表に追加される行ごとに増加する、キー(一意)値である必要があります。増加する一意の値であるためには、列のデフォルト値として現在のタイムスタンプを指定します。たとえば、Oracle Databaseの場合は、DEFAULT CURRENT_TIMESTAMPを指定します。

null値は指定できません。

注意: この列は、イベント表に追加される行ごとに増加する一意の値である必要があるため、1秒間に多くの挿入が行われる場合は、非常に高い精度を設定する必要がある可能性があります。このため、データベース機能のFRACTIONAL_SECOND_PRECISIONを調整して、UpdateTime列のフィルタで小数秒を使用するようにできます。Oracle BIサーバーでは、FRACTIONAL_SECOND_PRECISIONで定義される桁数でタイムスタンプが切り捨てられます。

たとえば、Oracle DatabaseやTeradataの場合は、FRACTIONAL_SECOND PRECISIONを0から6に変更します。

UPDATE_TYPE

NUMBER

更新スクリプトに値1を指定して、標準の更新であることを指定します(その他の値は、将来の使用に備えて予約されています)。

null値は指定できません。

Oracle BIサーバーは、イベント・ポーリング表に対して読取りと書込みの権限を持っている必要があります。サーバーは、指定された間隔でイベント表を読み取り、変更されたデータを探します。データベース表が変更されている場合は(たとえば、ロード処理時)、イベント表に行が追加されます。イベント表に行がある場合、基礎となるデータベースに変更されたデータがあります。変更された物理表に対応するキャッシュ・エントリが無効化され、イベント表から古い行が定期的に削除されます。次にイベント表を確認するときも、処理が繰り返されます。


注意:

クラスタ化されたOracle Business Intelligenceデプロイメントでは、1つのイベント・ポーリング表が、クラスタ内のすべてのOracle BIサーバー・ノードで共有されます。ただし、1つのイベント・ポーリング表を、複数のOracle BIサーバー・クラスタで共有することはできません。

Oracle BIサーバーに、イベント・ポーリング表(データベース内の他の表ではない)への書込み権限を与えるには、次のタスクを実行します。

  • 権限を持つ接続プールを使用して、管理ツールの物理レイヤーに、個別の物理データベースを作成します。

  • 削除権限を持つ接続プールにユーザーを割り当てます。

  • イベント表を使用して権限が必要なデータベースを移入します。

Oracle BIサーバーは、イベント・ポーリング表への書込み権限は持っていますが、ユーザー問合せに答えを返すために使用される表への書込み権限は持っていません。

7.8.2 イベント・ポーリング表のアクティブ化

物理データベースに表を作成したら、Oracle BIサーバーでその表をアクティブ化できます。これを行うには、最初に物理表をインポートし、表オブジェクトをイベント・ポーリング表としてマークします。

物理表をインポートするには:

  1. 管理ツールで、リポジトリを開き、物理データベースからメタデータをインポートします。これを行うには、「ファイル」を選択し、「メタデータのインポート」を選択します。

  2. ウィザードの手順に従います。「メタデータ型の選択」画面の「表」オプションを選択して、表のメタデータをインポートします。

    メタデータのインポート・ウィザードの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

  3. イベント・ポーリング表が複数ある場合は、イベント表ごとにステップ1および2を繰り返します。イベント表用に指定されているデータソースが、イベント表に対して読取りと書込みの権限を持つことを確認します。リポジトリは、表の読取りと表の行の削除を両方行うため、書込み権限が必要です。イベント表が、ビジネス・モデルとマッピング・レイヤーで公開されている必要はありません。

表オブジェクトをイベント・ポーリング表としてマークするには:

  1. 「ツール」メニューから「ユーティリティ」を選択します。

  2. オプション・リストから「Oracle BIイベント表」オプションを選択します。

  3. 「実行」をクリックします。

  4. イベント表として登録する表を選択し、「>>」ボタンをクリックします。

  5. ポーリング間隔を分単位で指定し、「OK」をクリックします。

    デフォルト値は60分です。10分未満のポーリング間隔は設定しないでください。非常に短いポーリング間隔が必要な場合は、表の一部またはすべてをキャッシュ不能とマークすることを検討します。

表がOracle BIサーバー・イベント表として登録されると、表のプロパティが変わります。イベント表として登録すると、イベント・ポーリング表から結果をキャッシュする理由がないため、表をキャッシュ可能とマークするオプションが削除されます。

7.8.3 Oracle BIサーバー・イベント・ポーリング表の移入

Oracle BIサーバーが、イベント・ポーリング表を移入することはありません。イベント表が更新されるたびに行を挿入することによって、イベント表が移入されます。このプロセスは、通常、データベース管理者によって構成されます。一般には、データベース管理者が、表が変更されるたびにポーリング表に行を挿入するロード・プロセスを変更します。これは、(トリガーをサポートするデータベース内で)データベース・トリガーを使用するロード・スクリプト、アプリケーション、または手動で行うことができます。イベント表の移入のプロセスが正しく行われないと、サーバーでは、ポーリング表内の情報が正確で最新であるとみなされるため、Oracle BIサーバーのキャッシュのパージに影響します。

7.8.4 イベント・ポーリング表に関する問題のトラブルシューティング

キャッシュのポーリングに関して問題が発生した場合は、Oracle BIサーバー・アクティビティ・ログを検索して、サーバーとイベント表とのやり取りに関するエントリを確認できます。

  • nqserver.logファイルは、Oracle BIサーバーに関するアクティビティを自動的に記録します。ログ・エントリは自明であり、Fusion Middleware Controlまたはテキスト・エディタで表示できます。

  • Oracle BIサーバーがイベント表のポーリングを行うと、管理者アカウント(インストール時に設定)を使用して、nqquery.logファイルに問合せが記録されます。ただし、管理者アカウントのログ・レベルが0に設定されている場合を除きます。最も役立つレベルの情報を提供するためには、管理者アカウントのログ・レベルを2に設定してください。

nqserver.logとnqquery.logは次の場所にあります。

ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obisn

7.9 Oracle BIプレゼンテーション・サービス・キャッシュ設定の管理

ユーザーが分析を実行すると、プレゼンテーション・サービスはその分析の結果をキャッシュします。プレゼンテーション・サービスでは、キャッシュされた結果を後続の分析が使用できるかどうかを決定します。キャッシュを共有できる場合、後続の分析は保存されません。

プレゼンテーション・サービス・キャッシュのファイルには、nQS_xxxx_x_xxxxxx.TMPのような名前が付けられます。ファイルはODBCドライバによって作成されますが、通常、プレゼンテーション・サービス・キャッシュが開いているODBCリクエストには対応していません。ファイルは、次のディレクトリに保存されています。

ORACLE_INSTANCE\tmp\OracleBIPresentationServices\coreapplication_obipsn\obis_temp

キャッシュのファイルは、プレゼンテーション・サービスが正常に停止するときに削除されます。プレゼンテーション・サービスが予期せず停止した場合、様々なキャッシュ・ファイルがディスクに残る可能性があります。プレゼンテーション・サービスが実行していないときにファイルを削除できます。

プレゼンテーション・サービス・キャッシュは、Oracle BIサーバーがアクセスするキャッシュとは異なります。instanceconfig.xmlファイルを変更してキャッシュ・エントリを含めることによって、プレゼンテーション・サービス・キャッシュのデフォルトを変更できます。

次のプロシージャは、プレゼンテーション・サービス・キャッシュを管理できる構成の変更に関する情報を示しています。

ODBCプロシージャを使用してキャッシュを共有する方法については、第7.6.2.2項「プレゼンテーション・サービス問合せキャッシュの共有について」を参照してください。

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

キャッシュを管理するための設定を手動で編集するには:

  1. 第3.6項「構成ファイルの格納場所」の説明に従って、instanceconfig.xmlファイルを編集するために開きます。

  2. 表7-7に示されている要素を追加する必要があるセクションを見つけます。


    注意:

    時間に関係する要素に、3分より短い値を指定しないでください。このような短い時間を指定すると、リフレッシュが頻繁に発生するため、パフォーマンスに悪影響を及ぼし、画面がちらつく可能性があります。

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

    <ServerInstance>
  <Cache>
    <Query>
      <MaxEntries>100</MaxEntries>
      <MaxExpireMinutes>60</MaxExpireMinutes>
      <MinExpireMinutes>10</MinExpireMinutes>
      <MinUserExpireMinutes>10</MinUserExpireMinutes>
    </Query>
  </Cache>
<ServerInstance>

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

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

表7-7 プレゼンテーション・サービスのキャッシュを構成する要素

要素 説明 デフォルト値

MaxEntries

プレゼンテーション・サービスが常に開いておくレコード・セットの最大数を指定します。最小値は3です。負荷が大きなシステムの場合、この値を700または1000に増加できます。

500

MaxExpireMinutes

キャッシュ内のエントリが削除されるまでの最大存続時間を、分単位で指定します。実行されている分析の数によっては、有効期限より前にエントリが削除される可能性があります。

60(1時間)

MinExpireMinutes

キャッシュ内のエントリが削除されるまでの最小存続時間を、分単位で指定します。CacheMinUserExpireMinutesの設定によって、特定のユーザーのエントリが、CacheMaxExpireMinutes要素で指定される時間より長く存在できます。

10

MinUserExpireMinutes

キャッシュ内のエントリがユーザーに表示された後の最小存続時間を、分単位で指定します。

たとえば、CacheMaxExpireMinutesが60分に設定されていて、ユーザーが59分のときにエントリを表示すると、そのユーザーのエントリはさらに10分間存続します。ユーザーは新しい分析を実行することなく、データのページングを継続できます。

10

7.10 Oracle BI Webクライアントのパフォーマンスの向上

Oracle BI Webクライアントのパフォーマンスを向上させるには、すべての静的ファイルを処理するWebサーバーを構成し、静的リソースも動的リソースも圧縮を有効化します。Webサーバー上でキャッシュおよびコンテンツの有効期限を有効にすると、Webブラウザでサーバーから静的ファイルをリロードする頻度を指定できます。

Oracle BI EEでは、静的ファイルはORACLE_HOME/bifoundation/web/appにあります。使用しているWebサーバー用の手順に従って、静的ファイルのキャッシングと、このディレクトリにあるファイルの圧縮を設定します。


注意:

Oracle WebLogic Serverを構成してApache HTTP Server、Microsoft Internet Information Server(Microsoft IIS)、Oracle HTTP ServerなどのWebサーバーと連携させる方法の詳細は、次のドキュメントを参照してください。

『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』

『Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server』

次の各項では、構成の例を示します。

7.10.1Apache HTTP Serverの静的ファイル・キャッシングの構成

この構成例は、Webサーバー・プラグインがインストールされていて、Apache HTTP ServerがOracle WebLogic Serverへリクエストをプロキシすることが前提です。PLUGIN_HOME/libディレクトリが、LD_LIBRARY_PATHまたはオペレーティング・システムでこれに相当するものに追加されている必要があります。

この項の手順は、構成例専用です。必要に応じて、構成を調整してください。詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』を参照してください。

プラグインの構成ディレクティブを追加するには:

  1. Apache HTTP Serverのhttpd.confファイルを見つけます。

  2. ファイルを編集用に開き、次のようなディレクティブを追加します。

    LoadModule weblogic_module modules/mod_wl.so

<IfModule mod_weblogic.c>
   WebLogicPort 9704
   Debug OFF
   WebLogicHost localhost
   WLLogFile /tmp/wl-proxy.log
</IfModule>

<LocationMatch "/analytics/saw\.dll.*">
SetOutputFilter DEFLATE
SetHandler weblogic-handler
</LocationMatch>

<LocationMatch "/analytics/.*\.jsp.*">
SetOutputFilter DEFLATE
SetHandler weblogic-handler
</LocationMatch>

    次の点に注意してください。

    • LoadModuleディレクティブを、プラグインをインストールした場所と方法に基づいて変更します。

    • IfModuleディレクティブによって、Oracle WebLogic Serverへの接続が有効になります。クラスタの構成方法やSSLに関する考慮事項など、接続オプションの詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』を参照してください。

    • LocationMatchディレクティブを使用して、すべての動的リクエストがOracle WebLogic Serverにルーティングされます。すべての動的リクエストでGZip圧縮を使用できるように、SetOutputFilter DEFLATEディレクティブを含めてください。

  3. ファイルを保存して閉じます。

静的ファイルを処理する構成ディレクティブを追加するには:

  1. Apache HTTP Serverのhttpd.confファイルを見つけます。

  2. ファイルを編集用に開き、次のようなディレクティブを追加します。

    Alias /analytics ORACLE_HOME/bifoundation/web/app
<Directory ORACLE_HOME/bifoundation/web/app>
# Disable cross-server ETags
FileETag none
# Enable compression for all files
SetOutputFilter DEFLATE
# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Enable future expiry of static files
ExpiresActive on
ExpiresDefault "access plus 1 week"
Header set Cache-Control "max-age=604800"
DirectoryIndex default.jsp
</Directory>

# Restrict access to WEB-INF
<Location /analytics/WEB-INF>
Order Allow,Deny
Deny from all
</Location>

    次の点に注意してください。

    • Apache HTTP Serverが、ORACLE_HOME/bifoundation/web/app内のOracle BI Webクライアントの静的ファイルにアクセスできることを確認する必要があります。Webサーバーが実行されていて、この場所への読取り権限を持つことを確認します。

    • 別名エントリおよびディレクトリ・エントリは、Apache HTTP Serverに対して、静的ファイルのリクエストをOracle WebLogic Serverにルーティングするのではなく、処理することを指定するものです。圧縮および静的ファイルの失効に関するディレクティブについて、次の点に注意してください。

      • FileETag

        FileETag none

        このディレクティブは、Webサーバーに対して、レスポンス内でETagヘッダーを生成しないことを指定します。Apache HTTP ServerのデフォルトのETag生成は、単一サーバーのファイル・システムに密接に関係します。そのため、ETagの生成は推奨されません。

      • 圧縮関連のディレクティブ

        SetOutputFilter DEFLATE
# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

        これらのディレクティブにより、Apache HTTP Serverは、イメージ以外のすべてのファイルを圧縮します。通常、イメージはすでに圧縮されており、さらに圧縮しても効果はありません。

      • Expiresヘッダーの制御

        # Enable future expiry of static files
ExpiresActive on
ExpiresDefault "access plus 1 week"

        このフラグメントでは、Apache HTTP Serverに対して、Expiresヘッダーの設定を有効にすることを指定しています。この例では、クライアントがファイルに最初にアクセスした日の1週間後がデフォルトの失効日です。この期間を長くすることもできますが、静的ファイルに対するパッチや更新を十分に処理できるように、静的ファイルを頻繁にリフレッシュする必要があります。

      • Cache-Controlヘッダーの制御

        Header set Cache-Control "max-age=604800"

        このフラグメントでは、Apache HTTPサーバーに対して、Cache-Controlヘッダーを設定することを指定しています。この例では、Expiresヘッダーと一致するように、デフォルトは1週間(秒単位)に設定されています。この値は、Expiresヘッダーと常に同期している必要があります。このヘッダーは、旧バージョンのMicrosoft Internet Explorerで静的ファイルを適切にキャッシュできるようにするために必要です。

      • デフォルトURLの処理

        DirectoryIndex default.jsp

        このディレクティブは、ユーザーが/analytics URLをリクエストして、その下のコンテンツを指定しなかった場合のフォールバック・ハンドラを提供します。このURLは、後続の処理でOracle WebLogic Serverにルーティングされます。

    • 最後のディレクティブでは、WEB-INFフォルダへのアクセスを制限します。このフォルダはJ2EEコンテナのデプロイメント・ディスクリプタの一部であり、Webクライアントに公開するものではありません。

  3. ファイルを保存して閉じます。

7.10.2Oracle HTTP Serverの静的ファイル・キャッシングの構成

Oracle HTTP Serverの構成は、Apache HTTP Serverの構成と似ています。ただし、Oracle HTTP Serverとともにデフォルトでmod_wl_ohs.soモジュールがインストールされるため、プラグインをダウンロードしてインストーする必要がない点が異なります。mod_wl_ohs.soモジュールで直接行う構成もあれば、httpd.confで行う構成もあります。詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

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