Oracle Data Guard: täglicher Betrieb und Fehlerszenarien (19c / 23ai)

Runbook für den täglichen Betrieb und die Fehlerbehebung einer bestehenden Data-Guard-Konfiguration (Physical Standby); für die Ersteinrichtung nutzt du den Guide zur Data-Guard-Installation. Wenn du nicht sicher bist, was zu tun ist, beginne mit 'Status- und Lag-Prüfung': Die schreibgeschützte Diagnose führt dich zum richtigen Szenario (geplanter Switchover, Failover, Reinstate der alten Primary, Archive Gap, Roll Forward mit RECOVER … FROM SERVICE, Neuaufbau der Standby, Snapshot Standby, Apply/Read-only, Schutzmodus/FSFO/Observer, Arbeiten an Datendateien und Redo Logs, RMAN-Backup von der Standby). Jedes Szenario folgt dem Ablauf Diagnose → Sicherheitsnetz → Durchführung → Prüfung → Nacharbeiten; es zeigt den Weg mit Broker (DGMGRL) und ohne Broker (SQL), jeweils mit den Unterschieden für Single Instance / Oracle Restart / RAC.

Topologie: Primary (Single Instance / Oracle Restart / RAC) + Physical Standby (Single Instance / Oracle Restart / RAC) + optionaler Observer

Szenarien

• Status- und Lag-Prüfung (ist alles in Ordnung?) — Schreibgeschützt: Konfiguration, Transport/Apply Lag, Archive Gap, Prozesse und Alert Log; nichts wird geändert. Wenn du nicht sicher bist, was zu tun ist, beginne hier: Der letzte Schritt nennt dir anhand der Ausgabe das richtige Szenario.
• Geplanter Switchover (Rollen tauschen) — Primary und Standby sind gesund und du willst die Rollen geplant tauschen (Wartung, DR-Übung, Rollen zurücktauschen); es gehen keine Daten verloren, die Anwendung steht einige Minuten. Solange du die Primary erreichst, wähle für einen Rollenwechsel immer dieses Szenario.
• Primary verloren: Failover auf die Standby — Die Primary ist nicht erreichbar und kommt nicht zurück (Verlust von Server, Storage oder Standort); die Standby wird zur Primary. Nicht umkehrbar: In MaxPerformance können die Daten der letzten Sekunden verloren gehen, die alte Primary braucht danach ein Reinstate oder einen Neuaufbau. Wenn du die Primary noch erreichst, wähle Switchover.
• Nach einem Failover die alte Primary als Standby zurückholen (Reinstate) — Ein Failover wurde durchgeführt und der Server der alten Primary ist wieder da; ist Flashback Database aktiv, wird sie ohne Neuaufbau zur Standby der neuen Primary. Die neue Primary bleibt geöffnet. Ist Flashback deaktiviert oder reicht das Flashback-Fenster nicht, verweist dich der Diagnoseschritt auf einen Neuaufbau.
• Archive Gap: Die Standby wartet auf fehlende archivierte Logs — v$archive_gap liefert Zeilen oder das Alert Log zeigt FAL-/Gap-Meldungen; Apply hängt bei einer Sequence. Die Datenbanken bleiben geöffnet. Gibt es die fehlenden archivierten Logs nirgends mehr, wechselt eine Auswahl im Formular auf den Roll-Forward-Weg.
• Standby weit zurück oder archivierte Logs weg: Roll Forward (RECOVER FROM SERVICE) — Die archivierten Logs aus dem Gap gibt es nirgends mehr, NOLOGGING-Operationen haben die Standby beschädigt oder die Standby liegt Tage zurück; die Standby wird ohne Neuaufbau inkrementell von der Primary aus synchronisiert (18c+).
• Standby von Grund auf neu aufbauen — Reinstate (kein Flashback) und Roll Forward sind nicht möglich oder die Dateien/die Steuerdatei der Standby sind verloren; die Standby wird gelöscht und mit DUPLICATE neu erstellt. Die Primary bleibt geöffnet, ist aber bis zum Ende des Neuaufbaus ungeschützt (sofern es keine weitere Standby gibt).
• In Snapshot Standby umwandeln / zurückwandeln (beschreibbare Kopie für Tests) — Du willst die Standby vorübergehend im Read-Write-Modus für Tests öffnen, danach die Änderungen verwerfen und zur Physical Standby zurückkehren; die Primary ist nicht betroffen und Redo kommt weiter an, aber solange sie Snapshot Standby ist, steht diese Standby nicht für einen Failover bereit.
• Redo Apply stoppen / starten, Apply-Instanz wechseln, read-only öffnen — Du willst MRP für Wartung stoppen oder neu starten, Apply auf einer RAC-Standby auf eine andere Instanz verlagern oder die Standby für Reporting öffnen (Lizenzhinweis Active Data Guard).
• Schutzmodus, Fast-Start Failover und Observer — Du willst zwischen MaxPerformance / MaxAvailability / MaxProtection wechseln, FSFO aktivieren oder deaktivieren oder den Observer verwalten.
• Datendateien, Redo Logs und Standby Redo Logs hinzufügen / UNNAMED-Datei — Auf der Primary soll eine Datendatei oder ein Redo Log hinzugefügt werden, auf der Standby ist eine UNNAMED-Datei entstanden (ORA-01111/ORA-01274) oder es fehlen Standby Redo Logs.
• RMAN-Backup von der Standby erstellen — Du willst RMAN-Backups auf der Standby ausführen, um die Primary von der Backup-Last zu befreien, und die Löschrichtlinie für archivierte Logs entsprechend einstellen.

