1. Oracle Analytics Serverの管理
  2. 高可用性とパフォーマンスのためのスケーリングおよびデプロイ
  3. パフォーマンス・チューニングと問合せキャッシングの管理
  4. キャッシュの使用方針
  5. キャッシュ・ヒットについて

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

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

キャッシュ・ヒットとは、Oracle BIサーバーがキャッシュを使用して問合せに答えを返すことができ、データベースにまったくアクセスしなかったことを意味します。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_DETECTIONUSE_ADVANCED_HIT_DETECTIONを参照してください。

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

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

ENABLE_CACHE_DIAGNOSTICS=4

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

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

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

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

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

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

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

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