Optionen für die Notfallwiederherstellung für Oracle-Datenbankarbeitslasten

In diesem Leitfaden werden die Optionen für die Notfallwiederherstellung beschrieben, die Nutzern zur Verfügung stehen, die geschäftskritische Oracle-Datenbankarbeitslasten in einer Bare-Metal-Lösungsumgebung ausführen.

In diesem Leitfaden wird davon ausgegangen, dass Sie Oracle Enterprise Edition verwenden. Einige der in dieser Anleitung beschriebenen Funktionen werden separat lizenziert und sind nicht in einer Enterprise Edition-Lizenz enthalten. Zu diesen Funktionen gehören unter anderem:

• Oracle Real Application Clusters
• Oracle Active Data Guard
• Oracle Advanced Compression
• Oracle GoldenGate

In Ihren Oracle-Lizenzvereinbarungen finden Sie Informationen dazu, welche Funktionen Sie bei der Planung der Notfallwiederherstellung und Hochverfügbarkeit verwenden dürfen.

RTO und RPO von Anwendungen

Die Notfallwiederherstellung für Oracle-Datenbanktechnologien muss anhand des Recovery Time Objective (RTO) und des Recovery Point Objective (RPO) einer Anwendung bestimmt werden. Im Allgemeinen beschreibt der RTO die akzeptable Ausfallzeit für ein System und der RPO den akzeptablen Datenverlust. Die Kosten und die Komplexität eines Systems steigen, wenn einer dieser Werte sinkt. Weitere Informationen zu RTO und RPO finden Sie unter Grundlagen der Planung der Notfallwiederherstellung.

Bei Architekturen, die als „RPO = 0“ oder „kein Datenverlust“ gekennzeichnet sind, müssen die Daten an mehreren Standorten geschrieben werden, bevor sie als „in der Datenbank gespeichert“ gelten. Die Latenz wird zu einem Problem, wenn sich der RPO dem Wert 0 nähert.

Wenn sie in der Designphase nicht richtig berücksichtigt wird, kann die Implementierung einer Architektur ohne Datenverlust sich negativ auf die Gesamtleistung der Anwendung auswirken.

Hochverfügbarkeit im Vergleich zur Notfallwiederherstellung

Hochverfügbarkeit und Notfallwiederherstellung sind sich ergänzende Konzepte beim Entwerfen zuverlässiger Datenbankarchitekturen. Im Kontext dieses Leitfadens bezieht sich Hochverfügbarkeit auf die Fähigkeit eines Systems, sich automatisch von einzelnen oder kaskadierenden Fehlern im System zu erholen. Die Notfallwiederherstellung ist dagegen Teil eines umfassenden Notfallplans zur Aufrechterhaltung des Geschäftsbetriebs und bezieht sich auf größere Ausfälle, die ganze Systemgruppen unzugänglich machen können. Die Notfallwiederherstellung umfasst einen größeren Umfang, da im Falle eines Notfalls eine Reihe integrierter Komponenten wiederhergestellt werden müssen.

Hochverfügbarkeit muss als „erste Verteidigungslinie“ betrachtet werden, wenn ein zuverlässiges System entworfen wird. Eine hochverfügbare Datenbankarchitektur muss einzelne Fehler verkraften und ohne Ausfallzeiten für die Anwendung weiterlaufen können. Die Hochverfügbarkeitskomponenten eines Systems müssen unter anderem Folgendes umfassen:

• Redundante Stromversorgung für Server-, Netzwerk- oder Speicherhardware
• Mehrere Netzwerkschnittstellen, Switches und Kabel
• Redundante Speicherstrukturen, Controller und Festplatten
• Fehlertolerante Partner Interconnect-Verbindungen zwischen Google Cloud und der regionalen Erweiterung der Bare-Metal-Lösung
• Oracle RAC, um zu verhindern, dass Serverausfälle eine Datenbank deaktivieren

Ein Design zur Notfallwiederherstellung muss Prozesse zur Wiederherstellung nach mehreren kaskadierenden Fehlern umfassen, die Komponenten nicht verfügbar machen. Bei der Planung der Notfallwiederherstellung müssen folgende Aspekte berücksichtigt werden:

• Regionale Ausfälle
• Naturkatastrophen
• Vorfälle, die zum vollständigen Ausfall einer oder mehrerer Komponenten einer Anwendung führen

Oracle-Tools für Notfallwiederherstellung und Hochverfügbarkeit

Im Folgenden finden Sie einige Oracle-Tools für Notfallwiederherstellung und Hochverfügbarkeit:

• Oracle Real Application Clusters
• Oracle Recovery Manager
• Oracle Data Guard
• Flashback-Datenbank
• Oracle GoldenGate

Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) wird verwendet, um Datenbankarbeitslasten horizontal zu skalieren, sodass sie von mehreren Datenbankservern verarbeitet werden können. Datenbanken, die RAC verwenden, ermöglichen eine Aktiv/Aktiv-Konfiguration zwischen Servern innerhalb einer regionalen Erweiterung.

RAC wird in der Regel verwendet, um eine hohe Verfügbarkeit für Systeme zu gewährleisten, die vor dem Ausfall eines einzelnen Servers geschützt werden müssen. Aufgrund des „Shared Everything“-Ansatzes (gemeinsamer Speicher und gemeinsame Netzwerke) für Clustering muss ein RAC-Cluster, der in einer Bare-Metal-Lösungsumgebung ausgeführt wird, in einem einzelnen Bare-Metal-Lösung-Pod vorhanden sein. RAC ist daher eine Lösung für Hochverfügbarkeit, erfüllt aber nicht die Anforderungen an die Notfallwiederherstellung.

Oracle Recovery Manager

Oracle Recovery Manager (RMAN) ist das primäre Tool für die Sicherung und Wiederherstellung von Oracle-Datenbanken, da es das proprietäre Datenformat von Oracle lesen kann. Es kann zum Klonen von Datenbanken, zur Wiederherstellung zu einem bestimmten Zeitpunkt oder sogar zur Wiederherstellung einer einzelnen Tabelle in einer Oracle-Datenbank verwendet werden.

RMAN ist das einzige Tool, mit dem Sicherungen erstellt werden können, während die Datenbank geöffnet ist. Außerdem wird sie verwendet, um den Katalog der Sicherungsdateien zu verwalten, die für die Wiederherstellung verfügbar sind.

Oracle Data Guard

Oracle Data Guard führt die Datenbankreplikation in Remote-RAC-Clustern oder anderen Datenbankinstallationen durch. Data Guard unterstützt Standby-Datenbanken in einer physischen oder logischen Konfiguration.

Physische Standby-Datenbanken sind Block-für-Block-Kopien, die es ermöglichen, dass eine Kopie der Datenbank zum Schreiben geöffnet ist. Alle anderen werden entweder gemountet (aber nicht geöffnet), um Änderungen anzuwenden, oder schreibgeschützt geöffnet, um Berichterstellungsanwendungen zu unterstützen.

Informationen zum Einrichten von Data Guard auf der Bare-Metal-Lösung finden Sie unter Oracle Data Guard auf der Bare-Metal-Lösung bereitstellen.

FLASHBACK DATABASE

Mit der FLASHBACK DATABASE-Funktion von Oracle Enterprise Edition können Administratoren eine Datenbank schnell zu einem bestimmten Zeitpunkt zurücksetzen, ohne zeitaufwendige Datenbankwiederherstellungen durchführen zu müssen.

Im Kontext der Notfallwiederherstellung wird FLASHBACK DATABASE häufig in Verbindung mit Data Guard bei Failover-Vorgängen verwendet, um die Datenbank schneller wiederherzustellen. Die fehlgeschlagene Datenbank wird auf einen bestimmten Zeitpunkt zurückgesetzt, der mit den Logs auf dem neuen primären Server übereinstimmt, und die Wiederholung wird übertragen, damit sie vollständig resynchronisiert werden kann.

Oracle GoldenGate

Oracle GoldenGate ist ein Tool für die logische Replikation, das häufig für die Aktivierung von Aktiv/Aktiv-Bereitstellungen an mehreren Standorten oder für die Übertragung von Daten zwischen Hardwareplattformen verwendet wird. Bei Verwendung von GoldenGate erfasst ein extract-Prozess in der Quelldatenbank Änderungen in den Online-Redo-Logs und schreibt diese Änderungen in Trail-Dateien, die zur Zieldatenbank übertragen werden. Ein replicat-Prozess in der Zieldatenbank konvertiert Transaktionen aus den Tail-Dateien in SQL und führt das SQL in der Zieldatenbank aus.

