1. Oracle Fusion Middleware DR in Oracle Cloud mit einer autonomen Datenbank konfigurieren
  2. DR-Topologie konfigurieren

DR-Topologie konfigurieren

Richten Sie die Disaster Recovery-(DR-)Topologie ein. Skripte stehen zur Optimierung des Prozesses zur Verfügung.

Skripts herunterladen

Rufen Sie die neuesten Setupskripte aus dem Repository GitHub ab.

Hinweis:

Speichern Sie alle heruntergeladenen Skripte im selben Ordner.
  1. Gehen Sie zum Repository GitHub.
  2. Laden Sie alle Skripte im Verzeichnis maa/fmw-wls-with-adb-dr herunter.
  3. Laden Sie alle Skripte im Verzeichnis maa/app_dr_common herunter.
    Diese Skripte führen gegenseitig Aufrufe aus. Laden Sie die gesamten Verzeichnisse herunter, und speichern Sie alle Skripte im selben Ordner. Sie benötigen die Skripte sowohl auf der primären als auch auf der sekundären Site.
  4. Befolgen Sie die Anweisungen in diesem Dokument, und lesen Sie die erforderlichen Variablen in jedem Skript für jeden Vorgang, den Sie ausführen.

Die heruntergeladene Datei enthält Skripte zur Ausführung der folgenden Aufgaben:

  1. TNS-Alias für Datenquellen konfigurieren
  2. Anfängliche DR-Konfiguration einrichten
  3. Laufende Replikation einrichten
  4. Ändern Sie Wallets für ein Oracle WebLogic Server-, Oracle SOA- oder Oracle Fusion Middleware-System.
Jedes Skript bietet Automatisierung für verschiedene Teile des DR-Setups und Lebenszyklus eines Katastrophenschutzsystems. Die folgende Tabelle enthält eine Übersicht über die Dienstprogramme:
Skriptname Beschreibung
fmwadb_config_replica.sh Konfiguration zwischen Sites replizieren
fmwadb_dr_prim.sh Bereitet einen primären Standort für das DR-Setup vor.
fmwadb_dr_stby.sh Bereitet einen sekundären Standort für das DR-Setup vor.
fmwadb_rest_api_listabds.sh Rufen Sie die Autonomous Database-Rollenbasis auf der ADB-ID und den Mandanteninformationen ab.
fmwadb_switch_db_conn.sh Ersetzt die vorhandenen Verbindungsinformationen durch einen neuen ADBS WALLET.
fmw_change_to_tns_alias.sh Ersetzen Sie die von Oracle WebLogic-Datenquellen und jps config-Dateien verwendeten Verbindungszeichenfolgen durch einen tns-Alias.
fmw_dec_pwd.sh Entschlüsselt ein von Oracle WebLogic verschlüsseltes Kennwort.
fmw_enc_pwd.sh Verschlüsselt ein Kennwort mit der Oracle WebLogic-Verschlüsselung.
fmw_get_connect_string.sh Gibt die Verbindungszeichenfolge zurück, die von einer Oracle WebLogic-, Oracle SOA- oder Oracle Fusion Middleware-Datenquelle verwendet wird.
fmw_get_ds_property.sh Gibt den Wert einer bestimmten Datenquelleigenschaft zurück.

Primäre Mid-Tier für das virtuelle Frontend vorbereiten

Wenn die primäre Mid-Tier noch nicht mit einem virtuellen Frontend-Namen konfiguriert ist, führen Sie diese Aktionen aus, um sie für die Disaster Recovery-(DR-)Konfiguration vorzubereiten.

  1. Fügen Sie den virtuellen Frontend-Namen und die IP zur Datei /etc/hosts auf allen primären Middle Tier-Hosts hinzu.
    Jeder Standort muss den Frontend-Namen in seinen lokalen Load Balancer auflösen, unabhängig von der clientseitigen Auflösung über das Domain Name System (DNS). Bearbeiten Sie als Benutzer root die Datei /etc/hosts, und ordnen Sie die öffentliche IP des primären Load Balancers dem vollqualifizierten Domainnamen (FQDN) des virtuellen Frontends zu. Wiederholen Sie den Vorgang auf allen primären Oracle WebLogic-Hosts. Beispiel: 
    [oracle@wlsociprefix-wls-0 ~]$ more /etc/hosts
(...)
# Front-end virtual name
111.111.111.111 mywebapps.example.com

    Hinweis:

    Die Datei /etc/hosts der primären Oracle WebLogic-Hosts darf bei einem Switchover oder Failover nicht geändert werden. Primäre Oracle WebLogic-Hosts lösen den virtuellen Frontend-Namen immer mit seiner Frontend-IP auf. Die DNS-Aktualisierung, die während der Switchover- und Failover-Prozeduren erforderlich ist, wird in den von den Clients verwendeten DNS- oder Hostdateien ausgeführt.

  2. Konfigurieren Sie den Frontend-Namen als Cluster-Frontend.
    1. Melden Sie sich bei der Oracle WebLogic-Konsole Ihrer Instanz an.
    2. Navigieren Sie zu Umgebung, Cluster, und wählen Sie das Cluster aus.
    3. Navigieren Sie zu Konfiguration und dann zu HTTP.
    4. Legen Sie den Frontend-FQDN als Host fest.
      Beispiel: mywebapps.example.com.
    5. Stellen Sie sicher, dass die Frontend-Ports für HTTP und HTTPS ordnungsgemäß mit Werten konfiguriert sind.
    6. Klicken Sie auf Speichern und dann auf Aktivieren.
  3. Starten Sie das Cluster neu, um die Änderungen zu implementieren.

Primäre Datenquellen und JPS-Konfiguration ändern, um einen TNS-Alias zu verwenden

Die Verwendung eines TNS-(Transparent Network Substrate-)Alias in JDBC-(Java Database Connectivity-)URLs erleichtert die Neukonfiguration von Oracle WebLogic Server for Oracle Cloud Infrastructure-Datenquellen, indem remote aktualisierbare Klone zum Verschieben zwischen Primär- und Standbydatenbank verwendet werden.

Hinweis:

Oracle SOA Suite on Marketplace-Instanzen, die mit Release 23.1.1 (Februar 2023) oder höher bereitgestellt werden, werden mit dem TNS-Aliasansatz out-of-the-box konfiguriert. In diesem Fall können Sie diese Aufgabe überspringen.

Die Verwendung eines TNS-Alias erfordert, dass die Datenquellen und jps-Dateien die Variable oracle.net.tns_admin in den Oracle Fusion Middleware-Konfigurationsdateien enthalten.

  1. Mit dem Befehl grep können Sie in der Oracle Fusion Middleware-Konfigurationsdatei nach der Variable oracle.net.tns_admin suchen. 
    [oracle@soarefr-soa-0 ~]$ grep oracle.net.tns_admin ${DOMAIN_HOME}/config/fmwconfig/jps-config.xml 
<property name="oracle.net.tns_admin" value="/u01/data/domains/soarefr_domain/config/atp"/>

