Oracle Cloud Infrastructure-Dokumentation

Info zu Standbydatenbanken

Enthält Informationen zum Aktivieren und Verwenden von Autonomous Data Guard für das Disaster Recovery in Autonomous Database.

Wenn Sie Autonomous Data Guard verwenden, erstellt das System eine Standbydatenbank, die kontinuierlich mit den Änderungen aus der Primärdatenbank aktualisiert werden. Sie können Autonomous Data Guard mit einer Standbydatenbank in der aktuellen Region, einer lokalen Standbydatenbank oder mit einer oder mehreren Standbydatenbanken in verschiedenen Regionen und regionsübergreifenden Standbydatenbanken verwenden. Sie können aber auch eine lokale Standbydatenbank und eine oder mehrere Remotestandbydatenbanken hinzufügen.

Sie können auch eine Autonomous Data Guard-Standbydatenbank erstellen, entweder lokal oder remote in einem anderen Mandanten.

Hinweis

Autonomous Data Guard ist mit den Workload-Typen "Data Warehouse" und "Transaktionsverarbeitung" verfügbar. Autonomous Data Guard ist mit den JSON- und APEX-Workload-Typen nicht verfügbar.

Wenn Sie eine der von Autonomous Database bereitgestellten Disaster Recovery-Optionen auswählen, können Sie die Features und Optionen auswählen, die Ihren Anforderungen an Recovery Time Objective (RTO) und Recovery Point Objective (RPO) entsprechen.

Standardmäßig stellt jede Autonomous Database-Instanz eine lokale Backup-basierte Disaster-Recovery-Peerdatenbank bereit.

Um automatisches Failover hinzuzufügen und das Recovery Time Objective (RTO) zu senken, können Sie eine lokale Autonomous Data Guard-Standbydatenbank verwenden.

Um die resilientste Disaster-Recovery-Option von Autonomous Database zu verwenden, können Sie eine lokale Autonomous Data Guard-Standbydatenbank und eine oder mehrere regionsübergreifende Autonomous Data Guard-Standbydatenbanken hinzufügen.

Darüber hinaus können Sie mit anderen Optionen, die Backup-Based Disaster Recovery verwenden, im Vergleich zu Autonomous Data Guard niedrigere Kosten und höhere Recovery Time Objective-(RTO-)Disaster Recovery-Optionen bereitstellen. Einzelheiten zu Backup-basiertem Disaster Recovery finden Sie unter Backup-basiertes Disaster Recovery nutzen.

Themen

Übergeordnetes Thema: Standbydatenbanken mit Autonomous Data Guard für Disaster Recovery nutzen

Autonomous Data Guard mit lokaler Standbydatenbank

Wenn Sie eine Autonomous Data Guard-Standbydatenbank in der aktuellen Region verwenden, stellt Autonomous Database eine lokale Standbydatenbank bereit und überwacht die Primärdatenbank. Wenn die Primärdatenbank heruntergefahren wird oder ausfällt, übernimmt die Standbyinstanz automatisch die Rolle der Primärinstanz.

Bei lokalen Autonomous Data Guard-Peerdatenbanken fallen die zusätzlichen Kosten für die Basis-CPUs und den Speicher der Primärdatenbank an, einschließlich der automatisch skalierten Speicherauslastung, die in der Primärdatenbank selbst abgerechnet wird. Autoscaling-CPUs der Primärdatenbank werden nicht zusätzlich in der lokalen Autonomous Data Guard-Peerdatenbank abgerechnet. Weitere Informationen finden Sie unter Oracle Autonomous Database Serverless - Features - Abrechnung.

Durch das Hinzufügen einer lokalen Standbydatenbank wird eine identische Standbydatenbank bereitgestellt, die je nach Status der Primärdatenbank Folgendes zulässt:

  • Wenn die Primärdatenbank heruntergefahren wird oder ausfällt, konvertiert Autonomous Data Guard die Standbydatenbank mit minimaler Unterbrechung in die Primärdatenbank. Nach Abschluss des Failovers erstellt Autonomous Data Guard eine neue Standbydatenbank für Sie.

  • Sie können einen Switchover-Vorgang ausführen, bei dem die Primärdatenbank zur Standbydatenbank wird und die Standbydatenbank zur Primärdatenbank.

Autonomous Database bietet keinen Zugriff auf eine Standbydatenbank in der aktuellen Region. Sie führen alle Vorgänge aus, z.B. das Skalieren der ECPU-Anzahl (OCPU-Anzahl, wenn Ihre Datenbank OCPUs verwendet) und das Aktivieren von Compute-Autoscaling in der Primärdatenbank. Autonomous Data Guard führt dann dieselben Aktionen in der lokalen Standbydatenbank aus. Gleichermaßen führen Sie Aktionen wie das Stoppen oder Neustarten der Datenbank nur in der Primärdatenbank aus.

Eine lokale Standbydatenbank wird in derselben Region wie die Primärdatenbank (aktuelle Region) erstellt. Für eine bessere Resilienz wird die Standbydatenbank wie folgt bereitgestellt:

  • In Regionen mit mehreren Availability-Domains wird eine lokale Standbydatenbank automatisch in einer anderen Availability-Domain als die Primärdatenbank bereitgestellt.

  • In Regionen mit einer einzelnen Availability-Domain wird eine lokale Standbydatenbank automatisch in einer anderen Faultdomain als die Primärdatenbank bereitgestellt (d.h. auf einem anderen physischen Rechner).

Weitere Informationen zu Availability-Domains finden Sie unter Netzwerkinformationen in der OCI-Konsole anzeigen und Regionen und Availability-Domains.

