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

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

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

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

パフォーマンスのチューニング

Oracle WebLogic Serverのパフォーマンスのチューニング

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

サービス・レベルの監視

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

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

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

WSLTコマンドを使用してメトリック情報を定期的にファイルに保存すると、過去のメトリック値の記録を作成できます。『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のDMSのカスタムWLSTコマンドに関する項を参照してください。

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

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

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

Fusion Middleware Controlの「パフォーマンス・サマリー」ページから、使用可能なすべてのOracle Business Intelligenceメトリックを表示してグラフを作成できます。

データは、一時的にロギングされます(つまり、ロギングが開始されるのは、そのページを表示し、特定のメトリックを表示するように選択したときです)。

  1. ツリー・ナビゲータで、「Business Intelligence」フォルダを開き、biinstanceノードを右クリックします。
  2. 「監視」を選択し、「パフォーマンス・サマリー」を選択します。「パフォーマンス・サマリー」ページが表示され、このOracle Business Intelligenceインストールで選択されているメトリックが表示されます。
  3. 「パフォーマンス・サマリー」ページに表示されているメトリックをカスタマイズするには、「メトリック・パレットの表示」をクリックします。次に、該当のメトリック・カテゴリを開き、個々のメトリックを選択するか、選択を解除します。選択するメトリックが、「パフォーマンス・サマリー」ページに表示されます。

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

Javaコンポーネントのメトリックを表示するには、管理コンソールを使用します。

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

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

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

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

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

  5. 「監視」タブをクリックします。

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

  1. 管理コンソールにログインします。
  2. 「チャートとグラフ」で、「監視ダッシュボード」をクリックします。
  3. 「メトリック・ブラウザ」タブをクリックします。

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

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

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

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

  • 基礎となるデータベースのチューニングと索引付け: Oracle BIサーバーのデータベース問合せを迅速に返すには、基礎となるデータベースを正しく構成、チューニングおよび索引付けする必要があります。データベース製品ごとにチューニングの考慮事項がそれぞれ異なるので注意してください。

    基礎となるデータベースからの戻りに時間がかかる問合せがある場合は、問合せのSQL文を問合せログに取得し、それをデータベース管理者(DBA)に提供して分析してもらいます。「問合せログの管理」を参照してください。

  • 集計表: 問合せのパフォーマンスを向上するには、集計表の使用が非常に重要です。集計表には、データの合計があらかじめ計算されて含まれています。詳細な数千もの行から答えを再計算するより、集計表から答えを取得する方がはるかに高速です。

    Oracle BIサーバーでは、リポジトリに正しく指定されている場合、集計表が自動的に使用されます。集計ナビゲーションの設定例については、Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイドを参照してください。

  • 問合せキャッシング: Oracle BIサーバーでは、後続の問合せで再利用するために、問合せ結果を保存しておくことができます。問合せキャッシングにより、よく使用されるダッシュボードの場合は特に、ユーザーに対する見かけ上のシステム・パフォーマンスが大幅に向上します。ただし、ほとんどの非定型な分析ではパフォーマンスは向上しません。「Oracle BIサーバーの問合せキャッシュについて」を参照してください。

  • Fusion Middleware Controlでのパラメータの設定: Fusion Middleware Controlを使用して各種のパフォーマンス構成パラメータを設定することで、システムのパフォーマンスを向上できます。「Fusion Middleware Controlでのパフォーマンス・パラメータの設定」を参照してください。

  • NQSConfig.INI内のパラメータの設定: NQSConfig.INIファイルには、一時記憶域用のディスク容量を構成するパラメータ、仮想表のページ・サイズを設定するパラメータ、その他の詳細な構成設定など、Oracle BIサーバーの構成およびチューニングの追加パラメータが含まれています。「構成ファイル設定」を参照してください。

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

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

Fusion Middleware Controlで設定できるいくつかのパフォーマンス・オプションがあります。

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

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

Fusion Middleware Controlを使用して、デフォルト・リポジトリ・ファイルへの更新を許可するか回避するかを指定できます。

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

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

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

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. 「Business Intelligence概要」ページに移動します。
  2. 「構成」ページの「パフォーマンス」タブを表示します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. 「RPD更新を許可しない」を選択して、リポジトリ・ファイルへの更新を回避します。
  5. 「適用」,をクリックしてから、「変更のアクティブ化」をクリックします。
  6. 「可用性」ページの「プロセス」タブに移動して、「すべて再起動」をクリックします。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

ユーザー・セッションのログオフ期間を設定するためのFusion Middleware Controlの使用

ユーザーが自動的にログオフされるまでの経過時間(分単位)をオーバーライドできます。

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. 「Business Intelligence概要」ページに移動します。
  2. 「構成」ページの「パフォーマンス」タブを表示します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. 「ユーザー・セッションの失効」オプションを設定します。
  5. 「適用」をクリックし、「変更のアクティブ化」をクリックして、変更を実行し、別のシステム管理者が変更できるようにロックを解除します。
  6. Business Intelligence概要ページに戻り、「再起動」をクリックします。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

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

この手順では、表およびピボット表のデータの基本的な構成オプションについて説明します。

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

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. 「Business Intelligence概要」ページに移動します。
  2. 「構成」ページの「パフォーマンス」タブを表示します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. 次のオプションを設定します。
  5. 「適用」,をクリックしてから、「変更のアクティブ化」をクリックします。
  6. Business Intelligence概要ページに戻り、「再起動」をクリックします。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

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

ビューをレンダリングするためにOracle BIサーバーから処理できる最大行数をオーバーライドできます。

表の行数を減らすと、指定のユーザー・セッションで消費されるシステム・リソースが減少し、パフォーマンスが大幅に向上することがあります。

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

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. 「Business Intelligence概要」ページに移動します。
  2. 「構成」ページで、「パフォーマンス」タブを選択します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. ページのヘルプ・トピックの説明を使用して、「表ビューのレンダリング時に処理された最大行数」フィールドを設定します。50より大きな整数値を入力してください。
  5. 「適用」,をクリックしてから、「変更のアクティブ化」をクリックします。
  6. Business Intelligence概要ページに戻り、「再起動」をクリックします。
この値を設定する際は、次の点に注意してください。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

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

Oracle BIサーバーを構成して、問合せ結果セットのディスクベース・キャッシュをローカルに保持できます(問合せキャッシュ)。

