Kritische Datenbanken mit Autonomous Data Guard vor Fehlern und Katastrophen schützen

Autonomous Data Guard

Autonomous Data Guard erstellt und verwaltet zwei vollständig separate Kopien der Datenbank: eine Primärdatenbank, die von Ihren Anwendungen verbunden und verwendet wird, und eine Standbydatenbank, bei der es sich um eine synchronisierte Kopie der Primärdatenbank handelt. Sollte die Primärdatenbank aus einem beliebigen Grund nicht mehr verfügbar sein, kann Autonomous Data Guard die Standbydatenbank in die Primärdatenbank konvertieren. Dadurch wird die Wartung Ihrer Anwendungen gestartet.

Primär- und Standby-Datenbanken werden häufig als gegenseitige Peerdatenbanken bezeichnet. Sie können bis zu zwei Standbydatenbanken pro autonomer Containerdatenbank verwenden.

Hinweis:

Anwendungen müssen für die Verwendung von Transparent Application Continuity (TAC) konfiguriert werden, um alle Vorteile der Datenbankverfügbarkeitsfeatures von Autonomous Data Guard nutzen zu können.

Das folgende Diagramm zeigt, wie jede Standbydatenbank mit der Primärdatenbank synchronisiert wird.

Beschreibung von autonomous-data-guard.eps folgt

Beschreibung der Abbildung Autonomous-data-guard.eps

An der Primärdatenbank vorgenommene Änderungen werden im Redo-Log der Primärdatenbank aufgezeichnet. Autonomous Data Guard überträgt diese Redo-Datensätze als Stream über das Netzwerk in das Redo-Log der Standbydatenbank. Anschließend wendet die Standbydatenbank diese Datensätze auf die Standbydatenbank an. Auf diese Weise bleibt die Standbydatenbank mit der Primärdatenbank synchronisiert.

Die Synchronisierung erfolgt nahezu unmittelbar. Wie der zuvor beschriebene Prozess nahelegt, gibt es jedoch zwei Vorgänge, die Zeit in Anspruch nehmen: die Übertragung der Redo-Datensätze an die Standbydatenbank und die Anwendung der Redo-Datensätze auf die Standbydatenbank. Der erste dieser Vorgänge wird als Transport Lag bezeichnet, der andere als Apply Lag. Sie können die aktuellen Lag-Werte für eine Autonomous Database auf der Seite "Details" der Datenbank über Autonomous Data Guard unter Ressourcen unter "Ressourcen" im Seitenmenü anzeigen. Auf der Seite "Details" der Containerdatenbank können Sie auf ähnliche Weise aktuelle Lag-Werte für alle Autonomous Database-Instanzen in einer Containerdatenbank anzeigen.

Hinweis:

Bei mehreren Standby-Datenbanken wird der kaskadierte Redo-Transport nicht unterstützt.

Autonomous Data Guard konfigurieren

In Autonomous Database on Dedicated Exadata Infrastructure konfigurieren und verwalten Sie Autonomous Data Guard auf der ACD-Ebene. Sie können Autonomous Data Guard für bereits bereitgestellte ACDs aktivieren und auf der Seite Details über die Oracle Cloud Infrastructure-Konsole bis zu zwei Standby-ACDs hinzufügen. Anweisungen finden Sie unter Autonomous Data Guard auf einer autonomen Containerdatenbank aktivieren und Zweite autonome Standbycontainerdatenbank hinzufügen.

Beachten Sie Folgendes, bevor Sie Autonomous Data Guard konfigurieren:

Für Autonomous Databases, die auf Exadata Cloud@Customer bereitgestellt werden, muss Port 1522 geöffnet sein, damit TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zulässig ist.
Autonomous Data Guard kann auf einer ACD mit einem aktiven Wartungslauf, der innerhalb der nächsten drei Tage geplant ist, nicht aktiviert werden. Sie können entweder zuerst die aktive Wartung ausführen und dann Autonomous Data Guard aktivieren oder den Wartungslaufplan so ändern, dass er erst beginnt, wenn die zweite Standbydatenbank hinzugefügt wurde.
Für das Hinzufügen einer zweiten Standbydatenbank ist ein automatischer Nicht-Rolling-Neustart für die erste Standbydatenbank erforderlich. Die Primärdatenbank ist von diesem Nicht-Rolling-Neustart nicht betroffen.

Autonomous Data Guard mit vom Kunden verwalteten Schlüsseln konfigurieren

In Autonomous Database on Dedicated Exadata Infrastructure können Sie Autonomous Data Guard mit vom Kunden verwalteten Schlüsseln auf der Ebene der autonomen Containerdatenbank (ACD) konfigurieren und verwalten. Sie können Autonomous Data Guard für bereits bereitgestellte ACDs aktivieren und über die Oracle Cloud Infrastructure-Konsole auf der Seite "Details" bis zu zwei Standby-ACDs hinzufügen. Anweisungen finden Sie unter Autonomous Data Guard in einer autonomen Containerdatenbank aktivieren und Zweite autonome Standbycontainerdatenbank hinzufügen.