Alle Autonomous Database-Features von der Primärdatenbank sind verfügbar, wenn die lokale Standbyinstanz zur Primärinstanz wird, nachdem das System einen Failover-Vorgang oder nach einem Switchover-Vorgang ausgeführt hat. Dazu gehören:

  • Datenbankoptionen: Die ECPU-Anzahl (OCPU-Anzahl, wenn Ihre Datenbank OCPUs verwendet), Speicher, Anzeigename, Datenbankname, Autoscaling, Tags und BYOL-Lizenzierungsoptionen haben nach einem Failover zur Standbydatenbank oder nach einem Switchover die gleichen Werte.

  • OML-Notizbücher: Notizbücher und Benutzer, die in der Primärdatenbank erstellt wurden, sind in der Standbydatenbank verfügbar.

  • APEX-Daten und -Metadaten: APEX-Informationen, die in der Primärdatenbank erstellt wurden, werden in die Standbydatenbank kopiert.

  • ACLs: Die Access-Control-Liste (ACL) der Primärdatenbank wird für die Standbydatenbank dupliziert.

  • Privater Endpunkt: Der private Endpunkt aus der Primärdatenbank gilt für die Standbydatenbank.

    Oracle empfiehlt, dass Sie beim Erstellen des Subnetzes für Datenbanken auf einem privaten Endpunkt die Option "Regionales Subnetz" für optimale Verfügbarkeit und Latenz verwenden. Weitere Informationen finden Sie unter Subnetz erstellen.

  • APIs oder Skripte: Alle APIs oder Skripte, mit denen Sie Autonomous Database verwalten, funktionieren nach einem Failover-Vorgang oder nach dem Switchover weiterhin ohne Änderungen.

  • Clientanwendungsverbindungen: Clientanwendungen müssen ihre Verbindungszeichenfolgen nicht ändern, um sich nach einem Failover zur Standbydatenbank oder nach dem Switchover mit der Datenbank zu verbinden.

  • Wallet-basierte Verbindungen: Sie können Ihre vorhandenen Wallets nach einem Failover zur Standbydatenbank oder nach dem Switchover weiterhin für die Verbindung mit der Datenbank verwenden.

Übergeordnetes Thema: Standbydatenbanken

Regionsübergreifende und mandantenübergreifende Features von Autonomous Data Guard

Bietet Informationen zu Features und Betrieb von Autonomous Data Guard mit einer regionsübergreifenden oder mandantenübergreifenden Standbydatenbank.

Wenn Sie eine Standbydatenbank in einer anderen Region hinzufügen und die Primärinstanz ausfällt, stellt Autonomous Data Guard eine Standbydatenbank bereit, die physisch in einer Remoteregion getrennt ist. Die Standbydatenbank ist verfügbar, um die Rolle der nicht verfügbaren Primärinstanz zu übernehmen. Wenn Sie eine Standbydatenbank in einem anderen Mandanten hinzufügen, stellt Autonomous Data Guard eine Standbydatenbank bereit, die sich in einem anderen Mandanten befindet. Die Standbydatenbank ist verfügbar, um die Rolle der nicht verfügbaren Primärinstanz zu übernehmen.

Eine regionsübergreifende Standbydatenbank ist ein Replikat der Primärdatenbank und kann bei Ausfall oder bei Nichtverfügbarkeit der Primärdatenbank für das Recovery verwendet werden. Die Aktivierung von Autonomous Data Guard mit einer regionsübergreifenden Standbydatenbank stellt eine Disaster-Recovery-Lösung für den Fall dar, dass eine gesamte Region nicht verfügbar ist oder die Primärdatenbank aus beliebigem Grund heruntergefahren wird oder ausfallen muss.

Bei regionsübergreifenden Standbydatenbanken von Autonomous Data Guard fallen die zusätzlichen Kosten für die Basis-CPUs und das Doppelte des Speichers der Primärdatenbank an, einschließlich der automatisch skalierten Speicherauslastung, die in der Remote-Peerdatenbank abgerechnet wird. Automatisch skalierte CPUs der Primärdatenbank werden nicht zusätzlich in der Remote-Peer-Datenbank abgerechnet. Die Anzahl der Basis-CPUs wird durch die Anzahl der ECPUs (OCPUs, wenn Ihre Datenbank OCPUs verwendet) angegeben, wie im Feld ECPU-Anzahl (OCPU-Anzahl) in der Oracle Cloud Infrastructure-Konsole angezeigt.

Mit Autonomous Database können Sie je nach Compute-Modell eine oder mehrere Remote-Disaster-Recovery-Peerdatenbanken erstellen:

  • OCPU-Compute-Modell: Sie können eine Remote-Standbydatenbank in einer gekoppelten Region hinzufügen. Gepaarte Regionen sind Remoteregionen, in denen Sie einen regionsübergreifenden Peer erstellen können.

  • ECPU-Compute-Modell: Sie können mehrere Remote-Disaster-Recovery-Peers mit bis zu einem Peer in jeder gepaarten Remoteregion hinzufügen. Beispiel: Wenn sich Ihre Primärdatenbank in der IAD-Region befindet, können Sie eine Standbydatenbank in PHX und eine Standbydatenbank in SJC hinzufügen. Sie können jedoch nicht zwei Remote-Disaster-Recovery-Peers in PHX hinzufügen.

Gepaarte Regionen sind Remoteregionen, in denen Sie eine regionsübergreifende Standbydatenbank erstellen können. Weitere Informationen zu gekoppelten Regionen finden Sie unter Regionsübergreifende gekoppelte Regionen in Autonomous Database.

Sie führen fast alle Vorgänge aus, wie das Skalieren der ECPU-Anzahl (OCPU-Anzahl, wenn Ihre Datenbank OCPUs verwendet) und das Aktivieren von Compute-Autoscaling in der Primärdatenbank. Autonomous Data Guard führt dann dieselben Aktionen für die regionsübergreifende Standbydatenbank aus.

Nachdem Sie eine Remotestandbydatenbank hinzugefügt haben, bietet Autonomous Database über die Oracle Cloud Infrastructure-Konsole Zugriff auf die Remotestandbybank. Autonomous Database bietet Zugriff auf die Remote-Standbydatenbank, sodass Sie einige Vorgänge unabhängig in der Remote-Standbydatenbank ausführen können. Unter anderem können Sie Netzwerke und VCNs für private Endpunkte konfigurieren und Tagging hinzufügen, um Schlüssel und Werte zu definieren, die nicht zwischen der Primärdatenbank und der Remote-Standbydatenbank repliziert werden.

Hinweis

Autonomous Data Guard führt keinen automatischen Failover für eine regionsübergreifende Standbydatenbank durch. Wenn die Primärdatenbank nicht verfügbar ist und eine lokale Standbydatenbank nicht verfügbar ist, können Sie einen manuellen Failover durchführen, damit eine regionsübergreifende Standbydatenbank die primäre Rolle übernimmt.

Sie können keine Verbindung zu einer regionsübergreifenden Standbydatenbank herstellen, während sie als Standbydatenbank ausgeführt wird, und sie ist nicht für schreibgeschützte Vorgänge verfügbar. In den folgenden Fällen können Sie sich bei der Datenbank anmelden:

Die folgenden Bereiche unterscheiden sich beim Failover bzw. Switchover von der Primärdatenbank zu einer Remotestandbydatenbank im Vergleich zu Failover bzw. Switchover zu einer lokalen Standbydatenbank:

  • Anzeigename: Der Anzeigename hat die Erweiterung "_region". Dabei ist region der Regionsname, wie IAD oder BOM.

    Wenn Sie den regionsübergreifenden Peer vor der Einführung der Unterstützung für mehrere regionsübergreifende Peers erstellt haben, hat der Anzeigename des regionsübergreifenden Peers die Erweiterung "_Remote".

  • OML-Notizbücher: Nach einem regionsübergreifenden Switchover oder Failover sind OML-Notizbücher aus der Primärdatenbank, für die ein Switchover oder ein Failover durchgeführt wurde, nicht in der Primärdatenbank vorhanden (die aktuelle Primärdatenbank nach der Rollenänderung). Neue OML-Notizbücher können erstellt werden.

  • Privater Endpunkt: Sie können vor dem Failover oder vor einem Switchover private Endpunkte in einer Standbydatenbank unabhängig konfigurieren und aktualisieren. Auf diese Weise können Sie einen privaten Endpunkt verwenden, der nach dem Failover oder nach einem Switchover unterschiedlich konfiguriert ist. Autonomous Database hält die Netzwerkkonfiguration nicht von der Primärdatenbank in eine Remoteregion synchronisiert.

    VCN-Peering und Domainweiterleitung sind erforderlich, damit Wallets regionsübergreifend arbeiten können. Autonome Datenbanken mit einem privaten Endpunkt mit einer Autonomous Data Guard-Standbydatenbank, bei der sich die Primär- und die Standbydatenbank in verschiedenen VCNs befinden. Weitere Informationen zu VCN-Peering und Domainweiterleitung finden Sie unter Remote-VCN-Peering mit einem RPC und DNS im virtuellen Cloud-Netzwerk.

  • Netzwerkzugriffssteuerungsliste: Standardmäßig verwenden eine primäre Disaster-Recovery-Datenbank und Remote-Peer-Datenbanken dieselben Netzwerkzugriffssteuerungslisten (ACLs). Optional können Sie Netzwerk-ACLs unabhängig in einer Remote-Peer-Datenbank bearbeiten. Auf diese Weise können Sie verschiedene ACLs in einer Remote-Peer-Datenbank verwenden.

    Weitere Informationen finden Sie unter Remote Peer Network-ACLs verwalten.

  • Tags: Tags werden unabhängig in einer Disaster-Recovery-Primärdatenbank und in einer Remote-Peer-Datenbank verarbeitet. Dies bedeutet:

    • Wenn Sie ein Tag auf einem Remote-Peer hinzufügen, entfernen oder aktualisieren, gilt die Änderung nur für die Remote-Peer-Datenbank.

    • Wenn Sie ein Tag in der Primärdatenbank hinzufügen, aktualisieren oder entfernen, wird das Tag nicht in Remote-Peer-Datenbanken hinzugefügt, aktualisiert oder entfernt.

  • APIs oder Skripts: Alle APIs oder Skripts, die Sie zur Verwaltung der Autonomous Database verwenden, müssen möglicherweise aktualisiert werden, um die APIs auf der Primärdatenbank aufzurufen.

    Sie können auch vordefinierte Substitutionsvariablen in Ihren Oracle Cloud Infrastructure-(OCI-)URLs für regionsübergreifendes Failover für Autonomous Database verwenden, wenn Sie OCI-REST-APIs verwenden. Weitere Informationen finden Sie unter Substitutionsvariablen in Oracle Cloud Infrastructure-(OCI-)URLs.

    Bei mTLS-Verbindungen müssen Sie ein Wallet aus der Primärdatenbank, der aktuellen Primärdatenbank, nach einem Failover oder nach einem Switchover herunterladen. Weitere Informationen finden Sie unter Regionsübergreifende Disaster-Recovery-Verbindungszeichenfolgen und Wallets.

  • Clientanwendungen: Clientanwendungen müssen eine Verbindung mit den Verbindungszeichenfolgen und dem Wallet herstellen, die Sie aus der Primärdatenbank, der aktuellen Primärdatenbank, nach einem Failover oder nach einem Switchover herunterladen. Weitere Informationen finden Sie unter Regionsübergreifende Disaster-Recovery-Verbindungszeichenfolgen und Wallets.

  • Wallet-basierte Verbindungen: Sie müssen ein Wallet herunterladen und eine Verbindung mit den Verbindungszeichenfolgen aus der Primärdatenbank, der aktuellen Primärdatenbank, herstellen, um nach einem Failover oder nach einem Switchover eine Verbindung zur Datenbank herzustellen. Weitere Informationen finden Sie unter Regionsübergreifende Disaster-Recovery-Verbindungszeichenfolgen und Wallets.

  • Autonomous Database Tools: Die Tools haben nach einem Failover oder nach einem Switchover abweichende URLs in der Primärdatenbank (bei einem Switchover oder Failover zu einer lokalen Standbydatenbank ändern sich die Tool-URLs für einen Switchover oder Failover nicht):

    • Datenbankaktionen

    • Oracle APEX

    • Oracle REST Data Services (ORDS)

    • Graph Studio

    • Oracle Machine Learning-Notizbücher

    • Datentransformationen

    • MongoDB-API

  • Oracle Cloud Infrastructure Object Storage-Nutzung: Nach dem Failover oder Switchover von der Primärdatenbank zu einer Standbydatenbank funktionieren die Zugangsdaten und URLs, die Zugriff auf Object Storage bieten, in der Primärdatenbank (der aktuellen Primärdatenbank) weiterhin wie vor dem Failover oder Switchover, sodass Zugriff auf Folgendes gewährt wird:

    • Externe Tabellen

    • Externe partitionierte Tabellen

    • Externe hybride partitionierte Tabellen

    Hinweis

    Dies gilt, wenn Object Storage verfügbar ist. Für seltene Szenarien, in denen Object Storage nicht verfügbar ist, empfiehlt Oracle, Object Storage-Backups oder -Replikationen für eine andere Region bereitzustellen. Wenn Object Storage nicht verfügbar ist (d.h. die Object Storage-Ressource, die Sie vor einem Switchover oder Failover mit der Primärdatenbank verwendet haben), können Sie Ihre Benutzerzugangsdaten und Parameter aktualisieren, die URLs für Object Storage festlegen, damit in den Parametern Werte für den Zugriff auf Object Storage einer verfügbaren Region angegeben werden. Weitere Informationen finden Sie unter Replikation verwenden.

