Cachetreffer

Eine Teilmenge der Spalten in der SELECT-Liste muss übereinstimmen

Alle Spalten in der SELECT-Liste einer neuen Abfrage müssen in der gecachten Abfrage vorhanden sein, damit sie sich für einen Cachetreffer qualifiziert, oder sie müssen aus den Spalten in der Abfrage berechnet werden können.

Diese Regel beschreibt die Mindestanforderung für einen Cachetreffer. Ein Erfüllen dieser Regel ist jedoch keine Garantie für einen Cachetreffer. Die anderen Regeln in dieser Tabelle gelten ebenfalls.

Spalten in der SELECT-Liste können Ausdrücke aus den Spalten der gecachten Abfragen enthalten

In Oracle Analytics Cloud können Ausdrücke aus gecachten Ergebnissen als Antwort auf die neue Abfrage berechnet werden. Allerdings müssen dabei alle Spalten im gecachten Ergebnis enthalten sein. Beispiel: Die Abfrage:

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

ergibt Cachetreffer für die Abfrage:

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

weil averageprice aus dollars und unitsales berechnet werden kann (averageprice = dollars/unitsales).

WHERE-Klausel muss semantisch identisch oder eine logische Teilmenge sein

Für eine Qualifikation der Abfrage als Cachetreffer müssen die Constraints der WHERE-Klausel entweder den gecachten Ergebnissen entsprechen oder eine Teilmenge der gecachten Ergebnisse sein.

Eine WHERE-Klausel, die eine logische Teilmenge einer gecachten Abfrage ist, qualifiziert sich für einen Cachetreffer, wenn die Teilmenge eines der folgenden Kriterien erfüllt:

• Eine Teilmenge von IN-Listenwerten. Abfragen, in denen weniger Elemente einer gecachten Abfrage der IN-Liste angefordert werden, qualifizieren sich als Cachetreffer. Beispiel: Die folgende Abfrage:

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

  qualifiziert sich als Treffer für die folgende gecachte Abfrage:

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

• Sie enthält weniger (aber identische) OR-Constraints als das gecachte Ergebnis.

• Sie enthält eine logische Teilmenge eines Literalvergleichs. Beispiel: Das folgende Prädikat:

  WHERE revenue < 1000

  qualifiziert sich als Cachetreffer für eine vergleichbare Abfrage mit dem Prädikat:

  WHERE revenue < 5000

• Es ist keine WHERE-Klausel vorhanden. Wenn eine Abfrage ohne WHERE-Klausel gecacht wird, qualifizieren sich Abfragen, die alle anderen Regeln für Cachetreffer erfüllen, als Cachetreffer, unabhängig von ihrer WHERE-Klausel.

Darüber hinaus müssen Spalten, die in der WHERE-Klausel verwendet werden, in der Projektionsliste vorhanden sein. Beispiel: Die folgende Abfrage:

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

Führt nicht zu einem Cachetreffer für die Seeding-Abfrage in der vorherigen Liste, weil REGION nicht in der Projektionsliste vorhanden ist.

Ausschließlich dimensionsbezogene Abfragen müssen exakt übereinstimmen

Wenn eine Abfrage ausschließlich dimensionsbezogen ist, d.h. dass keine Fakten oder Kennzahlen in der Abfrage enthalten sind, qualifiziert sich nur eine exakte Übereinstimmung der Projektionsspalten der gecachten Abfrage als Cachetreffer. Durch dieses Verhalten werden falsche positive Ergebnisse verhindert, wenn mehrere logische Quellen für eine Dimensionstabelle vorhanden sind.

Abfragen mit Sonderfunktionen müssen exakt übereinstimmen

