SQL Result Cache in Oracle 11g

Transkript

1 SQL Result Cache in Oracle 11g Autor: Jürgen Vester, ORACLE Deutschland GmbH Eine der interessantesten Neuerungen in Oracle 11g, da sind sich Tom Kyte und Steven Feuerstein einig, stellt das Caching von Result Sets in der SGA dar. In vielen BLOGs werden bereits erste Performance-Zahlen veröffentlicht, die die Erwartungen mehr als erfüllen. Sowohl Web-Anwendungen als auch DHW- und OLTP-Systeme können vom Result Cache profitieren, wenn bestimmte Voraussetzungen gegeben sind. Einmal vom Datenbank-Administrator konfiguriert, steht dieses Feature transparent für die Anwendung zur Verfügung. Der Entwickler kann diese Funktion beispielsweise direkt als Optimizer Hint im SQL-Statement verwenden. Der zur Verfügung stehende Hauptspeicher und die Dimensionierung der SGA spielen eine bedeutende Rolle bei den zu erzielenden Effekten. Mit Oracle 11g können neben den Datenbank-Blöcken auch Ergebnisse von SQLund PL/SQL-Funktionen in einem reservierten Bereich des Shared Pools gecached werden. Das Konzept erinnert an eine "Just-in-time" Materialized View, die im Memory liegt. Dieser neue Pool-Bereich wird vom Automatic-Shared-Memory- Management verwaltet. Sowohl als Hint im SQL-Statement als auch bei PL/SQL- Funktionen wird Memory für den Result Cache allokiert. Bei Änderungen an den Basistabellen wird dieser automatisch auf "invalid" gesetzt und neu aktualisiert. Wird beispielsweise im SQL-Statement der Hint /*+ result_cache */ verwendet, prüft der Optimizer zunächst, ob für diese Query ein passendes Ergebnis im Result Cache zur Verfügung steht. Ist dies der Fall, wird die Query direkt aus dem Result Cache beantwortet und kann zu extrem guten Antwortzeiten führen. Der Result Cache wird über Session-Grenzen hinweg genutzt. Statements mit gleichem oder teilweise identischem Ausführungsplan können vom Result Cache profitieren. Mit Hilfe des Optimizer-Hints /*+ no_result_cache */ lässt sich die Bildung eines Result Sets ausschliessen. Auf Session Ebene kann mit dbms_result_cache.bypass(true) der Result Cache für einzelne Statements umgangen werden. Im Ausführungsplan beziehungsweise im Memory Report wird der Result Cache bei Verwendung angezeigt (siehe Abbildung 1). Beim Einsatz von Real Application Clusters (RAC) werden die Result Caches zwischen den Instanzen

2 nicht ausgetauscht und müssen bei Bedarf auf jeder beteiligten Instanz disabled werden. Im folgenden Beispiel werden die Tabellen des HR-Schemas benutzt. Die SQL-Syntax wurde um diesen neuen Optimizer Hint SELECT /*+ result_cache */ Col1, Col2 from table; erweitert. department_name, emp_cnt FROM(SELECT /*+ result_cache */ department_id, COUNT(*) emp_cnt FROM employees GROUP BY department_id) e, departments d WHERE e.department_id = d.department_id AND CONTAINS(department_name, 'A%')>0; Erweitert man das Statement um die Contains-Klausel für eine Volltextrecherche, kann selbst in diesem Fall der Result Cache genutzt werden. In einer PL/SQL- Funktion wird nach der "result_cache"-klausel die Angabe der Tabelle(n) erwartet. Bei einer Änderung an den zugrunde liegenden Daten der Tabelle(n) wird der Cache für diese Query auf invalid gesetzt und beim nächsten Mal neu gebildet. Nachfolgend das Beispiel für eine PL/SQL-Funktion: HR@ORCL11g>...function f(p1 in Typ_1, p2 in Typ_2,...) return Typ_R result_cache relies_on(tab_1, Tab_2, Tab_3,...) is Der Entwickler kann anhand des Ausführungsplans erkennen, ob sein geschriebenes SQL-Statement die vorhandenen Ergebnisse im Result Cache nutzt. Abbildung 1: Execution Plan mit /*+ result_cache */-Hint im SELECT-Statement