Beachten Sie Folgendes, bevor Sie Autonomous Data Guard mit vom Kunden verwalteten Schlüsseln konfigurieren:

Wenn Sie Oracle Cloud Infrastructure Key Management System (OCI KMS) verwenden und regionsübergreifendes Autonomous Data Guard aktivieren möchten, müssen Sie zuerst den OCI-Vault in der Region replizieren, in der Sie die Standbydatenbank hinzufügen möchten. Weitere Informationen finden Sie unter Vaults und Schlüssel replizieren.

Hinweis:
Virtuelle Vaults, die vor der Einführung des regionsübergreifenden Vault-Replikationsfeatures erstellt wurden, können nicht regionsübergreifend repliziert werden. Erstellen Sie einen neuen Vault und neue Schlüssel, wenn Sie einen Vault haben, den Sie in einer anderen Region replizieren müssen, und die Replikation für diesen Vault nicht unterstützt wird. Alle privaten Vaults unterstützen jedoch die regionsübergreifende Replikation. Weitere Informationen finden Sie unter Regionsübergreifende Virtual-Vault-Replikation.
Wenn Sie Oracle Key Vault (OKV) verwenden und regionsübergreifendes Autonomous Data Guard aktivieren möchten, stellen Sie sicher, dass Sie Verbindungs-IP-Adressen für das OKV-Cluster im Keystore hinzugefügt haben.

Autonomous Data Guard-Modelle

Ab März 2025 können autonome Containerdatenbanken (ACDs) Autonomous Data Guard auf der Seite Details aktivieren und bis zu zwei Standby-ACDs erstellen. Mit diesem Release werden das vorherige Autonomous Data Guard-Verknüpfungsmodell und die zugehörigen APIs veraltet und durch das neue Autonomous Data Guard-Gruppenmodell und die neuen APIs ersetzt. Alle neuen ACDs, die nach März 2025 über die Oracle Cloud Infrastructure-(OCI-)Konsole bereitgestellt werden, verwenden automatisch das neue Modell Autonomous Data Guard-Gruppen.

Um vorhandene ACDs zu wechseln, können Kunden zum neuen Modell migrieren, indem sie auf der Seite Details von ACD in der OCI-Konsole auf Upgrade zu Autonomous Data Guard-Gruppen oder über die API MigrateAutonomousContainerDatabaseDataguardAssociation klicken.

Beim Upgrade:

Sie wechseln zur neuen Benutzererfahrung, bei der Autonomous Data Guard-Vorgänge für die Ressource Autonome Containerdatenbank anstelle der Ressource Autonome Containerdatenbank - Data Guard-Verknüpfung ausgeführt werden.
Die Autonomous Data Guard-Verknüpfungen-Ressource wird in eine Autonomous Data Guard-Gruppenressource mit Unterstützung mehrerer Standbydatenbanken konvertiert. Es gibt keine Auswirkungen auf vorhandene autonome Datenbanken oder das Data Guard-Setup.
Sie müssen Autonomous Data Guard auf der Seite Details der ACD aktivieren, nachdem Sie es bereitgestellt haben, um das Autonomous Data Guard-Feature zu verwenden.
Sie müssen die Switchover- und Failover-Vorgänge von der Standby-ACD aus initiieren, zu der Sie die Rollen mit der primären ACD oder dem Failover wechseln möchten.
Sie wechseln zu den neuen Autonomous Data Guard-Gruppen-APIs, die als Ersatz-APIs in der API zur Verwaltung der Autonomous Data Guard-Konfiguration aufgeführt sind. Die vorhandene Autonomous Data Guard-Verknüpfungs-API ist veraltet und wird ab März 2026 nicht mehr verfügbar sein.
Sie müssen die neuen Autonomous Data Guard-Gruppenereignisse abonnieren, die unter Autonomous Data Guard-Ereignistypen aufgeführt sind. Die vorhandenen Autonomous Data Guard-Verknüpfungen-Ereignisse funktionieren nur mit der alten Autonomous Data Guard-Verknüpfungen-API und werden zusammen mit diesen APIs veraltet.

Rollenübergänge und zugehörige Vorgänge

Nach der Erstellung einer autonomen Containerdatenbank (ACD) können Sie die Rolle der Peerdatenbanken mit einem Switchover- oder Failover-Vorgang ändern. Wenn das automatische Failover aktiviert ist, führt Autonomous Data Guard aus einem beliebigen Grund automatisch einen Failover-Vorgang aus, sobald die Primärdatenbank nicht mehr verfügbar ist.

