DR für Datenbanken planen

Mit Oracle GoldenGate, Active Data Guard und Autonomous Data Guard können Sie DR für Ihre in Oracle Cloud bereitgestellten Datenbanken implementieren.

• Active Data Guard bietet einen umfassenden Datenschutz, High Availability und Disaster Recovery für Oracle Database auf einfache und kostengünstige Weise, indem ein synchronisiertes physisches Replikat (Standby) einer Produktionsdatenbank an einem Remote-Standort beibehalten wird. Die Standby-Datenbank ist während der Redo-Übertragung, -Validierung und -Recovery schreibgeschützt geöffnet.

  Im Gegensatz zu typischen Speicherreplikationsmethoden repliziert Active Data Guard nur die speicherresidenten Redo Logs und validiert die Replikation, um eine Beschädigung zu verhindern.

• Oracle GoldenGate ist ein erweitertes logisches Replikationsprodukt, das Multimaster-Replikation, Hub- und Spoke-Deployment und Datentransformation unterstützt. GoldenGate bietet Kunden flexible Optionen zur Erfüllung der gesamten Replikationsanforderungen, einschließlich heterogener Hardwareplattformen.
• Autonomous Data Guard bietet Datenschutz und Disaster Recovery für Ihre autonomen Datenbankinstanzen in Oracle Cloud. Wenn Sie Autonomous Data Guard für eine autonome Datenbankinstanz aktivieren, wird eine Standbydatenbank in derselben Region erstellt. In Regionen mit mehreren Availability-Domains wird die Standby-Datenbank in einer anderen Availability-Domain als die Primärdatenbank bereitgestellt. In Regionen mit einer einzelnen Availability-Domain wird die Standby-Datenbank auf einem anderen physischen Rechner als die Primärdatenbank bereitgestellt. Autonomous Data Guard überwacht die primäre Instanz und führt einen automatischen Failover zur Standbydatenbank durch, wenn die Primärdatenbank nicht verfügbar ist.

Info zu Oracle Maximum Availability Architecture

Oracle Maximum Availability Architecture (MAA) ist eine Gruppe von Best Practices-Blueprints für den integrierten Einsatz der High Availability-Technologien von Oracle. Die MAA-Best Practices beschreiben Standardarchitekturen, die verschiedene Service Level Objectives für High Availability und Datenschutzanforderungen erreichen. Die Architekturstufen Bronze, Silber, Gold und Platinum MAA sind so konzipiert, dass Sie verschiedene Service Level Objectives erreichen und Ihnen Optionen für High Availability, Datenschutz und Disaster Recovery zur Verfügung stellen.

Jede der folgenden MAA-Tiers verwendet ein optimales Set an Oracle-Funktionen, die beim gemeinsamen Deployment die Zielservicegrade für ungeplante Ausfälle und geplante Wartungsereignisse zuverlässig erreichen:

• Bronze

  Die Bronze-Ebene bietet einfachen Datenbankservice zu möglichst niedrigen Kosten. Ein geringerer Grad an High Availability und Datenschutz wird im Gegenzug für geringere Kosten und Komplexität der Implementierung akzeptiert. Diese Architektur kann für Datenbanken geeignet sein, die für Test-, Entwicklungs- und weniger kritische Produktionsanwendungen und Datenbanken verwendet werden.

  Die Architektur verwendet die High Availability-Funktionen von Oracle Enterprise Edition. Bronze wird standardmäßig für die Oracle Database-Einzelinstanz- oder Mehrmandantenarchitektur verwendet. Mit den High Availability-Funktionen von Oracle Restart oder Oracle Clusterware können Sie eine ausgefallene Instanz, einen Datenbankserver oder einen relevanten verwalteten Service neu starten. Bei logischen Fehlern wie menschlichen Fehlern können Sie mit Flashback-Vorgängen die Datenbank zu einem bestimmten Zeitpunkt "zurückspulen". Im Worst-Case-Szenario eines vollständigen Siteausfalls ist zusätzliche Zeit erforderlich, um das System und die Datenbank aus Backups wiederherzustellen und wiederherzustellen, was zu Stunden oder Tagen Ausfallzeit führen kann.

  Ein lokales Backup innerhalb desselben Data Centers wird immer für das schnellste Recovery empfohlen. Oracle empfiehlt zudem, eine zweite Backupkopie in einem Remote-Data Center zu verwalten, um Siteausfälle und Katastrophen zu vermeiden. Mit Oracle Database Backup Cloud Service können Sie ein cloud-basiertes Backup von On-Premise-Datenbanken verwalten.