Mandantenübergreifendes Autonomous Data Guard mit regionsübergreifender Standbydatenbank

Sie können Autonomous Data Guard mandantenübergreifend mit einer regionsübergreifenden Standbydatenbank aktivieren. Wenn Sie eine mandantenübergreifende Autonomous Data Guard-Standbydatenbank in einer anderen Region hinzufügen, stellt Autonomous Database eine regionsübergreifende Standbydatenbank im Zielmandanten bereit. Mit einer mandantenübergreifenden Autonomous Data Guard-Standbydatenbank können Sie Failover, Switchover oder eine Snapshot-Standbydatenbank mit einer regionsübergreifenden Standbydatenbank in einem anderen Mandanten erstellen. Mit diesem Feature können Sie Autonomous Data Guard verwenden, um eine Datenbank in einen anderen Mandanten zu migrieren.

Weitere Informationen finden Sie unter Autonomous Data Guard-Standbydatenbank mandantenübergreifend verwenden.

OCI Full Stack Disaster Recovery mit einer regionsübergreifenden Autonomous Data Guard-Standbydatenbank

Wenn Full Stack Disaster Recovery aktiviert ist, wird auf der Autonomous Database-Detailseite unter "Disaster Recovery" das Feld Full Stack DR als Aktiviert angezeigt.


Beschreibung von adb_full_stack_dr_enabled.png folgt
Beschreibung der Abbildung adb_full_stack_dr_enabled.png

Weitere Informationen finden Sie unter OCI Full Stack Disaster Recovery mit Autonomous Database verwenden.

Themen

Übergeordnetes Thema: Standbydatenbanken

Autonomous Data Guard-Datenbankrolle

Nachdem Sie eine regionsübergreifende Standbydatenbank hinzugefügt haben, hat jede Datenbank eine bestimmte Rolle: Primär-, Standby- oder Snapshot-Standbydatenbank.

Die Rolle gibt den aktuellen Status einer Datenbank-, Primär-, Standby- oder Snapshot-Standbydatenbank an. Dieser Wert ändert sich, nachdem Sie ein Switchover oder ein Failover ausgeführt haben oder nachdem Sie eine Standbydatenbank in eine Snapshot-Standbydatenbank konvertiert haben. Sie können die Autonomous Database-Rolle in dem Symbol anzeigen, das auf der Seite "Informationen zur autonomen Datenbank" neben dem Anzeigenamen angezeigt wird. Beispiel:

Beschreibung von adb_adg_primary.png folgt
Beschreibung der Abbildung adb_adg_primary.png

Beschreibung von adb_adg_primary.png folgt
Beschreibung der Abbildung adb_adg_standby.png

Nachdem Sie eine regionsübergreifende Standbydatenbank hinzugefügt haben, können Sie die Rolle im Bereich Disaster Recovery auf der Detailseite anzeigen. Die Rolle ist eine der folgenden:

  • Unter Rolle wird Primär in der Primärdatenbank angezeigt.

  • Nach einem Switchover oder Failover zeigt die Rolle in derselben Datenbank Standby an.

  • Nachdem Sie einen regionsübergreifenden Peer in eine Snapshot-Standbydatenbank konvertiert haben, wird die Rolle als Snapshot-Standbydatenbank angezeigt.

Um Details für einen Peer anzuzeigen, wählen Sie auf der Autonomous Database-Detailseite die Registerkarte Disaster Recovery aus. In der Liste werden die Informationen zur Peerdatenbank angezeigt. In der Spalte Peerrolle wird die Peerrolle angezeigt:

  • Standby (lokal): In der Spalte Peerrolle wird Standby angezeigt, und die Datenbank hat denselben Anzeigenamen in der Spalte Peer Autonomous Database. In der Spalte Region wird der Name der aktuellen Region angezeigt.

  • Standby (regionsübergreifend) In der Spalte Peerrolle wird Standby für eine Remotestandbydatenbank angezeigt, und die Datenbank hat denselben Namen mit der Erweiterung "_region" in der Spalte Peer Autonomous Database. Sie können auf den Link klicken, um auf die Remotedatenbank zuzugreifen. In der Spalte Region wird der Name der Remoteregion angezeigt.

    Wenn Sie den regionsübergreifenden Peer vor der Einführung der Unterstützung für mehrere regionsübergreifende Peers erstellt haben, hat der Anzeigename des regionsübergreifenden Peers die Erweiterung "_Remote".

  • Snapshot-Standby: In der Spalte Peer-Rolle wird Snapshot-Standby angezeigt. In der Spalte Region wird der Name der Remoteregion angezeigt.

Regionsübergreifendes Failover und Switchover von Autonomous Data Guard

Sie können einen lokalen Disaster-Recovery-Peer verwenden und optional einen oder mehrere regionsübergreifende Peers hinzufügen (mehrere regionsübergreifende Peers sind mit dem ECPU-Compute-Modell zulässig). In lokalen und regionsübergreifenden Fällen kann ein Peer eine backupbasierte Disaster-Recovery-Kopie oder eine Autonomous Data Guard-Standbydatenbank sein.

Wenn sowohl eine aktuelle Region als auch mindestens eine regionsübergreifende Autonomous Data Guard-Peerdatenbank vorhanden ist, haben Sie je nach Status der Primärdatenbank die folgenden Optionen:

  • Wenn Sie die Primärdatenbank ausfallen und die lokale Standbydatenbank verfügbar ist, führt Autonomous Data Guard automatisch ein Failover durch, um die lokale Standbydatenbank mit minimaler Unterbrechung zu der Primärdatenbank umzuwandeln. Nach Abschluss des Failovers erstellt Autonomous Data Guard eine neue lokale Standbydatenbank. Wenn kein automatischer Failover möglich ist, können Sie einen manuellen Failover durchführen.

    Autonomous Data Guard verwendet weiterhin dieselben regionsübergreifenden Peerdatenbanken.

  • Wenn Ihre Primärdatenbank ausfällt und die lokale Standbydatenbank nicht verfügbar ist, können Sie einen manuellen Failover zu einer regionsübergreifenden Peerdatenbank durchführen und die regionsübergreifende Peerdatenbank, die Sie per Failover zur Primärdatenbank machen.

    In diesem Fall erstellt Autonomous Data Guard nach Abschluss des Failovers keine neue lokale Standbydatenbank (standardmäßig haben Sie einen Backupkopie-Peer).

  • Sie können einen Switchover-Vorgang ausführen, bei dem die Primärdatenbank zur lokalen Standbydatenbank wird und die lokale Standbydatenbank zur Primärdatenbank.

    Autonomous Data Guard verwendet weiterhin dieselben regionsübergreifenden Peerdatenbanken.

  • Sie können einen Switchover-Vorgang ausführen, bei dem eine regionsübergreifende Peerdatenbank zur primären Datenbank wird (und die Primärdatenbank als neue Standbydatenbank neu erstellt wird, sodass sie zu einer Peerdatenbank wird).

    Ein Switchover ändert die Rollen der primären und einer Peerdatenbank. Wenn Sie zwei Mal einen Switchover zwischen denselben beiden Remote-Regionen durchführen, wird die primäre Datenbank wieder die primäre Datenbank.