Ein Switchover ist eine Rollenumkehr zwischen der Primärdatenbank und der zugehörigen Datenbank. Ein Switchover erfolgt ohne Datenverlust. Während eines Switchovers geht die Primärdatenbank in die Standbyrolle und die Standbydatenbank in die Primärrolle über. Informationen zum Ausführen eines Switchover-Vorgangs finden Sie unter Rollen in einer Autonomous Data Guard-Konfiguration wechseln.

Ein Failover tritt auf, wenn die Primärdatenbank nicht verfügbar ist. Der Failover führt zu einem Übergang der Standbydatenbank in die Primärrolle. Wenn das automatische Failover nicht aktiviert ist, können Sie einen manuellen Failover ausführen, wie unter Failover zur Standbydatenbank in einer Autonomous Data Guard-Konfiguration beschrieben.

Die Verfügbarkeit und der Status der Datenbank nach einem Failover-Vorgang sind durch zwei Recovery-Ziele gekennzeichnet:

Recovery Time Objective (RTO): Das RTO ist die maximale Zeit, die erforderlich ist, damit die Datenbank nach einem Failover für Anwendungen verfügbar wird. Es hängt zu einem gewissen Grad mit dem Apply-Lag zum Zeitpunkt des Fehlers zusammen. Für Autonomous Data Guard beträgt das RTO wenige Sekunden bis zwei Minuten.
Recovery Point Objective (RPO): Das RPO ist die maximale Dauer des potenziellen Datenverlusts aufgrund der ausgefallenen Primärdatenbank. Es hängt zu einem gewissen Grad mit dem Transport-Lag zum Zeitpunkt des Fehlers zusammen. Für Autonomous Data Guard beträgt das RPO nahezu null.

Nach einem Failover wird die ausgefallene Primärdatenbank zu einer Deaktivierten Standbydatenbank und bleibt für keine Datenbankverbindung verfügbar. Sie können sie erneut aktivieren und in eine fehlerfreie Standbydatenbank verwandeln, indem Sie einen Neu instanziieren-Vorgang ausführen. Nachdem eine ausgefallene Primärdatenbank als Standbydatenbank neu instanziiert wurde, können Sie ein Switchover ausführen, um sie wieder in ihre ursprüngliche Primärrolle zurückzuversetzen. Informationen zum Ausführen eines Neuinstanziierungsvorgangs finden Sie unter Deaktivierte Standbydatenbank in einer Autonomous Data Guard-Konfiguration neu instanziieren.

Automatischer Failover oder Fast-Start Failover

Beim automatischen Failover wird automatisch ein Failover zur Standby-ACD ausgeführt, wenn die primäre ACD aufgrund eines Fehlers in der Region, der Availability-Domain, der Exadata-Infrastruktur, des autonomen Exadata-VM-Clusters (AVMC) oder der ACD selbst nicht verfügbar ist. Dies wird auch als Fast-Start Failover bezeichnet.

Sie können den automatischen Failover nicht aktivieren, während Sie Autonomous Data Guard auf einer ACD konfigurieren. Automatischer Failover kann nur beim Aktualisieren der Autonomous Data Guard-Einstellungen auf der Seite Details von ACD aktiviert oder deaktiviert werden.

Hinweis:

Automatischer Failover kann nicht für Autonomous Databases aktiviert werden, die in Exadata Cloud@Customer mit regionsübergreifendem Autonomous Data Guard-Setup bereitgestellt sind.

Sie können keine zweite Standby-ACD mit aktiviertem automatischen Failover für die erste Standby-ACD hinzufügen. Deaktivieren Sie daher den automatischen Failover mit Autonomous Data Guard-Einstellungen aktualisieren, bevor Sie die zweite Standby-ACD erstellen, und aktivieren Sie sie bei Bedarf später erneut.

Sowohl der Schutzmodus für maximale Performance als auch der Schutzmodus für maximale Verfügbarkeit unterstützen automatischen Failover:

Im Modus Maximale Verfügbarkeit garantiert der automatische Failover, dass keine Daten verloren gehen.
Im Modus Maximale Performance stellt der automatische Failover sicher, dass die Standbydatenbank nicht über den für Laglimit für Schnellstart-Failover angegebenen Wert hinaus hinter der Primärdatenbank zurückbleibt. Standardmäßig ist Laglimit für Fast Start-Failover auf 30 Sekunden eingestellt und gilt nur für den Modus "Maximale Performance". In diesem Fall ist ein automatisches Failover nur möglich, wenn der Apply Lag (potenzieller Datenverlust) der Standbydatenbank die konfigurierte Lag-Grenze nicht überschreitet. Sie können den Fast Start Failover Lag-Grenzwert in einen beliebigen Wert zwischen 5 und 3600 ändern.

Weitere Informationen finden Sie unter Autonomous Data Guard-Einstellungen aktualisieren.