• Silver

  Die Silver-Tier ist für Datenbanken konzipiert, die es sich nicht leisten können, auf einen Kaltstart oder eine Wiederherstellung aus einem Backup zu warten, falls eine nicht wiederherstellbare Datenbankinstanz oder ein Serverausfall vorliegt. Diese Architektur eignet sich möglicherweise für Produktionsanwendungen, die geschäftskritisch sind und Ausfallzeiten bei lokalen Fehlern und häufigsten geplanten Wartungsaktivitäten reduzieren müssen.

  Die Silver-Architektur basiert auf der Grundlage der Bronze-Architektur und fügt Oracle Real Application Clusters (Oracle RAC) aktiv-aktives Clustering für minimale oder keine Ausfallzeit bei Ausfall einer Datenbankinstanz oder eines Servers sowie keine Ausfallzeit der Datenbank für die häufigsten geplanten Wartungsereignisse hinzu.

  Wie in der Bronze-Architektur stellt Recovery Manager (RMAN) datenbankoptimierte Backups bereit, um die Verfügbarkeit wiederherzustellen, falls ein vollständiger Clusterausfall oder eine Katastrophe auftritt.

• Gold

  Die Gold-Tier wurde für Service Level-Anforderungen entwickelt, die lange Ausfallzeiten und Datenverluste nicht tolerieren können. Diese Gruppe von Architekturmustern bietet High Availability und umfassenden Datenschutz für alle Typen ungeplanter Ausfälle, darunter Datenbeschädigungen, Datenbankfehler und Siteausfälle. Missionskritische Produktionsanwendungen, die eine schnelle Recovery-Zeit und keinen oder minimalen Datenverlust bei allen Datenbank- und Systemausfällen und geplanten Wartungsaktivitäten erfordern, profitieren von den in der Gold-Referenzarchitektur enthaltenen Funktionen.

  Die Referenzarchitektur Gold basiert auf der Referenzarchitektur Silver und bietet mit Oracle Active Data Guard vier Architekturmuster. Die Muster unterscheiden sich von einem einzelnen Remote Active Standby mit Fast Start Failover und HA Observer zu mehreren Standby-Datenbankkonfigurationen, einschließlich Standby-Readerfarmen, und schließlich einer Far Sync (regionsübergreifend) Zero Data Loss Standby-Konfiguration.

• Platin

  Die Platinum-Ebene kann keine Ausfallzeiten für Ausfälle und geplante Wartungsaktivitäten bereitstellen, die mit der Gold-Architektur nicht erreichbar sind. Die Platinum-Architektur baut auf der Gold-Architektur auf, indem Oracle GoldenGate-Replikation hinzugefügt wird, um Ausfallzeiten bei Migrationen, Anwendungsupgrades und Datenbankupgrades zu beseitigen. Jede Oracle GoldenGate-Datenbank wird durch eine Standbydatenbank geschützt, um bei einem Datenbank-, Cluster- oder Siteausfall keinen Datenverlust zu ermöglichen.

  Im Gegensatz zu den anderen MAA-Architekturen sind Anwendungsüberlegungen erforderlich, um Oracle GoldenGate in die Architektur zu integrieren, um sicherzustellen, dass die Konflikterkennung und -auflösung ordnungsgemäß ausgeführt werden. Global Data Services oder benutzerdefinierte Application Service-Verwaltung sind möglicherweise auch erforderlich, um keine Anwendungsausfallzeiten für Aktivitäten wie Migration und Datenbankupgrades zu erreichen.

Active Data Guard verwenden

Data Guard umfasst zahlreiche Services, mit denen Sie Standbydatenbanken erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken Katastrophen und Datenbeschädigung bewältigen können. Data Guard verwaltet diese Standbydatenbanken als transaktional konsistente Kopien der Produktionsdatenbank. Die meisten Best Practices von Active Data Guard werden als Teil der Referenzarchitekturen in der MAA-Gold-Tier definiert, getestet und validiert.

Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Data Guard jede Standbydatenbank in die Produktionsrolle umschalten und so die Ausfallzeit des Ausfalls minimieren. Data Guard kann mit traditionellen Backup-, Restore- und Clustertechniken für ein hohes Maß an Datenschutz und Datenverfügbarkeit verwendet werden.