Vor dem Start

• Auf allen Servern setzt das Profil des Benutzers oracle ORACLE_HOME=…, ORACLE_SID (…bei RAC je Knoten …1, …2 …………) und PATH; sqlplus, rman…, dgmgrl… funktionieren. Die Konfiguration wurde mit dem Guide zur Data-Guard-Installation oder gleichwertig aufgebaut (TNS-Aliase …, …, statische _DGMGRL-Listener-Einträge, dieselbe Passwortdatei).
• Es ist geprüft, dass die Rollen den Eingaben entsprechen: Derzeit ist … die Primary, … die Physical Standby. Falls nicht (z. B. nach einem früheren Switchover), tausche die Namen in den Eingaben.
• Das SYS-Passwort ist bekannt (Rollenwechsel, Neustart der entfernten Instanz und RMAN FROM SERVICE erfordern eine passwortgestützte Verbindung). Das Passwort enthält kein @, /, " und keine Leerzeichen.
• Lizenz: Data Guard ist in der Enterprise Edition enthalten. Die Standby bei laufendem Apply geöffnet zu nutzen, Block Change Tracking auf der Standby und Far Sync erfordern eine Active Data Guard-Lizenz. Snapshot Standby und Öffnen im Read-only-Modus bei gestopptem Apply sind lizenzfrei.
• Die Änderung liegt in einem genehmigten Wartungsfenster; Anwendungs- und Monitoring-Teams sind informiert… (Verbindungen werden für einige Minuten unterbrochen)….
• Die Failover-Entscheidung hat eine befugte Person getroffen; es ist sichergestellt, dass die alte Primary nicht wieder geöffnet wird (Split-Brain): Der Server ist aus, vom Netz getrennt oder die Instanz wird in MOUNT gehalten.

Phasen der Anleitung