Neben Hardwarefehlern, Availability-Domainausfällen und regionalen Ausfällen gibt es einige weitere Datenbankzustände, die einen Fast-Start Failover auslösen können, wie unten aufgeführt:

Datenbankzustand	Beschreibung
Beschädigte Kontrolldatei	Die Kontrolldatei ist wegen eines Datenträgerfehlers dauerhaft beschädigt.
Beschädigtes Dictionary	Dictionary-Beschädigung einer kritischen Datenbank. Dieser Status wird derzeit nur erkannt, wenn die Datenbank geöffnet ist.
Datendatei-Schreibfehler	Schreibfehler treten in beliebigen Datendateien auf, einschließlich temporärer Dateien, Systemdatendateien und Undo-Dateien.

Durch einen automatischen Failover ändert sich die Rolle der ausgefallenen Primärdatenbank in "Deaktivierte Standbydatenbank". Nach kurzer Zeit übernimmt die Standbydatenbank die Rolle der Primärdatenbank. Nach Abschluss des automatischen Failovers wird auf der Detailseite der deaktivierten Standbydatenbank gemeldet, dass ein Failover stattgefunden hat.

Nachdem der Service die Probleme mit der ursprünglichen autonomen Primärcontainerdatenbank behoben hat, können Sie einen manuellen Switchover ausführen, um beide Datenbanken in ihre anfänglichen Rollen zurückzuversetzen. Nachdem Sie die Standbydatenbank bereitgestellt haben, können Sie verschiedene Verwaltungsaufgaben für die Standbydatenbank ausführen, darunter:

Manuellen Switchover einer Primärdatenbank zu einer Standbydatenbank durchführen
Manuellen Failover einer Primärdatenbank zu einer Standbydatenbank durchführen
Primärdatenbank nach Failover in Standbyrolle neu instanziieren
Standbydatenbank beenden

In einem Autonomous Data Guard-Setup mit mehreren Standbydatenbanken und automatischem Failover:

Bei manuellen Failovers müssen Sie die ursprüngliche Primärdatenbank, die zur neuen Standbydatenbank wird, manuell neu instanziieren.
Wenn ein automatischer Failover auftritt, versucht Autonomous Database on Dedicated Exadata Infrastructure, die alte Primärdatenbank als Standbydatenbank neu zu instanziieren. Wenn dieser Versuch jedoch fehlschlägt, muss er manuell wiederhergestellt werden.

Snapshot-Standbydatenbank

Bei einer Snapshot-Datenbank handelt es sich um eine vollständig aktualisierbare Standby-Datenbank, die durch das Konvertieren einer autonomen Standby-Containerdatenbank (ACD) in eine Snapshot-Standby-ACD erstellt wurde. Schrittweise Anweisungen finden Sie unter Physische Standbydatenbank in Snapshot Standby konvertieren.

Eine Snapshot-Datenbank empfängt und archiviert Redo-Daten von der Primärdatenbank, wird jedoch nicht angewendet. Es erhöht jedoch das Recovery Time Objective (RTO), da Echtzeitänderungen aus der primären Datenbank nicht angewendet werden.

Die Snapshot Standby-Funktion unterstützt verschiedene Anwendungsfälle, hier sind jedoch die primären Anwendungsfälle.

Verbinden Sie Primär- und Standby-Anwendungsinstanzen mit Primär- und Standbydatenbanken im Lese-/Schreibmodus, um anfängliche Konfigurationen auszuführen.
Patchen Sie zunächst die Snapshot-Standbydatenbank, und testen Sie sie mit der Standbyanwendungsinstanz, um die Patchstabilität zu bestätigen. Dazu muss zuerst die physische Standbydatenbank in eine Snapshot-Standbydatenbank konvertiert werden, damit der Patch in der Snapshot-Standbydatenbank eingespielt werden kann.

Hinweis:

Bei aktiviertem automatischem Failover können Sie eine autonome Standbydatenbank nicht in eine Snapshot-Standbydatenbank konvertieren.

Bei der Konvertierung in eine Snapshot-Standbydatenbank können Sie entweder neue Datenbankservices aktivieren, die nur im Snapshot-Modus aktiv sind, oder dieselben Services verwenden, die mit der Primärdatenbank verwendet werden. Die Aktivierung von Primärdatenbankservices in der Snapshot-Datenbank kann jedoch dazu führen, dass Verbindungsanforderungen für Snapshot-Standby an die Primärdatenbank weitergeleitet werden, oder umgekehrt, wenn Sie falsche Datenbank-Verbindungszeichenfolgen verwenden. Daher müssen Sie beim Herstellen einer Verbindung zur Primär- und Snapshot-Standbydatenbank die entsprechende Verbindungszeichenfolge verwenden.

Hinweis:

