Oracle Database · · 3 Min.

True Cache in 26ai einordnen

Wie ein transparenter Mid-Tier-Cache Read-Workloads entlasten kann und welche Betriebsfragen DBAs klären müssen.

Veröffentlicht am 25.09.2026 · Verfasst von Veysi Guenay

Viele Oracle-Anwendungen lesen deutlich mehr Daten, als sie ändern. Dashboards, Suchseiten, APEX-Anwendungen und APIs erzeugen dabei wiederkehrende Abfragen auf denselben Tabellen. Oracle AI Database 26ai ergänzt die Architektur um True Cache: einen Mid-Tier-Cache, der Lesezugriffe näher an die Anwendung bringen kann, ohne die SQL-Kompatibilität der Datenbank aufzugeben.

Einordnung: Ein Cache ist kein Ersatz für Datenbankdesign oder Lastanalyse. Der Nutzen entsteht nur, wenn die Workloads cachefähig sind und Konsistenzanforderungen, Invalidierung und Ausfallverhalten klar definiert wurden.

1. Für welche Workloads True Cache interessant ist

True Cache ist besonders für leseintensive Anwendungen interessant, bei denen viele Nutzer ähnliche Daten abfragen. Dazu gehören Kataloge, Statusübersichten, Stammdaten, Suchergebnisse oder analytische Auszüge mit kurzen Aktualisierungszyklen. Häufige Reads können dadurch näher an der Anwendung beantwortet werden, während der Primärdatenbank weniger Arbeit bleibt.

Schreibintensive Transaktionen, stark benutzerspezifische Abfragen oder Daten mit unmittelbar sichtbaren Änderungen müssen separat betrachtet werden. Eine Cache-Architektur sollte nicht pauschal auf jede Verbindung angewendet werden. Erstellen Sie zuerst eine Liste der SQL-Muster und klassifizieren Sie sie nach Aktualitätsbedarf.

2. Konsistenz als Architekturentscheidung

Für DBAs ist die zentrale Frage nicht nur „Wie schnell ist der Cache?“, sondern „Welche Daten darf ein Nutzer wie lange unverändert sehen?“. Bei einem Dashboard kann eine kurze Verzögerung akzeptabel sein; bei Kontoständen, Berechtigungen oder Lagerbeständen kann sie fachlich kritisch sein.

Dokumentieren Sie pro Anwendung oder Datenbereich die erlaubte Staleness. Prüfen Sie, wie Änderungen vom Primärsystem zum Cache gelangen und wie sich ein Neustart oder eine Unterbrechung auswirkt. Ein kontrollierter Fallback zur Primärdatenbank gehört in das Design und in den Testplan.

3. DBAs brauchen neue Betriebsmetriken

Neben den bekannten Datenbankmetriken werden Cache-Hit-Rate, Latenzverteilung, Synchronisationsstatus und Fehlerraten relevant. Ein hoher Hit-Anteil ist nicht automatisch gut, wenn die Treffer veraltet sind oder ein kleiner Teil kritischer Abfragen regelmäßig auf den Primärserver fällt.

Vergleichen Sie Baseline und Zielarchitektur mit identischen Lastprofilen. Messen Sie p95- und p99-Latenz, Primärdatenbank-CPU, Netzwerkwege und die fachliche Aktualität. Ein Ausfalltest sollte zeigen, ob Anfragen sauber zurückfallen oder ob die Anwendung Fehler beziehungsweise alte Daten erhält.

4. Einführung in fünf Schritten

  1. Read-Workloads über SQL Monitoring, AWR oder vorhandene Observability-Daten identifizieren.
  2. Abfragen nach Aktualitätsbedarf, Personalisierung und Schreibabhängigkeit klassifizieren.
  3. Eine nichtkritische, leseintensive Anwendung für einen kontrollierten Pilot auswählen.
  4. Hit-Rate, Latenz, Konsistenzfenster und Fallback-Verhalten unter Last messen.
  5. Runbooks für Cache-Ausfall, Wiederanlauf, Kapazität und Datenabweichungen dokumentieren.
Praxisregel: Beginnen Sie mit einem klar abgegrenzten Read-Use-Case. Wenn niemand sagen kann, wie alt ein Ergebnis maximal sein darf, ist die Anwendung noch nicht bereit für einen Cache-Pilot.

Fazit

True Cache kann in Oracle AI Database 26ai ein interessanter Baustein für niedrigere Lese-Latenzen und mehr Read-Scaling sein. Der Erfolg hängt aber an der Betriebsdisziplin: Workloads müssen klassifiziert, Konsistenzgrenzen vereinbart und Ausfälle getestet werden. Für DBAs wird der Cache damit zu einem eigenen Betriebsobjekt zwischen Anwendung und Primärdatenbank.

Weiterführend: Oracle: Überblick zu Oracle AI Database 26ai, die 26ai New Features und der Database Administrator’s Guide.