[oracle@soarefr-soa-0 ~]$ grep oracle.net.tns ${DOMAIN_HOME}/config/jdbc/opss-datasource-jdbc.xml  -A1 | grep value 
<value>/u01/data/domains/soarefr_domain/config/atp</value>
[oracle@soarefr-soa-0 ~]$
    Das in jps-config.xml (und Datenquellen) dargestellte Verzeichnis muss für alle Knoten in der Domain WebLogic Server verfügbar und zugänglich sein.
    • In Oracle SOA Suite on Marketplace befindet sich dieses Verzeichnis im Verzeichnis $DOMAIN_HOME/config/atp (vor Release 23.1.1) oder $DOMAIN_HOME/config/tnsadmin (für Release 23.1.1 und höher) und wird beim Starten der Managed Server automatisch vom WebLogic Server auf alle anderen Knoten repliziert.

      Hinweis:

      Wenn Ihre primäre Oracle SOA Suite on Marketplace vor 23.1.1 liegt, wird empfohlen, den Ordner in das Verzeichnis $DOMAIN_HOME/config/tnsadmin zu verschieben, damit er mit der Standbydatenbank konsistent ist.
    • Dieser Speicherort befindet sich in Oracle WebLogic Server for Oracle Cloud Infrastructure unter $DOMAIN_HOME/atpwallet.

      Hinweis:

      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.
    • In anderen Konfigurationen können Sie das Verzeichnis in Shared Storage speichern.
    In allen Fällen muss dasselbe Verzeichnis tns_admin von allen verschiedenen Mitgliedern einer WebLogic Server-Domain erreichbar sein. Dieses Verzeichnis enthält eine tnsnames.ora-Datei mit verschiedenen Aliasnamen für die verschiedenen in Oracle Autonomous Database erstellten Services.

    Im Folgenden finden Sie eine Beispieldatei für tnsnames.ora und eine Oracle Fusion Middleware-Konfiguration mit Oracle Autonomous Database Serverless. 

    [oracle@soarefr-soa-0 ~]$ cat 
$DOMAIN_HOME}}/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Änderungen an der Datei tnsnames.ora werden dynamisch von WLS-Datenquellen verbraucht. Das bedeutet, dass Sie die Datei tnsnames.ora ändern können (z.B. auf einen anderen Service zeigen), ohne dass der Neustart der Datenquelle erforderlich ist.

  2. Um eine Standard-Datenquellenkonfiguration so zu ändern, dass ein TNS-Alias in einem Oracle SOA Suite on Marketplace oder einem Oracle WebLogic Server for Oracle Cloud Infrastructure-System verwendet wird, das Autonomous Database verwendet, verwenden Sie das Skript fmw_change_to_tns_alias.sh.

    Der Alias muss in allen Datenquellendateien unter $DOMAIN_HOME/config/jdbc und in den jps config-Dateien unter $DOMAIN_HOME/config/fmwconfig verwendet werden.

    Hinweis:

    Dieses Skript ändert nur die Verbindungszeichenfolge und die Eigenschaft tns_admin. Wenn Sie andere benutzerdefinierte Datenquellen hinzufügen, müssen diese auch einen TNS-Alias verwenden, genau wie die internen Datenquellen für Oracle WebLogic, Oracle SOA Suite on Marketplace und Oracle Fusion Middleware.
    Wenn Oracle WebLogic Server for Oracle Cloud Infrastructure oder Oracle SOA Suite on Marketplace mit Oracle Autonomous Database bereitgestellt werden, ist die Konfiguration des Datenbank-Wallets in den Datenquellen enthalten (Truststore-Speicherort, Keystore-Speicherort usw.). Diese Parameter werden NICHT vom Skript fmw_change_to_tns_alias.sh geändert und sind unabhängig davon gültig, ob der TNS-Alias verwendet wird. Ein Wallet-Verzeichnis wird von Oracle WebLogic Server for Oracle Cloud Infrastructure und Oracle SOA Suite on Marketplace beim Provisioning erstellt und enthält bereits eine tnsnames.ora-Datei. Sie können das Oracle Autonomous Database-Wallet auch von der autonomen Datenbank-UI in OCI abrufen.

    Hinweis:

    Das von Oracle WebLogic Server for Oracle Cloud Infrastructure und Oracle SOA Suite on Marketplace verwendete Oracle Autonomous Database-Wallet wird beim Provisioning auf den Administrationsserverknoten heruntergeladen. Sie können das Wallet für das Primär- und das Standbysystem aktualisieren, indem Sie es über die Oracle Autonomous Database-UI neu herunterladen und das Wallet-Kennwort im Verzeichnis $DOMAIN_HOME/config/jdbc und in den jps config-Dateien unter $DOMAIN_HOME/config/fmwconfig aktualisieren. Die Verwendung desselben Kennworts für die Wallets der Primärdatenbank, der Standbydatenbank und des aktualisierbaren Klons erleichtert die Bearbeitung der Datenquellenkonfiguration auf beiden Sites. Die unten angegebenen Skripte können jedoch unterschiedliche Kennwörter verarbeiten. Verwenden Sie das Skript fmwadb_switch_db_conn.sh, um das System mit einem neuen Wallet zu aktualisieren.

    Beim Provisioning Ihres primären Systems haben Sie (in den Provisioning-Bildschirmen) eine der Oracle Autonomous Database-Serviceebenen gewählt. Führen Sie das Skript fmw_change_to_tns_alias.sh mit derselben Serviceebene aus. Die Servicegrade für einen DB-Service in Oracle Autonomous Database lauten: low, mid, high tp, tpurgent. Im Folgenden finden Sie ein Beispiel für die Änderung von Oracle Fusion Middleware in TNS-Alias: 

    [oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))"/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
<url>jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))</url>
 
NOTICE the "low" label in g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com, that is the service flag that will allow you identify the tns alias that needs to be used
 
[oracle@soarefr-soa-0 good]$ cat $DOMAIN_HOME/config/atp/tnsnames.ora | grep low | awk -F '=' '{print $1}'
soaadb1_low
 