Wenn Sie neue Services mit Snapshot-Standbydatenbank erstellen, werden Wallets für alle Autonomous Databases in der Snapshot-Standbydatenbank-ACD aktualisiert. Um auf die Datenbank zuzugreifen, laden Sie die Wallets neu aus Autonomous Database-Standbydatenbanken, und verwenden Sie Snapshot-Standbydatenbankverbindungszeichenfolgen.

Sie können die Snapshot-Standby-ACD manuell von Oracle Cloud Infrastructure (OCI) zurück in eine physische Standby-ACD konvertieren. Ausführliche Anweisungen finden Sie unter Snapshot-Standby in physische Standbydatenbank konvertieren. Wenn eine Snapshot Standby-Datenbank nicht manuell in eine physische Standby-Datenbank konvertiert wird, wird sie nach 7 Tagen nach ihrer Erstellung automatisch wieder in eine physische Standby-Datenbank konvertiert. In jedem Fall verwirft die Konvertierung der Snapshot-Standbydatenbank zurück in eine physische Standbydatenbank alle lokalen Aktualisierungen in den Snapshot-Standbydatenbanken und wendet die Redo-Daten an, die von den Primärdatenbanken empfangen wurden.

Wenn sich eine Standby-ACD im Snapshot-Standbymodus befindet, können Sie die folgenden Vorgänge nicht an der primären ACD ausführen:

Autonome Datenbanken erstellen oder beenden
Autonome Datenbanken vertikal oder horizontal skalieren
Autonomous Databases wiederherstellen

Wenn die Situation dies erfordert, können Sie manuell einen Failover von der Primärdatenbank zu einer Snapshot-Standbydatenbank durchführen. In diesem Fall konvertiert das Failover die Snapshot-Standby-Datenbank in eine physische Standby-Datenbank, indem alle lokalen Aktualisierungen an der Snapshot-Standby verworfen und Daten von der Primärdatenbank angewendet werden. Schrittweise Anweisungen finden Sie unter Failover zur Standbydatenbank in einer Autonomous Data Guard-Konfiguration.

Ein Switchover zwischen der Primärdatenbank und der zugehörigen Snapshot-Standbydatenbank ist nicht zulässig. Sie müssen die Snapshot-Standbydatenbank manuell in eine physische Standbydatenbank konvertieren, bevor Sie ein Switchover versuchen.

Aus Clientanwendungen auf Standbydatenbanken zugreifen

In einer Autonomous Data Guard-Konfiguration stellen Ihre Clientanwendungen in der Regel eine Verbindung zur Primärdatenbank her und führen Vorgänge für diese Datenbank aus.

Bei der physischen Standby-Datenbank anmelden

Neben dieser normalen Verbindung können Sie mit Autonomous Data Guard eine Verbindung zu Clientanwendungen herstellen, die schreibgeschützte Vorgänge ausführen. Um diese Option nutzen zu können, stellen Clientanwendungen eine Verbindung zur Datenbank mit Datenbankservicenamen her, die "_RO" ("Read-Only" bzw. "schreibgeschützt") enthalten, wie unter Vordefinierte Datenbankservicenamen für autonome Datenbanken beschrieben.

Bei der Snapshot-Datenbank anmelden

Mit Autonomous Data Guard können Sie auch Clientanwendungen, die Lese-/Schreibvorgänge ausführen, mit der Snapshot-Standbydatenbank verbinden. Diese Vorgänge sind in der Snapshot-Standbydatenbank lokal und ändern die zugehörige Primärdatenbank nicht. Um eine Verbindung zu einer Snapshot-Standbydatenbank herzustellen, können Clientanwendungen Datenbankservicenamen verwenden, die "_SS" (für "Snapshot-Standbydatenbank") enthalten, wie unter Vordefinierte Datenbankservicenamen für autonome Datenbanken beschrieben.

Hinweis:

Wenn sich die Standbydatenbank im Snapshot-Standbymodus befindet, sind alle Datenbankservices, die "_RO"-Services in ihrem Namen enthalten, inaktiv und können nicht für Verbindungen verwendet werden.

Lag-Zeiten überwachen

Während Ihre Datenbanken, die Autonomous Data Guard verwenden, ausgeführt werden, können Sie Transport- und Apply-Lagzeiten auf der Seite "Details" der Datenbank (oder Containerdatenbank) überwachen. Wählen Sie im Seitenmenü unter "Ressourcen" die Option Autonomous Data Guard-Verbindungen aus. Sie können auch die OCI-Konsole oder Beobachtbarkeits-APIs verwenden, um Transportverzögerungen zu überwachen und Alarme und Benachrichtigungen zu konfigurieren. Weitere Informationen finden Sie unter Datenbankbeobachtbarkeit mit Autonomous Database-Metriken.