問合せキャッシュを使用すると、Oracle BIサーバーがバックエンド・データソースにアクセスせずに、後続の問合せリクエストを多数処理できるため、問合せパフォーマンスが向上します。

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

  • 手動。Oracle BI管理ツールの「管理」メニューで「キャッシュ」を選択して、キャッシュ・マネージャを開きます。キャッシュ・マネージャでは、パージするキャッシュ・エントリやパージする日時をきわめて柔軟に選択できますが、手動の作業が必要です。「キャッシュ・マネージャの使用」を参照してください。

  • 自動。管理ツールでは、システムのキャッシュの無効化、特定の物理表のキャッシュ属性の設定、およびOracle Business Intelligenceイベント表を使用してのキャッシュの自動パージが可能です。「キャッシュの監視と管理」を参照してください。

  • プログラムによるサポート。Oracle BIサーバーには、プログラムでキャッシュ・エントリをパージするためのODBC拡張関数があります。これらの関数により、イベント表の自動化に関して、キャッシュ・マネージャの選択とタイミングの柔軟性が高まります。独自のスクリプトを記述して、これらの関数を必要に応じて呼び出すことができます。「ODBCプロシージャを使用するキャッシュのパージと保守」を参照してください。

問合せキャッシングを制御するパラメータは、Fusion Middleware Controlと、「構成ファイル設定」に記載されているNQSConfig.INIファイルにあります。「Oracle BIサーバー・キャッシュをシードするためのエージェントの使用」を参照してください。

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

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

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

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

問合せキャッシュ・エントリは、WindowsやUNIXの64ビットのアーキテクチャなどの異なるオペレーティング・システム間で移植可能です。互換性のないキャッシュ・エントリは、自動的に削除されます。

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

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

キャッシングの利点

問合せを最も速く処理する方法は、大部分の処理をスキップして、あらかじめ計算された答えを使用する方法です。

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

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

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

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

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

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

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

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

キャッシングに伴う代償

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

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

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

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

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

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

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

ディスク領域

問合せキャッシュには、専用のディスク領域が必要です。

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

管理タスク

管理タスクには、キャッシングに関連するがものがあります。各物理表に対して、その表内のデータの更新間隔を理解した上で、キャッシュの保持時間を適切に設定する必要があります。

更新の頻度が状況によって異なる場合は、変更が発生するタイミングを追跡し、必要に応じてキャッシュを手動でパージする必要があります。キャッシュのイベント・ポーリング表を作成し、データベースに対する変更が発生するときにポーリング表を更新するようにアプリケーションを変更することで、システムをイベント駆動型にすることもできます。

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

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

基礎となるデータベース内のデータが変更されたときにキャッシュ・エントリがパージされないと、問合せが返す結果が最新のものでなくなる可能性があります。

これが許容できるかどうかを評価する必要があります。キャッシュに多少古いデータが含まれていても、許容できる場合があります。許容できる古いデータのレベルを決定し、そのレベルを反映する一連のルールを構成(およびルールに準拠)する必要があります。

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

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

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

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

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

通常はごくわずかであるとはいえ、問合せキャッシングではCPU時間が必要であり、ディスクI/Oが増加します。

ほとんどの場合、CPU使用率とディスクI/Oは微々たるものです。ディスクI/Oの増加は、問合せで大量のデータ・セットが返される場合にのみ顕著となる可能性があります。

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

特定の接続プールに対して共有ログオンが有効化されている場合は、ユーザー間でのキャッシュの共有が可能であり、ユーザーごとにキャッシュをシードする必要はありません。

共有ログオンが有効ではなく、ユーザー固有のデータベース・ログオンが使用されている場合は、各ユーザーが独自のキャッシュ・エントリを生成します。

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

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

通常、XMLデータソースは頻繁にリアルタイムで更新されます。XMLデータソースのリフレッシュ間隔を設定することは、データベース表のキャッシュの永続性を設定するようなものです。

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

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

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

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

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

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

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

クラスタ環境では、グローバル・キャッシュと呼ばれる共有キャッシュにアクセスするようにOracle BIプレゼンテーション・サービスを構成できます。

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

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


GUID-5282B51A-7FA1-4950-A045-FC9E4BB3AA3B-default.gifの説明が続きます
GUID-5282B51A-7FA1-4950-A045-FC9E4BB3AA3B-default.gifの説明

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

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

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

注意:

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

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

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

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

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

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

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

問合せキャッシュとグローバル・キャッシュのどちらに対しても、キャッシュ記憶域などのパラメータは、Fusion Middleware ControlとNQSConfig.INIファイルで構成します。

古いキャッシュ・エントリのフラッシュの方針についても決める必要があります。詳細は、「キャッシュの監視と管理」を参照してください。

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

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

Fusion Middleware Controlを使用して、問合せキャッシングを有効または無効にできます。

問合せキャッシュは、デフォルトで有効化されています。

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. Fusion Middleware ControlのOracle Business Intelligenceページの表示の説明に従って、Business Intelligenceの「概要」ページに移動します。
  2. 「構成」ページの「パフォーマンス」タブを表示します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. 問合せキャッシングを有効にするには、「キャッシュ有効」を選択します。問合せキャッシングを無効にするには、「キャッシュ有効」の選択を解除します。
  5. 「適用」,をクリックしてから、「変更のアクティブ化」をクリックします。
  6. Business Intelligence概要ページに戻り、「再起動」をクリックします。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

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

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

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. Fusion Middleware ControlのOracle Business Intelligenceページの表示の説明に従って、Business Intelligenceの「概要」ページに移動します。
  2. 「構成」ページの「パフォーマンス」タブを表示します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. このページのヘルプ・トピックの説明を参照して、各要素を設定します。

    • 最大キャッシュ・エントリ・サイズ

    • 最大キャッシュ・エントリ

  5. 「適用」,をクリックしてから、「変更のアクティブ化」をクリックします。
  6. Business Intelligence概要ページに戻り、「再起動」をクリックします。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

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

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

次のようなパラメータがあります。

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

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

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

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

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

グローバル・キャッシュ・パラメータを設定するためのFusion Middleware Controlの使用

グローバル・キャッシュ・パラメータを設定すると、システム・キャッシュ構成全体で一貫性が保たれます。

この手順を始める前に、「Fusion Middleware Controlの使用」で説明している情報について確認しておいてください。

  1. Fusion Middleware ControlのOracle Business Intelligenceページの表示の説明に従って、Business Intelligenceの「概要」ページに移動します。
  2. 「構成」ページの「パフォーマンス」タブを表示します。
  3. 「ロックと編集」をクリックして、変更を実行できるようにします。
  4. 次のオプションを設定します。

    • グローバル・キャッシュ・パス

    • グローバル・キャッシュ・サイズ

  5. 「適用」,をクリックしてから、「変更のアクティブ化」をクリックします。
  6. Business Intelligence概要ページに戻り、「再起動」をクリックします。

対応する構成ファイルの要素の詳細は、ユーザー・インタフェース・ラベルと構成ファイルの要素のマッピングを参照してください。

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

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

次のようなパラメータがあります。

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

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

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

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

    BI_DOMAIN/servers/obisn/logs

「構成ファイル設定」を参照してください。

キャッシュの監視と管理

基礎となるデータベース内の変更を管理し、キャッシュ・エントリを監視するには、キャッシュの管理方針を決める必要があります。

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

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

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