[oracle@soarefr-soa-0 good]$ ./fmw_change_to_tns_alias.sh soaadb1_low                                                                                          
Getting variables from current datasource ...............
An existing tns_admin property was found in /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml and will be used
Found soaadb1_low  as tns_alias
No modifications will be required in /u01/data/domains/soarefr_domain/config/atp/tnsnames.ora
*******************WILL USE THESE SETTINGS********************
**************************************************************
TNS admin:........................./u01/data/domains/soarefr_domain/config/atp
TNS alias:........................ soaadb1_low
Current connect string:............(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current jps connect string:........(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current tnsnames.ora:..............
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
**************************************************************
Taking backup of existing config...
************** Replacing DB connect information **************
Replacing jdbc url in config/jdbc files...
Replacing jdbc url in config/fmwconfig files...
Replacement complete!
 
[oracle@soarefr-soa-0 ~]$ grep url $DOMAIN_HOME/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
    <url>jdbc:oracle:thin:@soaadb1_low </url>
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$
  3. Starten Sie alle Oracle WebLogic-Server in der Domain neu, um die vom Skript vorgenommenen Änderungen zu übernehmen.

VCN und Subnetz in der sekundären Region erstellen

Falls noch nicht geschehen, erstellen Sie ein VCN in der Standbyregion mit einem CIDR, das nicht mit dem CIDR der primären Region in Konflikt steht. Beispiel: Wenn das primäre VCN 10.1.0.0/16 verwendet, könnte das sekundäre VCN 10.2.0.0/16 verwenden.

  1. Erstellen Sie ein VCN und ein Subnetz in der sekundären Region.
    Sie können einen Cloud-Stack erstellen, um eine Gruppe verwandter Cloud-Services bereitzustellen.
  2. Stellen Sie sicher, dass die Sicherheitslisten die richtige Kommunikation zwischen Ebenen ermöglichen.

    Prüfen Sie die folgende Kommunikation:

    • Vom OCI-Load Balancer zum WebLogic-Server
    • Vom WebLogic-Server zur Datenbank
    • Vom WebLogic-Server zum Shared Storage

    Nehmen Sie außerdem die erforderlichen Regeln auf, um die Kommunikation zwischen Administrationsserverknoten über das dynamische Routinggateway (DRG) zuzulassen, nachdem es erstellt wurde.

DRG zwischen primären und sekundären VCNs konfigurieren

Für das Disaster Recovery-Setup müssen die primären und sekundären Oracle WebLogic Server-Administrationsknoten miteinander kommunizieren, um die Domainkonfiguration über Oracle Cloud Infrastructure File Storage-Kopien zu erhalten. Dazu müssen Sie ein dynamisches Routinggateway (DRG) zwischen den Mid-Tier-VCNs erstellen.

  1. Erstellen Sie ein DRG zwischen den Mid-Tier-VCNs.
  2. Prüfen Sie, ob das neue DRG auf der Seite Dynamische Routinggateways des ausgewählten Compartments oder der ausgewählten Region angezeigt wird.
    Die DR-Setupskripte prüfen, ob die erforderlichen Verbindungen hergestellt werden können.
  3. Konfigurieren Sie die entsprechenden Routen und Sicherheitsregeln in den primären und Standby-VCNs, um SSH-Verbindungen zwischen den Midtiers zuzulassen.
  4. Stellen Sie sicher, dass Sie eine SSH-Verbindung vom Oracle WebLogic Administration Server-Knoten in der primären zum Oracle WebLogic Administration Server-Knoten in der sekundären Verbindung herstellen können.
    Beispiel: Wenn 10.2.1.104 die IP des Administrationsserverknotens der Sekundärinstanz ist, führen Sie Folgendes auf dem Administrationsserverknoten der Primärinstanz aus.
    [opc@soarefr-soa-0 ~]$ ssh -i KeySOAMAA.ppk opc@10.2.1.104
Last login: Wed Dec 14 16:59:15 2022 from 10.2.0.83
[opc@soarefr-soa-0 ~]$

Oracle Autonomous Data Guard-Standby in der sekundären Region erstellen

Erstellen Sie eine Standbydatenbank für die vorhandene primäre Oracle Autonomous Database.

  1. Erstellen Sie für Oracle Autonomous Database Serverless eine Standby-Oracle Autonomous Database Serverless in der sekundären Region.
    1. Klicken Sie in der OCI-Konsole im linken Navigationsmenü auf Oracle Database, um zur primären Oracle Autonomous Database zu navigieren.
    2. Klicken Sie auf der Seite Autonomous Database-Details unter "Ressourcen" auf Disaster Recovery und dann auf Peer-Datenbank hinzufügen.
    3. Verwenden Sie die zuvor erstellten VCN- und privaten Subnetze.
  2. Für Oracle Autonomous Database on Dedicated Exadata Infrastructure
    1. Navigieren Sie in der OCI-Konsole zur Detailseite der autonomen Containerdatenbank, und wählen Sie im Abschnitt "Ressourcen" die Ressource Autonomous Data Guard-Verknüpfungen aus.
    2. Klicken Sie auf Autonomous Data Guard aktivieren.
    3. Geben Sie die Informationen zum autonomen Peer-VM-Cluster, den Schutzmodus und die automatische Failover-Auswahl ein. Nachdem Sie alle erforderlichen Informationen eingegeben haben, klicken Sie auf Autonomous Data Guard aktivieren.
      Im Rahmen dieses Workflows wird eine neue autonome Standbycontainerdatenbank mit allen autonomen Standbydatenbanken im ausgewählten autonomen VM-Cluster erstellt.

Standby-Autonomous Database für DR-Setup vorbereiten

Diese Aufgabe hängt davon ab, ob Sie die Snapshot Standby- oder Remote-Aktualisierbarer Klon verwenden.

Informationen zum Snapshot Standby-Ansatz finden Sie unter Standbydatenbank in eine Snapshot-Standbydatenbank konvertieren.

Informationen zum Remote Refreshable Clone-Ansatz finden Sie unter Remote Refreshable Clone in der sekundären Region erstellen.

Standby in eine Snapshot Standby-Datenbank konvertieren

Konvertieren Sie die autonome Standby-Datenbank mit dem Snapshot Standby-Ansatz in die Snapshot-Standby-Datenbank.

  1. Klicken Sie im linken Navigationsmenü der Oracle Cloud Infrastructure-Konsole auf Autonomous Database.
  2. Wählen Sie in der sekundären Region die Standby-Autonomous Database aus.
  3. Klicken Sie in der Dropdown-Liste Weitere Aktionen auf In Snapshot-Standbydatenbank konvertieren.
  4. Wenn Sie die dedizierte Infrastruktur verwenden, wählen Sie Primäre Datenbankservices verwenden aus.

Hinweis:

Wenn eine Snapshot Standby-Datenbank in Oracle Dedicated Exadata Infrastructure nicht innerhalb von 7 Tagen in eine physische Standbydatenbank konvertiert wird, wird die Snapshot Standby-Datenbank automatisch in die physische Standbydatenbank konvertiert.

Wenn eine Snapshot Standby in Oracle Autonomous Database Serverless nicht innerhalb von 2 Tagen in eine physische Standby-Datenbank konvertiert wird, wird die Snapshot Standby-Datenbank automatisch in eine physische Standby-Datenbank konvertiert.

Einen entfernten aktualisierbaren Klon in der sekundären Region erstellen

Erstellen Sie mit der Lösung "Remote - Aktualisierbarer Klon" einen aktualisierbaren Klon aus der vorhandenen primären Oracle Autonomous Database Serverless in der Remoteregion.

  1. Erstellen Sie einen aktualisierbaren Klon aus der vorhandenen primären Oracle Autonomous Database Serverless.
    Speichern Sie den aktualisierbaren Klon in der sekundären (Remote-)Region im VCN und im privaten Subnetz, das Sie zuvor erstellt haben.

    Hinweis:

    Sie können nicht denselben DB-Namen wie die Primärdatenbank verwenden, da dieser Name bereits von der physischen Standbydatenbank verwendet wird.
  2. Verwenden Sie Private Endpoint Access Only, um auf die Datenbank zuzugreifen.

    Nach der Erstellung bleibt der aktualisierbare Klon verbunden und befindet sich im schreibgeschützten Modus. Oracle WebLogic Server-, Oracle SOA- und Oracle Fusion Middleware-Systeme können nicht für sie bereitgestellt werden. UNLESS es wird in Lese-/Schreibzugriff konvertiert (nicht mit Primärdatenbank verbunden).

  3. Trennen Sie den aktualisierbaren Klon von der primären autonomen Datenbank, und konvertieren Sie ihn in den Lese-/Schreibmodus.

    Hinweis:

    Der remote aktualisierbare Klon kann nicht länger als 24 Stunden getrennt werden. Beispiel: Sie können nicht länger als 24 Stunden dauern, um die sekundären Mid-Tiers zu erstellen, die auf die remote aktualisierbare Klondatenbank zeigen.
    1. Klicken Sie im linken Navigationsmenü von Oracle Cloud Infrastructure auf Autonomous Database.
    2. Wählen Sie den Namen des aktualisierbaren Klons aus.
    3. Wählen Sie die Quelldatenbank aus, und klicken Sie auf Verbindung trennen.

Sekundäres System bereitstellen

Stellen Sie den sekundären Oracle WebLogic Server for Oracle Cloud Infrastructure-, Oracle SOA Suite on Marketplace- oder anderen Oracle Cloud Infrastructure-(OCI-)Service bereit, der Oracle Fusion Middleware (System) verwendet, der auf die sekundäre Datenbank verweist (für Snapshot Standby-Ansatz) oder auf den aktualisierbaren Klon (für die Remote-Aktualisierungsklonmethode).

  1. Befolgen Sie die Standard-Subnetz-, CIDR-, Sicherheitsregeln- und Präfixempfehlungen für das Disaster Recovery.

    Der Stackname kann unterschiedlich sein. Sie müssen jedoch dasselbe Präfix für den Ressourcennamen EXACT verwenden, das Sie am primären Speicherort verwendet haben. Oracle empfiehlt, dass Sie dieselbe Kapazitäts- und Compute-Konfiguration sowohl für primäre als auch für Standby-Speicherorte verwenden, um ein ideales Failover-/Switchover-Verhalten zu erzielen.

    Stellen Sie sicher, dass Version und Patchebene von Oracle WebLogic Server for OCI, die im sekundären Speicherort bereitgestellt werden sollen, mit der auf der primären Site ausgeführten Version übereinstimmen.

    Wenn Sie weitere Details benötigen, finden Sie in der Tabelle, in der die Provisioning-Assistentenoptionen für das DR-Setup im Abschnitt "Provisioning WLS for OCI in Secondary Site" von Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery oder im Abschnitt "Provisioning SOA Suite on Marketplace in Secondary Site" von SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery zusammengefasst sind.

  2. Erstellen Sie das sekundäre Middle Tier-System gemäß dem Standard-Provisioning-Prozess.
  3. Prüfen Sie den standardmäßigen Oracle WebLogic Server for Oracle Cloud Infrastructure-, Oracle SOA Suite on Marketplace- oder anderen Oracle Cloud Infrastructure-(OCI-)Service der Oracle Fusion Middleware-URLs (z.B. Konsole, soa-infra usw.), um zu prüfen, ob das System ordnungsgemäß erstellt wurde.
  4. Stoppen Sie nach der Validierung die Oracle WebLogic-Prozesse in der Standby-Datenbank: Managed Server, Admin Server und Node Manager.
  5. Wenn Sie einen aktualisierbaren Remoteklon verwenden, können Sie ihn erneut mit der Quelle verbinden. Wenn Sie Snapshot Standby verwenden, können Sie sie erneut in die physische Standbydatenbank konvertieren.
    Versuchen Sie nicht, die Oracle WebLogic-Prozesse sekundär zu starten, bis das DR-Setup abgeschlossen ist.

Verbindungszeichenfolgen für TNS-Alias des Sekundärmoduls ändern

Ändern Sie den im sekundären System verwendeten Alias so, dass er mit dem Aliasnamen im primären System übereinstimmt.

Genau wie im primären System sollten Sie einen TNS-(Transparent Network Substrate-)Alias in allen Datenquellendateien unter $DOMAIN_HOME/config/jdbc und in den jps config-Dateien unter $DOMAIN_HOME/config/fmwconfig verwenden. Der im sekundären (Standby-)System verwendete Alias ist derselbe wie im primären System, da Datenquellen aus der primären Instanz mit dem zuvor erstellten Alias repliziert werden.

Diese Aufgabe hängt davon ab, ob Sie eine Snapshot-Standby- oder eine Remote-Aktualisierungsklonmethode verwenden.

Verbindungszeichenfolgen für TNS-Alias für Snapshot Standby-Ansatz ändern

Für den Snapshot Standby-Ansatz wird erwartet, dass die Aliasnamen in der Datei tnsnames.ora mit den Aliasnamen in der Primärdatenbank übereinstimmen (obwohl Verbindungszeichenfolgen auf die Adresse der Standbydatenbank verweisen). Sie müssen sie nicht ändern.

  1. Wenn die Zeichenfolgen in der Datei tnsnames.ora doppelt vorhanden sind (wo sie sowohl lokale als auch Remotehosts für autonome Datenbanken enthalten), empfiehlt Oracle, sie so zu ändern, dass sie nur auf die lokale Datenbank verweisen.
    Dies kann passieren, wenn Sie Oracle Autonomous Database auf dedizierter Infrastruktur verwenden. Sie müssen diese Änderung nur einmal vornehmen, da die Datei tnsnames.ora für die Standbydatenbank nicht durch Konfigurationsreplikation und andere Lebenszyklusvorgänge geändert wird.

    Im Folgenden finden Sie ein Beispiel, bei dem die Einträge in der Datei tnsnames.ora doppelt vorhanden sind: 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…
  2. Wenn Sie duale Einträge haben, ändern Sie diese so, dass sie nur auf die lokale Autonomous Database zeigen, indem Sie die ADDRESS der Remote-Datenbank entfernen.

    Die Datei tnsnames.ora in der sekundären Datei darf nur den ADDRESS der Standbydatenbank enthalten. Beispiel: 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…

Verbindungszeichenfolgen für TNS-Alias für den Remote-Konzept für aktualisierbaren Klon ändern

Ändern Sie für den Remote Refreshable Clone-Ansatz den im sekundären System verwendeten Alias so, dass er dem Aliasnamen im primären System entspricht.

Die Datei tnsnames.ora, die in der sekundären Datei Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace oder der Oracle Fusion Middleware-Systemerstellung enthalten ist, enthält einen Alias basierend auf dem Namen des entfernten aktualisierbaren Klons. Beispiel: Wenn ein entfernter aktualisierbarer Klon mit dem Namen soaadb1rc2 erstellt wird, enthält die Datei tnsnames.ora (im beim Provisioning erstellten Wallet-Verzeichnis) den folgenden Alias: soaadb1rc2_high, soaadb1rc2_low, soaadb1rc2_medium, soaadb1rc2_tp, soaadb1rc2_tpurgent. Um die Konfiguration zu vereinfachen, müssen Sie denselben Aliasnamen in der Datei tnsnames.ora sowohl im primären als auch im sekundären System verwenden. Ändern Sie daher den TNS-Alias, den Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace oder die Oracle Fusion Middleware-Domain mit (aktualisierbaren Remoteklon) konfiguriert ist, um denselben Aliasnamen wie die primäre zu verwenden. Sie können den Aliasnamen in der primären Datei $tns_admin/tsnames.ora abrufen. Unterschiedliche Aliasnamen werden für verschiedene Services erstellt, und sie alle beziehen ein Präfix aus dem DB-Namen. Beachten Sie, dass Sie nur den Aliasnamen ändern möchten, nicht die Services. Verwenden Sie keine globale Suche und ersetzen Sie die Datei, da dadurch wahrscheinlich auch die Servicenamen in den Verbindungszeichenfolgen in der Datei tnsnames.ora geändert werden.

  • Ändern Sie die Datei tnsnames.ora des sekundären Systems, um denselben Alias wie das primäre System zu verwenden.

    Im Folgenden finden Sie eine tnsnames.ora-Beispieldatei für eine Oracle Fusion Middleware-Konfiguration mit Oracle Autonomous Database Serverless im primären System. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Im Folgenden finden Sie eine tnsnames.ora-Beispieldatei für eine Oracle Fusion Middleware-Konfiguration mit Oracle Autonomous Database Serverless im Sekundär mit aktualisierbarem Klon. 

    oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
rcsoaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Da es sich um einen einmaligen Vorgang handelt, besteht die einfachste Möglichkeit, den Alias für den aktualisierbaren Klon zu ändern, darin, die Datei zu bearbeiten. Sie können den Alias für den verwendeten Servicegrad oder alle aus Konsistenzgründen ändern.

    Hinweis:

    Dies muss jedes Mal geschehen, wenn ein neuer aktualisierbarer Klon zum Testen oder Validieren verwendet wird und ein neues Wallet verwendet wird.

    Im Folgenden finden Sie eine tnsnames.ora-Beispieldatei für eine Oracle Fusion Middleware-Konfiguration mit Oracle Autonomous Database Serverless im Sekundär mit aktualisierbarem Klon mit dem Alias der Primärdatenbank. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

Wie im primären System verwenden alle Datenquellendateien unter $DOMAIN_HOME/config/jdbc und in den JPS-Konfigurationsdateien unter $DOMAIN_HOME/config/fmwconfig den ausgewählten Alias. Es wird erwartet, dass dieselbe Serviceebene mit dem entfernten aktualisierbaren Klon gewählt wurde wie im primären System (entweder low, mid, high, tp oder tpurgent). Da Alias und Datenquellen aus dem primären System kopiert werden, müssen Sie das Skript fmw_change_to_tns_alias.sh nicht im sekundären System ausführen. Das Disaster Recovery-Setup übernimmt die erforderlichen Ersetzungen.

Wenn zusätzliche Aliasnamen auf andere Datenbanken in der primären Datei tnsnames.ora verweisen, fügen Sie diese entsprechend in der Datei tnsnames.ora des sekundären Systems hinzu.

Hostnamen-Aliasnamen und Frontend-Adresse in der primären und Standby-Midtiers aktualisieren

Die Domainkonfiguration WebLogic in der sekundären Domain ist eine Kopie der primären Domain WebLogic, wenn das DR-Setup abgeschlossen ist. Daher müssen die Hostnamen, die von den primären Oracle WebLogic-Servern als Listenadressen verwendet werden (die Hostnamen der primären Hosts sind), am sekundären Speicherort gültig sein, jedoch den sekundären IPs zugeordnet werden.

Sowohl in der Primär- als auch in der Standbydatenbank muss dieselbe Frontend-Adresse verwendet werden. Während des normalen Betriebs wird dieser Frontend-Hostname der IP des primären Oracle Cloud Infrastructure-(OCI-)Load Balancers zugeordnet. Bei der Ausführung von einem sekundären Host (nach einem Switchover oder Failover) wird dieser Frontend-Hostname der IP des sekundären OCI-Load Balancers zugeordnet.

Hinweis:

Die Datei /etc/hosts der Middle Tier-Hosts darf bei einem Switchover oder Failover nicht geändert werden. Die Middle Tier-Hosts lösen immer den virtuellen Frontend-Namen mit seiner Frontend-IP auf. Die DNS-Aktualisierung, die während der Switchover- und Failover-Prozeduren erforderlich ist, wird in den von den Clients verwendeten DNS- oder Hostdateien ausgeführt.

Sie können dieses Host-Aliasing wie folgt implementieren:

  • Fügen Sie die Hostnamen als Aliasnamen zu den /etc/hosts-Dateien der Oracle WebLogic Server for OCI-Compute-Instanzen hinzu
  • Private DNS-Ansicht im sekundären OCI-VCN verwenden

/etc/hosts-Dateien verwenden

Die vom primären Oracle WebLogic Server verwendeten Hostnamen werden den /etc/hosts-Dateien der sekundären Oracle WebLogic Server-Hosts hinzugefügt, die auf die IP-Adressen der sekundären Oracle WebLogic Server-Hosts verweisen. Dieser Modus ist gültig, wenn der DNS-Server auf primären und sekundären Oracle Cloud Infrastructure-(OCI-)Sites identisch ist und wenn separate DNS-Server in der primären und sekundären Site verwendet werden. Die Einträge in der Datei /etc/hosts haben Vorrang vor der DNS-Auflösung, da dies die Priorität ist, die Out-of-the-box in der Direktive "hosts" der Datei /etc/nsswitch.conf definiert ist.
  1. Bearbeiten Sie die Datei /etc/oci-hostname.conf jeder Compute-Instanz von WebLogic Server, und legen Sie die Eigenschaft PRESERVE_HOSTINFO=3 so fest, dass /etc/hosts-Einträge über Instanzneustarts hinweg beibehalten werden.
  2. Mit dem Befehl hostname --fqdn können Sie die vollständigen Hostnamen der OCI-Compute-Instanzen WebLogic Server identifizieren.
  3. Fügen Sie die folgenden Einträge zur Datei /etc/hosts der Mid-Tier-Compute-Instanzen hinzu:
    #################################
# ALIASES on OCI for DR
#################################
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname   ALIAS_OF_APPHOST1 
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname   ALIAS_OF_APPHOST2 
#################################
# Frontend name 
#################################
IP_OF_LBR  frontend_name_fqdn
    Im Folgenden finden Sie ein Beispiel für die Datei /etc/hosts der primären Oracle WebLogic Server-Hosts:
    # Aliases for DR in primary region
10.0.2.10 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0 
10.0.2.11 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-1

# Front-end virtual name to primary LBR IP
111.111.111.111 mywebapps.mycompany.com

    Im Folgenden finden Sie ein Beispiel für die Datei /etc/hosts in der sekundären OCI-Compute-Instanz WebLogic Server.

    Hinweis:

    Primäre Hostnamen werden als Aliasnamen der sekundären Knoten hinzugefügt, und dieser virtuelle Frontend-Name verweist auf die sekundäre Load Balancer-IP:

    # Aliases for DR in secondary region
10.1.2.5 wlsociprefix-wls-0.subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-0 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0
10.1.2.4 wlsociprefix-wls-1. subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-1 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0

# Front-end virtual name to secondary LBRIP
222.222.222.222 mywebapps.example.com

OCI Domain Name System (DNS) verwenden

Die von den primären Oracle WebLogic Server-Hosts verwendeten Hostnamen werden dem DNS-Resolver hinzugefügt, der vom VCN der sekundären Middle Tier-Server verwendet wird und auf die IP-Adressen der sekundären Oracle WebLogic Server-Hosts verweist. Dieser Modus ist gültig, wenn separate DNS-Server auf primären und sekundären Oracle Cloud Infrastructure-(OCI-)Sites verwendet werden. Andernfalls kann dies zu Konflikten bei der Namensauflösung führen. Der Server jeder Site muss diese Namen mit eigenen IPs auflösen. Der Vorteil dieser Methode besteht darin, dass Sie alle Einträge zu einer privaten DNS-Ansicht hinzufügen können, anstatt sie allen /etc/hosts aller Oracle WebLogic Server-Hosts hinzuzufügen.

Führen Sie die folgenden Schritte aus, um die private Ansicht im sekundären VCN zu erstellen und die von der primären Instanz verwendeten Hostnamen mit den sekundären IPs aufzulösen:

  1. Gehen Sie in der OCI-Konsole zur sekundären Region, und erstellen Sie die private Ansicht, um die Namen der PRIMARY-Hosts mit den SECONDARY-IP-Adressen aufzulösen.
    1. Klicken Sie auf Networking, DNS-Verwaltung, Private Ansichten und dann auf Private Ansicht erstellen.
      Beispiel: Sie können die private Ansicht benennen: PRIMARY_HOSTNAMES_PRIVATE_VIEW
    2. Klicken Sie in der privaten Ansicht auf Zone erstellen.
      Für den Zonennamen müssen Sie die vollständige Domain der Hosts verwenden. Beispiel: subnetpri.vcnpri.oraclevcn.com
    3. Fügen Sie die primären Hostnamen zu dieser Zone hinzu (Kurzname), werden jedoch mit der IP-Adresse der sekundären Oracle WebLogic Server-Hosts aufgelöst.
    4. Klicken Sie auf Änderungen veröffentlichen.
  2. Fügen Sie die private Ansicht zum sekundären VCN-Resolver hinzu.
    1. Klicken Sie auf die DNS-Resolver-Ressource im VCN.
    2. Fügen Sie die zuvor erstellte private DNS-Ansicht hinzu.
      Die Hosts im sekundären VCN lösen die von den primären Oracle WebLogic Server-Hosts verwendeten Hostnamen mit der privaten Ansicht auf.
  3. Validieren Sie die Auflösung von SECONDARY-Hosts, indem Sie ping und nslookup der Hostnamen ausführen.
    Sie müssen mit den entsprechenden SECONDARY-IPs aufgelöst werden.

    Hinweis:

    Sie finden den Terraform-Code zum Erstellen dieser privaten OCI-Ansicht und dieser Datensätze in GitHub.

Sekundäres System konfigurieren

Um das System als sekundäre Domain zu konfigurieren, müssen Sie die Domainkonfiguration WebLogic Server von der primären in die sekundäre Systemdomain WebLogic Server, Oracle SOA Suite oder Oracle Fusion Middleware kopieren.
Das Disaster Recovery-(DR-)Setup ersetzt alle sekundären Domains, mit Ausnahme spezifischer Verzeichnisse und Dateien, die lokal gültig bleiben müssen. Diese Verzeichnisse werden von den Skripten explizit ausgeschlossen. Darüber hinaus ersetzt das Skript die Datenquellendateien, sodass die sekundäre Datenbank dieselben DB-Schemanamen wie in der primären Datenbank verwendet, die vorhandene jdbc url jedoch auf die lokale Datenbank verweist (aktualisierbarer Klon während DR-Setup und Standbydatenbank zur Vorbereitung für Switchover) mit den erforderlichen Wallets.
  1. Führen Sie das Skript fmwadb_dr_prim.sh im WebLogic Server-Administrationsknoten der Primärdatenbank aus.
    Das Skript prüft die Konnektivität zwischen den WebLogic Server-Administrationsserverknoten über das dynamische Routinggateway und kopiert die Domain in das Staging-Verzeichnis in einem Oracle Cloud Infrastructure File Storage-Mount in der sekundären Region.

    Verwenden Sie die folgenden Parameter:

    • REMOTE_ADMIN_NODE_IP

      Die IP-Adresse des sekundären Administrationsserverknotens WebLogic Server.

      Diese IP muss von diesem HOST (dem primären Oracle WebLogic Server Administration Server-Knoten) aus erreichbar sein.

      Es wird empfohlen, das dynamische Routinggateway zu verwenden, um die primären und sekundären Sites zu verbinden, sodass Sie die private IP-Adresse angeben können.

    • REMOTE_SSH_PRIV_KEYFILE

      Die private SSH-Schlüsseldatei für die Verbindung zum Remoteknoten des Oracle WebLogic-Administrationsservers.

    • FSS_MOUNT

      Das gemountete Verzeichnis für OCI File Storage, mit dem die Kopie der WebLogic Server-Domainkonfiguration bereitgestellt wird. 

    ./fmwadb_dr_prim.sh [REMOTE_ADMIN_NODE_IP] [REMOTE_SSH_PRIV_KEYFILE] [FSS_MOUNT]
    Im Folgenden finden Sie ein Beispiel für den Befehl und die Ausgabe:
    [oracle@soarefr-soa-0 ~]$ ./fmwadbs_dr_prim.sh '10.2.1.104' '/u01/soacs/dbfs/share/KeyWithoutPassPhraseSOAMAA.ppk' /u01/soacs/dbfs/share/
 Checking ssh connectivity to remote WebLogic Administration server node....
    Connectivity to 10.2.1.104 is OK
    REMOTE_ADMIN_HOSTNAME...... soarefr-soa-0.sub09051735411.soaadbvcnstby.oraclevcn.com
 Checking local FSS mount folder readiness........
     The FSS is expected to be mounted in /u01/soacs/dbfs/share
     The folder for the copy of the domain is expected to be /u01/soacs/dbfs/share/domain_config_copy
     Local folder /u01/soacs/dbfs/share/domain_config_copy exists.
 Checking remote FSS mount folder readiness........
     Remote folder 10.2.1.104:/u01/soacs/dbfs/share/domain_config_copy exists.
 
----------- Rsyncing from local domain to local FSS folder ---------------
 
Local rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_local_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
 
----------- Local rsync complete -----------------------------------------
 
----------- Rsyncing from local FSS folder to remote site... --------------
Remote rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_remote_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
  2. Wenn die Ausführung des Skripts fmwadb_dr_prim.sh abgeschlossen ist, stoppen Sie alle WebLogic Server-Systeme und Node Manager im sekundären System, falls noch nicht geschehen.
  3. Melden Sie sich beim WebLogic Server-Administrationsknoten der Sekundärinstanz an, und führen Sie das Skript fmwadb_dr_stby.sh aus.

    Das Skript kopiert die Domain WebLogic Server aus dem Staging-Verzeichnis in einem OCI File Storage-Mount in das sekundäre Domainverzeichnis WebLogic Server und ersetzt die erforderlichen Wallet- und Kennworteinträge. Das bereitzustellende Wallet ist der aktualisierbare Klon, sodass der sekundäre Klon nach dem ersten DR-Setup validiert werden kann.

    Verwenden Sie die folgenden Parameter:

    • WALLET_DIR

      Das Verzeichnis für ein entpacktes Oracle Autonomous Database-Wallet. WebLogic Server-Administrationsserverknoten.

      Dieses Verzeichnis muss mindestens die Dateien tnsnames.ora, keystore.jks und truststore.jks enthalten.

      Wenn Sie die Snapshot Standby-Methode verwenden, ist dies nur der Ordner tnsadmin.

    • WALLET_PASSWORD

      Das Kennwort, das beim Herunterladen des Wallets von der OCI-UI von Oracle Autonomous Database Serverless angegeben wurde.

      Wenn das Wallet das erste Wallet ist, das vom WebLogic Server-, Oracle SOA Suite- oder Oracle Fusion Middleware-System beim Provisioning erstellt wurde. Sie erhalten ihn mit dem folgenden Befehl:

      Oracle SOA:
      python /opt/scripts/atp_db_util.py generate-atp-wallet-password
      Oracle WebLogic Server:
      python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    • FSS_MOUNT

      Das gemountete Verzeichnis für OCI File Storage, mit dem die Domainkonfiguration WebLogic Server bereitgestellt wird. 

    ./fmwadb_dr_stby.sh [WALLET_DIR] [WALLET_PASSWORD] [FSS_MOUNT]
    Im Folgenden finden Sie ein Beispiel für die Befehlsausführung und -ausgabe:
    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_dr_stby.sh /u01/data/domains/wsladbs2_domain/config/atpwallet/  7f3e3ed8ee7921fed058b481298eca55 /u01/shared/
Backing up current domain...
Backup created at /u01/data/domains/wsladbs2_domain/ /u01/data/domains/wsladbs2_domain_backup_11_42_19-26-10-22
Rsyncing from FSS  mount to domain dir...
 Syncing the Weblogic Administration server node...
Rsync complete!
Switching config to /u01/data/domains/wsladbs2_domain/config/atpwallet/
The password provided for the wallet is valid. Proceeding...
Gathering Data Soure information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_11_42_33-26-10-22
Replacing values in datasources...
Replacement complete!
  4. Führen Sie das Skript fmwadb_dr_stby.sh auf den anderen Managed Server-Knoten von WebLogic Server in der sekundären Region aus.
  5. Stellen Sie sicher, dass im Lese-/Schreibmodus auf die Standbydatenbank zugegriffen werden kann.
    • Wenn Sie die Snapshot-Standby-Methode verwenden, stellen Sie sicher, dass die Standbydatenbank in die Snapshot-Standbydatenbank konvertiert wird, sodass sie im Lese-/Schreibmodus zugänglich ist.
    • Wenn Sie den Remote Refreshable Clone-Ansatz verwenden, stellen Sie sicher, dass die Verbindung zur Quelle getrennt ist, sodass sie im Lese-/Schreibmodus zugänglich ist.
  6. Starten Sie Node Manager und Oracle WebLogic Administration Server sekundär. Rufen Sie die Konsole auf, und starten Sie die WebLogic Server-Managed Server in der Domain.
  7. Prüfen Sie, ob die vorhandenen Anwendungen und Deployments in der primären Anwendung auch in der sekundären Anwendung verfügbar sind.
  8. Fahren Sie die WebLogic Servers sekundär herunter.
  9. Konvertieren Sie die Standby-Datenbank in eine physische Standby-Datenbank, oder verbinden Sie den aktualisierbaren Klon erneut.

    • Wenn Sie eine Snapshot-Standby-Methode verwenden, konvertieren Sie die Standbydatenbank in eine physische Standbydatenbank.

    • Wenn Sie Remote Refreshable Clone verwenden, verbinden Sie den aktualisierbaren Klon erneut. Erinnerung: Der aktualisierbare Klon kann nicht länger als 24 Stunden vom primären Klon getrennt werden.

System für Switchover bereit lassen

Nachdem das sekundäre System mit einem aktualisierbaren Klon konfiguriert und validiert wurde, lassen Sie das System für das Switchover bereit, indem Sie den TNS-Alias auf den Standby-Oracle Autonomous Database Serverless verweisen.

Hinweis:

Diese Aufgabe ist nur erforderlich, wenn das sekundäre System mit einem Remote-Aktualisierbaren Klon konfiguriert und validiert wird.

Laden Sie das Wallet für die Standbydatenbank von der sekundären Datenbankbenutzeroberfläche herunter. Vermeiden Sie duale Verbindungszeichenfolgen (sowohl primäre als auch Standbyhosts) in Remote-DR-Fällen, da sie unnötige Wiederholungen verursachen.

  1. Melden Sie sich bei der Oracle Autonomous Database Serverless-Benutzeroberfläche für die Standbydatenbank an.
  2. Klicken Sie auf Autonomous Database, wählen Sie autonomous_db_name aus, klicken Sie auf DB-Verbindung, und klicken Sie dann auf Wallet herunterladen.
  3. Wenn das Wallet duale Zeichenfolgen enthält, die auf die Primärdatenbank verweisen, entfernen Sie den Eintrag der Primärbeschreibung aus der Datei tnsnames.ora, sodass die Verbindungszeichenfolge NUR auf die lokale DB in der sekundären Region verweist.

    Im Folgenden finden Sie eine Beispieländerung der Datei tnsnames.ora: 

    soaadb1_high = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_low = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_medium = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tp = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tpurgent = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))