Vorteile von Active Data Guard

Active Data Guard bietet mehrere Vorteile.

• Physische Replikation sichern

  Die Standbydatenbank ist schreibgeschützt geöffnet, sodass Ihre Datenkonsistenz gewährleistet ist.

  Beachten Sie, dass Sie ab Oracle Database 19c gelegentliche Aktualisierungs- und Einfügeanweisungen an die Standbydatenbank ausgeben können. Dadurch werden die Anweisungen an die Primärdatenbank umgeleitet.

• Einfache, schnelle, unidirektionale Replikation einer vollständigen Oracle Database.

  Die Standardkonfiguration verarbeitet die meisten Workloads, sodass nur wenig Verwaltungsaufwand entsteht.

• Keine Einschränkungen.

  Oracle Data Guard Redo Apply unterstützt alle Oracle-Features und repliziert transparent alle Daten- und Speichertypen, PL/SQL-Packages und DDL ohne besondere Überlegungen.

• Bester Datenschutz.

  Die Replikation direkt aus dem Speicher isoliert die Standby-Datenbank vor I/O-Beschädigungen, die in der primären Datenbank auftreten können. Ermittelt vollautomatische Datenverlustfehler, die unabhängig von der Primär- oder der Standbydatenbank auftreten können. Automatische Erkennung und Reparatur von physischen Blockbeschädigungen, die unabhängig von der Primär- oder Standbydatenbank auftreten können.

• Wahl zwischen synchronem Datenverlust ohne Datenverlust oder asynchronem Datenschutz ungleich Null.
• Verbesserte RoI.

  Sie können schreibgeschützte Workloads wie Reportinganwendungen, Ad-hoc-Abfragen und Datenextrakte in eine synchronisierte physische Standby-Datenbank auslagern.

• Mit einem einzigen Befehl wird eine physikalische Standby-Datenbank als Testsystem konvertiert, das Lese-/Schreibzugriff öffnet. Ein zweiter Befehl konvertiert sie wieder in eine physikalische Standby-Datenbank und synchronisiert sie mit der primären Datenbank neu. Primärdaten sind immer geschützt.
• Integrierte Verwaltung einer vollständigen Konfiguration mit Oracle Data Guard Broker-Befehlszeile und automatischem Datenbank-Failover.
• Wird für die Datenbank mit einem Knoten oder die Datenbankkonfiguration mit mehreren Knoten (Real Application Cluster) unterstützt.
• Application Continuity, für den aktiven Schutz Ihrer Transaktionen.

  Active Data Guard maskiert Datenbankausfälle von Endbenutzern und Anwendungen, indem die laufende Arbeit für betroffene Datenbanksessions wiederhergestellt wird.

Konfigurationsmodi

• Maximaler Schutz
  Dieser Schutzmodus bietet keinen Datenverlust, wenn die Primärdatenbank ausfällt. Um sicherzustellen, dass es zu keinem Datenverlust kommen kann, wird die Primärdatenbank heruntergefahren, wenn sie den Redo-Stream durch einen Fault nicht in das Standby-Redo-Log von mindestens einer Standby-Datenbank schreiben kann.

  Hinweis:

  Dieser Modus ist für autonome Datenbanken nicht verfügbar. Bei Exadata Cloud Service und Exadata Cloud@Customer können Sie diesen Modus manuell konfigurieren, die Cloud Control Plane gibt ihn jedoch nicht wieder.
• Maximale Verfügbarkeit:

  Dieser Schutzmodus bietet den höchsten Datenschutz, der ohne Auswirkungen auf die Verfügbarkeit der Primärdatenbank möglich ist. Wie im Modus "Maximaler Schutz" schreibt eine Transaktion erst fest, nachdem die Redo-Daten, die für das Recovery dieser Transaktion erforderlich sind, in das lokale Online-Redo-Log und das Standby-Redo-Log mindestens einer transaktional konsistenten Standby-Datenbank geschrieben wurden. Im Gegensatz zum Maximum Protection-Modus wird die Primärdatenbank nicht heruntergefahren, wenn ein Fault das Schreiben des Redo-Streams in ein Remote Standby-Redo-Log verhindert. Stattdessen werden die primäre Datenbank und die Data Guard-Konfiguration auf den Status UNSYNCHRONIZED zurückgesetzt. Wenn mindestens eine Standby-Datenbank verfügbar ist, wird die Standby-Datenbank automatisch resynchronisiert.

