キャッシュの使用方針

問合せキャッシングの主要な利点の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サーバー・キャッシュをシードできます。

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

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

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

注意:

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

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

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

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

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

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

オプション	説明
ユーザー	キャッシュ・エントリを生成した問合せを発行したユーザーの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つ以上のキャッシュ・エントリ。
- 指定されたビジネス・モデルに関連する、選択されている1つ以上のキャッシュ・エントリ。
- ビジネス・モデル内の指定されたユーザーに関連する、選択されている1つ以上のキャッシュ・エントリ。
物理モードでは、次のものをパージできます。
- 選択されている1つ以上のデータベースに関連する、すべての表のすべてのキャッシュ・エントリ。
- 選択されている1つ以上のカタログに関連する、すべての表のすべてのキャッシュ・エントリ。
- 選択されている1つ以上のスキーマに関連する、すべての表のすべてのキャッシュ・エントリ。
- 選択されている1つ以上の表に関連する、すべてのキャッシュ・エントリ。

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