Sie sollten mit einer geringfügigen Fluktuation im Laufe der Zeit rechnen, während die Workloads in der Datenbank ab- und zunehmen. Wenn Sie jedoch einen anhaltenden Aufwärtstrend bei der Lag-Zeit feststellen, können Sie das Problem wie folgt beheben:

Aufwärtstrend bei Apply Lag: Ein anhaltender Aufwärtstrend beim Apply Lag weist darauf hin, dass die Standbydatenbank nicht über ausreichende Kapazität für die von der Primärdatenbank eingehenden Redo-Datensätze verfügt. Um dieses Problem zu beheben, skalieren Sie die OCPUs der Datenbank vertikal, wie unter CPU- oder Speicherressourcen zu einer dedizierten autonomen Datenbank hinzufügen beschrieben.
Aufwärtstrend bei Transport-Lag: Ein anhaltender Aufwärtstrend beim Transport-Lag weist auf ein Problem mit der Netzwerkperformance hin. Das Oracle Cloud-Betriebspersonal überwacht konstant die Netzwerkperformance, sodass das Problem behoben werden sollte, ohne dass Sie Maßnahmen ergreifen müssen. Bei Bedarf können Sie das Problem jedoch dem Betriebspersonal melden, indem Sie eine Serviceanfrage stellen, wie unter Serviceanfrage in My Oracle Support erstellen beschrieben.

Konfigurationsoptionen für Autonomous Data Guard

Wenn Sie eine autonome Containerdatenbank mit aktiviertem Autonomous Data Guard erstellen, geben Sie an, in welchen Exadata-Infrastruktur- und autonomen Exadata-VM-Clusterressourcen die Standbydatenbank erstellt und welcher Datenschutzmodus verwendet werden soll.

Sie haben die folgenden Optionen, wenn Sie angeben, welche Exadata-Infrastruktur- und autonomen Exadata-VM-Clusterressourcen für die Standbydatenbank verwendet werden sollen:

In einer anderen Region als die Exadata-Infrastruktur und das autonome Exadata-VM-Cluster der Primärdatenbank:
Diese Option bietet den höchsten Schutz vor Katastrophen, einschließlich eines Ausfalls der gesamten externen Netzwerkkonnektivität oder Stromversorgung in einer gesamten Region.

Um diesen regionsübergreifenden Schutz optimal nutzen zu können, muss auch die Application Tier so konfiguriert sein, dass regionsübergreifender Schutz unterstützt wird. Daher empfiehlt Oracle, diese Option auszuwählen, wenn die Application Tier bereits so konfiguriert ist oder wenn Sie sie so neu konfigurieren möchten, dass regionsübergreifender Schutz unterstützt wird.

Wenn Sie die Datenbank in einer anderen Region speichern, empfiehlt Oracle, den Schutzmodus Maximale Performance zu verwenden.
In einer anderen Availability-Domain (AD) als die Exadata-Infrastruktur und das autonome Exadata-VM-Cluster der Primärdatenbank:
Diese Option bietet einen hohen Schutz vor Katastrophen, einschließlich eines Ausfalls der externen Netzwerkkonnektivität oder Stromversorgung zu einer Availability-Domain innerhalb einer Region.

Diese Option bietet ein ausgewogenes Verhältnis zwischen Datenschutz und einfacher Konfiguration in der Application Tier.

Wenn Sie die Standby-Datenbank in einer anderen Availability-Domain speichern, empfiehlt Oracle, den Schutzmodus Maximale Verfügbarkeit zu verwenden.
In derselben Availability-Domain (AD) wie die Exadata-Infrastruktur und das autonome Exadata-VM-Cluster der Primärdatenbank:
Diese Option bietet ein Mindestmaß an Schutz vor Katastrophen, und Oracle empfiehlt, diese Option nicht auszuwählen.

Wenn sich die Exadata-Infrastruktur- und die autonomen Exadata-VM-Clusterressourcen der Primärdatenbank in einer Region befinden, die nur eine Availability-Domain enthält, empfiehlt Oracle, die Option "In einer anderen Region" zu verwenden.

Wenn Sie die Datenbank in derselben Availability-Domain speichern, empfiehlt Oracle, den Schutzmodus Maximale Verfügbarkeit zu verwenden.
In einem anderen Mandanten als die Exadata-Infrastruktur und das autonome Exadata-VM-Cluster der Primärdatenbank:
Gilt nur für: Oracle Public Cloud ()

Mit dieser Option können Sie eine Standbydatenbank aus einem anderen Mandanten hinzufügen und Ihren Datenbank-Failover oder Switchover zu dieser mandantenübergreifenden Standbydatenbank zulassen. Sie können auch eine Snapshot-Standbydatenbank im Remotemandanten erstellen. Eine mandantenübergreifende Standbydatenbank kann bei der Datenbankmigration mandantenübergreifend hilfreich sein.

