Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 12c (12.2.1.1.0) E77226-02 |
|
![]() 前へ |
![]() 次へ |
問合せキャッシングの主要な利点の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サーバーは、問合せキャッシュを使用して、集計と同じかそれ以上のレベルで、問合せに答えを返すことができます。
キャッシュがヒットするかどうかは、多くの要因によって決まります。次の表はそれらの要因を示しています。
要因またはルール | 説明 |
---|---|
|
キャッシュ・ヒットと見なされるためには、新しい問合せの このルールはキャッシュ・ヒットの最小要件ですが、このルールを満たしていても、キャッシュ・ヒットが保証されるわけではありません。この表に記載されている他のルールも適用されます。 |
|
Oracle BIサーバーは、キャッシュされた結果の式を計算して、新しい問合せに答えを返すことができます。ただし、キャッシュされた結果にすべての列がある必要があります。たとえば、次の問合せ SELECT product, month, averageprice FROM sales WHERE year = 2000 この問合せは、次の問合せのキャッシュをヒットします。 SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000
|
|
問合せがキャッシュ・ヒットと見なされるためには、
さらに、 SELECT employeename FROM employee, geography WHERE region in ('EAST', 'WEST') REGIONがプロジェクション・リストにないため、前のリストのシード中の問合せに対してキャッシュ・ヒットになりません。 |
ディメンションのみの問合せが完全一致している |
問合せがディメンションのみで、問合せにファクトやメジャーが含まれない場合、キャッシュされた問合せの投影列が完全一致する場合のみ、キャッシュはヒットします。これにより、ディメンション表の論理ソースが複数ある場合の誤検出が回避されます。 |
特殊関数を使用する問合せが完全一致している |
時系列関数( |
一連の論理表が一致している |
キャッシュ・ヒットと見なされるためには、受信するすべての問合せが、キャッシュ・エントリと同じ論理表のセットを持つ必要があります。このルールにより、誤ったキャッシュ・ヒットが回避されます。たとえば、 |
セキュリティ・セッション変数を含めて、セッション変数値が一致している |
論理SQL文または物理SQL文がセッション変数を参照している場合、セッション変数値が一致している必要があります。一致していない場合、キャッシュはヒットしません。 さらに、セキュリティ・センシティブなセッション変数の値は、論理SQL文自体がセッション変数を参照していない場合であっても、リポジトリ内で定義されるセキュリティ・セッション変数値に一致している必要があります。詳細は、「行レベルのデータベース・セキュリティを使用している場合の適切なキャッシュ結果の確認」を参照してください。 |
同等の結合条件 |
キャッシュ・ヒットと見なされるためには、新しい問合せリクエストで作成された結合済論理表が、キャッシュされた結果と同じ(またはサブセット)である必要があります。 |
同じ |
キャッシュされた問合せでは、 |
問合せに互換性のある集計レベルが含まれている |
集計レベルの情報をリクエストする問合せでは、下位の集計レベルで、キャッシュされた結果を使用できます。たとえば、次の問合せは、仕入先、地域および市区レベルでの販売数量をリクエストしています。 SELECT supplier, region, city, qtysold FROM suppliercity 次の問合せは、市区レベルでの販売数量をリクエストしています。 SELECT city, qtysold FROM suppliercity 2番目の問合せは、最初の問合せのキャッシュ・ヒットになります。 |
追加の集計の制限 |
たとえば、列 |
|
SELECTリストに含まれていない列でソートする問合せは、キャッシュ・ミスになります。 |
詳細なヒット検出によるキャッシュ・ミスの回避 |
NQSConfig.INIファイル内でパラメータ |
キャッシュ・ヒット動作の診断 |
キャッシュ・ヒット動作をより適切に評価するには、次の例に示すように、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サーバー・キャッシュをシードするには:
キャッシュ・シード・エージェントと他のエージェントの唯一の違いは、以前のキャッシュを自動的に消去して、ダッシュボードにアラートとして表示されないことです。
注意:
キャッシュ・シード・エージェントは、完全一致の問合せのみパージするため、古いデータが引き続き存在する可能性があります。エージェント問合せは非定型の問合せやドリルには対処しないため、必ずキャッシング方針には常にキャッシュのパージを含めるようにします。キャッシュ・マネージャを使用すると、問合せキャッシュ全体に関する情報と、開いているリポジトリに関連付けられている問合せキャッシュ内の個々のエントリに関する情報を表示できます。
また、キャッシュ・マネージャを使用して特定のキャッシュ・エントリを選択し、そのエントリに対して、キャッシュされているSQL文の表示と保存、エントリのパージなど、様々な操作を実行できます。
キャッシュ・マネージャを開くには:
管理ツールのツールバーで、「管理」→「キャッシュ」を選択します。
左側のエクスプローラ・ペインの「キャッシュ」タブを選択すると、現在のリポジトリのキャッシュ・エントリ、ビジネス・モデルおよびユーザーが表示されます。関連するキャッシュ・エントリが右側のペインに反映され、上部の表示専用フィールドにエントリの総数が表示されます。
「オプション」設定を使用して、キャッシュ・エントリ情報およびその表示順序を制御できます(キャッシュ・マネージャから「編集」を選択し、「オプション」を選択するか、管理ツールのメニューから「ツール」→「オプション」→「キャッシュ・マネージャ」を選択します)。次の表に記載されているオプションを情報に含めることができます。
オプション | 説明 |
---|---|
ユーザー |
キャッシュ・エントリを生成した問合せを発行したユーザーのID。 |
作成 |
キャッシュ・エントリの結果セットが作成された時間。 |
最終使用 |
キャッシュ・エントリの結果セットが問合せに対応した最後の日時(Oracle BIサーバーが予期せず停止した後、最終使用日時が一時的に実際よりも古い値となることがあります)。 |
作成経過時間 |
このキャッシュ・エントリの結果セットを作成するのに必要な時間(秒単位)。 注意: ディスク上のキャッシュ・オブジェクト・ディスクリプタに保存されている値は、ミリ秒単位です。表示用に秒単位に変換されます。 |
行数 |
問合せによって生成された行数。 |
行サイズ |
このキャッシュ・エントリの結果セット内の各行のサイズ(バイト単位)。 |
フル・サイズ |
可変長の列、圧縮アルゴリズム、およびその他の要因を考慮して使用される最大サイズ。結果セットの実際のサイズはフル・サイズよりも小さくなります。 |
列数 |
このキャッシュ・エントリの結果セットの各行内の列数。 |
論理リクエスト |
このキャッシュ・エントリに関連付けられている論理リクエスト。サブリクエストがキャッシュされている場合、この列にはサブリクエストのテキストが表示されます。 |
使用回数 |
このキャッシュ・エントリの結果セットが問合せを満たした回数(Oracle BIサーバーの起動後)。 |
ビジネス・モデル |
キャッシュ・エントリに関連付けられているビジネス・モデルの名前。 |
リポジトリ |
キャッシュ・エントリに関連付けられているOracle Business Intelligenceリポジトリの名前。 |
SQL |
このキャッシュ・エントリに関連付けられているSQL文。サブリクエストがキャッシュされている場合、1つのSQL文に複数のキャッシュ・エントリが関連付けられている可能性があります。 |
サーバーの問合せ |
問合せを処理したOracle BIサーバー。 |
ファクト表ソース |
このキャッシュ・エントリの論理リクエストに関連付けられたファクト表。 |
リポジトリ・ツリーを開くとすべてのビジネス・モデルとキャッシュ・エントリが表示され、ビジネス・モデルを開くとすべてのユーザーとキャッシュ・エントリが表示されます。右側のペインには、階層ツリー内で選択されているアイテムに関連するキャッシュ・エントリのみが表示されます。
グローバル・キャッシュ情報を表示するには、「アクション」を選択し、「情報の表示」を選択します。
次の表は、「グローバル・キャッシュ情報」ウィンドウに表示される情報を示しています。
列 | 説明 |
---|---|
キャッシュ記憶域として使用できる空き容量 |
キャッシュ記憶域として使用できる空き領域(MB単位)です。 |
キャッシュ関連ファイルを含むディスクで使用される空き容量 |
キャッシュ関連ファイルが格納されているディスクの総使用量(MB単位)です(キャッシュ関連ファイル用に使用されている領域だけではありません)。 |
許容可能な最大キャッシュ・エントリ数 |
|
キャッシュ・エントリ結果セットごとの許容可能な最大行数 |
|
現在のキャッシュ・エントリ数 |
グローバル・キャッシュ内の現在のエントリ数です。これらのエントリは、複数のリポジトリに関連付けられている可能性があります。 |
Oracle BIサーバーの起動以降にキャッシュから満足されなかった問合せ数 |
Oracle BIサーバーの前回の起動以降のキャッシュ・ミスです。 |
Oracle BIサーバーの起動以降にキャッシュから満足された問合せ数 |
Oracle BIサーバーの前回の起動以降のキャッシュ・ヒットです。 |
キャッシュ・マネージャがアクティブ・ウィンドウの状態で、[F5]キーを押すか、「アクション」→「リフレッシュ」を選択して、表示をリフレッシュします。開いているリポジトリの現在のキャッシュ・エントリと現在のグローバル・キャッシュ情報が取得されます。DSNがクラスタ化されている場合は、クラスタ内のすべてのリポジトリに関する情報が表示されます。
キャッシュのパージは、問合せキャッシュからエントリを削除するプロセスです。
キャッシュ・エントリは、次の方法でパージできます。
管理ツールのキャッシュ・マネージャ機能(オンライン・モード)を使用して、手動で行います。
特定の表の「物理表」ダイアログの「キャッシュ永続時間」フィールドを設定して、自動で行います。
Oracle BIサーバー・イベント・ポーリング表を設定して、自動で行います。
キャッシュ記憶域がいっぱいになったときに、自動で行います。
注意:
キャッシュのパージは、ODBC拡張関数を使用してプログラムで行うこともできます。詳細は、「ODBCプロシージャを使用するキャッシュのパージと保守」を参照してください。
また、動的リポジトリ変数の値が変化するときにもキャッシュをパージできます。詳細は、「動的リポジトリ変数の変更」を参照してください。
キャッシュ・マネージャでキャッシュ・エントリを手動でパージするには:
パージによって、選択されているキャッシュ・エントリと関連するメタデータが削除されます。キャッシュの表示を更新するには、「アクション」→「リフレッシュ」を選択するか、[F5]キーを押します。