DR-Lösung mit einer Oracle Autonomous Database konfigurieren

Um die Geschäftskontinuität bei Katastrophen sicherzustellen, möchten Sie eine Disaster Recovery-(DR-)Strategie für Ihre Oracle WebLogic Suite-Anwendungen implementieren. Mit dieser Lösung erhalten Sie Datenschutz und können mit Oracle Autonomous Database schnell zum Standbysystem wechseln, ohne dass Daten und Produktivität verloren gehen.

Sie können ein Disaster Recovery-System einrichten und verwalten, das Oracle Autonomous Database als Datenbank für Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace oder einen anderen Oracle Cloud Infrastructure-(OCI-)Middle Tier-Service verwendet, der Oracle Fusion Middleware verwendet.

Oracle Autonomous Database Serverless und Oracle Exadata Database Service on Dedicated Infrastructure stellen ein Snapshot Standby-Feature bereit. Auf diese Weise können Sie die Standbydatenbank vorübergehend zum Lesen und Schreiben öffnen. Wenn Sie die Standbydatenbank in eine Snapshot-Standbydatenbank konvertieren, kann sie vollständig aktualisiert werden. Es empfängt weiterhin die redo-Daten von seiner Remote-Quelldatenbank (damit Sie noch DR-geschützt sind), wendet redo jedoch erst an, wenn es wieder in eine physische Standbydatenbank konvertiert wird. Alle in einer Snapshot-Standbydatenbank ausgeführten Änderungen werden zurückgesetzt, wenn sie erneut in eine physische Standbydatenbank konvertiert wird. Mit diesem Feature können Sie das Mid-Tier-System in der Standby-Region bereitstellen. Sie können diese Funktion auch während des Lebenszyklus Ihres DR-Systems verwenden, um das Standbysystem zu validieren, ohne einen vollständigen Switchover auszuführen.

Zusätzlich zur Snapshot Standby-Funktion stellt Oracle Autonomous Database Serverless aktualisierbare Remoteklone bereit. Dies bietet gleichwertige Funktionen wie die herkömmliche Oracle Data Guard-Snapshot-Standbydatenbankfunktionalität, jedoch mit einer zusätzlichen Datenbank. Der Remoteaktualisierbare Klon wird einzeln und separat von der Oracle Autonomous Data Guard-Standbydatenbank verwaltet. Wenn Sie Oracle Autonomous Database Serverless verwenden, können Sie einen Remoteaktualisierbaren Klon anstelle einer Snapshot-Standbydatenbank verwenden, um das Mid-Tier-System in der sekundären Region bereitzustellen oder Aufgaben in der Standbydatenbank auszuführen, wie Tests, Öffnen für Validierungen, Patching usw. Die Standby- und aktualisierbaren Klondatenbanken verwenden jedoch unterschiedliche Verbindungs-Wallets, und ihre Verbindungszeichenfolgen müssen ordnungsgemäß verwaltet werden, um diese Aufgaben auszuführen.

Bevor Sie beginnen

Es gibt mehrere technische Kurzüberblicke zu Oracle Maximum Availability Architecture (MAA), in denen beschrieben wird, wie ein Disaster Recovery-(DR-)System für Oracle WebLogic Server for Oracle Cloud Infrastructure und Oracle SOA Suite on Marketplace eingerichtet wird, wenn diese Middleware-Systeme Oracle Base Database Service verwenden.

Oracle WebLogic Server for Oracle Cloud Infrastructure-, Oracle SOA Suite on Marketplace- und Oracle Fusion Middleware-DR-Topologien verwenden ein Active-Passive-Modell. Das primäre System ist ein Oracle Cloud Infrastructure-(OCI-)Data Center und ein sekundäres System in einem anderen und Remote-OCI-Data Center.

Im Folgenden finden Sie weitere Details und Topologien für jeden Fall:

Die oben genannten Dokumente enthalten ausführliche Details, Setup- und Verwaltungsschritte sowie viele weitere Aspekte für Oracle WebLogic Server for Oracle Cloud Infrastructure und Oracle SOA Suite on Marketplace.