Autonomous Data Guard-Datenbank - Regionsübergreifendes Backup und Wiederherstellung

Nachdem Sie eine regionsübergreifende Standbydatenbank von Autonomous Data Guard hinzugefügt haben, werden Backups und Die Wiederherstellung aus Backups wie folgt abgewickelt:

  • Wenn die Primärdatenbank aus einem Backup wiederhergestellt wird, wird aus der wiederhergestellten Primärdatenbank eine neue Remotestandbydatenbank erstellt.

  • Automatische Backups werden nur für die Primärdatenbank erstellt (die Datenbank mit Rolle: Primär). Beispiel: Nach einem Switchover oder Failover übernimmt die Datenbank mit der Rolle Primär die Ausführung automatischer Backups. Eine Datenbank mit der Rolle Standby erstellt keine Backups mehr. Wenn Sie das Switchover erneut ausführen, beginnt die Datenbank, die zur primären Rollendatenbank wird, erneut Backups zu erstellen.

  • Sie können ein Backup nicht wiederherstellen oder klonen, wenn eine Peerdatenbank die Rolle Standby aufweist. Backups werden nur in der Datenbank mit der Rolle Primär erstellt. Die Wiederherstellung ist über die Oracle Cloud Infrastructure-Konsole in einer Standbydatenbank nicht verfügbar.

Regionsübergreifende Disaster-Recovery-Verbindungszeichenfolgen und Wallets

Wenn Sie eine regionsübergreifende (Remote-)Standbydatenbank von Autonomous Data Guard hinzufügen oder einen regionsübergreifenden Backup-basierten Disaster-Recovery-Peer verwenden, enthalten das Wallet und die Verbindungszeichenfolge aus der Primärdatenbank nur den Hostnamen der Primärdatenbank.

Darüber hinaus enthalten das Wallet und die Verbindungszeichenfolge einer Remote-Peer-Datenbank nur den Hostnamen der Remote-Datenbank. Dies gilt sowohl für Instanz- als auch für regionale Wallets.

Oracle empfiehlt, dass Sie Ihre Anwendungen, die in der Primärrollendatenbank ausgeführt werden, so konfigurieren, dass sie das Wallet oder die Verbindungszeichenfolge verwenden, die aus der Primärdatenbank heruntergeladen wurde. Verwenden Sie für Anwendungen, die auf einer Remotedatenbank ausgeführt werden, das Wallet oder die Verbindungszeichenfolge, die von der Remotedatenbank heruntergeladen wurde (wobei die Remotedatenbank die aktuelle Primärdatenbank nach einem Failover oder nach einem Switchover ist). Sie können diese Verbindungszeichenfolgen oder das Wallet abrufen, indem Sie in der Oracle Cloud Infrastructure-Konsole auf Datenbankverbindung klicken.

Beispiel: Wenn Ihr regionsübergreifender Autonomous Data Guard mit der Primärdatenbank in Ashburn (IAD) und einer regionsübergreifenden Standbydatenbank in Phoenix (PHX) eingerichtet ist, empfiehlt Oracle, dass Ihre Mid-Tier-Anwendungen, die in IAD ausgeführt werden, Verbindungszeichenfolge oder Wallet aus der Primärdatenbank in IAD und den entsprechenden Anwendungen, die nach einem Failover oder nach einem Switchover in PHX ausgeführt werden, verwenden Sie die Verbindungszeichenfolge oder das Wallet aus der Standbydatenbank in PHX. Beim regionalen Failover oder Switchover empfiehlt Oracle, für optimale Performance und zur Minimierung der regionsübergreifenden Latenz sowohl die Datenbank als auch die Mid-Tier-Anwendungen auf die neue Primärrollendatenbank zu übertragen.

Weitere Informationen finden Sie unter Clientzugangsdaten (Wallets) herunterladen.

Wenn Ihre Anwendung dies erfordert, können Sie manuell Verbindungszeichenfolgen erstellen, die sowohl primäre als auch Remote-Datenbankhostnamen enthalten, um die Verbindung zu einer Instanz zu unterstützen, die verfügbar ist und automatisch für Verbindungen geöffnet ist, zur primären oder Remote-Datenbank.

Einzelheiten zu den Schritten zum manuellen Erstellen dieser Verbindungszeichenfolgen finden Sie unter:

Autonomous Data Guard mit vom Kunden verwalteten Schlüsseln

Wenn Sie eine regionsübergreifende Autonomous Data Guard-Standbydatenbank hinzufügen, sollten Sie besondere Überlegungen anstellen, wenn die Primärdatenbank vom Kunden verwaltete Schlüssel verwendet oder wenn Sie zu vom Kunden verwalteten Schlüsseln in der Primärdatenbank wechseln möchten.

Hinweis

Autonomous Database unterstützt mehrere vom Kunden verwaltete Schlüsselprovider. Nur Oracle Cloud Infrastructure Vault wird für die Verwendung mit Autonomous Data Guard unterstützt. Andere Vaults werden für vom Kunden verwaltete Schlüssel nicht unterstützt.

Damit eine Remotestandbydatenbank denselben Masterverschlüsselungsschlüssel wie die Primärdatenbank verwenden kann, muss der Masterverschlüsselungsschlüssel in der Remoteregion repliziert werden. Vom Kunden verwaltete Verschlüsselungsschlüssel werden nur mit einer einzelnen regionsübergreifenden Autonomous Data Guard-Standbydatenbank unterstützt. Mehrere regionsübergreifende Standbydatenbanken werden nicht unterstützt, da Oracle Cloud Infrastructure Vault nur die Replikation in einer Remoteregion unterstützt.