SHOULD BE

soaadb1_high = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))) 
soaadb1_low = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
  4. Kopieren Sie das Wallet in einen temporären Ordner im Administrationsserverknoten WebLogic Server der sekundären Region, und navigieren Sie zum Verzeichnis.
    [oracle@wsladbs2-wls-0 scripts]$ cd /tmp
[oracle@wsladbs2-wls-0 tmp]$ mkdir wallet-stby
[oracle@wsladbs2-wls-0 tmp]$ cd wallet-stby/
  5. Dekomprimieren Sie das Wallet.
    [oracle@wsladbs2-wls-0 wallet-stby]$ unzip /tmp/Wallet_soaadb1-standby.zip
Archive:  ../Wallet_soaadb1-standby.zip
  inflating: ewallet.pem
  inflating: README
  inflating: cwallet.sso
  inflating: tnsnames.ora
  inflating: truststore.jks
  inflating: ojdbc.properties
  inflating: sqlnet.ora
  inflating: ewallet.p12
  inflating: keystore.jks
  6. Führen Sie das Skript fmwadb_switch_db_conn.sh aus, damit die Middle Tier mit dem sekundären Wallet und der Verbindungszeichenfolge bereit bleibt.

    Im Folgenden finden Sie ein Beispiel für die Skriptausführung, die auf das Standby-Wallet Oracle Autonomous Database Serverless verweist: 

    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_switch_db_conn.sh /tmp/wallet-stby/ wallet_password