Diese Architektur macht GoldenGate zu einem leistungsstarken Tool zum Übertragen von Daten zwischen Datenbankplattformen oder zum Transformieren von Daten während der Replikation. Im Gegensatz zu Data Guard erfordert GoldenGate die Installation und Wartung separater Software auf den Quell- und Zielsystemen. GoldenGate kann nicht für die synchrone Replikation verwendet werden, da Transaktionen übersetzt und als SQL auf die Zieldatenbank angewendet werden. GoldenGate kann zwar für eine Replikation mit minimaler Verzögerung sorgen, aber allein kann GoldenGate kein RPO von null garantieren.

Bereitstellungsmodelle für die Notfallwiederherstellung (nur Datenbank)

Oracle hat das MAA-Framework (Maximum Availability Architecture) entwickelt, um Ihnen empfohlene Modelle für die Notfallwiederherstellung für die Bereitstellung Ihrer Anwendungen und Datenbanken zur Verfügung zu stellen.

Für jedes der folgenden Modelle gelten bestimmte RTO- und RPO-Ziele:

• Copper-Modell
• Bronze-Modell
• Silbermodell
• Gold-Modell
• Platinum-Modell

Die Modelle sind bestimmten Bereitstellungsmustern zugeordnet, die die RPO und RTO bei geplanten und ungeplanten Ausfällen erfüllen. Jede Datenbankarbeitslast muss hinsichtlich ihrer Verfügbarkeitsanforderungen bewertet und mit einem entsprechenden Modell entworfen werden. In Entwicklungsdatenbanken wird häufig ein Modell mit einem niedrigeren Schutzgrad als in den entsprechenden Produktions- und QA-Datenbanken verwendet.

Das Bronze-Modell ist für Datenbanken vorgesehen, für die kein RTO in Minuten erforderlich ist. Die Modelle auf Silver-Ebene und höher umfassen Stand-by-Datenbanken, die an einem Remote-Standort ausgeführt werden. Jedes Modell enthält die Funktionen der Modelle der niedrigeren Ebene. Im Bronze-Modell werden beispielsweise Konzepte für Sicherung und Wiederherstellung verwendet, die auch bei der Bereitstellung einer Standby-Datenbank eingehalten werden müssen.

Copper-Modell

Das Kupfermodell bietet eine minimale Bereitstellung zum Sichern von Datenbanken auf lokalen Speichermedien und zum Kopieren in Speicher, der sich außerhalb der Region befindet. Für diese Bereitstellung ist ein zweistufiger Ansatz erforderlich. Die Übertragung von Sicherungen kann jedoch mit dem Google Cloud SDK automatisiert werden.

Bei dieser Bereitstellung erhöht sich auch die RTO, da eine zweistufige Wiederherstellung erforderlich ist. RMAN kann nicht direkt auf die Sicherungen zugreifen. Sie müssen also an einen Speicherort verschoben werden, auf den RMAN zugreifen kann, bevor die Wiederherstellung beginnen kann.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist
	Katastrophen: Beschädigungen	Letzte Archivprotokoll-, inkrementelle oder vollständige Sicherung, die aus der RE übertragen wurde	Stunden, je nach Datenbankgröße und Bandbreite, die Partner Interconnect zugewiesen ist
	Katastrophen: Fehler bei der Regionenerweiterung	Letzte Archivprotokoll-, inkrementelle oder vollständige Sicherung, die aus der RE übertragen wurde	Tage / Wochen, je nach Zeitaufwand für die Reaktivierung der Erweiterung
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
	Haupt-Datenbank-Upgrade	0	1–2 Stunden

Bronze-Modell

Das Bronze-Modell bietet zwei Bereitstellungsoptionen. Beide verwenden denGoogle Cloud-nativen Speicher zum Aufbewahren von Datenbanksicherungen.

Bronze-Bereitstellung 1: Sicherung im regionalen Speicher