キャッシュ管理方針の選択は、基礎となるデータベース内のデータの変動性と、この変動を引き起こす変更の予測可能性に依存します。

また、キャッシュに含まれる問合せの数と種類、およびその問合せの使用状況にも依存します。この項では、様々なキャッシュ管理方法の概要を説明します。

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

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

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

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

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

各物理表のキャッシュ可能属性を設定することで、その表に対する問合せをキャッシュに追加して、今後の問合せに答えを返すかどうかを指定できます。

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

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

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

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

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

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

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

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

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

Oracle BIサーバーのイベント・ポーリング表には、基礎となるデータベース内の更新に関する情報が保存されます。

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

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' );

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''というアイテムのエスケープ文字として使用されている、追加の一重引用符を示しています。

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

ユーザーがアンサーにアクセスして問合せを実行すると、プレゼンテーション・サービスは問合せの結果をキャッシュします。

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

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

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

SAGetSharedRequestKey('sql-string-literal')

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

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

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

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

「Oracle BIプレゼンテーション・サービス・キャッシュ設定の管理」を参照してください。

結果レコードについて

キャッシュをパージするコマンドを実行すると、結果レコードが返されます。

結果レコードには、2つの列が含まれています。最初の列は結果コードで、2番目の列は、パージ操作の結果を説明する短いメッセージです。次の表は、結果レコードの例を示しています。

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

1

SAPurgeCacheByDatabaseが正常終了しました。

59115

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

59116

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

59117

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

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

Microsoft Analysis ServicesとSAP/BWのデータ・ソースでは命名規則が異なるため、メンバーの一意の名前を格納するためのキャッシュ・サブシステムがあります。

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

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

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

注意:

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

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

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

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

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

    注意:

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

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

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

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

    SAPurgeALLIMCNCache ()

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

    SAPurgeMCNCacheByCube( 'DBName', 'CubeName')

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

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

1

SAPurgeALLMCNCacheが正常終了しました。

1

SAPurgeMCNCacheByCubeが正常終了しました。

59116

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

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

85025

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

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

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

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

オンライン・モード

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

オフライン・モード

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

リポジトリ間の切替え

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

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

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

動的リポジトリ変数の値が変更されると、列でこの変数を使用するBIサーバーのキャッシュ・エントリが失効し、そのエントリのデータが再び必要となったときに、新しいキャッシュ・エントリが生成されます。古いキャッシュ・エントリはすぐに削除されず、通常のキャッシュ・メカニズムによって消去されるまでそのまま残ります。

キャッシュの使用方針

問合せキャッシングの主要な利点の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)

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

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

キャッシングが有効な場合は、各問合せが評価されて、キャッシュ・ヒットと見なされるかどうかが判断されます。

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

キャッシュがヒットするかどうかは、多くの要因によって決まります。次の表はそれらの要因を示しています。

要因またはルール 説明

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句にかかわらず、キャッシュ・ヒットとみなされます。

さらに、WHERE句で使用されている列はプロジェクション・リストに存在する必要があります。次に例を示します。

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

REGIONがプロジェクション・リストにないため、前のリストのシード中の問合せに対してキャッシュ・ヒットになりません。

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

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

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

時系列関数(AGO、TODATEおよびPERIODROLLING)、極限関数およびオフセット関数(OFFSETおよびFETCH)、関係関数(ISANCESTOR、ISLEAF、ISROOTおよびISSIBLING)、外部集計関数などの特殊関数と一般的にフィルタ・メトリックを含むその他の問合せも、キャッシュされた問合せ内のプロジェクション列と完全一致する必要があります。このようなケースでは、フィルタも完全一致の必要があります。フィルタ・メトリックについては、フィルタ・メトリックをWHERE句として書き直せる場合、サブセット・キャッシュが利用される可能性があります。

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

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

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

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

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

同等の結合条件

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

同じ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」を参照してください。

キャッシュ・ヒット動作の診断

キャッシュ・ヒット動作をより適切に評価するには、次の例に示すように、ENABLE_CACHE_DIAGNOSTICSセッション変数を4に設定します。

ENABLE_CACHE_DIAGNOSTICS=4

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

仮想プライベート・データベース(VPD)のような行レベルのデータベース・セキュリティ方針を使用している場合、返されるデータ結果は、ユーザーの認可資格証明で決まります。

このため、Oracle BIサーバーは、行レベルのデータベース・セキュリティを使用しているかどうか、およびセキュリティに関係する変数を把握する必要があります。

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

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

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

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

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

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

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

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

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

キャッシュ・ヒットの可能性を最大限に高める1つの方法は、一連の問合せを実行してキャッシュを移入することです。

キャッシュをシードする一連の問合せを作成するときに使用する問合せの種類に関して、いくつかの推奨事項があります。

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

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

    SELECT QUANTITY, REVENUE...

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

    SELECT QUANTITY/REVENUE...

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

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

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

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

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

エージェントを構成して、Oracle BIサーバー・キャッシュをシードできます。

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

  1. Oracle Business Intelligenceにログインし、「新規」を選択し、「エージェント」を選択します。
  2. 「一般」タブで、「実行者」オプションの「受信者」を選択します。パーソナライズされたキャッシュ・シードでは、各受信者のデータ可視性に基づいて、エージェントによる各受信者へのコンテンツの配信をカスタマイズします。
  3. 「スケジュール」タブで、キャッシュをシードするタイミングを指定します。
  4. 必要に応じて「条件」を選択し、条件付きリクエストを作成または選択します。たとえば、ETLプロセスがいつ完了するかを決定するビジネス・モデルがあるものとします。このビジネス・モデルに基づくレポートを使用して、キャッシュ・シードを開始する条件付きトリガーとなることができます。
  5. 「配信コンテンツ」タブで、個々のリクエスト、またはキャッシュ・シードの対象となるダッシュボード・ページ全体を選択します。ダッシュボード・ページの選択は、時間の節約になります。
  6. 「受信者」タブで、受信者である個々のユーザーまたはグループを選択します。
  7. 「送信先」タブで、すべてのユーザー送信先の選択を解除し、「Oracle BIサーバー・キャッシュ」を選択します。
  8. 右上隅にある「保存」ボタンを選択して、エージェントを保存します。

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

注意:

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

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

キャッシュ・マネージャを使用すると、問合せキャッシュ全体に関する情報と、開いているリポジトリに関連付けられている問合せキャッシュ内の個々のエントリに関する情報を表示できます。

また、キャッシュ・マネージャを使用して特定のキャッシュ・エントリを選択し、そのエントリに対して、キャッシュされているSQL文の表示と保存、エントリのパージなど、様々な操作を実行できます。

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

  2. 「キャッシュ」タブをクリックすると、現在のリポジトリのキャッシュ・エントリ、ビジネス・モデルおよびユーザーが表示されます。

    関連するキャッシュ・エントリが右側のペインに反映され、上部の表示専用フィールドにエントリの総数が表示されます。

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