3 Anwendungsgebiete Gedacht ist der Result Cache für vorhersehbare, sich immer wiederholende Abfragen, bei denen geringe Änderungen an den zugrunde liegenden Datenbeständen vorliegen. Sowohl Abfragen mit kleinen Ergebnismengen als auch langlaufende, komplexe und mit aufwändigeb Berechnungen versehenen Queries und Subqueries, sind optimal für den Einsatz des Result Caches geeignet. Häufig sind diese Abfragen bei DWH-Systemen und Reporting Systemen anzutreffen. Weitere Anwendungsgebiete sind Suchmaschinen, Web-Applikationen und online Auskunftssysteme. Mit dem PL/SQL-Hierarchical-Profiler wurden in Application Express PL/SQL-Funktionen identifiziert, die den Result Cache nutzen können. Nach der Recompilierung einiger Funktionen wurde eine Performance-Steigerung von 15 Prozent gemessen. Administration und Monitoring Die erforderlichen Einstellungen für den Result Cache werden vom DBA mit Hilfe der Initialisierungsparameter RESULT_* statisch oder im laufenden Betrieb vorgenommen. Im Data Dictionary stehen mit den v$result_cache_-views und den gv$result_cache_-views (RAC) Möglichkeiten für das Monitoring zur Verfügung. Neben den Views kann vom DBA das PL/SQL-Paket dbms_result_cache genutzt werden, um Statistiken über die Cache-Nutzung abzufragen. Im Paket sind Funktionen enthalten, um den Result Cache komplett oder gezielt für spezielle Abfragen oder PL/SQL-Funktionen zu leeren. Die Größe des Result Caches wird mit RESULT_CACHE_MAX_SIZE festgelegt und hängt vom jeweiligen Betriebssystem ab: alter system set result_cache_max_size=20m; Standardmäßig steht der Wert auf Null, das heißt, der Result Cache kann nicht genutzt werden. Mit RESULT_CACHE_MODE wird die Art geregelt, wie der Result Cache genutzt wird. Dieser Wert steht nach der Installation auf MANUAL, das heißt, nur SQL-Statements die explizit den Optimizer Hint /* +result_cache */ verwenden, dürfen den Result Cache nutzen. Das bietet dem DBA zumindest einen gewissen Grad an Kontrolle. Ist dieser Wert auf FORCE gesetzt, wird versucht, alle Ergebnisse von Abfragen im Result Cache vorzuhalten. Dazu ein Beispiel: alter system set result_cache_mode='force';

4 Wird die Datenbank mit dem Initialisierungsparameter MEMORY_TARGET betrieben, werden 0,25 Prozent für den Result Cache reserviert. Bei Verwendung von SGA_TARGET werden 0,5 Prozent von sga_target für den Result Cache allokiert. Bei SHARED_POOL als Initialisierungsparameter allokiert Oracle 11g 1 Prozent des Shared Pools. Insgesamt werden nicht mehr als 75 Prozent des Shared Pools für den Result Cache reserviert. Der RESULT_CACHE_MAX_RESULT-Parameter spezifiziert, wieviel Prozent des Result Caches für ein einziges Ergebnis maximal benutzt werden darf. Der Parameter steht standardmässig auf 5 Prozent. Der Result Cache Memory Report kann mit SYS@ORCL11g> exec dbms_result_cache.memory_report; vom DBA abgerufen werden. Dazu zwei Beispiele: Flushen des gesamten Result Caches: SYS@ORCL11g>exec dbms_result_cache.flush(); und Flushen des Result Caches für eine oder mehrere Tabellen: SYS@ORCL11g>exec dbms_result_cache.invalidate('employees',); Einschränkungen Der Result Cache kann beispielsweise nicht für Dictionary- und Temporary-Tables, SQL-Funktionen wie SYSDATE, SYS_CONTEXT und nicht deterministische PL/SQL-Funktionen eingesetzt werden. Bei Tabellen, die sehr starken DML- Operationen unterworfen sind, kann sich die Performance sogar verschlechtern. Im Oracle Database Performance Tuning Guide sind im Kapitel 7die Restriktionen exakt beschrieben. Fazit Das Feature kann für Anwendungen zu sehr großen Performance-Verbesserungen führen. Optimale Ergebnisse sind bei Anwendungen zu erwarten, die häufig die gleichen Abfragen ausführen und deren Daten relativ geringen Änderungen unterworfen sind. Bei OLTP-Applikationen hängt dies sehr stark von der Anwendung ab. Der Result Cache kann als eine einfache Form des SQL- bzw. PL/SQL-Tunings verstanden werden. Die Nutzung des Features ist für DBAs und Entwickler sehr einfach. Das Feld für Anwendungen ist breit gefächert. Wie Standard ERP- Anwendungen dieses Feature nutzen können, wird die Zukunft zeigen. Ein Result-

5 Cache-Advisor für die Dimensionierung im Grid Control steht nicht zur Verfügung. Weitere Informationen und Beispiele stehen im Oracle Technology Network unter folgenden URL s zur Verfügung: Tom Kyte Steven Feuerstein Arup Nanda Kontakt: Jürgen Vester juergen.vester@oracle.com