The password provided for the wallet is valid. Proceeding...
Gathering Data Source information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_10_38_32-27-10-22
Replacing values in datasources...
Replacement complete!

Laufende Konfigurationsreplikation einrichten

Wenn der Lebenszyklus des Systems Häufigkeitsaktualisierungen für das Domaindateisystem umfasst, können Sie den Konfigurationsreplikationsprozess mit einem Skript automatisieren. Das Skript fmwadb_config_replica.sh repliziert Änderungen regelmäßig über das Staging-Verzeichnis von Oracle Cloud Infrastructure File Storage (OCI File Storage).

Die Konfiguration ist nach jeder Replikation bereit (vorbereitet) für ein Switchover.

Wenn Sie Remote Refreshable Clone verwenden, wird davon ausgegangen, dass die replizierte Konfiguration für die physische Standbydatenbank (nicht den aktualisierbaren Klon) "angepasst" wird. Wenn Sie eine Validierung oder einen Test mit aktualisierbaren Klonen benötigen, können Sie die Konfiguration der Standbydomain so ändern, dass sie stattdessen auf den aktualisierbaren Klon verweist.

Sie müssen das Skript fmwadb_config_replica.sh in den WebLogic Server-Administrationsknoten (in Primär- und Standbydatenbank) ausführen, um die Konfiguration zu replizieren. In der Regel ist dieses Skript mit einem cron-Job geplant, um die Konfiguration zwischen einem primären und einem Standby-System WebLogic Server, Oracle SOA Suite oder Oracle Fusion Middleware auf dem Oracle Autonomous Database-System in regelmäßigen Abständen zu replizieren. Dieses Skript prüft die aktuelle Rolle der lokalen Datenbank, um festzustellen, ob sie auf der Primär- oder Standbysite ausgeführt wird.

  • Wenn das Skript auf der PRIMARY-Site ausgeführt wird, kopiert es die Domainkonfiguration von der primären Domain in den lokalen Assistenzordner (FSS) und dann in den sekundären Siteassistenzordner (über rsync).
  • Wenn das Skript auf der STANDBY-Site ausgeführt wird, kopiert es die Domainkonfiguration aus dem sekundären Assistentenordner (OCI File Storage) in die sekundäre Domain und ersetzt die erforderlichen Ersetzungen, damit Datenquellen mit der lokalen Datenbank arbeiten können.