Stellen Sie zusätzlich zu den technischen Kurzüberblicken sicher, dass Sie mit den Konzepten und der Administration von Oracle Cloud Infrastructure (OCI) vertraut sind, einschließlich Networking, Compute-Instanzen, Load Balancing und Oracle Autonomous Database, bevor Sie mit der Analyse und den in diesem Playbook beschriebenen Schritten fortfahren.

Die Schritte und Beispiele in diesem Playbook werden mit Oracle WebLogic Server for OCI und Oracle SOA Suite on Marketplace für die folgenden Szenarios verifiziert:

Oracle Autonomous Data Guard auf Oracle Exadata Database Service on Dedicated Infrastructure, wobei das Feature Snapshot Standby für das Disaster-Recovery-Setup verwendet wird.
Oracle Autonomous Data Guard auf Oracle Autonomous Database Serverless mit dem Feature Snapshot-Standbydatenbank für das Disaster-Recovery-Setup.
Oracle Autonomous Data Guard auf Oracle Autonomous Database Serverless mit Remote Refreshable Clones für das Disaster-Recovery-Setup.

Die meisten Schritte gelten für die drei Szenarios. Nur einige der Schritte unterscheiden sich und sind für jeden Fall spezifisch.

Die Anpassung der Schritte an Oracle WebLogic Server- oder Oracle Fusion Middleware-Systeme, die Oracle Autonomous Database verwenden, sollte nicht schwierig sein.

Architektur

Dieses Architekturdiagramm zeigt die Topologie des Disaster Recovery-(DR-)Systems für die in diesem Playbook verwendeten Ansätze. Alle Laufzeit-, Konfigurations- und Metadateninformationen in der primären Datenbank werden von Region 1 in Region 2 mit Oracle Autonomous Data Guard repliziert. Oracle WebLogic Server for Oracle Cloud Infrastructure-, Oracle SOA Suite on Marketplace- und Oracle Fusion Middleware-DR-Topologien verwenden ein Active-Passive-Modell. Das primäre System ist ein Oracle Cloud Infrastructure-(OCI-)Data Center und ein sekundäres System in einem anderen und Remote-OCI-Data Center.

Die Oracle WebLogic-Domainkonfiguration wird mit einem Staging-Verzeichnis von Oracle Cloud Infrastructure File Storage (OCI File Storage) in der primären Region repliziert, das in einem OCI File Storage-Phasenverzeichnis in der sekundären Region repliziert wird. Dann wird die Konfiguration in das reale Domainverzeichnis auf der sekundären Seite kopiert. Eine direkte Kopie der Domain birgt Risiken, die mit einem Stufenverzeichnis vermieden werden. Da es sich bei Dateikopien um einen nicht transaktionalen Vorgang handelt, erfolgt eine erste Kopie in ein Staging-Verzeichnis. Dateien werden zunächst in diesem Zwischenverzeichnis verifiziert und dann in die echte (endgültige) Oracle WebLogic-Domain übertragen.

Beschreibung der Abbildung wls-dr-adb.png

wls-dr-adb-oracle.zip

Die Topologie ist typisch für die Verwendung durch Oracle WebLogic Server-, Oracle SOA- oder Oracle Fusion Middleware-Disaster Recovery-Umgebungen in OCI. Für das Provisioning der Standby-Middle Tier und für Lebenszyklusvorgänge wie das Testen der sekundären Datenbank konvertieren Sie die Standbydatenbank Oracle Autonomous Database in eine Snapshot-Standbydatenbank oder verwenden einen remote aktualisierbaren Klon.

Bei Verwendung eines Remote Refreshable Clone gibt es eine "Hilfsdatenbank" (ein aktualisierbarer Klon in einer Remote-Region) für die anfängliche Bereitstellung sowie für die Test- und Validierungsvorgänge in der Sekundärumgebung. In diesem Fall wird die sekundäre Middle Tier mit Datenquellen konfiguriert, die bei Switchover- und Failover-Ereignissen wieder in die Standbyadresse geändert werden müssen.