Mandantenübergreifende Standbydatenbanken:
- Kann mit dem ECPU- oder OCPU-Compute-Modell aktiviert werden. Die Standbydatenbank muss dasselbe Compute-Modell wie die Primärdatenbank verwenden.
- Automatisches Failover wird nicht unterstützt. Stattdessen können Sie nur ein manuelles Failover verwenden.
- Kann nicht mit der Oracle Cloud Infrastructure-Konsole hinzugefügt werden. Sie können nur eine mandantenübergreifende Standbydatenbank mit der CLI oder REST-API hinzufügen.

Schutzmodi

Autonomous Data Guard stellt die folgenden Datenschutzmodi bereit:

Maximale Verfügbarkeit. Dieser Schutzmodus bietet den höchsten Datenschutz, der ohne Auswirkungen auf die Verfügbarkeit der Primärdatenbank möglich ist.

Die Primärdatenbank schreibt Transaktionen erst fest, nachdem sie die Bestätigung erhalten hat, dass die Daten in der Standby-Datenbank empfangen wurden (nicht, dass sie auf den Datenträger geschrieben wurden). Wenn die primäre Datenbank diese Bestätigung nicht innerhalb von 30 Sekunden erhält, arbeitet sie wie im Modus "Maximale Performance", um die Verfügbarkeit der primären Datenbank zu erhalten, bis sie wieder zeitnah Bestätigungen erhält.

Dieser Schutzmodus stellt sicher, dass kein Datenverlust auftritt, außer bei bestimmten doppelten Fehlern wie dem Ausfall einer Primärdatenbank nach einem Ausfall der Standbydatenbank.
Maximale Performance. Dies ist der Standardschutzmodus. Dieser Schutzmodus bietet den höchsten Datenschutz, der ohne Auswirkungen auf die Performance der Primärdatenbank möglich ist.

Die Primärdatenbank schreibt Transaktionen fest, sobald alle von diesen Transaktionen generierten Redo-Daten in das Online-Redo-Log geschrieben wurden. Außerdem werden Redo-Daten an die Standbydatenbank gesendet. Dies erfolgt jedoch hinsichtlich der Transaktions-Commits asynchron, sodass die Performance der Primärdatenbank durch Verzögerungen beim Schreiben von Redo-Daten in die Standbydatenbank nicht beeinträchtigt wird.

Dieser Schutzmodus bietet etwas weniger Datenschutz als der Modus "Maximale Verfügbarkeit" und hat minimale Auswirkungen auf die Performance der Primärdatenbank.

Sie können den Schutzmodus in einem Autonomous Data Guard-Setup über die Oracle Cloud Infrastructure-(OCI-)Konsole ändern. Schrittweise Anweisungen finden Sie unter Autonomous Data Guard-Einstellungen aktualisieren.

Weitere Informationen zu Schutzmodi in Oracle Data Guard (das dem Autonomous Data Guard-Feature zugrunde liegt) finden Sie unter Oracle Data Guard Protection Modes in Oracle Data Guard Concepts and Administration.

Best Practices bei der Konfiguration von Autonomous Data Guard

Mit Autonomous Database können Sie mit Autonomous Data Guard bis zu zwei Standby-ACDs erstellen. Je nach Anforderung können Sie jedoch einzelne oder mehrere Standby-ACDs verwenden. Um jedoch die resilienteste Disaster-Recovery-Option zu verwenden, die eine Autonomous Database bietet, können Sie eine lokale Standbydatenbank-ACD und eine Remote- oder regionsübergreifende Standbydatenbank-ACD mit maximaler Verfügbarkeit als Datenschutzmodus hinzufügen.

Lassen Sie uns die Vorteile dieses Designs verstehen:

Lokale Standbydatenbank:
- Das automatische Failover zu einer lokalen Standbydatenbank in derselben Region bietet eine erhebliche lokale Disaster-Isolation und einfache Anwendungs-Failover-Funktionalität.
- Der Geschäftswert einer lokalen Standbydatenbank ergibt sich aus einem Failover ohne Datenverlust und einer auf Sekunden reduzierten Ausfallzeit der Anwendung.
- Anwendungen führen automatisch und transparent ein Failover zur lokalen Standbydatenbank durch und behalten dabei die gleiche Latenz zwischen Anwendungsservern und der Datenbank bei. Dies ist besonders wichtig für OLTP- und Packageanwendungen, da eine höhere Latenz den Durchsatz und die gesamte Antwortzeit der Anwendung erheblich beeinträchtigen kann.
Remotestandbydatenbank:
- Wenn bei einer regionalen Katastrophe auf die primären und lokalen Standby-Systeme nicht zugegriffen werden kann, können die Anwendung und die Datenbank ein Failover zur Remote Standby-Datenbank vornehmen.
- Auch wenn die Ausfallzeit der Datenbank bei einer regionalen Katastrophe immer noch sehr gering ist, kann die Ausfallzeit der Anwendung aufgrund zusätzlicher Orchestrierung, die für DNS-, Anwendungs- und Datenbank-Failover-Vorgänge in der sekundären Region erforderlich ist, höher sein.
Maximale Verfügbarkeit:
- Wenn automatisches Failover oder Fast Start Failover (FSFO) aktiviert ist und wenn die primäre ACD nicht verfügbar ist, führt Autonomous Data Guard ein Failover zur lokalen Standbydatenbank ohne Datenverlust und ohne Änderung der Datenbanklatenz in der Anwendung durch.
- Wenn automatisches Failover oder Fast-Start Failover (FSFO) aktiviert ist, führt das System immer dann einen Failover zur Remotestandbydatenbank durch, wenn auf die gesamte primäre Region nicht mehr zugegriffen werden kann. Dies kann zu einem potenziellen Datenverlust führen.