Bei dieser Bereitstellung werden Sicherungen direkt auf externe Medien geschrieben. In den meisten Fällen ist Cloud Storage mit Cloud Storage FUSE das bevorzugte Sicherungsziel, da ein Cloud Storage-Bucket als Dateisystem dargestellt wird.

Die Empfehlungen zur Verwendung von Cloud Storage FUSE finden Sie unter „Oracle-Sicherungen mit NFS und Cloud Storage“ Google Cloud Filestore.Filestore stellt NFS-Freigaben für die Bare-Metal-Lösungsinstanzen bereit und kann ebenfalls verwendet werden.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist
	Katastrophen: Beschädigungen	Letzte Archivprotokoll-, inkrementelle oder vollständige Sicherung	Stunden, je nach Datenbankgröße und Bandbreite, die Partner Interconnect zugewiesen ist
	Katastrophen: Fehler bei der Regionenerweiterung	Letzte Archivprotokoll-, inkrementelle oder vollständige Sicherung	Tage / Wochen, je nach Zeitaufwand für die Reaktivierung der Erweiterung
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
	Haupt-Datenbank-Upgrade	0	1–2 Stunden

Bronze-Bereitstellung 2: Sicherung mit Backup und DR

Bei dieser Bereitstellung wird der Backup- und DR-Dienst verwendet, um Sicherungen inGoogle Cloudzu speichern. Backup and DR bietet einen inkrementellen Ansatz für Sicherungen, die auf leistungsstarken Medien gespeichert und durch Cloud Storage für die langfristige Aufbewahrung gesichert werden.

Backup and DR bietet auch einen schnelleren RTO als das Speichern von Sicherungen in Filestore oder Cloud Storage, da es sofort Images von Datenbankdateien für die Oracle-Instanz bereitstellen kann. Mit der Funktion „Mount and Migrate“ wird eine Datenbank schnell online geschaltet, während die Daten auf die Produktionsspeichermedien zurückkopiert werden. Dadurch wird das RTO drastisch reduziert.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist Sekunden bei Verwendung von RAC
	Katastrophen: Beschädigungen	Letzte Archivprotokoll-, inkrementelle oder vollständige Sicherung	Minuten bis Stunden, je nach Leistungsanforderungen, Datenbankgröße und Bandbreite, die Partner Interconnect zugewiesen ist
	Katastrophen: Fehler bei der Regionenerweiterung	Letzte Archivprotokoll-, inkrementelle oder vollständige Sicherung	Tage / Wochen, je nachdem, wie lange es dauert, bis die Region wieder online ist, oder ob der Kunde zu einer anderen Region wechseln kann.
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist
	Haupt-Datenbank-Upgrade	0	1–2 Stunden

Silber

Im Silver-Modell wird die Datenbankreplikation mit Oracle Data Guard eingeführt. Data Guard bietet Datenbankreplikation in Echtzeit mit einer oder mehreren Datenbanken, die als Standby-Datenbank fungieren. Da Data Guard auf dem Transport und der Anwendung von Datenbankänderungen beruht, sobald sie auftreten, kann der RPO nahezu null sein. Das Silver-Modell basiert auf asynchroner Replikation. Bei Verwendung der synchronen Replikation wird kein Datenverlust garantiert, aber die Zeit, die zum Senden von Daten zwischen Regionen benötigt wird, führt in der Regel dazu, dass die Reaktionszeit der Anwendung über akzeptable Grenzen hinausgeht.

Die Fast-Start-Failover-Funktion von Data Guard kann automatische Failover-Vorgänge ausführen, wenn eine primäre Datenbank für einen benutzerdefinierten Zeitraum nicht verfügbar ist. Die Konfiguration wird von einem Data Guard-Beobachterprozess überwacht, der ausgeführt werden kann.