• Status: Konfiguration, Lag und Prozesse (schreibgeschützt) — Broker-Konfiguration und Bereitschaft für den Rollenwechsel anzeigen · Primary-Seite mit SQL prüfen · Standby-Seite mit SQL prüfen · Alert Logs nach Data-Guard-Fehlern durchsuchen · Ergebnis auswerten und das richtige Szenario wählen
• 1. Diagnose: bereit für den Switchover? — Bereitschaft prüfen (VALIDATE) · Bereitschaft prüfen (SWITCHOVER … VERIFY) · Lag der Standby prüfen
• 2. Sicherheitsnetz — Aktuelle Konfiguration sichern (Primary) · Aktuelle Konfiguration sichern (Standby)
• 3. Durchführung: Switchover — Switchover: … zur Primary machen (Broker) · Switchover starten (Primary → Standby) · Neue Primary öffnen (…) · Clusterware-Rolle aktualisieren (neue Primary) · Weitere Instanz öffnen (neue Primary, Knoten …: …) · Alte Primary als Standby mounten (…) …
• 4. Prüfung — Neue Rollen und Konfiguration prüfen · Apply und Lag auf der neuen Standby prüfen
• 5. Nacharbeiten — Prüfung von Anwendung, Jobs und Monitoring
• 1. Diagnose: Ist ein Failover wirklich nötig? — Primary ein letztes Mal zu erreichen versuchen (von der Standby aus) · Zustand der Standby und möglichen Datenverlust bewerten · Zustand aus Sicht des Brokers anzeigen (von der Standby aus)
• 2. Sicherheitsnetz und restliches Redo — Aktuelle Einstellungen der Standby sichern · Alte Primary mounten und restliches Redo übertragen (FLUSH REDO) · Fehlende archivierte Logs manuell kopieren (ohne Broker, falls möglich)
• 3. Durchführung: Failover — Failover: … zur Primary machen (Broker) · Redo Apply stoppen und Failover ausführen (SQL) · Neue Primary öffnen (SQL) · Clusterware-Rolle aktualisieren (neue Primary) · Weitere Instanz öffnen (neue Primary, Knoten …: …)
• 4. Prüfung — Neue Primary prüfen
• 5. Nacharbeiten — Vollständiges Backup der neuen Primary erstellen · Wenn die alte Primary zurückkommt: NICHT ÖFFNEN
• Anwendungsservice (rollenbasiert) — Service auf der Seite … definieren und starten (Clusterware) · Service auf der Seite … definieren (Clusterware) · Service und Rollen-Trigger definieren (ohne Grid) · Verbindungsbeschreibung des Clients mit zwei Adressen einrichten
• 1. Diagnose: Ist ein Reinstate möglich? — Neue Primary und SCN des Rollenwechsels prüfen · Broker-Status anzeigen (neue Primary) · Alte Primary mounten und Flashback-Fenster prüfen
• 2. Sicherheitsnetz — Steuerdatei und Parameter der alten Primary sichern
• 3. Durchführung: Reinstate — Reinstate der alten Primary (Broker) · Übrige Instanzen starten (alte Primary, RAC) · Per Flashback zurücksetzen und in Physical Standby umwandeln (SQL) · Ziel … auf der neuen Primary aktivieren (SQL) · Redo Apply starten und über die Datensätze des Rollenwechsels hinwegkommen (SQL)
• 4. Prüfung — Konfiguration prüfen · Apply auf der alten Primary (neue Standby) prüfen
• 5. Nacharbeiten — Ursprüngliche Rollen wiederherstellen (optional) und Grundursache beseitigen
• 1. Diagnose: Wo ist der Gap, gibt es die archivierten Logs noch? — Gap und Prozesse auf der Standby anzeigen · FAL-Verbindung und Alert Log prüfen (Standby) · Liegen die fehlenden archivierten Logs noch auf der Primary? · Sind die fehlenden archivierten Logs in einem RMAN-Backup?
• 2. Sicherheitsnetz — Prüfen, dass in der FRA der Standby Platz ist
• 3. Durchführung: fehlende archivierte Logs holen und registrieren — Wenn die archivierten Logs nur im Backup sind: auf der Primary wiederherstellen · Fehlende archivierte Logs ins Dateisystem kopieren und an die Standby senden (Primary) · Archivierte Logs auf der Standby registrieren · Redo Apply neu starten (Standby)
• 4. Prüfung — Schließen des Gap beobachten (Standby)
• 5. Nacharbeiten — Temporäre Kopien löschen · Grundursache beseitigen
• 1. Diagnose: Wie weit liegt die Standby zurück? — SCN und Zustand der Standby anzeigen · NOLOGGING-Operationen und COMPATIBLE-Wert auf der Primary prüfen
• 2. Sicherheitsnetz — Steuerdatei und spfile der Standby sichern
• 3. Durchführung: Standby vorrollen — Redo Apply stoppen (Standby) · Standby mounten… (nur Instanz 1)… · Standby von der Primary aus vorrollen (RECOVER STANDBY DATABASE FROM SERVICE) · Übrige Standby-Instanzen starten · Standby Redo Logs und Flashback-Status prüfen · Redo Apply starten (Standby)
• 4. Prüfung — Prüfen, dass der Lag aufgeholt ist
• 5. Nacharbeiten — Grundursache beseitigen
• 1. Diagnose: Ist ein Neuaufbau wirklich nötig? — Zustand von Konfiguration und Primary anzeigen
• 2. Sicherheitsnetz — Konfigurationsdateien der Standby aufbewahren
• 3. Durchführung: löschen und neu aufbauen — Standby aus der Broker-Konfiguration entfernen · Standby-Ziel auf der Primary zurückstellen (DEFER) · Alte Standby-Datenbank löschen · Verbliebene Broker-, init- und Passwortdateien bereinigen · Alte init-Datei umbenennen (Standby, Knoten …: …) · Standby mit dem Installations-Guide neu erstellen …