Auswirkungen von Autonomous Data Guard auf Standardverwaltungsvorgänge

In einigen Fällen funktionieren die Standardverwaltungsvorgänge, die Sie in autonomen Containerdatenbanken ausführen, in der Primär- und Standbycontainerdatenbank in einer Autonomous Data Guard-Konfiguration anders als in Standardcontainerdatenbanken. In der folgenden Liste werden diese Unterschiede beschrieben.

Wartungsplan ändern
Die Wartungsplanung einer Primärcontainerdatenbank ist mit dem ihrer Standbydatenbank verknüpft: Die Wartung der Standbydatenbank wird mehrere Tage vor der Wartung der Primärdatenbank ausgeführt. Der Standardwert beträgt 7 Tage. Sie können 1 bis 7 Tage auswählen, wenn Sie die Primärcontainerdatenbank erstellen oder die zugehörigen Wartungsdetails später bearbeiten.
Wartungstyp ändern
Der Wartungstyp einer Primärcontainerdatenbank muss mit dem ihrer Standbydatenbank identisch sein. Sie wählen den Wartungstyp sowohl für die Primär- und die Standbydatenbank aus, wenn Sie die Primärcontainerdatenbank erstellen oder die zugehörigen Wartungsdetails später bearbeiten.
Automatische Backups deaktivieren
Sie können automatische Backups beim Provisioning einer autonomen Containerdatenbank (ACD) mit Autonomous Data Guard nicht deaktivieren.
Geplante Wartung verwalten
Sie können die geplante Wartung einer Primärcontainerdatenbank und ihrer Standbydatenbank separat verwalten. Da die Wartungspläne der beiden Datenbanken jedoch verknüpft sind, müssen Sie die geplante Wartung für die Standbydatenbank vor der Primärdatenbank ausführen, wenn Sie die geplante Wartungszeit außer Kraft setzen möchten.
Zu einem anderen Compartment wechseln
Sie können Primär- und Standbycontainerdatenbanken separat und unabhängig in andere Compartments verschieben, genauso wie Standardcontainerdatenbanken. Wie bei Standardcontainerdatenbanken sollten Sie jedoch beim Verschieben einer Containerdatenbank äußerst vorsichtig sein. Stellen Sie sicher, dass die Containerdatenbank für die erforderlichen Gruppen von Cloud-Benutzern zugänglich bleibt.
Neustart
Sie können Primär- und Standbycontainerdatenbanken separat und unabhängig neu starten, genauso wie Standardcontainerdatenbanken.
Verschlüsselungsschlüssel rotieren
Sie können die Verschlüsselungsschlüssel aus der primären ACD oder der Primärdatenbank rotieren.
Beenden
Sie können Primär- und Standbycontainerdatenbanken separat beenden. Das Beenden einer Primärcontainerdatenbank hat jedoch andere Folgen als das Beenden einer Standbycontainerdatenbank:
- Beim Beenden einer Primärcontainerdatenbank werden sowohl die Primär- als auch die Standbydatenbank beendet. Sie können keine Primärcontainerdatenbanken beenden, die autonome Datenbanken enthalten.
- Wenn Sie eine Standbydatenbank beenden, wird die Standbydatenbank beendet, und sie wird aus der Autonomous Data Guard-Konfiguration entfernt. Wenn nur eine verbleibende Primärdatenbank vorhanden ist, wird die Autonomous Data Guard-Konfiguration entfernt, und die Primärdatenbank wird in eine Standalone-Containerdatenbank umgewandelt.

Schritt-für-Schritt-Anleitungen

Schritt-für-Schritt-Anleitungen zum Verwalten der Autonomous Data Guard-Konfiguration in einer autonomen Containerdatenbank finden Sie unter:

Mit der API können Sie auch die Autonomous Data Guard-Konfiguration anzeigen und verwalten. Weitere Informationen finden Sie unter API zum Verwalten der Autonomous Data Guard-Konfiguration.