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

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

キャッシュ・ヒットとは、サーバーがキャッシュを使用して問合せに答えを返すことができ、データベースにアクセスする必要がないことを意味します。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`