Andere Abfragen, die Sonderfunktionen wie Zeitreihenfunktionen (AGO, TODATE und PERIODROLLING), Limit- und Offsetfunktionen (OFFSET und FETCH), Beziehungsfunktionen (ISANCESTOR, ISLEAF, ISROOT und ISSIBLING), externe Aggregationsfunktionen und im Allgemeinen Filtermetriken enthalten, müssen ebenfalls exakt mit den Projektionsspalten in der gecachten Abfrage übereinstimmen. In diesen Fällen muss auch der Filter exakt übereinstimmen. Bei Filtermetriken kann der Teilmengencache herangezogen werden, wenn die Filtermetrik als WHERE-Klausel umgeschrieben werden kann.

Set von logischen Tabellen muss übereinstimmen

Für eine Qualifikation als Cachetreffer müssen alle eingehenden Abfragen dasselbe Set von logischen Tabellen wie der Cacheeintrag aufweisen. Mit dieser Regel werden falsche Cachetreffer vermieden. Beispiel: SELECT * FROM product stimmt nicht mit SELECT * FROM product, sales überein.

Werte von Sessionvariablen müssen übereinstimmen, darunter Sicherheitssessionvariablen

Wenn die logische oder physische SQL-Anweisung eine Sessionvariable referenziert, müssen die Werte der Sessionvariablen übereinstimmen. Andernfalls liegt kein Cachetreffer vor.

Darüber hinaus muss der Wert der sicherheitssensitiven Sessionvariablen auch dann mit den für das semantische Modell definierten Sicherheitssession-Variablenwerten übereinstimmen, wenn die logische SQL-Anweisung selbst keine Sessionvariablen referenziert. Siehe Korrekte Cacheergebnisse bei Verwendung der Datenbanksicherheit auf Zeilenebene sicherstellen.

Übereinstimmende Join-Bedingungen

Die resultierende verknüpfte logische Tabelle einer neuen Abfrageanforderung muss für eine Qualifikation als Cachetreffer mit den (oder mit einer Teilmenge der) gecachten Ergebnisse(n) identisch sein.

DISTINCT-Attribut muss identisch sein

Wenn eine gecachte Abfrage doppelte Datensätze mit DISTINCT-Verarbeitung beseitigt (z.B. SELECT DISTINCT...), müssen Anforderungen für die gecachten Spalten ebenfalls die DISTINCT-Verarbeitung einschließen. Eine Anforderung für dieselbe Spalte ohne DISTINCT-Verarbeitung ist ein Cachefehlschlag.

Abfragen müssen kompatible Aggregationsebenen enthalten

Abfragen, die eine aggregierte Ebene von Informationen anfordern, können gecachte Ergebnisse auf einer niedrigeren Aggregationsebene verwenden. Beispiel: Die folgende Abfrage fordert die verkaufte Menge auf Lieferanten- und Regions- und Ortsebene an:

SELECT supplier, region, city, qtysold
FROM suppliercity

Die folgende Abfrage fordert die verkaufte Menge auf Ortsebene an:

SELECT city, qtysold
FROM suppliercity

Die zweite Abfrage führt zu einem Cachetreffer für die erste Abfrage.

Begrenzte zusätzliche Aggregation

Beispiel: Wenn eine Abfrage mit der Spalte qtysold gecacht wird, dann führt eine Anforderung für RANK(qtysold) zu einem Cachefehlschlag. Außerdem kann eine Abfrage, die qtysold auf Landesebene anfordert, einen Cachetreffer aus einer Abfrage erhalten, die qtysold auf der Landes-, Regionsebene anfordert.

ORDER BY-Klausel muss aus Spalten in der SELECT-Liste bestehen

Abfragen, die nach Spalten sortieren, die nicht in der SELECT-Liste enthalten sind, führen zu Cachefehlschlägen.

Verhalten für Cachetreffer diagnostizieren

Um das Verhalten für Cachetreffer besser beurteilen zu können, setzen Sie die Sessionvariable ENABLE_CACHE_DIAGNOSTICS auf 4, wie im folgenden Beispiel dargestellt:

ENABLE_CACHE_DIAGNOSTICS=4