オプション 説明

ユーザー

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

作成

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

最終使用

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

作成からの経過時間

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

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

行数

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

行サイズ

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

フル・サイズ

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

列数

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

論理リクエスト

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

使用回数

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

ビジネス・モデル

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

リポジトリ

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

SQL

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

サーバーの問合せ

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

ファクト表ソース

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

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

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

グローバル・キャッシュ情報を表示するには、「アクション」を選択し、「情報の表示」を選択します。

次の表は、「グローバル・キャッシュ情報」ウィンドウに表示される情報を示しています。

列 説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

キャッシュ・エントリは、次の方法でパージできます。

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

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

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

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

注意:

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

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

次のように、キャッシュ・マネージャでキャッシュ・エントリを手動でパージできます。

  1. 管理ツールを使用してオンライン・モードでリポジトリを開きます。
  2. 「管理」→「キャッシュ」を選択して、「キャッシュ・マネージャ」ダイアログを開きます。
  3. 左ペインの該当のタブを選択することによって、キャッシュ・モードまたは物理モードを選択します。
  4. エクスプローラ・ツリーを参照して、関連するキャッシュ・エントリを右ペインに表示します。
  5. パージするキャッシュ・エントリを選択し、「編集」→「パージ」を選択して、選択されているエントリを削除します。または、選択されているエントリを右クリックし、「パージ」を選択します。

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

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

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

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

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

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

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

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

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

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

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

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

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

1つ以上の物理表が更新されたことをOracle BIサーバーに通知する方法として、Oracle BIサーバーのイベント・ポーリング表(イベント表)を使用できます。イベント表に追加される各行は、本番データベース内の本番表に対して発生する更新など、単一の更新イベントを表します。

Oracle BIサーバー・キャッシュ・システムは、イベント表から行を読み込み(ポーリング)、物理表の情報を行から抽出し、その物理表を参照する古いキャッシュ・エントリをパージします。

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

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

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

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

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

各物理データベース上に物理イベント・ポーリング表を構成して、データベース内の変更を監視できます。

独自のデータベースでイベント表を構成することもできます。イベント表は、データベース内の表が変更されるたびに更新されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 「ツール」メニューから「ユーティリティ」を選択します。
  2. オプション・リストから「Oracle BIイベント表」オプションを選択します。
  3. 「実行」をクリックします。
  4. イベント表として登録する表を選択し、「>>」ボタンをクリックします。
  5. ポーリング間隔を分単位で指定し、「OK」をクリックします。

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

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

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

Oracle BIサーバーが、イベント・ポーリング表を移入することはありません。イベント表が更新されるたびに行を挿入することによって、イベント表が移入されます。

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

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

イベント・ポーリング表に関する問題のトラブルシューティングは、アクティビティ・ログから開始できます。

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

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

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

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

BI_DOMAIN/servers/obisn/logs

データソース・キャッシュの構成

データ・ブレンドのパフォーマンスを高めるには、データソース・キャッシュを構成してください。このことは、データベースを使用するか、またはファイル・システム上で実行できます。

ファイル・システムでのデータソース・キャッシュの作成

BIサーバーによる直接アクセスのために、データソース・キャッシュのデータをファイル・システムに格納できます。これがデフォルトの構成です。これは、アップロードしたスプレッドシート・ファイルなど、小規模から中規模のデータソースに適しています。大規模なデータソースの場合は、データソース・キャッシュをデータベースに構成すると、より優れたパフォーマンスを得られます。

ファイル・システム・ベースのデータソース・キャッシュは、次のように機能します。

  1. BIサーバーがデータソースに対する論理SQL文を受け取ります。

  2. BIサーバーはデータソースのメタデータを取得します。メタデータの内容を使用して、BIサーバーは、データソースのデータをリクエストするかわりに、問合せへの応答に使用可能な既存のデータソース・キャッシュ・エントリが存在するかどうかをチェックします。

  3. いずれのデータソースにも既存のデータソース・キャッシュ・エントリがない場合、BIサーバーは、データソースのデータをキャッシュにロードするスレッドを開始します。

  4. 論理SQL文(および同じデータソースのデータを要求する他のすべての同時論理SQL文)は、スレッドの終了を待機します。

  5. スレッドの実行が完了すると、新たにシードされたデータソース・キャッシュ・エントリに依存するすべてのサブリクエストでこのキャッシュが使用されます。

ファイル・システムにデータソース・キャッシュを構成する手順は、次のとおりです。

  1. NQSConfig.INIファイルのXSA_CACHEセクションを次のように変更します。
    [XSA_CACHE]
ENABLE = YES;

# The schema and connection pool where the XSA data will be cached. 
# Set PHYSICAL_SCHEMA to ""."" to use file-based XSA cache. 
# This indicates that a file-based XSA cache should be used by BI Server and the value of the CONNECTION_POOL parameter should be ignored.
PHYSICAL_SCHEMA = "".""; # "<Database>"."<Schema>"; 
CONNECTION_POOL = "".""; # "<Database>"."<Connection Pool>";

# The path to the location where cache data files will be persisted. 
# This is only used if file-based XSA cache is configured. 
# If a relative path is specified, it will be relative to: 
# BI_DOMAIN/servers/obisn 
STORAGE_DIRECTORY = "storage"; # location where the cache data files are stored

# The maximum space allocated in the schema for the cache data.
MAX_TOTAL_SPACE = 5 GB;

# The maximum size allowed for a single XSA cache entry. 
MAX_CACHE_ENTRY_SIZE = 200 MB;

# The path to the location where descriptor files of the cache data will be persisted. 
# If a relative path is specified, it will be relative to: 
# BI_DOMAIN/servers/obisn 
DESCRIPTOR_STORAGE_PATH = "xsacache"; # location where the cache metadata files are stored

# The number of threads available for seeding XSA cache entries. 
CACHE_SEED_THREAD_RANGE = 0-40; 
CACHE_SEED_THREAD_STACK_SIZE = 0; # default is 256 KB (32 BIT mode), 1 MB (64 BIT mode), 0 for default

  2. BIサーバーを再起動します。

  3. データソース・キャッシュが正しく構成されていることを検証するには、obis1-diagnostic.logをチェックします。サーバー起動時に、次のようなエントリを探します。
    [2017-01-13T14:41:30.715-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101043] External Subject Area cache with internal storage is started successfully using configuration from the repository with the logical name Star.
[2011-01-13T14:41:30.716-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101017] External Subject Area cache has been initialized. Total number of entries: 0 Used space: 0 bytes Maximum space: 107374182400 bytes Remaining space: 107374182400 bytes. Cache table name prefix is XC.