Betrachten Sie die folgenden Fälle:

  • Das Hinzufügen einer Autonomous Data Guard-Remotestandbydatenbank ist zulässig, wenn Autonomous Database vom Kunden verwaltete Schlüssel verwenden. Wenn die Datenbank einen vom Kunden verwalteten Schlüssel verwendet und Sie eine regionsübergreifende Autonomous Data Guard-Standbydatenbank hinzufügen, werden in der Liste Region im Dialogfeld Peerdatenbank hinzufügen nur die Regionen angezeigt, die den replizierten Vault und die Schlüssel enthalten. Wenn keine Remoteregion aufgeführt wird, müssen Sie den Vault und die Schlüssel in der Region replizieren, in der Sie die Standbydatenbank verwenden möchten (dies muss eine gekoppelte Region sein).

  • Der Wechsel zu vom Kunden verwalteten Schlüsseln ist in der Primärdatenbank zulässig, wenn Sie über eine regionsübergreifende Autonomous Data Guard-Standbydatenbank verfügen. Wenn die Datenbank von Oracle verwaltete Schlüssel verwendet und Sie zu vom Kunden verwalteten Schlüsseln in der Primärdatenbank wechseln, werden nur die Schlüssel angezeigt, die sowohl in der Primär- als auch in der Standbyregion repliziert werden. In den Listen "Verschlüsselungsschlüssel verwalten" Vault und Masterverschlüsselungsschlüssel werden nur Vaults und Schlüssel angezeigt, die sowohl in der Primär- als auch in der Standbyregion repliziert werden. Wenn ein Schlüssel nicht aufgeführt wird, replizieren Sie den Vault und die Schlüssel in einer gekoppelten Region.

In den folgenden Themen finden Sie weitere Informationen:

Backups in einer regionsübergreifenden Autonomous Data Guard-Standbydatenbank replizieren

Wenn Sie eine regionsübergreifende Autonomous Data Guard-Standbydatenbank hinzufügen, können Sie die regionsübergreifende Backupreplikation aktivieren, sodass automatische Backups aus der Primärdatenbank auch in einer Remoteregion verfügbar sind.

Standardmäßig werden die Backups, die in der Primärdatenbank erstellt werden, nicht in einer regionsübergreifenden Standbydatenbank repliziert. Wenn Sie die regionsübergreifende Backupreplikation aktivieren, werden bis zu 7 Tage automatische Backups für die Primärdatenbank in einer regionsübergreifenden Standbydatenbank repliziert. Wenn dieses Feature aktiviert ist, sind automatische Backups wie folgt in der Remoteregion verfügbar:

  • Nach einem Switchover oder Failover können Sie einen beliebigen Zeitstempel in den letzten sieben (7) Tagen oder einen beliebigen Zeitstempel im angegebenen Aufbewahrungszeitraum wiederherstellen oder klonen, wenn der Aufbewahrungszeitraum auf weniger als sieben Tage festgelegt ist.

  • Alle Backups für die Primärdatenbank, die in der Remoteregion repliziert werden, werden im Peer der Remoteregion nach sieben Tagen oder nach der Aufbewahrungsfrist nach Tagen gelöscht, wenn der Aufbewahrungszeitraum auf weniger als sieben Tage festgelegt ist.

  • Sie können den Backupaufbewahrungszeitraum für replizierte Backups nicht ändern, es sei denn, Sie ändern den Backupaufbewahrungszeitraum in der Primärdatenbank, um einen Wert kleiner als sieben Tage anzugeben. In diesem Fall entspricht der Aufbewahrungszeitraum für replizierte Backups in der Remoteregion dem Aufbewahrungszeitraum für automatische Backups, der in der Primärdatenbank festgelegt ist.

Für die regionsübergreifende Backupreplikation fallen zusätzliche Kosten an. Weitere Informationen finden Sie unter Oracle Autonomous Database Serverless - Features - Abrechnung.

Weitere Informationen finden Sie unter Regionsübergreifende Standbydatenbank hinzufügen und Backupreplikation für eine vorhandene regionsübergreifende Standbydatenbank aktivieren oder deaktivieren.

Beachten Sie Folgendes für die regionsübergreifende automatische Backupreplikation:

  • Nach einem Switchover oder Failover werden Backups in der aktuellen Primärdatenbank erstellt und in der aktuellen (Remote-)Standbydatenbank repliziert, während die regionsübergreifende Datenbank in der Primärrolle ist.

  • In einer Remoteregion können Sie einen Klon aus einem replizierten Backup erstellen, während die Datenbank die Rolle Standby aufweist.

Regionsübergreifende BYOL-Lizenzierung für Autonomous Data Guard

Das BYOL-ECPU-Limit, das Sie in einer Autonomous Data Guard-Primärdatenbank festlegen, gilt nicht für eine regionsübergreifende oder mandantenübergreifende Autonomous Data Guard-Standbydatenbank.

In einer regionsübergreifenden oder mandantenübergreifenden Standbydatenbank können Sie das BYOL-ECPU-Limit nach Bedarf unabhängig festlegen. Wenn Sie einen Wert für das BYOL-Lizenzlimit festlegen, wird begrenzt, wie viele ECPUs von BYOL-Lizenzen abgedeckt werden.

Beispiel: Eine autonome Data Guard-Primärdatenbank mit 8 ECPUs mit BYOL-Lizenzierung. Wenn Sie eine regionsübergreifende oder mandantenübergreifende Standbydatenbank hinzufügen, übernimmt die Standbydatenbank ihre Lizenzierung von der Primärdatenbank (mit BYOL-Lizenzierung).

Wenn Sie in diesem Beispiel das BYOL-Lizenzlimit für die Primärdatenbank auf 4 (ECPUs) setzen, verwenden 4 der 8 ECPUs die BYOL-Lizenzierung. Das BYOL-Lizenzlimit, das Sie für die Primärdatenbank festlegen, gilt jedoch nicht für regions- oder mandantenübergreifende Standbydatenbanken. Die Standbydatenbank verwendet die BYOL-Lizenzierung (Bring your own License) (ohne BYOL-Lizenzlimit). Wenn Sie ein BYOL-Lizenzlimit in der Standbydatenbank separat festlegen, z.B. wenn Sie den Wert für BYOL-Lizenzlimit auf 2 (ECPUs) setzen, werden 2 ECPUs in der Standbydatenbank mit BYOL-Lizenzierung und 6 ECPUs abgerechnet. Das BYOL-ECPU-Limit, das Sie in der Standbydatenbank festlegen, wirkt sich nicht auf das BYOL-ECPU-Limit der Primärdatenbank aus.

