In Oracle Analytics Cloud wird ein lokaler Cache der Abfrageergebnissets im Abfragecache beibehalten.
Themen:
Mit dem Abfragecache können viele aufeinanderfolgende Abfrageanforderungen in Oracle Analytics Cloud verarbeitet werden, ohne dafür auf Backend-Datenquellen zugreifen zu müssen. Dadurch wird die Abfrageperformance verbessert. Die Abfragecacheeinträge können jedoch auch veraltet sein, wenn die Backend-Datenquellen aktualisiert wurden.
Die schnellste Methode zur Verarbeitung einer Abfrage besteht darin, einen Großteil der Verarbeitung zu überspringen und eine vorberechnete Antwort zu verwenden.
Beim Abfrage-Caching werden die vorberechneten Ergebnisse von Abfragen in Oracle Analytics Cloud in einem lokalen Cache gespeichert. Wenn diese Ergebnisse von einer anderen Abfrage verwendet werden können, entfällt die gesamte Datenbankverarbeitung für diese Abfrage. Dies kann zu deutlichen Verbesserungen bei der durchschnittlichen Abfrageantwortzeit führen.
Durch das Beantworten einer Abfrage aus einem lokalen Cache erhalten Sie nicht nur eine bessere Performance, sondern Sie sparen auch Netzwerkressourcen und Verarbeitungszeit beim Datenbankserver. Netzwerkressourcen werden gespart, weil keine Zwischenergebnisse an Oracle Analytics Cloud zurückgegeben werden. Wenn keine Datenbankabfrage ausgeführt wird, kann der Datenbankserver diese freien Kapazitäten für andere Aufgaben nutzen. Wenn die Datenbank ein Rückbelastungssystem verwendet, kann die Ausführung von weniger Abfragen auch zu einer Senkung der Kosten im Budget führen.
Ein weiterer Vorteil beim Beantworten von Abfragen mithilfe des Cache besteht darin, dass Sie Verarbeitungszeit in Oracle Analytics Cloud einsparen können, insbesondere wenn die Abfrageergebnisse aus mehreren Datenbanken abgerufen werden. Je nach Abfrage findet auf dem Server eine beträchtliche Join- und Sortierverarbeitung statt. Wenn die Abfrage bereits berechnet wurde, wird diese Verarbeitung vermieden, und es werden Serverressourcen für andere Aufgaben freigegeben.
Zusammenfassend kann das Abfrage-Caching die Abfrageperformance deutlich verbessern und gleichzeitig den Netzwerktraffic, die Datenbankverarbeitung und den Verarbeitungs-Overhead reduzieren.
Das Abfrage-Caching hat viele naheliegende Vorteile, geht aber auch mit bestimmten Kosten einher.
Gecachte Ergebnisse sind möglicherweise veraltet
Administrative Kosten für das Management des Cache
Beim Cachemanagement überwiegen die Vorteile normalerweise die Kosten deutlich.
Einige administrative Aufgaben gehen mit Caching einher. Sie müssen die Cachepersistenzzeit für jede physische Tabelle richtig festlegen. Dabei müssen Sie wissen, wie oft die Daten in dieser Tabelle aktualisiert werden.
Wenn die Häufigkeit der Aktualisierung unterschiedlich ist, müssen Sie verfolgen, wann die Änderungen vorgenommen werden, und den Cache gegebenenfalls manuell löschen.
Wenn die Cacheeinträge bei Datenänderungen in den zugrunde liegenden Datenbanken nicht gelöscht werden, können Abfragen unter Umständen veraltete Ergebnisse zurückgeben.
Sie müssen entscheiden, ob diese Tatsache akzeptabel ist. Sie ist möglicherweise akzeptabel, wenn der Cache veraltete Daten enthalten soll. Sie müssen entscheiden, welche Menge an veralteten Daten akzeptabel ist und dann ein Regelset entsprechend dieser Menge konfigurieren (und beachten).
Beispiel: Angenommen, in einer Anwendung werden Unternehmensdaten von einem großen Konglomerat analysiert, und Sie erstellen Jahresübersichten zu den verschiedenen Geschäftsbereichen im Unternehmen. Neue Daten haben keine maßgeblichen Auswirkungen auf die Abfragen, weil die neuen Daten nur die Übersichten des nächsten Jahres beeinflussen. In diesem Fall ist es sinnvoller, die Einträge im Cache beizubehalten.
Nehmen wir allerdings an, dass die Datenbanken dreimal täglich aktualisiert werden und Sie Abfragen zu den Aktivitäten des aktuellen Tages ausführen. In diesem Fall müssen Sie den Cache viel häufiger löschen oder vielleicht in Betracht ziehen, den Cache überhaupt nicht zu verwenden.
In einem weiteren Szenario erstellen Sie das Dataset von Anfang an in regelmäßigen Abständen neu (z.B. einmal pro Woche). In diesem Beispiel können Sie den gesamten Cache im Rahmen der Neuerstellung des Datasets löschen und so sicherstellen, dass nie veraltete Daten im Cache vorhanden sind.
Unabhängig von der vorliegenden Situation müssen Sie entscheiden, welche Menge an nicht aktuellen Informationen akzeptabel ist, die an die Benutzer zurückgegeben wird.
Wenn für einen bestimmten Verbindungspool die gemeinsame Anmeldung aktiviert ist, kann der Cache unter den Benutzern geteilt werden, und es muss kein Seeding für die einzelnen Benutzer erfolgen.
Wenn die gemeinsame Anmeldung nicht aktiviert ist und eine benutzerspezifische Datenbankanmeldung verwendet wird, generiert jeder Benutzer einen eigenen Cacheeintrag.
In Oracle Analytics Cloud ist der Abfragecache standardmäßig aktiviert. Sie können das Abfrage-Caching auf der Seite "Systemeinstellungen" aktivieren und deaktivieren.
Um die Änderungen in den zugrunde liegenden Datenbanken zu verwalten und die Cacheeinträge zu überwachen, müssen Sie eine Cachemanagementstrategie entwickeln.
Sie benötigen einen Prozess zum Invalidieren von Cacheeinträgen, wenn die Daten in den zugrunde liegenden Tabellen, aus denen der Cacheeintrag besteht, geändert werden. Außerdem benötigen Sie einen Prozess, mit dem Sie unerwünschte Cacheeinträge überwachen, erkennen und entfernen können.
Der vorliegende Abschnitt umfasst die folgenden Themen:
Die Wahl einer Cachemanagementstrategie hängt von der Volatilität der Daten in den zugrunde liegenden Datenbanken und der Vorhersagbarkeit der Änderungen ab, die diese Volatilität verursachen.
Außerdem hängt sie von der Anzahl der Abfragen und den Abfragetypen in Ihrem Cache sowie von der Nutzung dieser Abfragen ab. Dieser Abschnitt enthält einen Überblick über die verschiedenen Ansätze des Cachemanagements.
Sie können das Caching für das gesamte System deaktivieren, damit keine neuen Cacheeinträge erstellt werden und damit neue Abfragen den vorhandenen Cache nicht nutzen. Sie können das Caching später wieder aktivieren, ohne dass im Cache gespeicherte Einträge verloren gehen.
Ein vorübergehendes Deaktivieren des Cachings ist sinnvoll, wenn Sie vermuten, dass veraltete Cacheeinträge vorhanden sind, aber zunächst prüfen möchten, ob die Einträge tatsächlich veraltet sind, bevor Sie diese Einträge oder den gesamten Cache löschen. Wenn Sie feststellen, dass die im Cache gespeicherten Daten immer noch relevant sind, oder nachdem Sie problematische Einträge erfolgreich gelöscht haben, können Sie den Cache wieder aktivieren. Falls erforderlich, können Sie den gesamten Cache oder den mit einem bestimmten Geschäftsmodell verknüpften Cache löschen, bevor Sie den Cache wieder aktivieren.
Sie können ein für Caching geeignetes Attribut für jede physische Tabelle festlegen. So können Sie angeben, ob Abfragen für diese Tabelle dem Cache zur Beantwortung zukünftiger Abfragen hinzugefügt werden.
Wenn Sie das Caching für eine Tabelle aktivieren, werden sämtliche Abfragen im Zusammenhang mit der Tabelle dem Cache hinzugefügt. Alle Tabellen sind standardmäßig für Caching geeignet. Allerdings sollten bestimmte Tabellen nur in den Cache aufgenommen werden, wenn Sie geeignete Einstellungen für die Cachepersistenz einrichten. Beispiel: Angenommen, Sie haben eine Tabelle mit Börsentickerdaten, die jede Minuten aktualisiert werden. Sie können angeben, dass die Einträge für diese Tabelle alle 59 Sekunden gelöscht werden sollen.
Außerdem können Sie über die Cachepersistenzeinstellungen angeben, wie lange die Einträge für diese Tabelle im Abfragecache gespeichert werden. Diese Aktion ist hilfreich für Datenquellen, die häufig aktualisiert werden.
Doppelklicken Sie in Model Administration Tool im physischen Layer auf die physische Tabelle.
Wenn Sie den semantischen Modellierer verwenden, lesen Sie Was sind die allgemeinen Eigenschaften einer physischen Tabelle?.
Wählen Sie im Dialogfeld mit den Eigenschaften der physischen Tabelle auf der Registerkarte "Allgemein" eine der folgenden Optionen aus:
Um das Caching zu aktivieren, wählen Sie Für Caching geeignet aus.
Um das Caching für eine Tabelle zu verhindern, deaktivieren Sie die Option Für Caching geeignet.
Um eine Cacheablaufzeit festzulegen, geben Sie eine Cachepersistenzzeit und eine Maßeinheit (Tage, Stunden, Minuten oder Sekunden) an. Wenn Sie verhindern möchten, dass Cacheeinträge automatisch ablaufen, aktivieren Sie die Option Cache läuft nie ab.
Klicken Sie auf OK.
Wenn Sie semantische Modelle mit dem semantischen Modellierer oder mit Model Administration Tool ändern, können diese Änderungen Auswirkungen auf Einträge haben, die im Cache gespeichert sind. Beispiel: Wenn Sie die Definition eines physischen Objekts oder einer dynamischen Variablen semantischer Modelle ändern, sind Cacheeinträge mit Referenzen auf dieses Objekt oder diese Variable möglicherweise nicht mehr gültig. Aufgrund dieser Änderungen ist es unter Umständen erforderlich, den Cache zu löschen. Dabei sind zwei Szenarios möglich: Ändern eines vorhandenen semantischen Modells oder Erstellen (oder Hochladen) eines neuen semantischen Modells.
Änderungen am semantischen Modell
Wenn Sie ein semantisches Modell ändern oder eine andere RPD-Datei hochladen, werden bei Änderungen, die Cacheeinträge betreffen, automatisch alle Cacheeinträge mit Referenzen auf die geänderten Objekte gelöscht. Der Löschvorgang wird beim Hochladen der Änderungen ausgeführt. Beispiel: Wenn Sie eine physische Tabelle aus einem semantischen Modell löschen, werden alle Cacheeinträge mit Referenzen auf diese Tabelle beim Einchecken gelöscht. Bei Änderungen an einem semantischen Modell im logischen Layer werden alle Cacheeinträge für dieses semantische Modell gelöscht.
Änderungen an globalen Variablen semantischer Modelle
Die Werte von globalen Variablen semantischer Modelle werden durch Daten aktualisiert, die von Abfragen zurückgegeben werden. Wenn Sie eine globale Variable semantischer Modelle definieren, erstellen Sie einen Initialisierungsblock, oder verwenden Sie einen bereits vorhandenen Initialisierungsblock, der eine SQL-Abfrage enthält. Sie können auch einen Zeitplan erstellen, um die Abfrage auszuführen und den Wert der Variablen regelmäßig zu aktualisieren.
Wenn sich der Wert einer globalen Variablen semantischer Modelle ändert, sind alle Cacheeinträge, die diese Variable in einer Spalte verwenden, veraltet. Ein neuer Cacheeintrag wird generiert, wenn die Daten in diesem Eintrag wieder benötigt werden. Der alte Cacheeintrag wird nicht sofort entfernt. Er wird so lange beibehalten, bis er im Rahmen des normalen Caching-Mechanismus gelöscht wird.
Einer der Hauptvorteile beim Abfrage-Caching ist die Verbesserung der wahrnehmbaren Abfrageperformance.
Abfrage-Caching ist möglicherweise hilfreich, um außerhalb der Geschäftszeiten Cache-Seeding auszuführen, indem Sie Abfragen ausführen und deren Ergebnisse cachen. Für eine gute Seeding-Strategie müssen Sie wissen, wann Cachetreffer auftreten.
Wenn Sie Cache-Seeding für alle Benutzer ausführen möchten, können Sie beispielsweise folgende Abfrage ausführen:
SELECT User, SRs
Nachdem Sie das Cache-Seeding mit SELECT User, SRs ausgeführt haben, sind die folgenden Abfragen Cachetreffer:
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)
Der vorliegende Abschnitt umfasst die folgenden Themen:
Bei aktiviertem Caching wird jede Abfrage dahingehend ausgewertet, ob sie sich für einen Cachetreffer qualifiziert.
Ein Cachetreffer bedeutet, dass Oracle Analytics Cloud die Abfrage mit dem Cache beantworten konnte und nicht auf die Datenbank zugreifen musste. In Oracle Analytics Cloud können Abfragen auf derselben oder einer höheren Aggregationsebene mit dem Abfragecache beantwortet werden.
Ob ein Cachetreffer vorliegt, hängt von mehreren Faktoren ab. In der nachstehenden Tabelle werden diese Faktoren beschrieben.
| Faktor oder Regel | Beschreibung |
|---|---|
|
Eine Teilmenge der Spalten in der |
Alle Spalten in der 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 |
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 |
|
|
Für eine Qualifikation der Abfrage als Cachetreffer müssen die Constraints der Eine
Darüber hinaus müssen Spalten, die in der 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 ( |
|
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: |
|
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. |
|
|
Wenn eine gecachte Abfrage doppelte Datensätze mit |
|
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 |
|
|
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 |
Wenn Sie eine Datenbanksicherheitsstrategie auf Zeilenebene verwenden, wie Virtual Private Database (VPD), sind die zurückgegebenen Datenergebnisse von den Autorisierungszugangsdaten des Benutzers abhängig.
Aus diesem Grund muss in Oracle Analytics Cloud angegeben werden, ob für eine Datenquelle die Datenbanksicherheit auf Zeilenebene verwendet wird und welche Variablen sicherheitsrelevant sind.
Um sicherzustellen, dass Cachetreffer nur für Cacheeinträge auftreten, bei denen alle sicherheitssensitiven Variablen enthalten sind und übereinstimmen, müssen Sie das Datenbankobjekt und die Sessionvariablenobjekte im Model Administration Tool wie folgt ordnungsgemäß konfigurieren:
Datenbankobjekt: Wählen Sie im physischen Layer im Dialogfeld "Datenbank" auf der Registerkarte "Allgemein" die Option Virtual Private Database aus, um anzugeben, dass die Datenquelle Datenbanksicherheit auf Zeilenebene verwendet.
Wenn Sie die Datenbanksicherheit auf Zeilenebene mit gemeinsamem Caching verwenden, müssen Sie diese Option auswählen, um das Sharing von Cacheeinträgen zu verhindern, deren sicherheitssensitiven Variablen nicht übereinstimmen.
Sessionvariablenobjekt: Wählen Sie für sicherheitsbezogene Variablen im Dialogfeld "Sessionvariable" die Option Sicherheitssensitiv aus, um diese bei Verwendung einer Datenbanksicherheitsstrategie auf Zeilenebene als sicherheitssensitiv zu identifizieren. Mit dieser Option stellen Sie sicher, dass Cacheeinträge mit den sicherheitssensitiven Variablen markiert werden und ein Abgleich der sicherheitssensitiven Variablen für alle eingehenden Abfragen aktiviert wird.
Um die möglichen Cachetreffer zu maximieren, haben Sie die Möglichkeit, eine Folge von Abfragen zum Auffüllen des Cache auszuführen.
Im Folgenden erhalten Sie Empfehlungen für die Abfragetypen, die Sie beim Erstellen einer Folge von Abfragen für das Seeding des Cache ausführen können.
Allgemeine vordefinierte Abfragen: Allgemein ausgeführte Abfragen, insbesondere solche mit aufwendiger Verarbeitung, sind hervorragende Abfragen für das Cache-Seeding. Ein gutes Beispiel für allgemeine Abfragen sind solche, deren Ergebnisse in Dashboards eingebettet sind.
SELECT-Listen ohne Ausdrücke: Durch das Beseitigen von Ausdrücken in Spalten der SELECT-Liste wird die Möglichkeit für Cachetreffer erhöht. Eine gecachte Spalte mit einem Ausdruck kann nur als Antwort auf eine neue Abfrage mit demselben Ausdruck verwendet werden. Eine gecachte Spalte ohne Ausdrücke kann als Antwort auf eine Anforderung für diese Spalte mit einem beliebigen Ausdruck verwendet werden. Beispiel: Eine gecachte Anforderung wie:
SELECT QUANTITY, REVENUE...
kann als Antwort auf eine neue Abfrage verwendet werden, wie:
SELECT QUANTITY/REVENUE...
aber nicht umgekehrt.
Keine WHERE-Klausel: Wenn in einem gecachten Ergebnis keine WHERE-Klausel verwendet wird, kann es als Antwort auf Abfragen verwendet werden, die den Regeln für Cachetreffer für die SELECT-Liste mit einer beliebigen WHERE-Klausel entsprechen, die Spalten in der Projektionsliste enthält.
Im Allgemeinen sind die besten Abfragen für das Cache-Seeding solche Abfragen, die große Mengen an Datenbankverarbeitungsressourcen konsumieren und wahrscheinlich erneut ausgegeben werden. Achten Sie darauf, dass Sie keine einfachen Abfragen, die viele Zeilen zurückgeben, für das Cache-Seeding verwenden. Diese Abfragen (z.B. SELECT * FROM PRODUCTS, wobei PRODUCTS einer einzigen Datenbanktabelle direkt zugeordnet ist) erfordern sehr wenig Datenbankverarbeitung. Ihr Aufwand besteht aus Netzwerk- und Datenträger-Overhead. Solche Faktoren werden von Caching nicht vermindert.
Wenn Oracle Analytics Cloud Variablen semantischer Modelle aktualisiert, werden Geschäftsmodelle dahingehend untersucht, ob sie diese Variablen semantischer Modelle referenzieren. Ist das der Fall, löscht Oracle Analytics Cloud den gesamten Cache für diese Geschäftsmodelle. Siehe Auswirkungen von Änderungen eines semantischen Modells auf den Abfragecache.
Sie können Agents für das Seeding des Oracle Analytics Cloud-Abfragecache konfigurieren.
Ein Cache-Seeding kann die Antwortzeiten für Benutzer verkürzen, wenn sie Analysen ausführen oder anzeigen, die in ihren Dashboards eingebettet sind. Dies können Sie erreichen, indem Sie Agents für die Ausführung von Anforderungen zur Aktualisierung dieser Daten planen.
Der einzige Unterschied zwischen Cache-Seeding-Agents und anderen Agents besteht darin, dass sie den vorherigen Cache automatisch löschen und auf dem Dashboard nicht als Alerts angezeigt werden.
Hinweis:
Cache-Seeding-Agents löschen nur Abfragen mit exakten Übereinstimmungen, d.h. unter Umständen sind noch veraltete Daten vorhanden. Stellen Sie sicher, dass die Caching-Strategie immer ein Löschen des Cache beinhaltet, weil Abfragen von Agents keine Ad-hoc-Abfragen oder Drills berücksichtigen.Beim Löschen des Cache werden Einträge aus dem Abfragecache gelöscht und Ihre Inhalte auf dem aktuellen Stand gehalten. Sie können Cacheeinträge für bestimmte Tabellen automatisch löschen, indem Sie das Feld Cachepersistenzzeit für die jeweilige Tabelle in Model Administration Tool festlegen.
Hinweis:
Wenn Sie den semantischen Modellierer verwenden, lesen Sie Was sind die allgemeinen Eigenschaften einer physischen Tabelle?.
Diese Aktion ist hilfreich für Datenquellen, die häufig aktualisiert werden. Beispiel: Bei einer Tabelle, in der Börsentickerdaten gespeichert sind, die jede Minute aktualisiert werden, können Sie die Einstellung Cachepersistenzzeit verwenden, um die Einträge für diese Tabelle alle 59 Sekunden zu löschen. Siehe Caching und Cachepersistenzzeit für bestimmte physische Tabellen.