データソース・キャッシュを有効にすると、NQSConfig.INIのXSA_CACHEセクションのSTORAGE_DIRECTORYパラメータの定義に従って、ファイル・システムにデータソースのデータが格納されます。メタデータは、NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定された、ローカル・ファイル・システムのディレクトリに格納されます。パフォーマンスを向上させるには、データソースのデータおよびデータソース・キャッシュのメタデータ・ファイルをRAMディスクに配置します。

データベースでのデータソース・キャッシュの作成

大規模なデータソースの場合は、データソース・キャッシュをデータベースに構成すると、より優れたパフォーマンスを得られます。

データベース・ベースのデータソース・キャッシュは、次のように機能します。

  1. BIサーバーがデータソースに対する論理SQL文を受け取ります。

  2. BIサーバーはデータソースのメタデータを取得します。メタデータの内容を使用して、BIサーバーは、データソースのデータをリクエストするかわりに、問合せへの応答に使用可能な既存のデータソース・キャッシュ・エントリが存在するかどうかをチェックします。データソース・キャッシュを使用できるサブリクエストはすべて、キャッシュ・データベースのネイティブ物理SQLに再書込みされます。

  3. いずれのデータソースにも既存のデータソース・キャッシュ・エントリがない場合、BIサーバーは、データソースのデータをキャッシュ・データベースにロードするスレッドを開始します。各データソースは、データソースのすべての列を含む単一のデータベース表に変換されます。

  4. 論理SQL文(および同じデータソースのデータを要求する他のすべての同時論理SQL文)は、スレッドの終了を待機します。

  5. スレッドの実行が完了すると、新たにシードされたデータソース・キャッシュ・エントリに依存するすべてのサブリクエストが、キャッシュ・データベースのネイティブ物理SQLに再書込みされます。

サポートされている次の2つのデータソース・キャッシュ・データベース設定から選択できます。

データ・ウェアハウスとは異なるデータベースでのデータソース・キャッシュの構成

  1. キャッシュ・データベースを表す物理オブジェクトをリポジトリに作成します。これには、新規データベース・オブジェクト、新規物理スキーマ・オブジェクトおよび新規接続プールが含まれます。この例では、データベース・オブジェクトの名前はXSACache、接続プールの名前はCP、新規物理スキーマ・オブジェクトの名前はXSA_CACHEです。

    • 接続プールで使用されるユーザー名は、スキーマの名前と同じである必要があります。

    • 接続プールに指定されているユーザーは、スキーマ内の表に対してDDLおよびDMLを実行するために必要な権限を持っている必要があります。たとえば、Oracleでは、ユーザーは少なくともCREATE TABLE権限を持っている必要があります。

  2. NQSConfig.INIのXSA_CACHEセクションにあるパラメータを、適切なスキーマおよび接続プールを指し示すように更新します。 

    [XSA_CACHE]
ENABLE = YES;

# The schema and connection pool where the XSA data will be cached. 
# Set PHYSICAL_SCHEMA to ""."" to use file-based XSA cache. 
PHYSICAL_SCHEMA = "XSACache"."XSA_CACHE"; # "<Database>"."<Schema>"; 
CONNECTION_POOL = "XSACache"."CP"; # "<Database>"."<Connection Pool>";

# The path to the location where descriptor files of the cache data will be persisted. 
# If a relative path is specified, it will be relative to: 
# BI_DOMAIN/servers/obisn 
DESCRIPTOR_STORAGE_PATH = "xsacache"; # location where the cache metadata files are stored

  3. BIサーバーを再起動します。

  4. データソース・キャッシュが正しく構成されていることを検証するには、obis1-diagnostic.logをチェックします。サーバー起動時に、次のようなエントリを探します。
    [2017-01-13T14:41:30.715-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101001] External Subject Area cache is started successfully using configuration from the repository with the logical name Star.
[2011-01-13T14:41:30.716-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101017] External Subject Area cache has been initialized. Total number of entries: 0 Used space: 0 bytes Maximum space: 107374182400 bytes Remaining space: 107374182400 bytes. Cache table name prefix is XC2627531314.

データソース・キャッシュを有効にすると、データソースのデータがデータベースに格納されます。ただし、メタデータは、NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定された、ローカル・ファイル・システムのディレクトリに格納されます。パフォーマンスを向上させるには、データソース・キャッシュのメタデータ・ファイルをRAMディスクに配置します。

データ・ウェアハウスと同じデータベースでのデータソース・キャッシュの構成

この構成により、結合がBIサーバーによって内部的に実行されるのではなく、データソースにプッシュ・ダウンされるため、問合せパフォーマンスが向上します。

  1. キャッシュ・データベースを表す物理オブジェクトをデータ・ウェアハウス・データベース・オブジェクトのリポジトリに作成します。これには、新規物理スキーマ・オブジェクトおよび新規接続プールが含まれます。この例では、新規接続プールの名前はXSA Cache Connection Poolで、物理スキーマ・オブジェクトの名前はXSA_CACHEです。

    アプローチとしては、データ・ウェアハウスの接続プールで、別のスキーマに作成されたデータソース・キャッシュ表に問合せを実行できるようにしながら、データソース・キャッシュのシードおよびパージ専用の接続プールを設定します。管理を単純化するには、データソース・キャッシュ・スキーマに専用の表領域を設定することが理想的です。

    • 新規接続プールで使用されるユーザー名は、新規スキーマの名前と同じである必要があります。

    • 新規接続プールに指定されているユーザーは、新規スキーマ内の表に対してDDLおよびDMLを実行するために必要な権限を持っている必要があります。たとえば、Oracleでは、ユーザーは少なくともCREATE TABLE権限を持っている必要があります。

    • 元のデータ・ウェアハウス接続プールに指定されているユーザーは、新規スキーマ内の表のSELECTに必要な権限を持っている必要があります。たとえば、Oracleでは、既存のデータ・ウェアハウス接続プールのユーザーは少なくともSELECT ANY TABLE権限を持っている必要があります。

    • データソース・キャッシュ接続プールをデータベース・オブジェクトのプライマリ接続プールにしないでください。つまり、データソース・キャッシュ接続プールは、データ・ウェアハウスの問合せに使用されるデータ・ウェアハウス接続プールの後に配置されている必要があります。

  2. NQSConfig.INIのXSA_CACHEセクションにあるパラメータを、適切なスキーマおよび接続プールを指し示すように更新します。 

    [XSA_CACHE]
ENABLE = YES;

# The schema and connection pool where the XSA data will be cached. 
# Set PHYSICAL_SCHEMA to ""."" to use file-based XSA cache. 
PHYSICAL_SCHEMA = "Oracle Data Warehouse"."Catalog"."XSA_CACHE"; # "<Database>"."<Schema>"; 
CONNECTION_POOL = "Oracle Data Warehouse"."XSA Cache Connection Pool"; # "<Database>"."<Connection Pool>";

