Data Guard ist kein einzelner Schalter für Hochverfügbarkeit, sondern ein Betriebsmodell für geplante und ungeplante Ausfälle. In Oracle AI Database 26ai bleibt deshalb die wichtigste Frage dieselbe: Welche Ausfallzeit und welcher Datenverlust sind für die jeweilige Anwendung akzeptabel?
1. RTO und RPO vor der Topologie festlegen
Das Recovery Time Objective (RTO) beschreibt, wie schnell ein Service wieder verfügbar sein muss. Das Recovery Point Objective (RPO) beschreibt, wie viele Transaktionen im schlechtesten Fall verloren gehen dürfen. Ohne diese beiden Werte lässt sich nicht sinnvoll entscheiden, ob asynchroner Transport genügt oder ob ein strengerer Schutzmodus und zusätzliche Netzwerk- oder Standortplanung nötig sind.
Dokumentieren Sie die Ziele pro Anwendung statt pauschal für die gesamte Datenbank. Ein Reporting-System kann andere Anforderungen haben als ein Auftragssystem. Auch abhängige Komponenten wie ORDS, Batch-Jobs, externe Schnittstellen und Secrets gehören in dieselbe Recovery-Betrachtung.
2. Transport und Apply getrennt beobachten
Bei der Überwachung sollten DBAs zwischen Transport Lag und Apply Lag unterscheiden. Transport Lag zeigt, wie weit die Standby noch auf Redo vom Primärsystem wartet. Apply Lag zeigt, wie weit die übertragenen Änderungen dort noch verarbeitet sind. Nur „Standby erreichbar“ zu prüfen, reicht daher nicht aus.
Schwellenwerte müssen zur Anwendung passen und alarmieren, bevor das RPO verletzt wird. Zusätzlich gehören Broker-Status, Redo-Transportfehler, Archive-Destinationen, Speicherplatz, Netzwerklatenz und die zeitliche Entwicklung des Rückstands ins Monitoring. Ein kurzer Lag-Spike ist anders zu bewerten als ein kontinuierlich wachsender Rückstand.
3. Switchover und Failover sauber unterscheiden
Ein Switchover ist ein geplanter Rollenwechsel. Er eignet sich für Wartungsfenster, Tests und regelmäßige Übungen, weil die beteiligten Systeme kontrolliert vorbereitet werden können. Ein Failover ist die Reaktion auf einen ausgefallenen oder nicht mehr vertrauenswürdigen Primärstandort. Dabei stehen Geschwindigkeit, Datenkonsistenz und eine klare Entscheidungskette im Vordergrund.
Für beide Szenarien braucht das Runbook mehr als einen Datenbankbefehl: Anwendungen müssen gestoppt oder umgeschaltet, Services am neuen Primärsystem gestartet, Verbindungen und Zertifikate geprüft und Schreibzugriffe kontrolliert werden. Nach einem ungeplanten Failover muss außerdem entschieden werden, ob und wie der alte Primärstand wieder als Standby eingebunden wird.
4. Standby-Offload bewusst einsetzen
Eine Standby kann nicht nur als Notfallkopie dienen. Read-only-Reports, Backups oder bestimmte Extraktionen lassen sich – abhängig von Lizenzierung, Architektur und fachlicher Konsistenz – vom Primärsystem entkoppeln. Das kann Produktionsressourcen schonen, ändert aber nichts an den Anforderungen an Transport, Apply und Überwachung.
Für jede ausgelagerte Last sollte festgelegt sein, wie aktuell die Daten sein müssen und wie sich ein Apply-Rückstand auf das Ergebnis auswirkt. Fachbereiche brauchen diese Grenze als verständliche Zusage, nicht nur als technische Metrik.
5. Der Recovery-Test als wiederholbares Runbook
- RTO, RPO, Verantwortliche und Kommunikationsweg pro Service bestätigen.
- Transport, Apply, Broker-Status und verfügbare Zielkapazität vor dem Test prüfen.
- Switchover mit realistischen Client- und Anwendungstests durchführen.
- Für das Failover den Entscheidungsweg, Datenstand und Freigabepunkt dokumentieren.
- Services, Jobs, Schnittstellen, Backups und Monitoring am neuen Primärsystem verifizieren.
- Rückkehr zur Ausgangstopologie oder Reinstatement testen und die gemessene Dauer festhalten.
Fazit
Oracle AI Database 26ai macht moderne Hochverfügbarkeits- und Recovery-Architekturen nicht automatisch planbar. Planbar werden sie durch klare RTO- und RPO-Ziele, getrennte Lag-Metriken, geprüfte Rollenwechsel und regelmäßige Übungen. Data Guard liefert dafür die technische Grundlage; der belastbare Notfallbetrieb entsteht erst aus Architektur, Monitoring und einem getesteten Prozess.
Weiterführend: Oracles Überblick zu mission-critical availability in der AI-Ära und die Dokumentation zur High Availability.