Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Oracle Data Guard ist die integrierte Hochverfügbarkeitslösung (HA) und Notfallwiederherstellungslösung von Oracle. Es hält eine oder mehrere Standby-Datenbanken synchron mit Ihrer primären (Produktions-)Datenbank, indem Redo-Daten – also alle Änderungen an der Datenbank – kontinuierlich übermittelt und angewendet werden.
Falls die primäre Datenbank durch Hardwareausfall, menschlichen Fehler oder einen standortweiten Ausfall ausfällt, kann Data Guard eine Standby-Datenbank zur neuen primären Instanz befördern und damit Ausfallzeiten sowie Datenverluste minimieren.
Typen von Standby-Datenbanken
Data Guard unterstützt drei Standby-Typen. Die passende Auswahl hängt von Ihren Wiederherstellungszielen und der geplanten Nutzung der Standby-Instanz ab:
| Standby-Typ | Funktionsweise | Einsatzzweck |
|---|---|---|
| Physische Standby-Datenbank | Wendet Redo-Daten als direkte Block-Level-Änderungen an und erstellt eine exakte Byte-für-Byte-Kopie der Primärdatenbank. | Notfallwiederherstellung und HA-Failover |
| Logische Standby-Datenbank | Wandelt Redo-Daten in SQL-Anweisungen um und führt diese aus. Die Standby-Datenbank kann lesend geöffnet werden und eine abweichende Schema-Struktur aufweisen. | Reporting und Live-Migrationen |
| Snapshot-Standby-Datenbank | Eine temporäre schreibbare Kopie, die aus einer physischen Standby-Datenbank erstellt wird. Redo-Daten werden empfangen, aber erst nach Rückumwandlung angewendet. | Entwicklung und Test mit echten Produktionsdaten |
Bevor Sie Befehle ausführen, stellen Sie sicher, dass Ihre Umgebung ordnungsgemäß vorbereitet ist. Fehlende Vorbereitungen sind einer der häufigsten Gründe für fehlgeschlagene Data Guard-Konfigurationen.
Primär- und Standby-Server sollten möglichst identisch ausgestattet sein. Abweichende Betriebssystemversionen oder Patch-Stände können unerwartete Fehler bei der Anwendung von Redo-Daten verursachen.
prod_pri und prod_stdby).Vor Beginn der Konfiguration prüfen Sie, ob folgende Initialisierungsparameter auf der Primärdatenbank korrekt gesetzt sind:
Die Einrichtung von Data Guard erfordert eine festgelegte Reihenfolge von Schritten. Beginnen Sie mit der Vorbereitung der Primärdatenbank, damit diese Redo-Daten generieren und an die Standby-Datenbank übermitteln kann.
Die Primärdatenbank muss im Modus ARCHIVELOG ausgeführt werden – damit werden Redo-Daten gespeichert und für die Übertragung zur Standby-Datenbank verfügbar gemacht. Zusätzlich muss FORCE LOGGING aktiviert werden, damit Vorgänge wie Direct-Path-Laden nicht die Redo-Logs umgehen und eine Synchronisationslücke zur Standby-Datenbank entsteht.
Primärdatenbank – SQL*Plus
-- Wechsel in den ARCHIVELOG-Modus
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE FORCE LOGGING;
ALTER DATABASE OPEN;
-- Überprüfung
SELECT log_mode, force_logging FROM v$database;
Standby-Redo-Logs (SRL) speichern die von der Primärdatenbank empfangenen Redo-Daten. Sie sind Voraussetzung für das Echtzeit-Anwenden von Logs (Real-Time Apply), bei dem Änderungen sofort nach Eingang verarbeitet werden, ohne auf einen vollständigen Archiv-Log warten zu müssen.
Empfohlene Best Practice: Erstellen Sie eine Gruppe Standby-Redo-Logs mehr als vorhandene Online-Redo-Log-Gruppen mit identischer Dateigröße. Bei 3 Online-Log-Gruppen erstellen Sie 4 SRL-Gruppen.
Primärdatenbank – SQL*Plus
ALTER DATABASE ADD STANDBY LOGFILE
GROUP 4 ('/u01/app/oracle/oradata/srl04.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE
GROUP 5 ('/u01/app/oracle/oradata/srl05.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE
GROUP 6 ('/u01/app/oracle/oradata/srl06.log') SIZE 200M;
Primär- und Standby-Datenbank kommunizieren über Oracle Net Services. Zwei Dateien müssen konfiguriert werden: tnsnames.ora und listener.ora.
Aktualisieren der tnsnames.ora
Tragen Sie auf beiden Servern Einträge für beide Datenbanken ein. Dadurch kann jede Seite die andere im Netzwerk adressieren.
Primär- und Standby-Server – tnsnames.ora
PRIMARY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = pri_server_ip)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = primary_db_service)
)
)
STANDBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = stdby_server_ip)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = standby_db_service)
)
)
Konfigurieren des Listeners
Auf dem Standby-Server benötigen Sie einen statischen Listener-Eintrag in der Datei listener.ora. Beim erstmaligen Erstellen der Standby-Datenbank läuft diese im Status NOMOUNT oder MOUNT – eine dynamische Registrierung funktioniert in diesem Zustand nicht. Ohne statischen Eintrag erkennt der Listener den Dienst nicht, sodass die Primärdatenbank keine Verbindung aufbauen kann.
Standby-Server – listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = standby_db_service)
(ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
(SID_NAME = standby_sid)
)
)
Testen der Netzwerkverbindung
Nach der Aktualisierung beider Dateien laden Sie den Listener neu (lsnrctl reload) und führen folgenden Testbefehl auf dem Primärserver aus:
Primärserver – Shell
tnsping standby
Zur Initialisierung der Standby-Datenbank benötigen Sie eine konsistente Kopie der Primärdatenbank. Das Standardwerkzeug dafür ist RMAN (Recovery Manager), es sichert sowohl Datendateien als auch Archiv-Logs, die zur Synchronisation der Standby-Datenbank benötigt werden.
Primärdatenbank – RMAN
RMAN TARGET /
BACKUP DATABASE PLUS ARCHIVELOG;
Sobald die Backup-Dateien auf dem Standby-Server vorhanden sind, können Sie die Datenbank wiederherstellen. Starten Sie die Standby-Instanz mit der kopierten Parameterdatei im Modus NOMOUNT und verwenden anschließend RMAN zur Wiederherstellung und Einbindung als Standby-Datenbank.
Standby-Datenbank – SQL*Plus
STARTUP NOMOUNT;
Standby-Datenbank – RMAN
RMAN TARGET /
-- Zuerst die Kontrolldatei wiederherstellen
RESTORE CONTROLFILE FROM '/path/to/backup/controlfile_auto';
-- Wiederherstellen der Datendateien
RESTORE DATABASE;
-- Einbinden als Standby-Datenbank
ALTER DATABASE MOUNT STANDBY DATABASE;
Durch die Einbindung als STANDBY DATABASE teilen Sie Oracle mit, dass diese Instanz Redo-Logs empfangen und anwenden soll, statt eigene Transaktionen zu generieren.
Nachdem die Standby-Datenbank eingebunden ist, müssen Sie der Primärdatenbank mitteilen, wohin die Redo-Daten versandt werden sollen. Dies erfolgt über die Parameter der Log Transport Services auf der Primärdatenbank.
Der zentrale Parameter ist LOG_ARCHIVE_DEST_2, er definiert das Ziel für die Standby-Datenbank sowie den Übertragungsmodus.
Primärdatenbank – SQL*Plus
-- Registrieren von Primär- und Standby in der Data Guard-Konfiguration
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db_unique_name,standby_db_unique_name)';
-- Definieren des entfernten Archivierungsziels
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
'SERVICE=standby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db_unique_name';
-- Aktivieren des Ziels
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
ASYNC (asynchrone) Übertragung wird hier verwendet, um Leistungseinbußen auf der Primärdatenbank bei Netzwerkverzögerungen zu vermeiden. Das Attribut VALID_FOR beschränkt dieses Ziel auf die Primärrolle, sodass es keine Wirkung hat, falls diese Datenbank einmal zur Standby-Instanz wechselt.
Der letzte Schritt ist das Starten der Redo Apply auf der Standby-Datenbank. Dadurch wird ein Hintergrundprozess gestartet, der kontinuierlich Redo-Daten von der Primärdatenbank empfängt und auf die Datendateien der Standby-Instanz anwendet.
Standby-Datenbank – SQL*Plus
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
USING CURRENT LOGFILE aktiviert das Echtzeit-Anwenden von Logs: Die Standby-Datenbank verarbeitet Änderungen sofort nach Eingang in den Standby-Redo-Logs, ohne auf einen vollständigen Archiv-Log warten zu müssen. DISCONNECT führt den Prozess im Hintergrund aus und gibt Ihre SQL*Plus-Sitzung frei.
v$managed_standby ab und achten Sie auf den Status APPLYING_LOG.Oracle Data Guard bildet eine solide Grundlage für die Oracle-Hochverfügbarkeit – die Verwaltung erfordert jedoch ständige manuelle Überwachung: Prüfung des Replikationsstatus, Verwaltung von Failover-Skripten und Sicherstellung der Synchronisation der Standby-Datenbank.
Für Unternehmen, die eine umfassendere, stärker automatisierte Hochverfügbarkeitslösung für die gesamte Infrastruktur benötigen, bietet i2Availability eine ergänzende Schutzebene.
Für Teams mit Oracle-Betrieb in anspruchsvollen Umgebungen wie Finanzwesen, Gesundheitswesen oder Behörden erweitert i2Availability Ihre HA-Strategie über die Datenbankebene hinaus auf den gesamten Anwendungsstack.
Die meisten Data Guard-Fehler entstehen durch kleine Versehen bei Netzwerkeinstellungen oder Initialisierungsparametern. Hier die häufigsten Probleme und deren Lösungen.
ORA-12154 oder ORA-12514 im Alert-Log deuten meist auf Tippfehler in der tnsnames.ora, einen gestoppten Listener oder eine Blockierung des Ports 1521 hin. Testen Sie die Verbindung mit tnsping standby und stellen Sie sicher, dass die Remote Login-Passwortdatei (orapwd) auf beiden Servern identisch ist.
Falls Redo-Logs eingehen, die Standby-Datenbank aber zurückhängt, läuft der Anwendungsprozess ggf. nicht oder es gibt eine Lücke in der Log-Sequenz. Fragen Sie V$MANAGED_STANDBY zur Prüfung des Anwendungsstatus ab und nutzen Sie V$ARCHIVE_GAP, um fehlende Sequenzen zu ermitteln und manuell zu registrieren.
Ohne den Modus ARCHIVELOG gibt es keine Redo-Daten zur Übertragung. Ohne FORCE LOGGING werden NOLOGGING-Vorgänge nicht protokolliert, wodurch die Standby-Datenbank über nicht wiederherstellbare Datenblöcke verfügt. Prüfen Sie beide Einstellungen vor Beginn der Konfiguration:
SELECT log_mode, force_logging FROM v$database;
Wenn die Verzeichnisstrukturen auf den Servern abweichen, müssen DB_FILE_NAME_CONVERT und LOG_FILE_NAME_CONVERT in der SPFILE der Standby-Datenbank gesetzt werden. Fehlen diese Parameter, schlägt die Wiederherstellung fehl, falls Primär- und Standby-Instanz abweichende Dateipfade verwenden.
F1: Was ist der Unterschied zwischen Switchover und Failover bei Oracle Data Guard?
Ein Switchover ist ein geplanter Rollenwechsel – Primär- und Standby-Datenbank bleiben während des gesamten Vorgangs verfügbar, es entsteht kein Datenverlust. Ein Failover wird ausgelöst, wenn die Primärdatenbank unerwartet ausfällt. Abhängig vom Schutzmodus kann beim Failover ein geringer Datenverlust auftreten.
F2: Welcher Standby-Typ eignet sich für Hochverfügbarkeit?
Für die meisten Produktions-HA-Bereitstellungen ist die physische Standby-Datenbank die richtige Wahl. Sie erstellt eine Block-genaue Kopie der Primärdatenbank und bietet die schnellsten Failover-Zeiten bei geringem Leistungsaufwand. Die logische Standby-Datenbank eignet sich besser für Reporting oder rollierende Upgrades.
F3: Wie viele Standby-Datenbanken lassen sich konfigurieren?
Ab Oracle 11g R2 unterstützt eine einzelne Data Guard-Konfiguration bis zu 30 Standby-Datenbanken.
F4: Beeinträchtigt Data Guard die Leistung der Primärdatenbank?
Dies hängt vom Übertragungsmodus ab. Die asynchrone Übertragung hat minimale Auswirkungen auf die Primärdatenbank, da sie keine Bestätigung der Standby-Instanz abwartet. Die synchrone Übertragung bietet einen stärkeren Datenschutz, kann aber Latenzen verursachen, wenn die Netzwerkumlaufzeit zwischen Primär- und Standby-Instanz hoch ist.
F5: Wie überprüfe ich nach der Konfiguration, ob Data Guard ordnungsgemäß funktioniert?
Fragen Sie auf der Standby-Datenbank die Ansicht v$managed_standby ab, um zu bestätigen, dass der Anwendungsprozess läuft, und prüfen Sie v$archive_gap auf fehlende Log-Sequenzen. Auf der Primärdatenbank zeigt v$dataguard_status den aktuellen Übertragungs- und Anwendungsstatus an.
F6: Was passiert, wenn die Standby-Datenbank durch einen Netzwerkausfall zurückhängt?
Data Guard erkennt die Lücke automatisch und synchronisiert die Standby-Datenbank nach Wiederherstellung der Netzwerkverbindung anhand archivierter Redo-Logs neu. Falls die Archiv-Logs nicht mehr vorhanden sind, können Sie ein inkrementelles RMAN-Backup verwenden, um die Standby-Datenbank wieder zu synchronisieren.
Die Konfiguration von Oracle Data Guard ist eine grundlegende Aufgabe für Administratoren zum Schutz geschäftskritischer Daten. Mit dieser Schritt-für-Schritt-Anleitung stellen Sie sicher, dass Ihre Primärdatenbank korrekt vorbereitet, das Netzwerk für den Log-Versand optimiert und die Standby-Datenbank jederzeit zur Übernahme bereit ist.
Beachten Sie, dass eine Data Guard-Einrichtung nur so zuverlässig ist wie der letzte Test. Führen Sie stets einen Test-Switchover in einer Nicht-Produktionsumgebung durch. Dadurch stellen Sie sicher, dass Ihr Team im Ernstfall über das erforderliche Fachwissen und die passende Infrastruktur verfügt, um die Geschäftskontinuität sicher zu gewährleisten.
Quelle: Einreichung von Info2soft bei „Cybersicherheit und Informatisierung“