• Maximale Performance:

  Dieser Schutzmodus (der Standardmodus) stellt den höchsten Grad des Datenschutzes bereit, der möglich ist, ohne dass sich dies auf die Performance der Primärdatenbank auswirkt. Dies wird erreicht, indem eine Transaktion festschreiben kann, wenn die Redo-Daten, die für das Recovery dieser Transaktion erforderlich sind, asynchron in das lokale Online-Redo-Log geschrieben werden. Wenn Netzwerk-Links mit ausreichender Bandbreite verwendet werden, bietet dieser Modus einen hohen Grad an Datenschutz, der dem Maximum Availability-Modus mit minimaler Auswirkung auf die Performance der Primärdatenbank nahe kommt.

Überlegungen zur DB-Platzierung

Um Verfügbarkeit und Disaster Recovery zu verbessern, speichern Sie das DB-System der Standby-Datenbank in einer anderen Availability-Domain als das DB-System der Primärdatenbank.

Wenn Sie Data Guard für eine Datenbank aktivieren und sich die Standby-Datenbank in derselben Availability-Domain wie die Primärdatenbank befindet (je nach Wahl oder weil die Region eine einzelne Availability-Domain aufweist), speichern Sie die Standby-Datenbank in einer anderen Faultdomain als die der Primärdatenbank.

Wenn es sich bei Ihrer Primär- und Standbydatenbank um RAC-DB-Systeme mit 2 Knoten handelt und sich beide in derselben Availability-Domain befinden, empfehlen wir die Verteilung aller vier Knoten (zwei für Primär- und zwei für Standby-Datenbanken) auf alle drei Faultdomains in der Availability-Domain. Diese Konfiguration gewährleistet eine möglichst hohe Verfügbarkeit und nutzt dabei alle drei Faultdomains. In diesem Szenario kann sich nur einer der beiden Knoten der Standby-Datenbank in einer Faultdomain befinden, die keine anderen Knoten aus der primären oder Standby-Datenbank enthält.

Um optimale Rollenübergänge zwischen der primären Datenbank und der Standby-Datenbank sicherzustellen, empfiehlt Oracle, dass Sie die Größe und Konfiguration der beiden Datenbanken symmetrisch festlegen.

Konfiguration - Best Practices

Siehe "Oracle Data Guard Best Practices" in Oracle Database High Availability - Überblick und Best Practices.

Oracle GoldenGate verwenden

Oracle GoldenGate ist ein umfassendes Softwarepaket für die Echtzeit-Datenintegration und -replikation in heterogenen IT-Umgebungen. Das Produktset ermöglicht High Availability-Lösungen, Echtzeit-Datenintegration, Erfassung von Transaktionsänderungsdaten, Datenreplikation, Transformationen und Prüfung zwischen betrieblichen und analytischen Unternehmenssystemen. Die meisten Best Practices von Oracle GoldenGate werden als Teil von Referenzarchitekturen in der MAA-Platinum-Tier definiert, getestet und validiert.

Verwenden Sie Oracle GoldenGate, wenn eine Replikatdatenbank mit Lese-/Schreibzugriff geöffnet sein muss, während die Replikation aktiv ist, einschließlich in den folgenden Szenarios:

• Erweiterte Replikationsanforderungen, wie Multimaster- und bidirektionale Replikation, Subset-Replikation, Eins-zu-Eins-Replikation, Cross-Endian-Replikation und Datentransformationen
• Wartung und Migrationen, die ohne Ausfallzeiten über bidirektionale Replikation erforderlich sind
• Plattformübergreifende Migration, die von Data Guard nicht unterstützt wird (z.B. Migration einer plattformübergreifenden Plattform)
• Unterstützung für datenbankübergreifende verteilte Systeme (Beispiel: Replikat 1 befindet sich auf 12.2, und Replikat 2 befindet sich auf 19c)
• Unterstützung für DB-übergreifende Plattformen (Beispiel: Replikat 1 befindet sich auf Oracle, Replikat 2 befindet sich nicht auf Oracle DB)