Diese Architektur unterstützt die folgenden Komponenten:

Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domains bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie voneinander trennen (innerhalb von Ländern oder sogar Kontinenten).
Availability-Domain
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Ein Fehler in einer Availability-Domain sollte sich daher nicht auf die anderen Availability-Domains in der Region auswirken.
Faultdomain
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.
Virtuelles Cloud-Netzwerk (VCN) und Subnetz
Ein VCN ist ein anpassbares, Software-definiertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz ist öffentlich oder privat.
Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server im Backend.
Oracle WebLogic-Domain
Eine Domain ist die Basisadministrationseinheit für WebLogic-Serverinstanzen. Eine Domain besteht aus einer oder mehreren WebLogic-Serverinstanzen (und den zugehörigen Ressourcen), die Sie mit einem einzelnen Administrationsserver verwalten. Die Oracle WebLogic-Domain wird gemäß den Best Practices von Oracle Maximum Availability Architecture (MAA) für High Availability konfiguriert.
Dynamisches Routinggateway (DRG)
Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, wie einem VCN in einer anderen Oracle Cloud Infrastructure-Region, einem On-Premise-Netzwerk oder einem Netzwerk in einem anderen Cloud-Provider.
Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der in das und aus dem Subnetz zugelassen werden muss.
Oracle Cloud Infrastructure-Dateispeicher
Oracle Cloud Infrastructure File Storage Service bietet ein dauerhaftes, skalierbares und sicheres Netzwerkdateisystem der Unternehmensklasse. Sie können über jede Bare-Metal-, VM- oder Containerinstanz in Ihrem virtuellen Cloud-Netzwerk (VCN) eine Verbindung mit einem File Storage Service-Dateisystem herstellen. File Storage Service unterstützt das Network File System Version 3.0-(NFSv3-)Protokoll. Der Service unterstützt das Network Lock Manager-(NLM-)Protokoll zur Dateisperrung.

Oracle Cloud Infrastructure File Storage verwendet 5-fach replizierten Speicher, der in verschiedenen Faultdomains gespeichert ist, um Redundanz für elastischen Datenschutz bereitzustellen. Daten werden durch die Löschungscodierung geschützt. Der Service erfüllt die Anforderungen von Anwendungen und Benutzern, die ein Unternehmensdateisystem für verschiedene Anwendungsfälle benötigen.
Autonomous Database
Oracle Autonomous Database ist eine vollständig verwaltete, vorkonfigurierte Datenbankumgebung, die Sie für Transaktionsverarbeitungs- und Data Warehousing-Workloads verwenden können. Sie müssen keine Hardware konfigurieren oder verwalten und keine Software installieren. Oracle Cloud Infrastructure verwaltet das Erstellen der Datenbank sowie Backup, Patching, Upgrade und Optimierung der Datenbank.
Oracle Autonomous Database auf dedizierter Exadata-Infrastruktur
Oracle Autonomous Database on Dedicated Exadata Infrastructure ist eine Oracle Autonomous Database mit einer privaten Datenbank-Cloud in der Public Cloud. Mit der dedizierten Datenbank erhalten Sie einen vollständig dedizierten Compute-, Speicher-, Netzwerk- und Datenbankservice, der ein äußerst hohes Sicherheits-, Isolations- und Governance-Niveau bietet.
Oracle Autonomous Database Serverless

Oracle Autonomous Database Serverless ist eine Oracle Autonomous Database. Sie verfügen über eine vollständig elastische Datenbank, in der Oracle automatisch alle Aspekte des Datenbanklebenszyklus von der Datenbankplatzierung bis hin zu Backup und Updates betreibt.
Data Guard
Mit Oracle Data Guard erhalten Sie ein umfangreiches Set von Services, mit denen Sie eine oder mehrere Standbydatenbanken erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Diese Standbydatenbanken werden von Oracle Data Guard als Kopien der Produktionsdatenbank verwaltet. Wenn dann die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht mehr verfügbar ist, kann Oracle Data Guard jede Standbydatenbank in die Produktionsrolle umschalten und so die Ausfallzeit für den Ausfall minimieren.
Oracle Autonomous Data Guard
Mit Oracle Autonomous Data Guard kann eine Standby-(Peer-)Datenbank Datenschutz und Disaster Recovery für Ihre Autonomous Database-Instanz bereitstellen. Sie umfasst zahlreiche Services, mit denen Sie eine oder mehrere Standbydatenbanken erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken als Kopien der Produktionsdatenbank. Wenn dann die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, können Sie jede Standbydatenbank in die Produktionsrolle umschalten, um die Ausfallzeit für den Ausfall zu minimieren.
Snapshot Standby
Bei einer Snapshot Standby-Datenbank handelt es sich um eine vollständig aktualisierbare Standby-Datenbank, die durch die Konvertierung einer physischen Standby-Datenbank in eine Snapshot Standby-Datenbank erstellt wurde.

