Eine PL/SQL-Funktion wird in einer Anwendung oft tausendfach mit denselben Parametern aufgerufen, etwa um einen Steuersatz oder eine Länderbezeichnung nachzuschlagen. Wenn jeder Aufruf erneut eine Tabelle liest, entstehen vermeidbare SQL-Ausführungen. Mit RESULT_CACHE kann Oracle das Ergebnis im SGA zwischenspeichern und bei passenden Folgeaufrufen zurückgeben.
Nur Funktionen mit stabiler Semantik cachen
Das Beispiel eignet sich für eine kleine, vergleichsweise selten geänderte Referenztabelle. Oracle erkennt die Tabellenabhängigkeit automatisch; eine RELIES_ON-Klausel ist in aktuellen Versionen nicht erforderlich.
CREATE OR REPLACE FUNCTION get_tax_rate (
p_country_code IN VARCHAR2,
p_category IN VARCHAR2
) RETURN NUMBER
RESULT_CACHE
IS
l_rate NUMBER;
BEGIN
SELECT rate
INTO l_rate
FROM tax_rates
WHERE country_code = p_country_code
AND category = p_category;
RETURN l_rate;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 0;
END;
/Der Cache-Schlüssel wird aus den Eingabeparametern gebildet. Oracle verwaltet erkannte Tabellenabhängigkeiten und invalidiert betroffene Ergebnisse nach einem Commit, der diese Tabellen verändert. Bei häufigen Änderungen kann der Invalidierungsaufwand den Nutzen allerdings aufzehren. Auch der erste Aufruf ist nicht automatisch schneller: Oracle baut den Cache erst bei wiederholter Nutzung auf.
Session-Kontext ist die häufigste Falle
Ein gecachtes Ergebnis muss ausschließlich von den Parametern und dem maßgeblichen committed Datenstand abhängen. Funktionen, die etwa SYS_CONTEXT, NLS-Einstellungen, Package-Variablen, Sequenzen oder die aktuelle Uhrzeit auswerten, können bei gleichen Parametern je Session unterschiedliche Werte liefern. Ein gemeinsam genutzter Cache wäre dann fachlich falsch oder die Funktion ist nicht cachefähig.
Das ist besonders für APEX-Anwendungen mit Mandanten- oder Benutzerkontext wichtig: Berechtigungsentscheidungen und benutzerabhängige Daten sollten nicht unbedacht über einen gemeinsamen Funktionscache geteilt werden. Falls ein Kontext fachlich wirklich Teil des Ergebnisses ist, muss er explizit in die Parameter und damit in den Cache-Schlüssel einfließen – andernfalls besser nicht cachen.
Nutzen messen statt vermuten
Prüfen Sie nach einem repräsentativen Lasttest, ob Einträge wiederverwendet und selten invalidiert werden:
SELECT name, status, scan_count, invalidations
FROM v$result_cache_objects
WHERE type = 'Result'
ORDER BY scan_count DESC;Viele Scans bei niedrigen Invalidierungen sprechen eher für Wiederverwendung; häufige Invalidierungen oder kaum erneute Treffer sind ein Anlass, den Cache-Einsatz zu hinterfragen. Beobachten Sie zusätzlich die tatsächliche Datenbanklast und den Anteil der wiederholten Argumentkombinationen. Der Result Cache ist ein SGA-Cache, kein dauerhaftes Speicherverfahren.
Fazit
RESULT_CACHE ist nützlich für reine Funktionen mit wiederkehrenden Eingaben und stabilen Referenzdaten. Der entscheidende Schritt ist nicht das Schlüsselwort, sondern der Nachweis, dass das Ergebnis nicht heimlich von Session oder Zeit abhängt und dass Invalidierungen selten genug sind. Erst messen, dann gezielt aktivieren.
Weiterführend: Oracles Dokumentation zu PL/SQL Function Result Cache, zur RESULT_CACHE-Klausel und zum Tuning des Result Cache.