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

前
前へ
次
次へ

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

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

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

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

問合せキャッシングを制御するパラメータは、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_CACHINGYESに設定します。「構成ファイル設定」を参照してください。

キャッシングの利点

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

問合せキャッシングにより、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プレゼンテーション・サービスによって行われた論理イベント・キューへの更新を取得できます。

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プレゼンテーション・サービス・ノードに伝播されます。