# The path to the location where descriptor files of the cache data will be persisted. 
# If a relative path is specified, it will be relative to: 
# BI_DOMAIN/servers/obisn 
DESCRIPTOR_STORAGE_PATH = "xsacache"; # location where the cache metadata files are stored

  3. BIサーバーを再起動します。

  4. データソース・キャッシュが正しく構成されていることを検証するには、obis1-diagnostic.logをチェックします。サーバー起動時に、次のようなエントリを探します。
    [2017-01-13T14:41:30.715-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101001] External Subject Area cache is started successfully using configuration from the repository with the logical name Star.
[2011-01-13T14:41:30.716-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101017] External Subject Area cache has been initialized. Total number of entries: 0 Used space: 0 bytes Maximum space: 107374182400 bytes Remaining space: 107374182400 bytes. Cache table name prefix is XC2627531314.

データソース・キャッシュを有効にすると、アップロードされたファイルのデータがデータベースに格納されます。ただし、メタデータは、NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定された、ローカル・ファイル・システムのディレクトリに格納されます。パフォーマンスを向上させるには、データソース・キャッシュのメタデータ・ファイルをRAMディスクに配置することをお薦めします。

データソース・キャッシュの管理

データソース・キャッシュを有効にした後で、個々のキャッシュ・エントリまたはキャッシュ全体の削除が必要になることがあります。

データソース・キャッシュ・エントリの削除

Oracle BIサーバーには、キャッシュ・エントリをパージするためのODBC拡張関数があります。ストアド・プロシージャの書式は、次のとおりです。
call SAPurgeXSACache('<XSA_PATH>', '<XSA_TABLE>');

<XSA_PATH>は、データソース定義へのパスです。これは、論理SQL内のXSA()句で使用される値です。このパラメータではワイルドカード文字%もサポートされており、これを使用してシステム内のすべてのデータソース・キャッシュ・エントリをパージできます。

<XSA_TABLE>は、データソース内の表の名前です。これは、論理SQL内のXSA()句の後に続く値です。このパラメータではワイルドカード文字%もサポートされており、これを使用してデータソース定義内のすべての表のキャッシュ・エントリをパージできます。

たとえば、データソース・キャッシュ・エントリが、SELECT XSA('weblogic'.'Sample Order Lines')."Columns"."Product Category" FROM XSA('weblogic'.'Sample Order Lines')という問合せを使用して生成されているとします。

  • データソース・キャッシュ・エントリをパージするには、call SAPurgeXSACache('''weblogic''.''Sample Order Lines''', 'Columns');を使用します

  • システム内のすべてのデータソース・キャッシュ・エントリをパージするには、call SAPurgeXSACache('%', '%');を使用します

ファイル・システム上のキャッシュの手動クリーンアップ

データソース・キャッシュ・エントリを手動で削除するには、次のステップを使用します。

  1. BIサーバーを停止します。

  2. NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHおよびSTORAGE_DIRECTORYパラメータで指定されているディレクトリ内のファイルを削除します。

データベース内のキャッシュの手動クリーンアップ

次の理由により、データソース・キャッシュ・スキーマにあるすべての表の削除が必要になることがあります。

  • 古いインストールを置き換える新しいBIサーバーのインストールで使用される既存スキーマをクリーンアップするため。

  • メンテナンスによるダウンタイム中に、白紙の状態でのデータソース・キャッシュを開始するため。

キャッシュを消去する手順は、次のとおりです。

  1. このスキーマを使用するBIサーバーが実行されていないことを確認します。表を削除するときにこのようなサーバーが実行されていると、これらのサーバーが不整合な状態で残り、結果として、これらのサーバーが再起動されるまで、表が見つからないというエラーによりデータソースの問合せが失敗します。

  2. SQLクライアントから、データソース・キャッシュ・スキーマのユーザーとしてデータベースにログインします。

  3. 次のPL/SQLを実行します。
    BEGIN  
FOR i IN (SELECT table_name FROM user_tables where table_name like 'XC%')  
LOOP  
EXECUTE IMMEDIATE('DROP TABLE ' || user || '.' || i.table_name || ' CASCADE CONSTRAINTS PURGE');  
END LOOP;  
END;
    データソース・キャッシュの表の名前は、先頭にXCが付くことに注意してください。

  4. NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定されているディレクトリ内のファイルを削除します。

Oracle BI Presentation Servicesキャッシュ設定の管理

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

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

BI_DOMAIN/servers/obips/tmp/obis_temp

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

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

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

「プレゼンテーション・サービス問合せキャッシュの共有について」を参照してください。

  1. 次の場所で編集するinstanceconfig.xmlファイルを開きます。

    BI_DOMAIN/config/fmwconfig/biconfig/OBIPS

  2. 次の表で説明している要素を追加する必要があるセクションを見つけます。

    注意:

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

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

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

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

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

要素 説明 デフォルト値

MaxEntries

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

500

MaxExpireMinutes

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

60

MinExpireMinutes

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

10

MinUserExpireMinutes

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

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

10

RefreshIncludeBIServerCache

ダッシュボードまたは分析のリフレッシュ時にプレゼンテーション・サービスのキャッシュをバイパスするかどうかを指定します。

Oracle Business Intelligence12c以降、分析またはダッシュボードをリフレッシュすると、キャッシュがバイパスされ、最新バージョンのデータが使用されます。以前はリフレッシュ時にキャッシュが使用されていました。このパラメータをfalseに設定すると、以前の動作に戻ります。

true

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

Oracle BI Webクライアントのパフォーマンスを向上させるには、すべての静的ファイルを処理するWebサーバーを構成し、静的リソースも動的リソースも圧縮を有効化します。

Webサーバー上でキャッシュおよびコンテンツの有効期限を有効にすると、Webブラウザでサーバーから静的ファイルをリロードする頻度を指定できます。

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

注意:

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

Oracle WebLogic Serverプロキシ・プラグインの使用

Oracle HTTP Serverの管理

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

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

この構成例は、Webサーバー・プラグインがインストールされていて、Apache HTTP ServerがOracle WebLogic Serverへリクエストをプロキシできることが前提です。

PLUGIN_HOME/libディレクトリが、LD_LIBRARY_PATHまたは使用しているオペレーティング・システムのこれに相当するものに追加されていることを確認します。

この項のステップは、構成例専用です。必要に応じて、構成を調整してください。詳細は、Oracle WebLogic Server Proxy Plug-Insの使用を参照してください。

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

  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 WebLogic Server Proxy Plug-Insの使用を参照してください。

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

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

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

  1. Apache HTTP Serverのhttpd.confファイルを見つけます。
  2. ファイルを編集用に開き、次のようなディレクティブを追加します。
    Alias /analytics ORACLE_HOME/bi/bifoundation/web/appv2
<Directory ORACLE_HOME/bi/bifoundation/web/appv2>
# 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/bi/bifoundation/web/appv2内の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. ファイルを保存して閉じます。

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

