Konfiguration planen

Planen Sie die Ressourcen und die Konfiguration im primären System auf Oracle Cloud Infrastructure, bevor Sie das sekundäre System erstellen.

Snapshot Standby oder Remote-Aktualisierbaren Klon auswählen

Prüfen Sie Folgendes, um festzustellen, ob Sie einen Snapshot Standby- oder Remote-aktualisierbaren Klon verwenden möchten.

Hinweis:

Aktualisierbarer Remoteklon ist nur mit Oracle Autonomous Database Serverless verfügbar.

Wenn Sie Oracle Autonomous Database on Dedicated Exadata Infrastructure verwenden, verwenden Sie das Snapshot Standbyfeature für das Setup und den Lebenszyklus. Oracle Autonomous Database on Dedicated Exadata Infrastructure implementiert das Feature für einen aktualisierbaren Remoteklon nicht.

Wenn Sie Oracle Autonomous Database Serverless verwenden, können Sie den Remoteaktualisierbaren Klon oder die Snapshot-Standbyfunktion für das Setup und den Lebenszyklus verwenden. Beachten Sie bei der Entscheidung Folgendes:

Snapshot Standby

Vorteile:
- Die Einrichtungs- und Lebenszyklusvorgänge sind einfacher. Sie müssen das Wallet nicht sekundär ändern, wenn Sie die Standbydatenbank in einen Snapshot oder zurück in eine physische Standbydatenbank konvertieren.
- Für die Snapshot Standby-Datenbank ist keine zusätzliche Datenbank in der Standby-Region erforderlich. Es gibt nur die Standbydatenbank, die Sie in einen Snapshot und zurück in eine physische Standbydatenbank konvertieren können.
- Wenn Sie die Standbydatenbank in der Snapshot Standby-Datenbank zur Validierung der sekundären Datenbank verwenden, verwenden Sie wirklich dieselbe autonome Datenbank, die Sie bei einem Switchover verwenden. Daher ist Ihre Validierung hinsichtlich der Konnektivität realistischer, da Sie dasselbe Wallet verwenden, das Sie im Falle eines Switchovers verwenden.
Nachteile:
- Während sich die Standbydatenbank im Snapshot-Standbymodus befindet, empfängt die Standbydatenbank zwar die redo von der primären Datenbank, ist sie jedoch nicht anwendbar. Wenn Sie beim Testen der sekundären Datenbank ein dringendes Failover oder Switchover ausführen müssen, müssen Sie es zuerst in die physische Standbydatenbank konvertieren, damit sie mit der primären Datenbank synchronisiert wird. Dies kann zu Verzögerungen bei der Switchover-Zeit führen.

Remote-Aktualisierbaren Klon

Vorteile:
- Der remote aktualisierbare Klon ist eine separate autonome Datenbank. Sie interagieren nicht direkt mit der Standbydatenbank, wenn Sie die Standby-Middle Tier einrichten oder wenn Sie die sekundäre Datenbank während des Lebenszyklus testen.
Nachteile:
- Da es sich um eine separate autonome Datenbank handelt, wird sie als zusätzliche autonome Datenbankinstanz abgerechnet.
- Setup- und Lebenszyklusvorgänge sind komplexer. Sie müssen das Wallet jedes Mal zwischen der reellen Standbydatenbank und dem entfernten aktualisierbaren Klon wechseln, um auf einen oder anderen zu verweisen.

Die Wahl eines oder eines anderen Ansatzes zwingt Sie nicht, während des gesamten Lebenszyklus des Systems denselben Ansatz zu verwenden. Solange Sie die entsprechenden Schritte ausführen, können Sie während des Lebenszyklus einen anderen Ansatz verwenden als den Ansatz, den Sie für das Disaster Recovery-Setup verwenden. Sie können für einige Vorgänge auch eine Snapshot Standby-Datenbank mit aktualisierbaren Klonen für andere Tests kombinieren. Beispiel: Verwenden Sie Snapshot für Provisioning und Workload-Prüfungen auf der sekundären Seite, verwenden Sie jedoch einen aktualisierbaren Klon für Sparse-Tests, während das System unter hoher Belastung ist. Auf diese Weise können Sie den Overhead (und mögliche Switchover-Verzögerungen) vermeiden, der durch massive redo apply bei der Konvertierung von Snapshot in physische Standbydatenbank verursacht wird.

Überlegungen zum primären System

Es wird davon ausgegangen, dass das primäre System Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace oder Oracle Fusion Middleware erstellt wird und den Oracle Autonomous Database-Service verwendet. Wenn Sie ein sekundäres System in Oracle Cloud Infrastructure (OCI) implementieren möchten, prüfen Sie die folgenden Überlegungen für das primäre System:

Privates Subnetz
Sowohl Oracle Autonomous Database als auch Oracle SOA Suite on Marketplace werden in einem privaten Subnetz abgelegt.
Privater Endpunkt bei Verwendung von Oracle Autonomous Database Serverless
Das Oracle Autonomous Database Serverless-System wird über einen privaten Endpunkt (PEP) bereitgestellt.
Oracle Cloud Infrastructure Load Balancing
Ein Frontend-OCI-Load Balancer stellt das System Oracle WebLogic Server for OCI, Oracle SOA Suite on Marketplace oder Oracle Fusion Middleware bereit.

Der OCI-Load Balancer kann je nach Clientzugriffsanforderungen öffentlich oder privat sein. Platzieren Sie für implizite High Availability-Features in Regionen mit mehreren ADs den OCI-Load Balancer in einem regionalen Subnetz.
Oracle Cloud Infrastructure-Dateispeicher
Das Oracle WebLogic Server for Oracle Cloud Infrastructure-, Oracle SOA Suite on Marketplace- oder Oracle Fusion Middleware-System DR verwendet einen Oracle Cloud Infrastructure File Storage-Mount, der von den verschiedenen Knoten in den WebLogic-Clustern gemeinsam verwendet wird. Mit dem Mount wird die Konfiguration regionsübergreifend repliziert.
- Mit dem System Oracle SOA Suite on Marketplace können Sie einen neuen Dateispeicher erstellen oder einen vorhandenen Dateispeicher wiederverwenden. Sie wird im Verzeichnis /u01/soacs/dbfs/share/ gemountet. Trotz des Namens dieses Verzeichnisses ist dies kein gemountetes Verzeichnis für Oracle Database File System (DBFS) für Oracle Autonomous Database. Stellen Sie sicher, dass Sie File Storage konfigurieren in Ihrem Oracle SOA Suite on Marketplace-Stack auswählen. Sie können die Option beim Provisioning oder nach dem Provisioning auswählen.
- Mit dem Oracle WebLogic Server for Oracle Cloud Infrastructure-System können Sie einen neuen Dateispeicher erstellen oder vorhandenen Dateispeicher wiederverwenden (im Verzeichnis /u01/shared eingehängt). Stellen Sie sicher, dass Sie Dateisystem hinzufügen in den Oracle WebLogic Server for OCI-Stacks auswählen. Sie können die Option beim Provisioning oder nach dem Provisioning auswählen.
- Bei anderen Services müssen Sie den OCI File Storage-Mount möglicherweise sowohl auf dem primären als auch auf dem sekundären Middle Tier-Knoten manuell erstellen. Wenn Sie Oracle WebLogic Server for Oracle Cloud Infrastructure oder Oracle SOA Suite on Marketplace nicht verwenden, finden Sie in der Dokumentation zu OCI File Storage weitere Informationen und Schritte zum Erstellen des Speichers.