Konfigurationsmodi

Verwenden Sie die Oracle GoldenGate-Microservices-Architektur, die eine sichere, umfassende und skalierbare Replikationsplattform in der Cloud bereitstellt. Um den Overhead auf den Datenbankservern zu minimieren, empfiehlt Oracle, dass Sie GoldenGate in der Hubkonfiguration bereitstellen.

GoldenGate unterstützt mehrere Topologien, wie im folgenden Diagramm dargestellt. Wählen Sie einen Modus, der zu Ihrem Anwendungsfall passt.

Beschreibung der Abbildung gg-config-modes.png

Konfiguration - Best Practices

Da Oracle GoldenGate Daten auf Transaktionsebene repliziert, wird empfohlen, die Data Consistency zwischen zwei Sites zu implementieren. Konflikte werden sofort identifiziert und mit automatisierten Skripten behandelt.

Wenn Sie GoldenGate hauptsächlich für DR-Zwecke verwenden und die Replikation nur eine Möglichkeit ist, wird empfohlen, Data Guard zwischen zwei Regionen hinzuzufügen. Dadurch erhalten Sie eine Lösung ohne Datenverlust mit starker Datenkonsistenz zwischen der primären und der Data Guard-Instanz. Diese Konfiguration verringert auch den Overhead beim Ausführen des GoldenGate-Extrakts aus der primären Datenbank.

Beschreibung der Abbildung db-dg-gg.png

Hinweis:

Die Architektur zeigt mehrere Availability-Domains (ADs) an. Passen Sie für eine Region mit einer einzelnen AD die Architektur an, um Ihre Ressourcen auf die Faultdomains innerhalb der AD zu verteilen.

Stellen Sie Oracle GoldenGate sowie in einer HA-Konfiguration bereit. Sie können die Oracle ASM Cluster File System-(ACFS-)Replikation für kritische GoldenGate-Dateien verwenden.

Active Data Guard und GoldenGate verwenden

Oracle GoldenGate und Active Data Guard schließen sich nicht gegenseitig aus. Sie können sie zusammen verwenden, um ein Recovery Point Objective (RPO) von Null (d.h. kein Datenverlustrisiko) zu erreichen, da GoldenGate asynchron ist, während Active Data Guard eine synchrone Replikation zusammen mit anderen wichtigen Features wie Datenblockvalidierung, automatische Blockreparatur und Anwendungskontinuität bereitstellen kann.

Die folgenden Szenarios nutzen Oracle GoldenGate und Active Data Guard:

• Verwenden Sie eine Active Data Guard-Standby für Katastrophenschutz und rollende Datenbankupgrades für eine erfolgsrelevante OLTP-Datenbank. Mit GoldenGate können Sie Daten aus der primären Data Guard-Datenbank (oder aus der Standbydatenbank mit dem ALO-Modus GoldenGate) für die ETL-Aktualisierung eines Enterprise Data Warehouse extrahieren.
• Verwenden Sie die Teilmengenreplikation GoldenGate, um Daten aus zahlreichen Datenquellen zu extrahieren, zu transformieren und in einen zentralen Betriebsdatenspeicher (ODS) zu aggregieren. ODS unterstützt geschäftskritische Anwendungssysteme, die erhebliche Umsätze für das Unternehmen generieren. Schützen Sie ODS mit einer Active Data Guard-Standbydatenbank, und bieten Sie optimalen Datenschutz und optimale Verfügbarkeit.
• Verwenden Sie die Multimaster-Replikation GoldenGate, um mehrere Datenbanken zu synchronisieren, die sich jeweils in verschiedenen Geografien befinden. Jede GoldenGate-Kopie verfügt über eine eigene lokale synchrone Data Guard-Standbydatenbank, die ein Failover ohne Datenverlust ermöglicht, wenn ein Ausfall auftritt.

Hinweis:

Um die Architektur für maximale Verfügbarkeit auf Platinum-Ebene zu implementieren, verwenden Sie Oracle Real Application Clusters (Oracle RAC), Active Data Guard und Oracle GoldenGate.