Oracle HTTP Serverの構成は、Apache HTTP Serverの構成と似ています。ただし、Oracle HTTP Serverとともにデフォルトでmod_wl_ohs.soモジュールがインストールされるため、プラグインをダウンロードしてインストールする必要がない点が異なります。

mod_wl_ohs.soモジュールで直接行う構成もあれば、httpd.confで行う構成もあります。『Oracle HTTP Serverの管理』を参照してください。

Oracle Business IntelligenceのJVMヒープ・サイズの設定

管理サーバーおよび管理対象サーバーのデフォルトJVMヒープ・サイズは、Oracle WebLogic Serverの起動スクリプトでUSER_MEM_ARGSパラメータを設定することにより変更できます。

次の手順で、管理サーバーと管理対象サーバーの両方に同じ値を設定します。

『Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。

  1. WebLogic Server管理コンソールを使用して、サーバーを正常に停止します。
  2. setDomainEnv.sh (Windowsシステムの場合はsetDomainEnv.bat)を編集用に開きます。次の場所にこのファイルを作成できます。

    BI_DOMAIN/bin

  3. USER_MEM_ARGSに、引数-Xmxを設定します。次のリストは、様々なオペレーティング・システムでUSER_MEM_ARGSを設定する方法の例を示しています。

    • UNIXシェル・スクリプト(.sh)

      USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -xx:PermSize=128m -XX:MaxPermSize=512m"

    • Windowsコマンド・スクリプト(.bat)

      set USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -xx:PermSize=128m -XX:MaxPermSize=512m"

    注意:

    USER_MEM_ARGSの引数は、JDKベンダーによって異なる可能性があります。
  4. パラメータの設定後、ファイルを保存して閉じ、変更内容を有効にするため、管理サーバーと管理対象サーバーを再起動します。
  5. スケールアウトされたシステムでは、各ドメインのホームでこれらのステップを繰り返します。

    水平方向にスケールアウトする場合に設定がコピーされます。

大規模レポートをダウンロードする際のパフォーマンスの向上

Oracle BI EE 12cでの大規模レポートのダウンロードでは、タイムアウト設定値を増やすことが必要になる場合があります。

レポートのダウンロードに6分よりも長くかかる場合は、次のようにタイムアウト設定値を増やします。

  1. <ORACLE HOME>/user_projects/domains/bi/config/fmwconfig/biconfig/bridgeconfig.propertiesを開きます

  2. oracle.bi.presentation.sawconnect.ConnectionPool.SocketReadTimeoutSecパラメータを探します。ファイルにない場合は追加します。

  3. このパラメータのデフォルト値は360秒(6分)です。必要に応じてパラメータ値を増やし、構成ファイルを保存します。

ロード・バランシングのためのF5 BIG-IPの使用

ロード・バランシングにF5 BIG-IPを使用しており、大規模レポートのダウンロードに5分よりも長くかかる場合は、次のようにタイムアウト設定値を増やします。

  1. BIG-IP構成ユーティリティにログインします。

  2. ナビゲーション・ペインのメイン・タブで、「Local Traffic」を展開し、「Profiles」→「Protocol」→「TCP」の順にクリックします。

  3. TCPプロファイルで「Idle Timeout」フィールドを探します。このパラメータのデフォルト値は300秒(5分)です。必要に応じてパラメータ値を増やします。

タイムアウト設定の詳細は、ASKF5 Knowledge Centerの記事『K7559: Overview of the TCP profile (9.x-10.x)』を参照してください

ロード・バランシングのためのOracle HTTP Serverの使用

ロード・バランシングにOracle HTTP Serverを使用しており、大規模レポートのダウンロードに5分よりも長くかかる場合は、次のようにタイムアウト設定値を増やします。

  1. ORACLE_INSTANCE/config/OHS/component_name/mod_wl_ohs.confを開きます

  2. ファイルの<IfModule weblogic_module>セクションを探し、そのセクションにWLIOTimeoutSecsという名前のパラメータを追加します。

  3. このパラメータのデフォルト値は300秒(5分)です。必要に応じてパラメータ値を増やし、構成ファイルを保存します。Oracle HTTP Serverを再起動します。

『Oracle WebLogic Serverプロキシ・プラグインの使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。

ダイナミック・モニタリング・サービスを使用したメトリックの取得

Fusion Middleware Controlのメトリック・ブラウザを使用する以外に、ダイナミック・モニタリング・サービス(DMS)やWLSTコマンドを使用してOracle Business Intelligenceのメトリックを表示することもできます。

この項では、これらの方法について説明します。

ダイナミック・モニタリング・サービスを使用したメトリックの取得

ダイナミック・モニタリング・サービス(DMS)を使用して、Oracle Business Intelligenceのメトリックを表示できます。

このサービスにアクセスするには、次のURLを使用します。

http://<host>:<AdminServerのポート>/dms

左側のペインのメトリック表リストから「非J2EEメトリック」を選択してOracle Business Intelligenceのメトリックのリストを表示します。これは、Fusion Middleware Controlのメトリック・ブラウザで表示されるものと同じリストです。

ダイナミック・モニタリング・サービスを使用することで、メトリックのスナップショットを迅速に取得できます。Microsoft Excelスプレッドシートを使用したWeb問合せのソースとして特定のメトリックのURLを指定し、このWeb問合せに対して、アーカイブ・シートに値をコピーする処理と一定期間ループで問合せを更新する処理を自動的に実行するマクロを結合します。

たとえば、ダイナミック・モニタリング・サービスを使用して、Oracle_BI_Generalというメトリック表の詳細を表示するとします。メトリック表リストでOracle_BI_Generalリンクをクリックすると、画面の右側にこの表が表示されます。このメトリック表は、Active_Execute_RequestsやTotal_Sessionsなどのいくつかのモニター値で構成されています。メトリック・ブラウザに表示されたこの表の情報をWLSTコマンドの一部として使用できます。

WLSTコマンドを使用したDMSメトリックへのアクセスの詳細は、WLSTコマンドを使用したメトリックの取得を参照してください。

WLSTコマンドを使用したメトリックの取得

WLSTを使用すると、システムに関するメトリックを収集できます。