Weitere Informationen finden Sie unter Bring Your Own License-Option beim Provisioning oder Klonen auswählen und Bring Your Own License in Autonomous Database (ECPU-Compute-Modell) auswählen.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) in Autonomous Data Guard

Autonomous Data Guard überwacht die Primärdatenbank. Wird die Instanz heruntergefahren, übernimmt die lokale Standbyinstanz gemäß dem Recovery Time Objective (RTO) und Recovery Point Objective (RPO) die Rolle der Primärinstanz.

Wenn keine lokale Autonomous Data Guard-Standbyinstanz verfügbar ist und Sie regionsübergreifendes Disaster Recovery aktiviert haben, können Sie manuell ein Failover zur regionsübergreifenden Standbydatenbank ausführen.

Wenn Sie keine regionsübergreifende Autonomous Data Guard-Standbydatenbank hinzufügen, können Sie einen regionsübergreifenden Backup-basierten Disaster-Recovery-Peer hinzufügen. Weitere Informationen zu RTO und RPO mit Backup-Based Disaster Recovery finden Sie unter Backup-Based Disaster Recovery Time Objective (RTO) und Recovery Point Objective (RPO).

Das RTO ist die maximale Zeit, die für die Wiederherstellung der Datenbankkonnektivität mit einer Standbydatenbank erforderlich ist, nachdem ein manueller oder automatischer Failover initiiert wurde. Das RPO ist die maximale Dauer des potenziellen Datenverlusts auf der Primärdatenbank.

Lokale Autonomous Data Guard-Standbydatenbank

Wenn Sie eine lokale Standbydatenbank hinzufügen, stellt Autonomous Data Guard die folgenden Optionen für Failover oder Switchover bereit:

  • Automatisches Failover oder Switchover:

    Wenn Sie Autonomous Data Guard aktivieren, können Sie ein Datenverlustlimit auswählen. Der standardmäßige Datenverlustgrenzwert für automatisches Failover beträgt 0 (gültige Werte sind 0 bis 3600 Sekunden). Beispiel: Ein Datenverlustgrenzwert von 0 bedeutet, dass Autonomous Data Guard nur automatisches Failover ausführt, wenn kein Datenverlust auftritt. Das heißt, wenn Autonomous Data Guard prüfen kann, ob kein Datenverlust vorliegt, wird bei einem Problem automatisch ein Failover durchgeführt. Wenn ein Problem auftritt und Autonomous Data Guard feststellt, dass der mögliche Datenverlust größer ist als das Datenverlustlimit, erfolgt kein automatisches Failover, und Sie haben die Möglichkeit, ein manuelles Failover auszuführen.

  • Manueller Failover: Das RTO beträgt zwei (2) Minuten und das RPO 10 Sekunden.

Regionsübergreifende Autonomous Data Guard-Standbydatenbank

Wenn Sie eine regionsübergreifende Standbydatenbank hinzufügen, lauten die RTO- und RPO-Zahlen für den Failover zur regionsübergreifenden Autonomous Data Guard-Standbydatenbank wie folgt:

  • Switchover: Das RTO ist weniger als zehn (10) Minuten und das RPO ist null (0).

  • Automatischer Failover: Nicht verfügbar

  • Manueller Failover: Das RTO beträgt weniger als zehn (10) Minuten und das RPO bis zu einer (1) Minute.

In den folgenden Themen finden Sie weitere Informationen:

Übergeordnetes Thema: Standbydatenbanken

Autonomous Data Guard-Vorgänge

Autonomous Data Guard bietet eine Reihe von Vorgängen zum Verwalten einer Standbydatenbank, darunter: Aktivieren, Switchover, Trennen oder Beenden einer Standbydatenbank.

Arbeitsvorgang Beschreibung
In Snapshots-Standbydatenbank konvertieren

Wenn Sie einen Disaster-Recovery-Peer in eine Snapshot-Standbydatenbank konvertieren, wird die Datenbank im Lese-/Schreibmodus geöffnet, und der regionsübergreifende Disaster-Recovery-Peer stoppt vorübergehend die Aktualisierung von Daten aus der Quelldatenbank.

Weitere Informationen finden Sie unter Regionsübergreifendes Peer zu Snapshot-Standby konvertieren.

Autonomous Data Guard deaktivieren

Wenn Sie eine lokale Standbydatenbank oder eine regionsübergreifende Standbydatenbank haben, können Sie den Disaster-Recovery-Typ in "Backupbasiertes Disaster Recovery" für die lokale Standbydatenbank ändern oder eine regionsübergreifende Standbydatenbank beenden. Wenn Sie Autonomous Data Guard deaktivieren, wird die Standbydatenbank beendet.

Weitere Informationen finden Sie unter Standby aktualisieren, um einen Backupkopie-Peer zu verwenden oder Regionsübergreifende Standbydatenbank deaktivieren.

Standby trennen

Wenn Sie eine regionsübergreifende Standbydatenbank trennen, wird die Verknüpfung der Standbydatenbank mit der primären Datenbank aufgehoben. Dadurch wird die Datenbank von einer Peerdatenbank in eine Standalone-Datenbank konvertiert. Nach dem Trennvorgang können Sie die Verbindung zur Primärdatenbank nicht erneut herstellen.

Weitere Informationen finden Sie unter Peerdatenbank trennen und Snapshot-Standbydatenbank trennen.

Autonomous Data Guard aktivieren

Wenn Sie backupbasiertes Disaster Recovery verwenden, können Sie den Disaster-Recovery-Typ in lokalen (aktuellen) Autonomous Data Guard aktualisieren oder eine regionsübergreifende Autonomous Data Guard-Standbydatenbank hinzufügen.

Weitere Informationen finden Sie unter Autonomous Data Guard aktivieren und Regionsübergreifende Standbydatenbank hinzufügen.

Failover - Automatisch

Nachdem Sie eine lokale Autonomous Data Guard-Standbydatenbank hinzugefügt haben, überwacht das System die Primärinstanz und führt automatisch in bestimmten Szenarios einen Failover auf eine lokale Standbydatenbank aus.

Weitere Informationen finden Sie unter Automatischer Failover mit Standbydatenbank.

Failover - Manuell