Eine Snapshot-Standbydatenbank empfängt und archiviert, wendet jedoch keine redo-Daten von einer Primärdatenbank an. Die von der Primärdatenbank empfangenen redo-Daten werden angewendet, sobald eine Snapshot-Standbydatenbank wieder in eine physische Standbydatenbank konvertiert wird, nachdem alle lokalen Updates in der Snapshot-Standbydatenbank verworfen wurden.
Aktualisierbare Klone
Oracle Autonomous Database stellt ein Klonen bereit, mit dem Sie einen Full Clone der aktiven Instanz, einen Metadatenklon oder einen aktualisierbaren Klon erstellen können. Mit einem aktualisierbaren Klon erstellt das System einen Klon, der leicht mit Änderungen aus der Quelldatenbank aktualisiert werden kann.

Überlegungen zur Middle Tier

Alle Überlegungen in Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery und SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery für die Middle Tier gelten in den in diesem Dokument beschriebenen Oracle Autonomous Database-Szenarios.

Beachten Sie die folgenden Aspekte für die Middle Tier:

Frontend-Adresse
Der Zugriff von Clients auf das Oracle WebLogic Server-System muss unabhängig von der Site sein, die als primäre Site verwendet wird. Dazu muss der für den Zugriff auf das System verwendete Frontend-Adressname eindeutig sein und immer auf das derzeit primäre System verweisen. Dieser Name wird in der Regel als virtuelle Frontend- oder Vanity-URL bezeichnet.

Sie können die Frontend-Hostnamenadresse des vorhandenen Systems als virtuelles Frontend für Katastrophenschutz wiederverwenden. Beispiel: Wenn das ursprüngliche System mywebapps.example.com als Vanity-URL für das primäre System enthält, können Sie denselben virtuellen Hostnamen nach einem Switchover oder Failover der Load Balancer-IP der zweiten Site erneut zuordnen.

Verwenden Sie einen geeigneten DNS-(Domain Name System-)Service für den Frontend-Namen, der einer der beiden Sites zugeordnet werden soll. Beispiel: (Oracle Cloud Infrastructure DNS-Service, andere kommerzielle DNS-, lokale DNS- oder lokale Hostauflösung).
Namenspräfix der Instanz
Geben Sie eine Instance Name Prefix an, wenn Sie Oracle WebLogic Server for OCI oder Oracle SOA Suite on Marketplace bereitstellen. Mit dieser Eigenschaft werden die Namen aller Ressourcen erstellt, einschließlich: WebLogic-Serverdomainname, Clustername, WebLogic-Servernamen, Hostnamen der VM usw.

Setzen Sie Instance Name Prefix auf denselben Wert in primären und sekundären Oracle WebLogic Server-Systemen, sodass beide Systeme denselben Namen für die Oracle WebLogic-Ressourcen haben. Die Verwendung desselben Namens garantiert Konsistenz und ist für das Recovery von JMS-Nachrichten und TLogs erforderlich. Außerdem werden Anpassungen und Vorgänge auf beiden Sites vereinfacht.

Sie können dieselbe Instance Name Prefix in mehreren Instanzen in demselben Oracle Cloud-Mandanten verwenden, solange Sie sie in verschiedenen Regionen oder Compartments erstellen. Jede Instanz wird nur in ihrer jeweiligen Region und ihrem Compartment angezeigt.

Der Provisioning-Prozess Oracle SOA Suite on Marketplace bietet eine optionale Funktion, mit der Sie benutzerdefinierte Namen für die Domain, das Cluster, den Admin-Server, das Präfix des Managed Servers usw. konfigurieren können. In diesem Fall werden die Namen nicht von Instance Name Prefix abgeleitet. Sie übernehmen stattdessen die angegebenen Werte. Diese Funktion kann in der in diesem Dokument beschriebenen Disaster Recovery-(DR-)Topologie verwendet werden, solange die angegebenen benutzerdefinierten Namen auf dem Primär- und dem Standbysystem identisch sind.
Benutzerdefinierte Dateien
Die meiste Domainkonfiguration von Oracle WebLogic Server for OCI, die von WebLogic Cloud verwendet wird, wird zunächst über Sites hinweg mit den folgenden Überlegungen synchronisiert:

Jedes WebLogic-System verwaltet die ursprünglichen JDBC-URLs, die für die Verbindung mit der lokalen Datenbank verwendet werden, auch nach Abschluss des DR-Setups. Nur das Schemapräfix wird so geändert, dass beide Speicherorte auf dieselben Schemas (Primärschemas) verweisen.

Das Domaininfrastrukturfeature WebLogic verteilt die Konfiguration unter dem Verzeichnis weblogic_domain_name/config automatisch an die anderen Knoten in derselben Domain.

Benutzerdefinierte Anwendungs-Deployments (Ear-/war-Dateien, Deployment-Pläne usw.) und alle Elemente, die sich im Domainverzeichnis von Oracle WebLogic Administration Server befinden (mit Ausnahme der temporären Daten), werden zunächst über Sites hinweg mit den in diesem Dokument beschriebenen Verfahren synchronisiert. Wenn Oracle WebLogic Administration Server Daten verwendet, die sich in anderen Knoten oder außerhalb des Domainverzeichnisses befinden, müssen Sie sie manuell in den sekundären Speicherort kopieren. Weitere Details zum Replizieren der Konfiguration finden Sie später.

Überlegungen zur Snapshot-Standbydatenbank in Oracle Autonomous Database Serverless

Beachten Sie bei der Implementierung dieser Lösung Folgendes, wenn Sie Snapshot Standby in einer Oracle Autonomous Database Serverless-Datenbank aktivieren.

Zeitlimit für Snapshot Standby in einer serverlosen Infrastruktur
Wenn eine Snapshot-Standbydatenbank in Oracle Autonomous Database Serverless nicht innerhalb von 48 Stunden erneut verbunden wird, stellt die Snapshot-Standbydatenbank automatisch eine neue Verbindung zur Quelldatenbank her.
Konvertierung zurück in Disaster Recovery-Peer
Oracle empfiehlt, dass Sie eine Snapshot-Standby zurück in einen Disaster Recovery-Peer konvertieren, sobald Sie mit den Vorgängen fertig sind, bei denen die Standbydatenbank für Lese-/Schreibvorgänge geöffnet sein muss. Wenn Sie zurück in einen Disaster Recovery-Peer konvertieren, werden die kumulierten Änderungen aus der Quelldatenbank auf den Peer angewendet. Wenn Sie den Disaster Recovery-Peer für einen längeren Zeitraum als Snapshot-Standby geöffnet lassen und die Primärdatenbank während dieser Zeit fortlaufende Änderungen aufweist, dauert die Konvertierung in einen Disaster Recovery-Peer länger.
Kostenauswirkungen der Snapshot Standby-Datenbank in Oracle Autonomous Database Serverless
Die CPU-Auslastung der Standbydatenbank wird basierend auf der Basis-CPU-Anzahl und jeder zusätzlichen CPU-Auslastung abgerechnet, wenn die automatische Compute-Skalierung aktiviert ist. Die Anzahl der Basis-CPUs wird durch die Anzahl der ECPUs angegeben (OCPUs, wenn die Datenbank OCPUs verwendet), wie im Feld "ECPU-Anzahl" oder "OCPU-Anzahl" in der Oracle Cloud Infrastructure-Konsole dargestellt.

Die Nutzung des Snapshot Standby-Speichers wird basierend auf dem Speicher der Snapshot Standby-Datenbank plus dem 1-fachen Speicher der primären Quelldatenbank abgerechnet.

Weitere Informationen finden Sie unter Info zu Disaster-Recovery-Snapshot-Standbydatenbanken.

Überlegungen zu Snapshot Standby auf Oracle Autonomous Database on Dedicated Exadata Infrastructure

Beachten Sie bei der Implementierung dieser Lösung Folgendes, wenn Sie Snapshot Standby auf einer Oracle Autonomous Database on Dedicated Exadata Infrastructure aktivieren.