WLSTコマンドを使用して、Oracle Business Intelligenceのメトリックを取得できます。

  1. ORACLE_HOME/oracle_common/bin/ディレクトリに移動します。
  2. WLSTユーティリティを実行します。
  3. 次の例のように、connectコマンドを使用してOracle BIシステムに接続します。

    connect('user','password','t3://<host><port>)

  4. 次のプロンプトが表示されたら、オンライン・モードになっています。

    wls:/bi/serverConfig>

これで、DMSカスタムWLSTコマンドを対話的に使用できるようになりました。たとえば、先頭にOracle_BIが付くすべてのメトリック表を表示するには、次のコマンドを入力します。

wls:/bifoundation_domain/serverConfig> displayMetricTables('Oracle_BI*')

このコマンドでは、Oracle BIのメトリックごとにデータの長大なリストが生成されます。そのため、Oracle_BI_Generalなどの特定のメトリック表に焦点を絞ったほうが役立ちます。次のコマンドでは、次に示すサンプルのような出力が表示されます。

wls:/bifoundation_domain/serverConfig> displayMetricTables('Oracle_BI_General')

-----------------
Oracle_BI_General
-----------------
Active_Execute_Requests.value:  0
Active_Fetch_Requests.value:    0
Active_File_Handles.value:      1
Active_Initblock_Executions.value:      0
Active_Logins.value:    0
Active_Prepare_Requests.value:  0
Avg._Failed_Logins_Elapsed_Time.value:  0
Avg._Initblock_Executions_Elapsed_Time.value:   0
Avg._Succeeded_Logins_Elapsed_Time.value:       0
Avg._query_elapsed_time.value:  0
Busy_File_Handles.value:        0
File_Handle_Waiters.value:      0
Free_File_Handles.value:        502
Host:   oracle-bc5ac6af
Max._Initblock_Execution_Elapsed_Time.value:    0
Max_File_Handles.value: 503
Name:   Oracle BI General
New_Execute_Requests.value:     19
New_Fetch_Requests.value:       32
New_Initblock_Executions.value: 0
New_Logins.value:       7
New_Prepare_Requests.value:     19
New_Requests.value:     187
OBPERF_***.value:       7
Oracle_BI_Applications: Oracle BI Server
Parent: /Oracle BI Server
Process:        Oracle BI Server:4004:/instance1/coreapplication_obis1
Queries/sec.value:      0
ServerName:     /instance1/coreapplication_obis1
Succeeded_Initblock_Execution_Ratio_as_%.value: 0
Succeeded_Logins_Ratio_as_%.value:      7
Total_sessions.value:   0

WLSTのスクリプト作成機能を使用してDMSコマンドをPythonスクリプトに組み込み、必要なメトリック値をファイルに格納できます。次にこのようなスクリプトの例を示します。

# Script to dump timestamp (in milliseconds) for a single Oracle BI metric 
# to a file
#
from java.util import Date
from java.text import SimpleDateFormat
#
# Modify to connect to your server 
connect('biadmin','welcome1','t3://localhost:9500')
#
# This is the number of times to sample the metric
sample_length = 100
#
# This is where you define what metric table and metric to dump to file
metric_table = "Oracle_BI_General"
metric_of_interest = "Avg._query_elapsed_time.value"
#
# Some metrics have non-text characters in the name. Provide a reference here 
# so it dumps to file without error in file name
output_file_metric_ref = "Avg_Qry_Elapse"
#
# This section defines the output file name with unique time 
start_time = str(SimpleDateFormat("dd-MMM-yyyy_HH-mm-ss").format(Date()))
output_filename = start_time + "_" + output_file_metric_ref + "_dump.txt"
#
# Open the file and write summary of metric to be dumped
file = open(output_filename,'w')
print >>file, "Start Metric Dump of: " + str(metric_table) + " : " + str(metric_of_interest) + " at " + str(SimpleDateFormat("dd-MMM-yyyy HH-mm-ss").format(Date()))
#
#
# The following section forms a loop according to the sample length defined
# earlier. The 'displayMetricTables()' command returns the metric table in the 
# form of a JMX composite data array. The code following this command access 
# the metric data from this array. In this case, a particular metric of
# interest is tested for and only the value of that metric is output to file.
#
counter = 0
while counter <= sample_length:
    results = displayMetricTables(metric_table)
    for table in results:
        name = table.get('Table')
        rows = table.get('Rows')
    rowCollection = rows.values()
    iter = rowCollection.iterator()
    while iter.hasNext():
        row = iter.next()
    rowType = row.getCompositeType()
    keys = rowType.keySet()
    keyIter = keys.iterator()
    while keyIter.hasNext():
        columnName = keyIter.next()
        value = row.get(columnName)
        if columnName == metric_of_interest:
            print >>file, str(SimpleDateFormat("dd-MMM-yyyy HH-mm-ss-SSS").format(Date())) + "," + str(value)
    counter = counter + 1
file.close()
disconnect()

「Oracle_BI_Thread_Pool」などの一部のOracle BIメトリック表は、実際には2つのディメンションで構成される表です。「Oracle_BI_Thread_Pool」表では、「Server」や「Usage_Tracking」などの様々な「名前」のメトリック値の問合せを実行できます。この場合、必要なメトリック値をファイルにエクスポートするには、前のスクリプト例のループで使用しているロジックを、2つのディメンションを扱うように変更する必要があります。次のスクリプト例では、このような場合の処理方法の1つを示しています。

# Script to dump timestamp (in milliseconds) and a 
#single Oracle BI metric to a file for metrics with multiple sections
#
from java.util import Date
from java.text import SimpleDateFormat
#
# Modify to connect to your server
connect('biadmin','welcome1','t3://localhost:9500')
#
# This is the number of times to sample the metric
sample_length = 100
#
# This is where you define what metric table, category, and metric to 
# dump to file
metric_table = "Oracle_BI_Thread_Pool"
category_of_interest = "Server"
metric_of_interest = "Avg._Request/sec.value"
#
# Some metrics have non-text characters - provide a reference here 
# so it dumps to file without error
output_file_metric_ref = "Avg_Req_Sec"
#
# This section defines the output file name with unique time 
start_time = str(SimpleDateFormat("dd-MMM-yyyy_HH-mm-ss").format(Date()))
output_filename = start_time + "_" + output_file_metric_ref + "_dump.txt"
#
# Open the file and write summary of metric to be dumped
file = open(output_filename,'w')
print >>file, "Start Metric Dump of: " + str(metric_table) + " : " + str(metric_of_interest) + " for Category: " + str(category_of_interest) + " at " + str(SimpleDateFormat("dd-MMM-yyyy HH-mm-ss").format(Date()))
#
#
counter = 0
while counter <= sample_length:
    results = displayMetricTables(metric_table)
    for table in results:
        name = table.get('Table')
        rows = table.get('Rows')
    rowCollection = rows.values()
    iter = rowCollection.iterator()
    while iter.hasNext():
        row = iter.next()
        if row.containsValue(category_of_interest):
            rowType = row.getCompositeType()
            keys = rowType.keySet()
            keyIter = keys.iterator()
            while keyIter.hasNext():
                columnName = keyIter.next()
                value = row.get(columnName)
                if columnName == metric_of_interest:
                    print >>file, str(SimpleDateFormat("dd-MMM-yyyy HH-mm-ss-SSS").format(Date())) + "," + str(value)
    counter = counter + 1
file.close()
disconnect()
前
前 		次
次
目次へ移動
目次