In unserem Unternehmen Drägerwerk AG & Co. KGaA verwenden die Techniker weltweit eine spezielle Service Connect Applikation, über die Dokumentationen von Geräten zur Verfügung gestellt werden. Die Applikation arbeitet im Hintergrund mit einer Oracle Datenbank der Version 11.2.0.4.

In der betroffenen Datenbank kommen seit kurzer Zeit Oracle Data Rest Services (kurz ORDS) zum Einsatz; in jedem Rest Modul ist dabei eine Authentifizierung eingebaut. Da die Clients ständig nach Aktualisierungen fragen, werden die ORDS Module und das dort existierende Authentifizierungspackage sehr oft ausgeführt. Dies führte bei uns zu massiven Performanceproblemen.

Folgende Tabelle zeigt eine Messung aus der Praxis: Innerhalb einer (1) Stunde (von 12:28 bis 13:28) zeigte sich folgendes Verhalten.

Sum_in_Sec	SQL_ID	Begin	End	Executions
50877	cd07b8r05zymu	2016-06-27 12:28:08	2016-06-27 13:28:07	50733
28115	4cqvnf34a5qm4	2016-06-27 12:28:08	2016-06-27 13:28:07	28037
9808	dvj0g055n95qz	2016-06-27 12:28:08	2016-06-27 13:28:07	9779
...	...	2016-06-27 12:28:08	2016-06-27 13:28:07	...

Offensichtlich wurden drei Abfragen (Authentifizierungabfragen) circa 88.000 Mal pro Stunde (siehe rechte Spalte) ausgeführt und dies in 88801 CPU Sekunden (siehe linke Spalte). Allein um diese Aufgabe auszuführen, bräuchten wir rein rechnerisch circa 24 Prozessoren. Weil der Server nur 16 CPUs besitzt, kam es natürlich immer wieder zu großen Performanceproblemen. Die Abfragen selbst waren dabei sehr einfach, und es sah für uns so aus, als ob diese nicht zu beschleunigen/verbessern seien. Sollten etwa diese simplen Abfragen die gesamte Datenbank lahm legen?

Auf der Suche nach einer Lösung ist mir die Dojo Publikation Oracle Database In Memory Technologie in die Hände gefallen. Nach der Lektüre des Kapitels 5 Der Ergebnis Result Cache wurde mir sofort klar, dass der PL/SQL Function Result Cache die Lösung für unser Problem ist.

Zur Erinnerung noch einmal eine kurze Beschreibung des Result Caches aus dem Dojo:

"Der Result Cache ist ein speziell für Ergebnisse aus SQL-Abfragen oder PL/SQL-Funktionen vorgesehener Cache. Die Datenbank verwaltet den Cache dabei völlig selbstständig und stellt dabei sicher, dass niemals veraltete Ergebnisse ausgegeben werden. Oder etwas genauer: Ergebnisse von Statements bzw. Ergebnisse aus PL/SQL Funktionen, die den Result Cache nutzen, werden bei der Ausführung im Result Cache abgelegt und bei den Folgeausführungen wiederverwendet. Die Konsequenz ist eine drastisch reduzierte Ausführungszeit besonders bei Statements und PL/SQL Funktionen, die sich häufig wiederholen und deren Ergebnisse nur mit aufwändigen Mitteln d.h. mit hohem Ressourcenaufwand und Ausführungszeiten zu realisieren sind. Um konsistente Abfragen zu garantieren, wird bei Änderungen an den Tabellenwerten der Cache automatisch invalidiert. Der Result Cache kann übrigens client- oder serverseitig Verwendung finden."

Wie konnte nun unsere Lösung aussehen? Da sich der PL/SQL Function Result Cache offensichtlich nur innerhalb des PL/SQL Codes selbst aktivieren lässt, müssen die entsprechenden Funktionen mit dem Schlüsselwort Result Cache ausgestattet werden. Da unsere Authentifizierungsabfragen auf ein bestimmtes Package zugreifen, das aus vielen Funktionen besteht, haben wir in jeder Funktion das Schlüsselwort "result_cache" wie folgt hinzugefügt.

  FUNCTION func1 (
                  par1 IN VARCHAR2, 
                  par2 IN VARCHAR2 default 'R001', 
                  par3 IN NUMBER default null
                  ) return VARCHAR2 RESULT_CACHE;

Nachdem der Result Cache aktiv war, warteten wir ungeduldig auf die Ergebnisse.

Sofort nach der Umsetzung konnte ich sehen, dass die Authentifizierungsabfragen aus dem "Top SQL" Bereich komplett verschwunden waren. Zusätzlich konnte ich feststellen, das die Datenbank Server plötzlich kaum noch belastet war!

Nun wartete ich noch auf die ersten Reaktionen der Applikationsbetreuer, und hier kam eine tolle Überraschung: " Was hast Du gemacht? Die Performance ist ausgezeichnet! Dies waren die ersten Kommentare."
Nach der Überprüfung des Result Caches über die View V$RESULT_CACHE_OBJECTS wusste ich auch woher diese Performanceverbesserung rührte. Anmerkung: V$RESULT_CACHE_OBJECTS gibt Aufschluss über die Nutzung der einzelnen Ergebnisse im Cache und ihren Abhängigkeiten. So kann man genau feststellen, wie häufig z.B. ein "Cache-Objekt" vom Typ "Result" oder "Dependency" verwendet worden ist.

SQL> SELECT id, name, cache_id, type, status, invalidations, scan_count  
     FROM v$result_cache_objects;

In unserem Beispiel so das so aus:

In der Spalte SCAN_COUNT (rechte Spalte rot umrandet) konnten wir erkennen, dass die Authentifizierungsabfragen im Result Cache sehr schnell tausende Male gescannt wurden.

Fazit

Das Ergebnis hat alle unsere Erwartungen übertroffen. Nach der Einführung des Result Caches verbrauchen die gleichen Abfragen durchschnittlich nur noch 0,5 CPU pro Stunde statt wie zu Beginn die berechneten 24 CPUs. Im erwähnten Dojo fand ich folgendes Zitat: " Den Oracle Result Cache finde ich einfach cool! " Dieser Feststellung kann ich mich einfach nur anschließen. Für mich ist Oracle Result Cache in einigen Applikationen unersetzlich, weil dadurch massiv Performance verbessert werden kann.

Weitere Informationen

Downloadadresse der Dojo Büchlein: http://tinyurl.com/dojoonline

Zurück zum Anfang des Artikels

Zurück zur Community-Seite