Zeitlimit für Snapshot Standby in einer dedizierten Infrastruktur
Wenn eine Snapshot-Standbydatenbank in Oracle Autonomous Database on Dedicated Exadata Infrastructure nicht innerhalb von 7 Tagen in eine physische Standbydatenbank konvertiert wird, wird die Snapshot-Standbydatenbank automatisch in eine physische Standbydatenbank konvertiert.
Zurück in eine physische Standby-Datenbank konvertieren
Oracle empfiehlt, dass Sie eine Snapshot-Standby zurück in eine physische Standbydatenbank konvertieren, sobald Sie mit den Vorgängen fertig sind, bei denen die Standbydatenbank für Lese-/Schreibvorgänge geöffnet sein muss. Wenn Sie die physische Standbydatenbank zurückkonvertieren, werden die kumulierten Änderungen aus der Quelldatenbank auf die Standbydatenbank angewendet. Wenn Sie die Standbydatenbank länger als Snapshot-Standby geöffnet lassen und die Primärdatenbank während dieser Zeit fortlaufende Änderungen aufweist, dauert die Konvertierung in eine physische Standbydatenbank länger.
Datenbankservices bei der Konvertierung in eine Snapshot Standby-Datenbank
In Oracle Autonomous Database on Dedicated Exadata Infrastructure werden im Dialogfeld "In Snapshot Standby konvertieren" zwei Optionen angezeigt:
- Neue Datenbankservices verwenden: Wählen Sie diese Option aus, um mit neuen Services eine Verbindung zu einer Snapshot-Standbydatenbank herzustellen, die nur im Snapshot-Standbymodus aktiv sind.
- Primäre Datenbankservices verwenden: Wählen Sie diese Option aus, wenn Sie eine Verbindung zur Snapshot-Standbydatenbank mit denselben Services wie die Primärdatenbank herstellen möchten.
Verwenden Sie für das Disaster-Recovery-Setup die Option Primärdatenbankservices verwenden, wenn Sie die Standbydatenbank in eine physische Standbydatenbank konvertieren. Auf diese Weise ist der von Oracle WebLogic Server in der sekundären Middle Tier konfigurierte Verbindungsaliasname mit der primären konsistent.

Weitere Informationen finden Sie unter Autonomous Data Guard.

Überlegungen zu Remote aktualisierbaren Klonen in Oracle Autonomous Database Serverless

Beachten Sie Folgendes, wenn Sie einen aktualisierbaren Klon von Oracle Autonomous Database Serverless verwenden, um ein sekundäres Oracle WebLogic Server for Oracle Cloud Infrastructure-, Oracle SOA Suite on Marketplace- oder Oracle Fusion Middleware-System zu testen und zu validieren.

Lebenszyklus von aktualisierbaren Klonen
Im Gegensatz zu einer herkömmlichen Oracle Data Guard-Standby werden remote aktualisierbare Klone separat aktiviert und separat von einer Primär- und einer Standbydatenbank verwaltet. Es handelt sich um eine separate Entity mit einem eigenen Lebenszyklus, der über die Aktualisierungsvorgänge hinausgeht und mit der Quelldatenbank synchronisiert wird (primär).
CPU-Ressourcenzuweisung
Remote-Aktualisierbare Klone werden nicht basierend auf der CPU-Ressourcenzuweisung des primären oder Standby-Systems erstellt. Das bedeutet, dass Sie OCPU-Optionen für den aktualisierbaren Klon separat angeben müssen. Sie müssen Workload-Tests auf dem entfernten aktualisierbaren Klon manuell konfigurieren, damit er mit der Kapazität des primären Systems übereinstimmt. Im Idealfall sollten Sie den entfernten aktualisierbaren Klon mit einer Konfiguration erstellen, die der Primärdatenbank entspricht, sodass Test-Workloads auf der Sekundärdatenbank realistisch sind. Remote Refreshable Clones übernehmen jedoch die in der primären Datenbank verwendete Speicherkonfiguration.
Patching
Patches werden automatisch wöchentlich auf Oracle Autonomous Database Serverless pro wöchentlichem Wartungsfenster eingespielt. Daher erfolgt eine kontinuierliche und zwanghafte Synchronisierung von Patches zwischen dem primären, Standby- und Remoteaktualisierbaren Klon.
Service-Limits
Remote Refreshable Clones sind eine erstklassige Entity. Sie verursachen zusätzliche Kosten pro Speicher, CPU und Lizenzauswirkungen einer formellen Autonomous Database und werden auf die Servicelimits der Region für Oracle Autonomous Database Serverless angerechnet.
Aktualisierbarer Klon bei Switchover
Wenn ein Failover oder ein "nicht sofort reversibles Switchover" stattfindet, müssen Sie manuell einen aktualisierbaren Klon auf der Primärdatenbank erstellen, damit das System in dem sekundären System mit den entsprechenden Servicelimits, dem Management und anderen Überlegungen für Test- und Wartungsvorgänge bereit bleibt. Remote-Aktualisierbare Klone haben keine Rollenumkehrsteuerung.