Sie müssen aus Sicherheitsgründen verschiedene Parameter aus der OCI-Konsole erfassen und das Kennwort für den Zugriff auf die Oracle Autonomous Database-Wallets verschlüsseln.

Im Folgenden werden die Variablen beschrieben, die im Skript verwendet werden, und wie sie abgerufen werden:

  • REMOTE_WLSADMIN_NODE_IP

    IP des Administrationsserverknotens des Peers und des Remotes WebLogic Server.

    Dies ist die IP des Knotenhosts auf dem Administrationsserver WebLogic Server auf der Peer-Site. Er muss vom lokalen Knoten aus erreichbar sein. Es wird empfohlen, mit einem dynamischen Routinggateway eine Verbindung zur privaten Remote-IP des Knotens herzustellen.

  • REMOTE_SSH_PRIV_KEYFILE

    Die private SSH-Schlüsseldatei für die Verbindung zum Remote-Oracle WebLogic-Administrationsserverknoten.

  • TENANCY_OCID

    Die OCID des Mandanten, in dem sich Oracle Autonomous Database befindet. Sie können die OCID von der Oracle Cloud Infrastructure-(OCI-)Benutzeroberfläche (UI) abrufen.

  • USER_OCID

    Die OCID des Benutzers, der Eigentümer der autonomen Datenbankinstanz ist. Sie finden die OCID in der OCI-UI.

  • PRIVATE_KEY

    Pfad zum privaten PEM-Formatschlüssel für diesen Benutzer.

  • LOCAL_ADB_OCID

    Die OCID der Oracle Autonomous Database, die geprüft wird. Sie finden die OCID im Fenster Oracle Autonomous Database in der OCI-Konsole.

  • WALLET_DIR

    Das Verzeichnis für das lokale Oracle Autonomous Database-Wallet (entpacken Sie das aus der OCI-Konsole heruntergeladene Wallet). Dieses Verzeichnis muss mindestens die Dateien tnsnames.ora, keystore.jks und truststore.jks enthalten. Wenn Sie die Snapshot Standby-Methode verwenden, ist dies der Ordner tnsadmin.

  • ENC_WALLET_PASSWORD

    Die WLS-Inkarnation ENCRYPTED des Kennworts, das beim Herunterladen des Wallets von der OCI-UI von Oracle Autonomous Database angegeben wurde.

    Wenn das Wallet das erste Wallet ist, das von WebLogic Server, Oracle SOA Suite oder Oracle Fusion Middleware beim Provisioning von WebLogic Server erstellt wurde, können Sie das Kennwort mit den folgenden Befehlen abrufen:

    Für WebLogic:
    [oracle@wsladbs2-wls-1 ~]$ python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Für SOA:
    [oracle@soarefr-soa-0 ~]$ python /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Um das Kennwort zu verschlüsseln, können Sie das Skript fmw_enc_pwd.sh verwenden, unabhängig davon, ob es in der OCI-Konsole oder beim Provisioning verwendet wird.
    ./fmw_enc_pwd.sh UNENC_WALLET_PASSWORD

    Verwenden Sie die erhaltene Zeichenfolge für die Variable ENC_WALLET_PASSWORD.

  • FSS_MOUNT

    Das gemountete Verzeichnis für OCI File Storage, mit dem die Domainkonfiguration WebLogic Server bereitgestellt wird.

