Viele Anwendungen halten Metadaten-Caches für Tabellen, Spalten oder Objekte im Mittel-Tier. Ohne Benachrichtigung bleibt oft nur regelmäßiges Polling: Es erzeugt Abfragen, reagiert verzögert und kann nach einer DDL-Änderung kurzzeitig mit veralteten Informationen arbeiten. Oracle AI Database 26ai führt dafür Table DDL Change Notification ein.
1. DDL-Änderungen abonnieren
Ein Client registriert eine Subscription über OCISubscriptionRegister und verwendet dafür die DDL-Notification-Quality-of-Service-Option OCI_SUBSCR_CQ_QOS_DDL_NTFN. Die Benachrichtigungen werden im Namespace DBCHANGE verarbeitet. Je nach Anwendungsfall kann die Registrierung auf einzelne Tabellen, ein Schema oder die gesamte Datenbank begrenzt werden.
Das ist besonders nützlich für Middle-Tier-Komponenten, die ihre Objekt- oder Schema-Metadaten nur dann neu laden müssen, wenn sich tatsächlich etwas geändert hat. Die Ereignisverarbeitung läuft asynchron und blockiert die normalen Benutzer-DMLs nicht.
2. Was ein Ereignis enthält
Das Payload liefert unter anderem die DDL-Operation, den Namen der Basistabelle, den Objekttyp, den Datenbanknamen, die Commit-SCN und den Änderungszeitpunkt in UTC. Abhängig vom Scope können beispielsweise CREATE, ALTER, DROP, TRUNCATE, RENAME oder FLASHBACK relevant sein. Partition- und Subpartition-Operationen lassen sich mit der passenden Option ebenfalls berücksichtigen.
Die Anwendung sollte das Ereignis nicht blind als vollständige Cache-Invalidierung interpretieren. Besser ist eine kleine Zuordnung: Welcher Metadaten-Cache hängt vom Objektnamen und Operationstyp ab, muss neu geladen werden? So bleibt die Reaktion schnell und nachvollziehbar.
3. Cache-Invalidierung statt Dauer-Polling
Ein praktikabler Ablauf besteht aus drei Schritten: Das Ereignis wird entgegengenommen, der betroffene Cache-Eintrag wird als veraltet markiert und ein kontrollierter Refresh liest die aktuelle Definition aus der Datenbank. Bei konkurrierenden Änderungen sollte die Anwendung mehrere Ereignisse zusammenfassen können, statt für jedes Signal einen eigenen Refresh zu starten.
Wichtig ist außerdem die Beobachtbarkeit. Logge Objekt, DDL-Typ, Commit-SCN, Empfangszeit und Refresh-Ergebnis. Damit lässt sich später unterscheiden, ob ein veralteter Cache durch eine übersehene Notification, einen fehlgeschlagenen Refresh oder eine fachlich zu lange TTL entstanden ist.
4. Neustart und Failover einplanen
Die Ereignisse werden für die Verarbeitung im SGA bereitgestellt. Nicht verarbeitete Events sind nach einem Instance-Neustart oder Failover nicht dauerhaft verfügbar. Ein Client darf daher nicht annehmen, dass er nach einer Unterbrechung jedes einzelne DDL-Ereignis nachträglich erhält.
Nach einem Standby-Failover muss die Anwendung ihre Registrierung auf der neuen Primary erneut einrichten. Zusätzlich empfiehlt sich ein Initial- oder Recovery-Refresh: Nach einem Verbindungsverlust werden die relevanten Metadaten neu eingelesen, bevor der Cache wieder als vollständig aktuell gilt.
5. Betriebsmodell für OCI-Clients
- Scope klein starten: zunächst einzelne Tabellen oder ein klar abgegrenztes Schema abonnieren.
- Handler idempotent bauen und doppelte oder gebündelte DDL-Signale tolerieren.
- Bei Disconnect, Instance-Neustart und Failover automatisch re-registrieren.
- Nach Unterbrechungen einen vollständigen Recovery-Refresh ausführen.
- Empfang, SCN, Latenz, Refresh-Fehler und Registrierungsstatus überwachen.
- DDL-Berechtigungen und Netzwerkpfade des OCI-Clients getrennt prüfen.
Fazit
Table DDL Change Notification in Oracle AI Database 26ai schafft einen sauberen Auslöser für Metadaten- und Schema-Caches. OCI-Clients reagieren gezielter als mit periodischem Polling, während DMLs unbeeinträchtigt bleiben. Den produktiven Unterschied machen jedoch Re-Registrierung, Recovery-Refresh und messbares Event-Monitoring.
Weiterführend: Oracles Dokumentation zu Table DDL Change Notification, die 26ai-Neuerungen für Application Development und die Neuerungen in Oracle AI Database 26ai.