Nach einem Switchover auf die sekundäre Datei kann der erstellte aktualisierbare Klon nicht mehr aktualisiert werden (da die Quelle jetzt eine Standbydatenbank ist) und wird als getrennt markiert. Nach 24 Stunden wird es zu einem nicht aktualisierbaren und nicht verbundenen Klon.
Aktualisierbare Klone aktualisieren - Fenster
Remote-Aktualisierbare Klone müssen mindestens einmal pro Woche aktualisiert werden. Wenn Sie dann mit den Primärdaten synchron sind, müssen Sie einen neuen Remote-Klon erstellen, der aktualisiert werden kann, und den nicht aktualisierten Klon verwerfen.
Schreibmodus für aktualisierbare Klone
Remote-Aktualisierbare Klone können nicht länger als 24 Stunden im Schreibmodus (Verbindung zur Primärdatenbank trennen) bleiben. Nach diesem Zeitraum kann die Remote-Datenbank für aktualisierbare Klone nicht erneut mit der Primärdatenbank verbunden werden. Wenn Sie dann mit den Daten der Primärdatenbank synchron sind, müssen Sie einen neuen Remote Refreshable Clone erstellen und den nicht aktualisierten Klon verwerfen.

Überlegungen zum Speicherort des Konfigurationsordners `tns_admin`

Beachten Sie Folgendes für den Konfigurationsordner tns_admin.

Konsistenten Speicherort für den Ordner tns_admin verwenden
Die Mid-Tiers in einer WebLogic-Domain verwenden einen Ordner, um das Oracle Autonomous Database-Wallet und die Datei tnsnames.ora zu speichern. Die Eigenschaft oracle.net.tns_admin verweist auf diesen Ordner in den Datenquellen- und JPS-Konfigurationsdateien. Der Pfad dieses Ordners muss in primären und Standby-Midtiers identisch sein. Wenn der Ordnerpfad anders ist, ändern Sie den Ordner entweder in der Primär- oder der Standbydatenbank, sodass er denselben Ordner verwendet, bevor Sie die Disaster Recovery-(DR-)Setupskripte ausführen.
Hinweis:
Im Folgenden können Unterschiede zwischen Primär- und Standbydatenbank an diesem Ordnerspeicherort auftreten:
- Oracle SOA Suite on Marketplace-Instanzen, die vor Ende Februar 2023 (vor Release 23.1.1) bereitgestellt wurden, verwenden $DOMAIN_HOME/config/atp für den Ordner tns_admin. Ab Release 23.1.1 lautet der Speicherort $DOMAIN_HOME/config/tnsadmin.
Der Ordner tns_admin unter dem Ordner "Domain config"
Prüfen Sie den Speicherort des Oracle Autonomous Database-Wallets in der Datenquellenkonfiguration WebLogic. Wenn das Wallet nicht im Verzeichnis DOMAIN_HOME/config gespeichert ist, werden Änderungen am Inhalt des Wallet-Verzeichnisses NICHT automatisch von der Oracle WebLogic Server-Infrastruktur auf andere Knoten repliziert. In diesen Fällen müssen Sie entweder das Wallet-Verzeichnis ändern (und die erforderlichen Datenquellenkonfigurationen aktualisieren) oder es manuell auf andere Knoten kopieren, wenn es aktualisiert wird.