Wenn die Primärdatenbank nicht verfügbar ist, können Sie einen manuellen Failover durchführen, um die Rollen zu ändern, und eine Standbydatenbank zur Primärdatenbank zu machen:

  • Wenn eine lokale Standbydatenbank verfügbar ist, können Sie einen manuellen Failover zur lokalen Standbydatenbank vornehmen (Sie haben keinen Failover zur Standbydatenbank einer Remoteregion, wenn eine lokale Standbydatenbank verfügbar ist).
  • Wenn eine lokale Standbydatenbank nicht verfügbar ist, können Sie manuell ein Failover zu einer Remotestandbydatenbank durchführen.

Weitere Informationen finden Sie unter Manuelles Failover ausführen.

Switchover

Wenn Autonomous Data Guard aktiviert ist, ändert ein Switchover die Rollen der Primärdatenbank und der Standbydatenbank. Die Standbydatenbank wird zur Primärdatenbank, und die Primärdatenbank wird zur Standbydatenbank. Wenn Sie sowohl eine lokale Standbydatenbank (aktuelle Region) als als auch eine regionsübergreifende Standbydatenbank (remote) haben, können Sie entweder ein Switchover zur lokalen Standbydatenbank oder zur Remotestandbydatenbank durchführen.

Weitere Informationen finden Sie unter Switchover ausführen.

Beenden

Wenn Sie die Primärinstanz beenden möchten, wählen Sie Weitere Aktion und Beenden aus. Durch Beenden der Primärinstanz wird auch eine lokale Standbydatenbank beendet.

Wenn sowohl eine lokale Standbydatenbank (aktuelle Region) als auch eine regionsübergreifende Standbydatenbank vorhanden ist, müssen Sie die regionsübergreifende Standbydatenbank beenden, bevor Sie die Primärdatenbank beenden.

Weitere Informationen finden Sie unter Regionsübergreifende Standbydatenbank beenden.

Übergeordnetes Thema: Standbydatenbanken

Disaster-Recovery-Status von Autonomous Database

Autonomous Database bietet Informationen zum Disaster Recovery-Status auf der Seite "Autonomous Database-Details".

Gehen Sie im Bereich Disaster Recovery wie folgt vor:

Im Feld Rolle wird die Rolle der aktuellen Datenbank wie folgt angezeigt:

  • Wenn Sie entweder einen lokalen Backupkopie-Peer oder eine lokale Autonomous Data Guard-Standbydatenbank haben, wird in der Oracle Cloud Infrastructure-Konsole der Feldwert Rolle Primär angezeigt. Autonomous Database bietet keinen Zugriff auf eine lokale Standbydatenbank (oder einen lokalen Backupkopie-Peer).

  • Wenn Sie einen regionsübergreifenden Backupkopie-Peer oder eine regionsübergreifende Autonomous Data Guard-Standbydatenbank verwenden, wird in der Oracle Cloud Infrastructure-Konsole der Wert Rolle im Feld Primär angezeigt, wenn Sie die Primärdatenbank anzeigen. Wenn Sie die Details für eine Standbydatenbank anzeigen, wird Standby angezeigt.

  • Switchover: Stellt einen Link bereit, mit dem Sie einen Switchover-Vorgang ausführen können.

  • Failover: Wenn die Primärdatenbank nicht verfügbar ist, eine lokale Standbydatenbank vorhanden ist und ein automatischer Failover nicht erfolgreich war, können Sie mit dem Failover-Link einen manuellen Failover initiieren.

    Wenn die Primärdatenbank nicht verfügbar, eine regionsübergreifende Standbydatenbank vorhanden und ein Failover zu einer lokalen Standbydatenbank nicht möglich ist, können Sie mit dem Failover-Link einen manuellen Failover zur Remotestandbydatenbank initiieren.

Um die Peer-Autonomous Database-Informationen anzuzeigen, wählen Sie auf der Seite "Autonomous Database-Details" die Registerkarte Disaster Recovery aus. Dadurch werden die Peer-Autonomous Database-Informationen angezeigt. Im Feld Status wird der Status der Standbydatenbank wie folgt angezeigt:

  • Provisioning

    • Dieser Status wird angezeigt, wenn Sie Autonomous Data Guard aktivieren, und gibt an, dass eine Standbydatenbank bereitgestellt wird (bis der Status der Standbydatenbank in Standby geändert wird).

    • Dieser Status wird nach einem Failover zu einer lokalen Standbydatenbank angezeigt, wenn eine lokale Standbydatenbank neu erstellt wird.

    • Dieser Status wird angezeigt, wenn eine Wiederherstellung aus einem Backup in der Primärdatenbank ausgeführt, die lokale Standbydatenbank neu erstellt und in der Spalte Status "Provisioning wird ausgeführt" angezeigt wird.

  • Standby: Gibt an, dass eine Standbydatenbank verfügbar und für einen Switchover- oder Failover-Vorgang bereit ist.

    Hinweis

    Wenn eine Standbydatenbank gestoppt wird, wird im Standbystatus Standby angezeigt. In einer Standbydatenbank wird nie der Status Gestoppt angezeigt.

  • Rollenänderung wird ausgeführt:: Gibt an, dass ein Failover- oder Switchover-Vorgang gestartet wurde.

Übergeordnetes Thema: Standbydatenbanken

Autonomous Data Guard-Ereignisse

Sie können mit Oracle Cloud Infrastructure-Ereignissen reagieren, wenn sich der Autonomous Database-Status aufgrund eines mit Autonomous Data Guard zusammenhängenden Ereignisses ändert, wie einem Failover- oder Switchover-Vorgang.

Zu Autonomous Database-Ereignissen gehören die Folgenden:

  • Automatisches Failover starten
  • Automatisches Failover beenden
  • Deaktivierung von Autonomous Data Guard starten
  • Aktivierung von Autonomous Data Guard starten
  • Failover starten
  • Switchover starten
  • Deaktivierung von Autonomous Data Guard beenden
  • Aktivierung von Autonomous Data Guard beenden
  • Failover mit Failover-Ergebnis "Erfolgreich" oder "Fehler" beenden
  • Switchover mit Switchover-Ergebnis "Erfolgreich" oder "Fehler" beenden

Auf Basis von Ereignissen können Sie Aktionen ausführen oder Benachrichtigungen senden. Weitere Informationen zur Verwendung von Ereignissen und zur Erstellung von Benachrichtigungen finden Sie unter Ereignisse und Benachrichtigungen für eine Standbydatenbank.

Übergeordnetes Thema: Standbydatenbanken