Das Silver-Modell hat den Vorteil, dass die Datenbank im Falle eines vollständigen regionalen Ausfalls verfügbar ist. Failover- und Switchover-Vorgänge können sich jedoch auf die Anwendungsleistung auswirken, da die Netzwerklatenz zwischen den Anwendungsservern und der Datenbank zunimmt. Es wird selten empfohlen, Anwendungen und zugehörige Datenbanken in verschiedenen Regionen auszuführen. Der RTO für die Datenbank liegt möglicherweise unter einer Minute. Bei einem Anwendungs-Failover kann es jedoch Minuten bis Stunden dauern, bis die Dienste wieder voll funktionsfähig sind. In den meisten Fällen sind für die Ausführung von standortübergreifenden Notfallwiederherstellungsplänen in der Regel manuelle Prozesse erforderlich, da eine große Anzahl von Komponenten verschoben wird.

Im Silver-Modell kann es bei vierteljährlichen Patching-Aktivitäten weiterhin zu Ausfallzeiten oder Wartungsfenstern kommen. Durch die Einführung von Oracle RAC kann die Ausfallzeit für das Patchen oder bei Serverfehlern reduziert werden.

Das folgende Diagramm zeigt ein Beispiel für eine Konfiguration.

Die Beispielkonfiguration im Diagramm zeigt RAC-Datenbanken, die in den Regionen us-west2 und us-east4 ausgeführt werden. Die Replikation wird mit asynchronem Data Guard konfiguriert. Der gesamte Traffic zwischen der Bare-Metal-Lösung und Google Cloudwird über eine Partner Interconnect-Verbindung übertragen. Regionsübergreifender Traffic wird über das Google-Netzwerk-Backbone übertragen. Anwendungsserver werden in jeder Region konfiguriert, sind aber in der Notfallwiederherstellungsregion in der Regel heruntergefahren, bis ein Failover-Ereignis deklariert wird.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist Sekunden bei Verwendung von RAC
	Katastrophen: Beschädigungen	< 60 Sek.	Minuten bis Stunden, je nach Anwendungs-Failover.
	Katastrophen: Fehler bei der Regionenerweiterung	< 60 Sekunden	Minuten bis Stunden, je nach Anwendungs-Failover.
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist. Sekunden bei Verwendung von RAC
	Haupt-Datenbank-Upgrade	0	1–2 Stunden Minuten, wenn Sie DBMS_ROLLING für das Upgrade verwenden.

Gold-Modell

Wenn Sie sich Sorgen über den Datenverlust im Silver-Modell machen, können Sie sich für das Gold-Modell entscheiden, das eine Far-Sync-Instanz verwendet, um eine synchrone Replikation für eine Instanz bereitzustellen, die in Google CloudCompute Engine ausgeführt wird.

Eine Far-Sync-Instanz enthält eine Datenbanksteuerdatei und eine Reihe von Standby-Redo-Logs, die geografisch in der Nähe der primären Datenbank ausgeführt werden. Diese Instanz ist so konfiguriert, dass sie das Wiederherstellen synchron mit geringer Latenz empfängt. So können alle Änderungen außerhalb der Region der primären Datenbank aufgezeichnet werden. Die Far-Sync-Instanz leitet das Wiederherstellen dann an die Standby-Datenbank in der Remote-Region weiter, um es asynchron anzuwenden.

Eine Far-Sync-Instanz ist keine vollständige Kopie der Datenbank und kann daher keinen Anwendungs-Traffic verarbeiten. Die Far-Sync-Instanz wird verwendet, um einen fehlertoleranten Ort für das synchrone Schreiben von Datenbankänderungen bereitzustellen. So wird eine Lösung ohne Datenverlust ermöglicht. Bei der synchronen Replikation in die Far-Sync-Instanz werden Transaktionen erst dann in der primären Datenbank committet, wenn die Änderungen in der Far-Sync-Instanz empfangen und committet wurden.

