Info zu Oracle Data Guard

Sie können Oracle Data Guard in einem DB-System nutzen. Oracle Data Guard gewährleistet High Availability, Datenschutz und Disaster Recovery für Unternehmensdaten.

Weitere Informationen über Oracle Data Guard finden Sie unter Einführung in Oracle Data Guard.

Erforderliche IAM-Policy

Um Oracle Cloud Infrastructure verwenden zu können, muss einem Administrator der Sicherheitszugriff in einer Policy erteilt werden. Dieser Zugriff ist unabhängig davon erforderlich, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Meldung erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Administrator, welcher Zugriffstyp Ihnen zugewiesen wurde und in welchem Compartment Sie arbeiten sollen.

Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter Erste Schritte mit Policys und Allgemeine Policys.

Allgemeine Informationen

Für die Oracle Data Guard-Konfiguration sind mindestens zwei Datenbanken erforderlich: eine mit der Primär- und eine mit der Standbyrolle. Die Primär- und die Standbydatenbank bilden zusammen eine Data Guard-Konfiguration. Die meisten Anwendungen greifen auf die Primärdatenbank zu. Eine Standbydatenbank ist eine Kopie der Primärdatenbank, die in allen Transaktionen mit der Primärdatenbank übereinstimmt.

Die Data Guard-Gruppe bietet die Möglichkeit, mehrere lokale und Remote-Standbydatenbanken zu erstellen und zu verwalten, die mit einer Primärdatenbank verknüpft sind. Dies bietet Flexibilität für Datenschutz und Disaster Recovery. In einer Data Guard-Gruppe kann eine Primärdatenbank bis zu sechs Standbydatenbanken unterstützen.

Die Standbydatenbank wird von Oracle Data Guard verwaltet, indem Redo-Daten aus der Primärdatenbank übertragen und angewendet werden. Wenn die Primärdatenbank nicht mehr verfügbar ist, können Sie mit Data Guard der Standbydatenbank pro Switchover oder Failover die Primärrolle zuweisen. Dies gilt auch dann, wenn mehrere Standby-Datenbanken vorhanden sind.

• Switchover: Mit einem Switchover werden die Rollen der Primär- und Standbydatenbank umgekehrt.
• Failover: Bei einem Failover wird der Standbydatenbank die Primärrolle zugewiesen, wenn die vorhandene Primärdatenbank ausfällt oder nicht mehr erreichbar ist.
• Neu instanziieren: Damit wird eine Datenbank in einer Data Guard-Konfiguration wieder in der Standbyrolle instanziiert.

In einer typischen Data Guard-Konfiguration werden häufig zwei Standbydatenbanken verwendet:

• Lokale Standbydatenbank: Eine Standbydatenbank in derselben Region wie die Produktionsdatenbank eignet sich ideal für Failover-Szenarios und bietet keinen Datenverlust für lokale Fehler (wie Datenbank-, Cluster- oder Availability-Domainfehler). Die Auswirkungen auf das Anwendungs-Failover werden in diesem Fall reduziert, da Anwendungen ohne den Performance-Overhead für die Kommunikation mit einer Remoteregion weiterarbeiten.
• Remote-Standbydatenbank (regionsübergreifend): Eine Remote-Standbydatenbank, die sich in einer anderen Region befindet, wird in der Regel für Disaster Recovery oder zum Auslagern der schreibgeschützten Abfrageverarbeitung verwendet. Ein Remote-Standbydatenbanksetup gewährleistet den Datenschutz vor regionalen Ausfällen.

Einige Unternehmenskunden streben nach einem Standortwechsel Symmetrie an. Beispiel: Sie bevorzugen sowohl die primäre als auch die lokale Standbydatenbank in Region 1 als auch eine Remote-Standbydatenbank mit eigener lokaler Standbydatenbank in Region 2. In dieser Konfiguration gibt es drei Standby-Datenbanken. Nach einem Site-Switch sind weiterhin eine Primärdatenbank und eine lokale Standbydatenbank in der neuen primären Region verfügbar.

Darüber hinaus können Sie ihre Konfigurationen verbessern, indem Sie eine weitere Standbydatenbank zu Testzwecken hinzufügen und unsere Snapshot-(Lese-/Schreib-)Standbyfunktionen nutzen.

Eine Data Guard-Konfiguration erfordert mindestens zwei DB-Systeme: eines für die Primärdatenbank und eines für die Standbydatenbank. Wenn Sie Data Guard für eine Datenbank aktivieren, wird ein neues DB-System mit der Standbydatenbank erstellt und mit der Primärdatenbank verknüpft.

Weitere Anforderungsdetails:

• Die Datenbankversionen und -editionen müssen identisch sein. Bei 26ai-Datenbanken müssen sich die Primär- und die Standbydatenbank auf derselben Major Release-Version befinden, während sich die Standbydatenbank auf einer höheren Minor-Version befinden kann.
• Data Guard unterstützt nicht Oracle Database Standard Edition. (Active Data Guard erfordert Enterprise Edition Extreme Performance.)
• Jede Datenbank in einer Data Guard-Konfiguration muss einen eindeutigen Namen (DB_UNIQUE_NAME) aufweisen, die nicht von anderen Datenbanken in den DB-Systemen verwendet wird, in denen die Data Guard-Konfiguration gespeichert ist. Die Primär- und die Standbydatenbank können jedoch denselben Wert für den Datenbanknamen DB_NAME verwenden.
• Die Datenbankedition bestimmt, ob Active Data Guard (ADG) verwendet werden kann. ADG ist nur mit Enterprise Edition Extreme Performance verfügbar. Wenn Sie das BYOL-Lizenzmodell verwenden und Ihre Lizenz ADG nicht umfasst, müssen Sie sicherstellen, dass ADG bei der Konfiguration von Data Guard für Enterprise Edition Extreme Performance nicht aktiviert ist. Alternativ können Sie Enterprise Edition oder Enterprise Edition High Performance verwenden, wodurch ADG nicht standardmäßig aktiviert wird. Siehe Oracle Data Guard mit der Datenbank-CLI verwenden.
• Wenn sich die Primär- und die Standbydatenbank in derselben Region befinden, müssen beide dasselbe virtuelle Cloud-Netzwerk (VCN) verwenden.
• Wenn sich die Primär- und die Standbydatenbank in unterschiedlichen Regionen befinden, müssen Sie Peering der virtuellen Cloud-Netzwerke (VCNs) für jede Datenbank konfigurieren. Siehe Remote-VCN-Peering mit einem RPC.
• Die Primär- und die Standbydatenbank können sich in einer anderen Region befinden, müssen sich jedoch in derselben Realm befinden.
• Das SYS-Kennwort und das TDE-Wallet-Kennwort der Primär- und der Standbydatenbank müssen identisch sein.
• Ein regionsübergreifendes Data Guard wird auch unterstützt, wenn die Datenbank OCI Vault für TDE-Schlüssel verwendet.

• Konfigurieren Sie die Ingression- und Egress-Regeln für die Sicherheitsliste für die Subnetze der DB-Systeme in einer Data Guard-Konfiguration, damit TCP-Traffic zwischen den betreffenden Ports fließend kann. Stellen Sie sicher, dass die von Ihnen erstellten Regeln zustandsbehaftet sind (Standardwert).

  Beispiel: Wenn das Subnetz des Primär-DB-Systems das Quell-CIDR 10.0.0/24 und das Subnetz des Standby-DB-Systems das Quell-CIDR 10.0.1.0/24 verwendet, erstellen Sie Regeln wie im folgenden Beispiel dargestellt. Beachten Sie, dass anhand der Egress-Regeln im Beispiel nur gezeigt wird, wie TCP-Traffic für Port 1521 aktiviert wird. Das ist eine Mindestanforderung, damit Data Guard funktioniert. Wenn der TCP-Traffic bereits auf allen ausgehenden Ports (0.0.0.0/0) aktiviert ist, müssen Sie diese spezifischen Egress-Regeln nicht explizit hinzuzufügen.

• Die Standbydatenbanken in OCI sind physische Standbydatenbanken.
• Das Erstellen einer Standbydatenbank, die mit einer anderen Standbydatenbank verknüpft ist ("kaskadierende Standbydatenbank"), wird nicht unterstützt.
• Sie können eine Data Guard-Konfiguration erstellen, wenn die Datenbank mit OCI Vault verschlüsselt wird. OCI Vault unterstützt derzeit jedoch die Schlüsselreplikation nur in einer Remoteregion. Daher sind regionsübergreifende Data Guard-Konfigurationen für die Datenbanken, die OCI Vault verwenden, auf zwei Regionen beschränkt: die primäre Region und eine Remoteregion. Innerhalb dieser Regionen können mehrere Standbydatenbanken erstellt werden. Konfigurationen, die sich über drei oder mehr Regionen erstrecken, werden nicht unterstützt.

Bekannte Probleme

• In einem regionsübergreifenden Data Guard können Sie nach einem Switchover den Datenbank-KMS-Schlüssel in der neuen Primärdatenbank nicht rotieren.
• In einem regionsübergreifenden Data Guard können Sie nach einem Switchover keine PDB in der neuen Primärdatenbank erstellen.

Sicherheitsliste für Subnetz des Primär-DB-Systems

Ingress Rules:
	Stateless: No
	Source: 10.0.1.0/24
	IP Protocol: TCPSource Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.1.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Sicherheitsliste für Subnetz des Standby-DB-Systems

Ingress Rules:
	Stateless: No
	Source: 10.0.0.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.0.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Informationen zum Erstellen und Bearbeiten von Regeln finden Sie unter Sicherheitslisten.

Überlegungen zu Availability-Domains und Faultdomains für Oracle Data Guard

Oracle empfiehlt, dass sich das DB-System, das die Standbydatenbank enthält, in einer anderen Availability-Domain als das DB-System, das die Primärdatenbank enthält, um Verfügbarkeit und Disaster Recovery zu verbessern. Wenn Sie Oracle Data Guard für eine Datenbank aktivieren und sich die Standbydatenbank in derselben Availability-Domain wie die Primärdatenbank befindet (entweder auf Wunsch oder weil Sie in einer Region mit einer einzigen Availability-Domain arbeiten), empfiehlt Oracle, die Standbydatenbank in einer anderen Faultdomain als die Primärdatenbank zu platzieren.

Hinweis: Wenn Primär- und Standbydatenbank zwei Oracle RAC-Datenbanken sind und sich beide in derselben Availability-Domain befindet, kann sich nur einer der beiden Knoten der Standbydatenbank in einer Faultdomain befinden, die keine anderen Knoten der Primär- oder Standbydatenbank umfasst. Grund dafür ist, dass jede Availability-Domain nur drei Faultdomains enthält und Primär- und Standbydatenbank insgesamt vier Knoten aufweisen. Weitere Informationen zu Availability-Domains und Faultdomains finden Sie unter Regionen und Availability-Domains.