Nachdem Sie die Informationen für die Variablen erfasst haben, führen Sie die folgenden Schritte aus, um die Skripte für Ihre Umgebung zu kopieren und anzupassen:

  1. Verschlüsseln Sie das Kennwort für den Zugriff auf die Oracle Autonomous Database-Wallets aus Sicherheitsgründen.
  2. Kopieren Sie das Skript auf die primäre Site, und bearbeiten Sie das Skript, indem Sie die erforderlichen Variablen für die primäre Site vervollständigen.
    Eine Beschreibung der im Skript verwendeten Variablen finden Sie oben.
  3. Kopieren Sie das Skript auf die Standby Site, und bearbeiten Sie dann das Skript, das die erforderlichen Variablen für die Standby Site enthält.
    Eine Beschreibung der im Skript verwendeten Variablen finden Sie oben.
  4. Führen Sie nach der Anpassung für die Region "ACH" (Sie müssen die OCID der LOCAL-Datenbank für jede Region angeben) die folgenden Aufgaben aus:
    1. Führen Sie das Skript auf dem Oracle WebLogic-Administrationshost in der Primärdatenbank aus.
    2. Führen Sie das Skript auf dem Oracle WebLogic-Administrationshost in der sekundären Region aus.
  5. Fügen Sie das Skript zu einem cron-Job in jeder Region hinzu.