Die Compute Engine-Instanzen werden in der Regel als Kandidaten für das Hosting einer Far-Sync-Instanz ausgewählt. Wenn Sie die Far-Sync-Instanz in einer Compute Engine-Zone in unmittelbarer Nähe der primären Datenbank platzieren, wird die Latenz minimiert (in der Regel unter 1,5 ms) und es wird Schutz vor Ausfällen innerhalb der Regionerweiterung geboten.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Die Beispielkonfiguration im Diagramm zeigt eine primäre RAC-Datenbank, die in us-west2 ausgeführt wird, und Anwendungen, die in Compute Engine ausgeführt werden. Auf einer Compute Engine-Instanz in us-west2 wird eine Far-Sync-Instanz ausgeführt, die synchronen Redo-Log empfängt. Die Far-Sync-Instanz ist so konfiguriert, dass Redo-Logs asynchron an eine RAC-Datenbank gesendet werden, die in der Region us-east4 ausgeführt wird. Anwendungsinstanzen werden in der Region us-east4 in Compute Engine konfiguriert, um im Katastrophenfall Anwendungs-Traffic zu verarbeiten.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist Sekunden bei Verwendung von RAC
	Katastrophen: Beschädigungen	0	Minuten bis Stunden, je nach regionalem Failover der Anwendung.
	Katastrophen: Fehler bei der Regionenerweiterung	0	Minuten bis Stunden, je nach regionalem Failover der Anwendung.
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist. Sekunden bei Verwendung von RAC
	Haupt-Datenbank-Upgrade	0	1–2 Stunden Minuten, wenn Sie DBMS_ROLLING für das Upgrade verwenden.

Platin-Modell

Das Platinum-Modell bietet zwei Bereitstellungsoptionen. Jede Bereitstellungsoption bietet Schutz mit einer anderen Technologie und hat unterschiedliche RTO- und RPO-Merkmale.

Platinum-Bereitstellung 1: Data Guard mit Fast-Start-Failover

Die Platinum-Bereitstellung 1 basiert auf der Gold-Modellbereitstellung. Es wird eine zweite Data Guard-Standby-Datenbank in der lokalen Region hinzugefügt, die auf einer Compute Engine-Instanz ausgeführt wird. Bei dieser Konfiguration wird die synchrone Replikation zwischen der primären Datenbank und der in Compute Engine ausgeführten Standby-Datenbank verwendet, wodurch in der primären Region kein Datenverlust garantiert wird.

Wenn Sie eine Standby-Datenbank in derselben Region erstellen, können Datenbank-Failover und ‑Switchover erfolgen, ohne dass sich dies auf Anwendungen auswirkt. Bei Änderungen an der Datenbankrolle stellen Anwendungen, die gemäß den Client-Überlegungen von Oracle konfiguriert sind, automatisch eine neue Verbindung zur neuen primären Datenbank her, ohne dass ein manueller Eingriff erforderlich ist. Bei ordnungsgemäß konfigurierten Anwendungen dauert ein Failover-Ereignis weniger als 2 Minuten.

Die Standby-Datenbank in Compute Engine führt kein RAC aus, muss aber so dimensioniert sein, dass sie den normalen Anwendungs-Traffic unterstützt, wenn sie als primäre Datenbank ausgeführt wird. Diese Instanz kann entweder mit einer kleineren Form als Standby ausgeführt und bei Failover-Ereignissen hochskaliert werden oder jederzeit mit voller Kapazität ausgeführt werden. Wenn Sie die Größe der Instanz während eines Failover-Ereignisses ändern, wirkt sich das negativ auf den RTO aus, da die Instanz während des Vorgangs neu gestartet werden muss.

Das Fast-Start-Failover wird auf einer Compute Engine-Instanz konfiguriert, auf der der Data Guard-Broker mit einem Beobachter ausgeführt wird. Der Observer führt einen einfachen Oracle-Client mit Verbindungen zu allen primären und Standby-Datenbanken aus. Wenn der Observer einen Fehler in der primären Datenbank erkennt, initiiert er ein Failover zu einer der Standby-Datenbanken. Die Standby-Datenbank, die in Compute Engine ausgeführt wird, muss als bevorzugtes Failover-Ziel konfiguriert werden, wenn Sie die Bereitstellung auf Gold-Niveau verwenden.

Oracle empfiehlt, den Observer in einer Region zu platzieren, die sich von der primären und der Standby-Datenbank unterscheidet. So wird der beste Schutz vor regionalen Ausfällen und Netzwerkpartitionierungsereignissen geboten. Wenn eine dritte Region nicht möglich ist, muss der Observer in der primären Region installiert werden und in einer anderen Zone als der Near-Site-Standby ausgeführt werden.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Die im Diagramm dargestellte Beispielbereitstellung besteht aus Folgendem:

• Eine primäre Datenbank, die RAC auf einem Bare-Metal-Lösungsserver in der Region us-west2 ausführt.
• Eine Near-Site-Standby-Datenbank, die auf einer Compute Engine-Instanz in der Region us-west2 ausgeführt wird.
• Eine Remote-Standby-Datenbank, die auf einem Bare-Metal-Lösungsserver in der Region us-east4 ausgeführt wird.
• Der Data Guard-Beobachter wird auf einer Compute Engine-Instanz in der Region us-central1 ausgeführt.

Die synchrone Replikation ist für die Standby-Datenbank in der Region konfiguriert, die auf der Compute Engine-Instanz ausgeführt wird, und die asynchrone Replikation ist für die Remote-Region konfiguriert. In jedem Fall wird das Wiederherstellen von der primären Datenbank an die Standby-Datenbank gesendet. Das Wiederherstellen wird nicht von einer Standby-Datenbank an die andere weitergeleitet. Der Observer ist in einer dritten Region konfiguriert und stellt eine Verbindung zu allen Datenbanken in der Konfiguration aufrecht. Anwendungsinstanzen werden in der primären Region konfiguriert und stellen eine Verbindung zur primären Datenbank auf dem Bare-Metal-Lösungsserver her (oder zur Datenbank auf der Compute Engine-Instanz während Failover- und Switchover-Vorgängen). Anwendungsinstanzen werden in der Region us-east4 in Compute Engine konfiguriert, um Anwendungs-Traffic im Katastrophenfall zu verarbeiten.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist Sekunden bei Verwendung von RAC
	Katastrophen: Beschädigungen	0	< 60 Sek.
	Katastrophen: Fehler bei der Regionenerweiterung	0	< 60 Sek.
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist. Sekunden bei Verwendung von RAC
	Haupt-Datenbank-Upgrade	0	1–2 Stunden Minuten, wenn Sie DBMS_ROLLING für das Upgrade verwenden.

Platin-Bereitstellung 2: GoldenGate für die Replikation

Bei der Platinum-Bereitstellung 2 wird Oracle GoldenGate für die Replikation verwendet. Da GoldenGate nicht auf Blockebene repliziert. Dadurch kann jede Datenbank Lese- und Schreibanwendungssitzungen unabhängig voneinander verarbeiten. Die Änderungen werden bidirektional repliziert, was eine Aktiv/Aktiv-Datenbankkonfiguration ermöglicht.

Anwendungen müssen gründlich validiert werden, bevor Sie sich für eine Active/Active-Bereitstellung entscheiden. Außerdem müssen Sie die Konflikterkennung und ‑behebung berücksichtigen.

Im Gegensatz zu Data Guard erfordert GoldenGate die Installation und Wartung zusätzlicher Software auf den Oracle-Datenbankservern. Für Active/Active-Bereitstellungen ist in der Regel ein ausgeklügeltes Schema- und Anwendungsdesign erforderlich, um die Vorteile einer Datenbankbereitstellung an mehreren Standorten nutzen zu können. Viele vorgefertigte Anwendungen unterstützen diese Art von Architektur nicht.

Bereitstellungen, die für die gesamte Replikation von GoldenGate abhängig sind, können aufgrund der asynchronen Natur der logischen Replikation keinen RPO ohne Datenverlust unterstützen. Lokale Standby-Datenbanken, die in Compute Engine mit Data Guard ausgeführt werden, können bereitgestellt werden, um mit synchroner Replikation ein RPO von null zu erreichen.

Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung.

Ausfall	Ausfalltyp	RPO	RTO
Nicht geplant	Behebbarer Knoten- oder Instanzfehler	0	Zeit, die für den Neustart der Instanz erforderlich ist
	Katastrophen: Beschädigungen	Sekunden in Minuten 0, wenn Data Guard an jedem Standort verwendet wird	0
	Katastrophen: Fehler bei der Regionenerweiterung	Sekunden in Minuten 0, wenn Data Guard an jedem Standort verwendet wird	0
Geplant	Datenbank-Patches, Betriebssystem-/Firmware-Updates	0	Zeit, die für die Aktualisierung und den Neustart der Instanz erforderlich ist. Sekunden bei Verwendung von RAC
	Haupt-Datenbank-Upgrade	0	0