A propos des accès réussis au cache

Un sous-ensemble de colonne dans la liste SELECT doit être mis en correspondance

Toutes les colonnes de la liste SELECT d'une nouvelle requête doivent exister dans la requête mise en cache pour pouvoir générer un accès réussi au cache, ou doivent pouvoir être calculées à partir des colonnes de la requête.

Cette règle décrit les exigences minimales d'accès au cache, mais le respect de cette règle ne garantit pas un accès réussi au cache. Les autres règles répertoriées dans ce tableau s'appliquent également.

Les colonnes de la liste SELECT peuvent être composées d'expressions des colonnes des requêtes mises en cache

Oracle Analytics Cloud peut calculer les expressions des résultats mis en cache afin de répondre à la nouvelle requête, mais toutes les colonnes doivent figurer dans le résultat mis en cache. Par exemple, la requête :

SELECT product, month, averageprice FROM sales WHERE year = 2000

entraîne un accès réussi au cache sur la requête :

SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000

car averageprice peut être calculé à partir de dollars et unitsales (averageprice = dollars/unitsales).

La clause WHERE doit être identique au niveau sémantique, ou constituer un sous-ensemble logique

Pour que la requête puisse générer un accès réussi au cache, les contraintes de la clause WHERE doivent être équivalentes aux résultats mis en cache ou constituer un sous-ensemble des résultats mis en cache.

Une clause WHERE qui est un sous-ensemble logique d'une requête mise en cache peut générer un accès réussi au cache si le sous-ensemble respecte l'un des critères suivants :

• Il s'agit d'un sous-ensemble de valeurs de liste IN. Les requêtes demandant une quantité moindre d'éléments d'une requête mise en cache de liste IN peuvent générer un accès réussi au cache. Par exemple, la requête suivante :

  SELECT employeename, region
  FROM employee, geography
  WHERE region in ('EAST', 'WEST')

  peut générer un accès réussi sur la requête mise en cache suivante :

  SELECT employeename, region
  FROM employee, geography
  WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')

• Il contient des contraintes OR en moins grand nombre (mais identiques) que le résultat mis en cache.

• Il contient un sous-ensemble logique d'une comparaison littérale. Par exemple, le prédicat suivant :

  WHERE revenue < 1000

  peut générer un accès réussi au cache sur une requête comparable avec le prédicat :

  WHERE revenue < 5000

• Aucune clause WHERE n'est présente. Si une requête sans clause WHERE est mise en cache, les requêtes respectant toutes les autres règles d'accès réussi au cache peuvent générer un accès réussi quelle que soit leur clause WHERE.

Par ailleurs, les colonnes utilisées sur la clause WHERE doivent se trouver dans la liste de projection. Par exemple, la requête suivante :

SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')

ne génère pas un accès réussi au cache pour la requête de prédéfinition de la liste précédente car REGION ne figure pas dans la liste de projection.

Les requêtes de dimension uniquement doivent constituer des correspondances exactes

S'il s'agit d'une requête de dimension uniquement, c'est-à-dire qu'aucun fait ou indicateur n'est inclus dans la requête, seule une correspondance exacte des colonnes de projection de la requête mise en cache entraîne un accès réussi au cache. Ce comportement empêche les faux positifs en présence de plusieurs sources logiques pour une table de dimensions.

Les requêtes avec des fonctions spéciales doivent constituer des correspondances exactes

Les autres requêtes contenant des fonctions spéciales telles que les fonctions de séries temporelles (AGO, TODATE et PERIODROLLING), les fonctions de limite et de décalage (OFFSET et FETCH), les fonctions de relation (ISANCESTOR, ISLEAF, ISROOT et ISSIBLING), les fonctions d'agrégation externe et, plus généralement, les mesures de filtre doivent également constituer une correspondance exacte avec les colonnes de projection dans la requête mise en cache. Dans ces cas-là, le filtre doit également constituer une correspondance exacte. Pour les mesures de filtre, si elles peuvent être réécrites en tant que clauses WHERE, le cache du sous-ensemble peut être exploité.

L'ensemble de tables logiques doit concorder

Pour pouvoir générer des accès réussis au cache, toutes les requêtes entrantes doivent posséder le même ensemble de tables logiques que l'entrée de cache. Cette règle permet d'éviter les faux accès réussis au cache. Par exemple, SELECT * FROM product n'est pas mis en correspondance avec SELECT * FROM product, sales.

Les valeurs de variable de session doivent concorder, y compris les variables de session de sécurité

Si l'instruction SQL physique ou logique fait référence à une variable de session, les valeurs de variable de session doivent concorder. Sinon, la requête n'accède pas au cache.

Par ailleurs, les valeurs des variables de session en lien avec la sécurité doivent correspondre aux valeurs de variable de session de sécurité définies dans le modèle sémantique, même si l'instruction SQL logique en elle-même ne référence pas les variables de session. Reportez-vous à Résultats de cache corrects assurés lors de l'utilisation de la sécurité de base de données de niveau ligne.

Conditions de jointure équivalentes

La table logique jointe résultante d'une nouvelle demande de requête doit être identique aux résultats mis en cache (ou en représenter un sous-ensemble) pour pouvoir générer un accès réussi au cache.

L'attribut DISTINCT doit être identique

Si une requête mise en cache élimine les enregistrements en double via le traitement DISTINCT (par exemple, SELECT DISTINCT...), les demandes pour les colonnes mises en cache doivent également inclure le traitement DISTINCT. Toute demande pour la même colonne sans traitement DISTINCT est un accès non réussi au cache.

Les requêtes doivent contenir des niveaux d'agrégation compatibles

Les requêtes qui demandent un niveau d'informations agrégé peuvent utiliser les résultats mis en cache à un niveau inférieur d'agrégation. Par exemple, la requête suivante demande la quantité vendue au niveau du fournisseur, de la région et de la ville :

SELECT supplier, region, city, qtysold
FROM suppliercity

La requête suivante demande la quantité vendue au niveau de la ville :

SELECT city, qtysold
FROM suppliercity

La seconde requête génère un accès réussi au cache sur la première requête.

Agrégation supplémentaire limitée

Par exemple, si une requête avec la colonne qtysold est mise en cache, une demande pour RANK(qtysold) entraîne un accès non réussi au cache. De plus, une requête qui demande qtysold au niveau du pays peut obtenir un accès réussi au cache à partir d'une requête qui demande qtysold au niveau du pays et de la région.

La clause ORDER BY doit être composée de colonnes dans la liste SELECT

Les requêtes avec des colonnes ORDER BY qui n'apparaissent pas dans la liste SELECT génèrent des accès non réussis au cache.

Diagnostic du comportement d'accès réussi au cache

Pour mieux évaluer le comportement d'accès réussi au cache, définissez la variable de session ENABLE_CACHE_DIAGNOSTICS sur 4, comme indiqué dans l'exemple suivant :

ENABLE_CACHE_DIAGNOSTICS=4