Dieser Artikel bietet einen Überblick über die Oracle-Datenbankreplikation. Behandelt werden Konzepte, Architekturen, Implementierungsschritte sowie bewährte Verfahren für den Betrieb. Sie erfahren, wie die Replikation mit RPO und RTO zusammenhängt. Dargestellt werden zentrale Methoden: Data Guard, GoldenGate, materialisierte Views sowie veraltete Optionen. Zudem lernen Sie Monitoring, Alarmierung und Sicherheitsaspekte der Replikation kennen.
Was ist die Oracle-Datenbankreplikation?
Oracle erfasst Änderungen an einer Quelldatenbank und wendet sie auf einer oder mehreren Zieldatenbanken an. Sie unterstützt den synchronen Modus, bei dem auf eine Bestätigung des Commit-Vorgangs gewartet wird, sowie den asynchronen Modus, bei dem Änderungen ohne Warten gesendet werden. Der synchrone Modus führt nahezu zu keinem Datenverlust, verursacht jedoch zusätzliche Latenz. Der asynchrone Modus verringert die Latenz, birgt aber bei einem Ausfall das Risiko minimaler Datenlücken. Oracle verwendet je nach Methode den Redo-Transport, das Log-Mining oder Materialized-View-Logs. Die Konsistenzmodelle unterscheiden sich: unmittelbar für den synchronen Modus, eventual für den asynchronen Modus.
Replikation steht in Zusammenhang mit dem Wiederherstellungsziel für den Datenstand (RPO, Recovery Point Objective) und dem Wiederherstellungsziel für die Zeit (RTO, Recovery Time Objective). Synchrone Modi ermöglichen nahezu einen RPO von null. Asynchrone Modi stellen einen Kompromiss zwischen RPO und Netzwerkentfernung dar. Die Wahl erfolgt anhand der geschäftlichen Anforderungen und der vorhandenen Infrastruktur. Außerdem planen Sie das RTO: wie schnell eine Replik online gebracht werden kann. Diese Ziele leiten die Auswahl der Methode und deren Konfiguration.
Warum sollten Sie die Oracle-Datenbank replizieren?
Die Replikation erfüllt zentrale Operationsziele: Katastrophenwiederherstellung, hohe Verfügbarkeit, Lastverteilung und Geschäftskontinuität. Sie unterstützt zudem Analysen und Migrationen.
Katastrophenwiederherstellung und RPO/RTO: Bei der Replikation werden Kopien an entfernten Standorten gespeichert. Im Fehlerfall wechseln Sie zum Bereitschaftssystem. Die synchrone Replikation führt zu einem minimalen Datenverlust (nahezu null RPO). Die asynchrone Replikation eignet sich für Standorte mit größerer Entfernung und akzeptablem RPO. Der RTO wird anhand der Geschwindigkeit gemessen, mit der Sie die Rollen wechseln. Durch Tests des Failovers wird überprüft, ob die vorgegebenen RTO-Ziele erreicht werden.
Hohe Verfügbarkeit: Eine Standby-Datenbank kann über einen Switchover oder Failover die Steuerung übernehmen. Data Guard bietet verwaltete Apply-Dienste für schnelle Übergänge. GoldenGate kann in einigen Fällen Active-Active-Setups aufbauen. So verringern Sie geplante und ungeplante Ausfallzeiten, erfüllen Ihre SLAs und steigern die Zuverlässigkeit Ihres Dienstes.
Lastverteilung und Berichterstattung: Mit Active Data Guard können Sie eine Standby-Datenbank für Lesezugriffe öffnen. Dadurch entlasten Sie die Primärdatenbank bei der Berichterstattung. Materialisierte Sichten können lokale Berichte mit regelmäßiger Aktualisierung bereitstellen. So verbessern Sie die Leistung für Endbenutzer und Analyseteams.
Geschäftskontinuität und Wartung: Sie können Patches oder Upgrades während des Betriebs der primären Instanz auf der Standby-Instanz anwenden. Nach der Testphase tauschen Sie die Rollen aus. So minimieren Sie Ausfallzeiten bei Wartungsarbeiten. Durch Replikation in eine neue Umgebung können Sie Plattformen migrieren.
Datenaustausch: Sie replizieren Daten an entfernte Standorte oder in Cloud-Zonen. Materialisierte Ansichten oder GoldenGate können Teilmengen oder gefilterte Daten übertragen. Sie unterstützen verteilte Anwendungen mit lokalen Kopien.
Test und Entwicklung: Sie führen eine Kopie für Qualitätssicherung oder Entwicklung. Sie aktualisieren sie regelmäßig aus der Produktionsumgebung. So können Teams Änderungen testen, ohne die Hauptumgebung zu gefährden.
Arten der Datenbankreplikation in Oracle
Oracle bietet mehrere Methoden an. Jede eignet sich für unterschiedliche Anwendungsfälle und weist jeweils verschiedene Kompromisse hinsichtlich RPO, RTO, Komplexität und Lizenzierung auf. Nachfolgend finden Sie eine vergleichende Übersicht:
| Method | RPO | RTO | Use Case | Complexity | Licensing | Status | Oracle Version |
|---|
| Data Guard | Data Guard | Fast failover/switchover | HA/DR for Oracle only | Moderate | Included in EE | Current | 11g onwards |
| GoldenGate | Near-zero to configurable | Varies; depends on apply | Logical replication, heterogeneous, migrations, active-active | High | Separate license | Current | 11g onwards |
| Materialized Views | Scheduled lag | Depends on refresh | Reporting, caches, minimal sync | Low | Included in EE | Current | 11g onwards |
| Advanced Replication | Moderate; conflict risk | Slow for conflict resolution | Multi-master legacy | High | Included in EE | Legacy/Superseded | 11g,12c |
| Streams | Near-zero to async | Fast | Deprecated logical replication | High | Included but deprecated | Deprecated | Deprecated in 12c, desupported 19c |
So replizieren Sie eine Oracle-Datenbank
Die folgenden Übersichten geben Anleitungen zur Einrichtung und zum Betrieb. Konsultieren Sie stets die offizielle Oracle-Dokumentation für Ihre Version und Umgebung.
Voraussetzungen und Planung
Vor der Einrichtung einer Replikation: Überprüfen Sie die Netzwerkverbindung, stellen Sie ausreichende Bandbreite und gesicherte Verbindungen sicher. Stellen Sie sicher, dass die verwendeten Oracle-Versionen und -Lizenzen die gewählten Methoden zulassen. Erstellen Sie Sicherungskopien über RMAN. Weisen Sie dedizierte Benutzer mit den richtigen Berechtigungen zu. Planen Sie den Speicherplatz für Standby- oder Trail-Zielumgebungen. Definieren Sie die Zielwerte für RPO und RTO. Führen Sie zunächst Tests in der Staging-Umgebung durch. Dokumentieren Sie Runbooks für Einrichtung, Überwachung und Failover.
1. Data-Guard-Setup
Data Guard bietet ein verwaltetes Standby-System für Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR). Sie können den Broker oder eine manuelle Konfiguration verwenden. Active Data Guard erweitert die Funktionalität um Lesezugriff.
Aktivieren Sie den ARCHIVELOG-Modus und das FORCE LOGGING. Erstellen Sie Standby-Redo-Logs: jeweils eines mehr als die Anzahl der Redo-Log-Gruppen. Legen Sie DB_UNIQUE_NAME auf Primär- und Standby-System fest. Konfigurieren Sie die LOG_ARCHIVE_DEST_n-Einträge: Die Primärdatenbank sendet Redo-Daten an die Standby-Ziele. Setzen Sie FAL_SERVER und FAL_CLIENT für die Lückenaufklärung. Stellen Sie sicher, dass die Initialisierungsparameter auf beiden Seiten übereinstimmen.
Verwenden Sie RMAN DUPLICATE TARGET DATABASE FOR STANDBY von der Primärdatenbank oder führen Sie ein Backup und Restore auf dem Standby-Host durch. Passen Sie die Initialisierungsparameter in der Standby-Initialisierungsdatei an: DB_NAME muss mit der Primärdatenbank übereinstimmen, DB_UNIQUE_NAME muss sich unterscheiden. Konfigurieren Sie die automatische Sicherung der Kontrolldatei. Stellen Sie sicher, dass die Netzwerkeinträge in tnsnames.ora und listener.ora korrekt sind.
Der Broker (DGMGRL) vereinfacht das Management. Sie erstellen eine DG-Konfiguration, fügen die Primär- und Standby-Datenbanken hinzu und legen den Schutzmodus fest (MAXAVAIL, MAXPERFORMANCE, MAXPROTECTION). Der Broker übernimmt die Validierung, Rollenwechsel und Statusüberwachung. Bei der manuellen Einrichtung verwenden Sie SQL- und RMAN-Befehle: Sie bearbeiten die Initialisierungsparameter und starten die verwaltete Wiederherstellung mit ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT. Der Broker wird für die meisten Konfigurationen empfohlen.
Der SYNC-Modus (SYNC oder FASTSYNC) wartet auf die Bestätigung durch die Standby-Datenbank und ermöglicht so nahezu keinen Datenverlust. ASYNC sendet die Redo-Informationen ohne Warten; dies toleriert Netzwerklatenz, birgt jedoch das Risiko eines Datenverlusts. Konfigurieren Sie den Schutzmodus entsprechend Ihren Anforderungen an die Recovery Point Objective (RPO). Überwachen Sie die Transportverzögerung über V$ARCHIVE_DEST_STATUS und V$DATAGUARD_STATS.
Im Bereitschaftsmodus wendet der MRP (Managed Recovery Process) Redo-Daten an. Mit Active Data Guard öffnen Sie die Standby-Datenbank schreibgeschützt: ALTER DATABASE OPEN READ ONLY. Abfragen werden auf der Standby-Datenbank ausgeführt, ohne den Anwendungsprozess zu beeinträchtigen. Überwachen Sie die Anwendungsverzögerung mithilfe von V$ARCHIVE_DEST_STATUS und der Spalte APPLIED_TIME.
Test-Wechsel: Geplanter Wechsel, bei dem die Primärinstanz zur Standby-Instanz wird. Verwenden Sie DGMGRL SWITCHOVER TO standby. Test-Notfallwechsel: Ungeplanter Wechsel, bei dem die Primärinstanz nicht erreichbar ist. Verwenden Sie DGMGRL FAILOVER TO standby. Nach der Rollenänderung konfigurieren Sie die ursprüngliche Instanz als neue Standby-Instanz neu. Dokumentieren Sie die Verfahren und führen Sie regelmäßig Tests durch.
Abfrage von V$ARCHIVE_DEST_STATUS und V$DATAGUARD_STATS zur Ermittlung der Transport- und Apply-Verzögerung. Verwenden Sie DGMGRL SHOW CONFIGURATION für den Gesamtstatus. Richten Sie Warnungen ein, wenn die Verzögerung einen Schwellenwert überschreitet. Überwachen Sie die Nutzung der Standby-Redo-Logs (SRL) und den verfügbaren Speicherplatz auf der Standby-Datenbank. Überwachen Sie Netzwerkfehler in den Alert-Logs. Automatisieren Sie Benachrichtigungen mittels Skripten oder Überwachungstools.
Netzausfälle verursachen Wiederholungslücken (Redo-Gaps). Verwenden Sie FAL_SERVICE, um fehlende Protokolle abzurufen. Beheben Sie das Problem mit ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL und starten Sie die Wiederherstellung dann neu. Unzureichende Standby-Redo-Protokolle führen zu einer langsamen Anwendung. Die Aufbewahrungsdauer für Archivprotokolle muss den Verbrauch durch die Standby-Datenbank berücksichtigen. Versionsunterschiede blockieren die Anwendung; stellen Sie sicher, dass die Patch-Stände übereinstimmen. Testen Sie den Failover, um die Konfiguration zu validieren.
2. GoldenGate-Konfiguration
GoldenGate bietet logische Replikation. Sie funktioniert über heterogene Systeme hinweg. Dabei kommen die Prozesse Extract, Trail-Dateien, Pump (optional) und Replicat zum Einsatz.
Ergänzendes Logging aktivieren: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA und ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS oder ADD TRANDATA für Tabellen. Dadurch wird sichergestellt, dass die erforderlichen Änderungsdaten im Redo-Log gespeichert werden. Erstellen Sie einen GoldenGate-Benutzer mit den erforderlichen Berechtigungen.
Installieren Sie die GoldenGate-Binärdateien auf den Quell- und Zielservern. Verwenden Sie Versionen, die mit der Oracle-Datenbankversion kompatibel sind. Konfigurieren Sie den Manager-Prozess mit den entsprechenden Porteinstellungen.
Quelldatenbank und Tabellen definieren. Speicherort der Trail-Dateien angeben. Für höhere Effizienz „Integrated Extract“ für Oracle verwenden. Prüfpunkttabellen (Checkpoint Tables) im Zielschema konfigurieren, um den Fortschritt zu verfolgen. Optional kann ein Data-Pump-Extrakt eingerichtet werden, um die Trail-Dateien an die Zielumgebungen zu übertragen.
Ziel-Datenbank und Tabellen definieren. Speicherort für Anmeldedaten oder Alias für sichere Authentifizierung konfigurieren. Parameterdateien verwenden, um Quell- und Zielschemata sowie Tabellen zuzuordnen. Transformationen oder Filterung in den Parameterdateien durchführen.
GoldenGate kann DDL-Anweisungen mit entsprechenden Einstellungen replizieren, erfordert jedoch sorgfältige Planung. Verwenden Sie DDL INCLUDEMAPPING oder skriptbasierte Ansätze. Stellen Sie sicher, dass das Zielschema die neuen Strukturen unterstützt.
Starten Sie die Prozesse „Manager“, „Extract“, „Pump“ und „Replicat“ über GGSCI. Verwenden Sie den Befehl INFO ALL, um den Status und die Verzögerung (Lag) zu überprüfen. Prüfen Sie die Berichtsdateien auf Fehler. Überwachen Sie die Lag-Metriken und den Durchsatz. Verwenden Sie Heartbeat-Tabellen, um Stillstände zu erkennen.
Die bidirektionale Replikation erfordert die Erkennung und Auflösung von Konflikten. Verwenden Sie Globalization Support für Zeichensätze. Konfigurieren Sie bei heterogenen Zielsystemen die Zuordnung entsprechend.
Sichern Sie Trail-Dateien mithilfe von Betriebssystemebenen-Berechtigungen. Verwenden Sie verschlüsselte Netzwerkverbindungen oder Secure Sockets für die Übertragung. Nutzen Sie den GoldenGate-Anmeldeinformations-Speicher für Passwörter. Erwägen Sie die Integration von Oracle Key Vault.
Abfrage von INFO EXTRACT und INFO REPLICAT zur Ermittlung der Verzögerung und des Status. Auswertung der Berichtsdateien auf Fehler. Festlegen von Schwellenwerten für die Verzögerung; Alarmierung bei Überschreitung. Überwachung der Prüfpunkttabellen auf Verzögerungen. Verwenden Sie Skripte oder Überwachungstools, um Metriken zu erfassen.
Fehlende ergänzende Protokollierung führt zu Datenverlust. Erfassungslücken entstehen, wenn Redo-Logs überschrieben werden; planen Sie die Aufbewahrungsdauer für Archiv-Logs. DDL-Änderungen können fehlschlagen, falls keine Übereinstimmung vorliegt. Netzwerkprobleme stören die Übermittlung der Trail-Dateien. Prüfen Sie die Manager-Protokolle auf Fehler. Überwachen Sie den verfügbaren Festplattenspeicher für Trail-Dateien. Testen Sie Failover-Szenarien.
Für GoldenGate-Upgrade: Koordinieren Sie das Beenden und Neustarten von Extract und Replicat. Verwenden Sie ein gestuftes Upgrade, um Ausfallzeiten zu vermeiden. Überprüfen Sie die Kompatibilität mit den neuen Oracle-Patches.
3. Einrichtung materialisierter Ansichten
Materialisierte Ansichten kopieren Daten in regelmäßigen Abständen. Sie eignen sich für Berichte oder Caches.
Erstellen Sie auf der Quelle Materialized View Logs für die Tabellen: CREATE MATERIALIZED VIEW LOG ON schema.tabelle WITH ROWID. Dadurch wird ein schneller Refresh ermöglicht.
Als Ziel: CREATE MATERIALIZED VIEW mv_name REFRESH FAST ON DEMAND AS SELECT ... FROM schema.table@dblink;. Verwenden Sie ON COMMIT, um bei Quell-Commits unverzüglich einen Refresh durchzuführen, falls dies akzeptabel ist.
Verwenden Sie bei vorhandenen Protokollen die FAST-Aktualisierung; andernfalls führen Sie eine COMPLETE-Aktualisierung durch. Planen Sie die Aktualisierung mithilfe des Oracle Scheduler: DBMS_SCHEDULER.CREATE_JOB. Überwachen Sie LAST_REFRESH_DATE in DBA_MVIEWS.
Überprüfen Sie DBA_MVIEW_REFRESH_TIMES für die Historie. Behandeln Sie Aktualisierungsfehler, die durch Netzwerkprobleme oder Nichtübereinstimmungen der Datentypen verursacht werden. Stellen Sie sicher, dass die erforderlichen Berechtigungen für die Quellverbindungen vorliegen. Verwalten Sie veraltete Daten, indem Sie die Aktualisierungshäufigkeit festlegen.
Berichterstattung nahezu in Echtzeit an verteilten Standorten. Zwischenspeichern von Referenzdaten. Entlastung der Primärdatenbank durch Abfragen.
4. Erweiterte Replikationseinrichtung (veraltet)
Die erweiterte Replikation verwendet Replikationsgruppen und -aufträge. Sie unterstützt Multi-Master-Topologien, ist jedoch veraltet. Für neue Projekte sollte GoldenGate verwendet werden.
Definieren Sie die Replikationsgruppe über DBMS_REPCAT. Fügen Sie Master-Standorte hinzu. Definieren Sie die zu replizierenden Objekte. Konfigurieren Sie Methoden zur Konfliktlösung. Planen Sie die Verteilungsaufträge. Überwachen Sie mithilfe von DBA_REPCAT oder den von Oracle bereitgestellten Ansichten.
Unterstützt keine neuen Oracle-Funktionen wie Multitenancy. Komplexe Einrichtung und Konfliktbehandlung. Eingeschränkte Herstellerunterstützung. Wird durch GoldenGate ersetzt.
5. Streams (veraltet)
Oracle Streams bot logische Replikation. Die Funktion wurde in Oracle 12c als veraltet gekennzeichnet und in Oracle 19c vollständig entfernt. Verwenden Sie sie nicht für neue Installationen. Nutzen Sie stattdessen Oracle GoldenGate für vergleichbare Anforderungen.
Sicheres Sichern der Oracle-Datenbank mit Vinchin
Auch bei vorhandener Replikation bleiben Backups unverzichtbar. Replikation gewährleistet zwar die Verfügbarkeit, deckt jedoch nicht alle Ausfallarten ab. Regelmäßige und konsistente Backups sind daher nach wie vor erforderlich. Vinchin Backup & Recovery ist eine professionelle, enterprisefähige Datenbanksicherungslösung, die die meisten gängigen Datenbanken unterstützt – Oracle, MySQL, SQL Server, MariaDB, PostgreSQL und PostgresPro.
Es bietet zahlreiche Funktionen; zu den wichtigsten zählen Cloud-Backup und Bandarchivierung, vollständige sowie inkrementelle Backups mit Unterstützung für archivierte Logs bei Oracle, geplante Backups mit Datenkompression und Deduplizierung, Wiederherstellung auf einem neuen Server mit Zeitpunktwiederherstellung (Point-in-Time Recovery) sowie Ransomware-Schutz. Für Oracle speziell werden zudem Oracle-spezifische Komprimierung, Unterstützung für Block Change Tracking, Überspringen zugänglicher Dateien und Überspringen offline befindlicher Dateien zur Optimierung der Backup-Aufträge hinzugefügt.
Die Vinchin-Webkonsole ist einfach und intuitiv. Die Sicherung von Oracle umfasst vier klare Schritte:
1. Wählen Sie die Datenbank aus, die gesichert werden soll,
2. Wählen Sie den Speicherort für die Sicherungskopie aus,
3. Definieren Sie die Sicherungsstrategie
4. Die Aufgabe einreichen
Die Benutzeroberfläche führt Sie mithilfe klarer Bezeichnungen und Aufforderungen. Sie können den Fortschritt von Aufgaben überwachen, Protokolle einsehen und Zeitpläne in der Konsole anpassen – ohne komplexe Befehle.
Mit einer globalen Kundenbasis und hohen Produktbewertungen bietet Vinchin eine 60-tägige kostenlose Testversion mit vollem Funktionsumfang – klicken Sie auf die Schaltfläche, um das Installationsprogramm herunterzuladen und einfach bereitzustellen.
Häufig gestellte Fragen zur Oracle-Datenbankreplikation
F1: Wie überwache ich die Apply-Verzögerung von Data Guard?
Verwenden Sie folgende SQL-Anweisung: SELECT DEST_ID, DEST_NAME, STATUS, RECEIVED_TIME, APPLIED_TIME FROM V$ARCHIVE_DEST_STATUS WHERE STATUS NOT IN ('DEFERRED','INACTIVE'); prüfen Sie die Verzögerungsmetriken in V$DATAGUARD_STATS.
F2: Wie werden Lücken behoben, wenn die erneute Übertragung fehlschlägt?
Führen Sie ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL aus; rufen Sie dann die fehlenden Logs über FAL_SERVER ab; starten Sie die Wiederherstellung neu: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT.
F3: Wie testet man den GoldenGate-Failover?
Extraktionsprozess auf der Quelle stoppen; Ziel-System als neue Quelle hochstufen; Extraktionsparameter anpassen, um Daten von der neuen Quelle zu erfassen; Prozesse neu starten; nach Behebung der Störung ursprüngliches System als Ziel neu konfigurieren.
F4: Wie wirkt sich die Replikation auf die Leistung der Primärdatenbank aus?
Der SYNC-Modus erhöht die Commit-Wartezeit; der ASYNC-Modus nur minimal. Die GoldenGate-Erfassung erhöht die Redo-Generierung und die CPU-Auslastung. Überwachen Sie AWR und Systemmetriken; dimensionieren Sie die Ressourcen entsprechend.
F5: Wie wählt man zwischen Data Guard und GoldenGate?
Verwenden Sie Data Guard für die zentrale Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR) innerhalb von Oracle. Verwenden Sie GoldenGate für logische Replikation, heterogene Ziele, Filterung, Migrationen ohne Ausfallzeiten sowie Multi-Master-Szenarien.
Fazit
Die Oracle-Replikation steigert Verfügbarkeit, Ausfallsicherheit und Skalierbarkeit. Data Guard und GoldenGate erfüllen die Anforderungen der meisten Unternehmen. Materialisierte Views eignen sich für Berichterstattungszwecke, während veraltete Optionen nur noch in begrenztem Umfang genutzt werden. Für einen effektiven Betrieb sind klare RPO- und RTO-Ziele, umfassende Tests sowie proaktives Monitoring erforderlich. Sichern Sie die Replikation durch Verschlüsselung und sichere Anmeldeinformationen.
Replikation sollte stets mit zuverlässigen Sicherungen kombiniert werden. Vinchin bietet eine leistungsstarke Sicherungslösung für Oracle. Testen Sie die kostenlose Testversion, um Ihre Umgebung zu schützen.
