Umgebung konfigurieren

Richten Sie das sekundäre System in OCI ein, und konfigurieren Sie es als Standbydatenbank des primären On-Premise-Systems.

Skripte sind verfügbar, um einige der Schritte zu automatisieren. Diese Skripte automatisieren das vollständige Setup nicht. Sie müssen daher die Aufgaben abschließen und können die Skripte verwenden, wenn sie referenziert werden.

Klicken Sie auf den Link Code herunterladen, um die in diesem Dokument referenzierten Skripte herunterzuladen.

WebLogic-Datenquellen im primären Data Center vorbereiten

Es gibt mehrere Ansätze, die Sie für die Datenbankverbindungszeichenfolge der WebLogic-Datenquellen in einer Disaster-Recovery-Topologie verwenden können, z.B. duale Zeichenfolge, verschiedene Verbindungszeichenfolgen und TNS-Alias. Weitere Informationen und Vergleiche zwischen den verschiedenen Ansätzen finden Sie im Oracle Fusion Middleware Disaster Recovery Guide. TNS-Alias wird verwendet, da ein einmaliges Setup erforderlich ist. Wenn Sie einen TNS-Alias verwenden, müssen Sie die WebLogic-Konfiguration nicht jedes Mal ändern, wenn Sie sie in den sekundären kopieren. Die Verwendung eines TNS-Alias in GridLink-Datenquellen wird ab FMW-Version 12.2.1.3 unterstützt.

Der TNS-Alias ist derselbe Name in der primären und sekundären Datenbank. Daher verwenden die Datenquellen dieselbe DB-Verbindungszeichenfolge. Sie wird mit einer tnsnames.ora-Datei aufgelöst, die nicht in die Standbydatenbank kopiert wird. Daher können Sie in jeder Site unterschiedliche tnsnames.ora-Inhalte verwenden. Sie können sie getrennt von der Domainkonfiguration WebLogic in einem Dateisystem platzieren, das nicht zwischen Sites repliziert wird. Da es Teil der Konfiguration ist, können Sie es auch in einem Ordner unter der Domainkonfiguration speichern. Stellen Sie in diesem Fall sicher, dass Sie diesen Ordner ausschließen, wenn Sie die Domainkonfiguration von der Primär- in die Standbydatenbank kopieren. Jede Site löst den TNS-Alias mit der entsprechenden Verbindungszeichenfolge in jeder Site auf und verweist nur auf die lokale Datenbank. Beispiel: 

Connect string in data sources in primary site:
jdbc:oracle:thin:@soapdb

The tnsnames.ora file in primary contains:
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Connect string in data sources in secondary site:
jdbc:oracle:thin:@soapdb
The tnsnames.ora file in secondary: 
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Die Verwendung des TNS-Alias hat folgende Vorteile:

  • Da dieselbe DB-Verbindungszeichenfolge in der WebLogic-Domain config verwendet wird, müssen Sie die WebLogic-Konfiguration nicht ändern, nachdem Sie die config von der Primär- in die Standbydatenbank repliziert haben.
  • Da jeder Standort nur auf die lokale Datenbank verweist, besteht keine Gefahr von Crossconnections von der Middle Tier zur Remote-Datenbank.

Wenn Sie diesen Ansatz noch nicht im primären SOA-System verwenden, führen Sie die folgenden Schritte aus, um einen TNS-Alias in den Datenquellen zu verwenden.

  1. Erstellen Sie den Ordner tns auf den primären Mid-Tier-Hosts:

    Dieser Ordner muss für den Oracle-Benutzer lesbar sein und in einem Dateisystem abgelegt werden, das nicht zwischen Sites repliziert wird.

    Da der tns-Ordner Teil der Konfiguration ist, können Sie ihn auch unter dem Konfigurationsordner erstellen, der von allen Servern gemeinsam verwendet wird. Stellen Sie in diesem Fall jedoch sicher, dass Sie den tns-Ordner ausschließen, wenn Sie die Domainkonfiguration nach einem Failover oder Switchover von der Primärdatenbank in die Standbydatenbank kopieren oder tnsnames.ora im Standbysystem aktualisieren, um auf die sekundäre Datenbank zu verweisen. 

    [oracle@host3 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@host4 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Erstellen Sie eine tnsnames.ora-Datei im Verzeichnis mit dem TNS-Alias, der in den Datenquellen verwendet wird, wie im Beispiel gezeigt.
    Oracle empfiehlt, die Zeichenfolge in einer einzelnen Zeile einzugeben.
    SOAPDB = 
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=dbhost-scan.example.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME= soapdb.example.com))
)
  3. Geben Sie die Eigenschaft oracle.net.tns_admin an, die auf das Verzeichnis der Datei tnsnames.ora verweist. Verwenden Sie eine der folgenden Methoden:

    • Option 1: Legen Sie die Eigenschaft als Verbindungseigenschaft für die Datenquelle fest. Oracle empfiehlt diese Methode.

      1. Geben Sie die Eigenschaft oracle.net.tns_admin=tns_directory in der Datenquellenkonfiguration an.

        Um diese Eigenschaft in der WebLogic-Administrationskonsole anzugeben, gehen Sie zu Services, klicken Sie auf Datenquellen, wählen Sie eine Datenquelle aus der Liste aus, klicken Sie auf Verbindungspool, und fügen Sie sie dann dem Textfeld "Eigenschaften" hinzu. Wiederholen Sie diesen Schritt für jede Datenquelle.

        Beispiel: oracle.net.tns_admin=/home/oracle/tnsnames_dir

      2. Geben Sie diese Eigenschaft in den OPSS-Sicherheitsspeichern der Dateien jps-config-jse.xml und jps-config.xm an, die im Ordner $ASERVER_HOME/config/fmwconfig verfügbar sind.

        Um diese jps-Dateien zu ändern, bearbeiten Sie sie, und fügen Sie die Eigenschaft oracle.net.tns_admin nach der Eigenschaft jdbc.url hinzu. Beispiel: 

        …
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/>
<property name="oracle.net.tns_admin" value="tns_directory"/>
…

        Hinweis:

        Diese Eigenschaft gilt für die spezifische Datei (Datenquelle, jps-Datei), in der sie angegeben ist.

    • Option 2: Legen Sie die Eigenschaft als JAVA-Systemeigenschaft fest.

      1. Geben Sie die Systemeigenschaft -Doracle.net.tns_admin=tns_directory an, wobei tns_directory der Verzeichnisspeicherort der Datei tnsnames.ora ist.

        Um sie als java-Eigenschaft für die Server festzulegen, bearbeiten Sie die folgenden Dateien:
        • $ASERVER_HOME/bin/setUserOverrides.sh and
        • $MSERVER_HOME/bin/setUserOverrides.sh (Diese Datei wird nicht freigegeben. Daher sollten Sie die Datei auf allen SOA-Mid-Tier-Hosts bearbeiten.)

      2. Fügen Sie diesen Dateien folgenden Inhalt hinzu: 

        # For using tns alias in the datasources 
export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dir

        Hinweis:

        Diese Eigenschaft gilt für alle Datenquellen und jps-Dateien in Oracle WebLogic Server. Bevor Sie einige WLST-Befehle und den Konfigurationsassistenten ausführen, müssen Sie bei dieser Methode die Eigenschaft in der Umgebung festlegen.
        • Legen Sie vor der Ausführung von WLST die Eigenschaft in der Umgebungsvariablen WLST_PROPERTIES fest.
        • Bevor Sie den Konfigurationsassistenten ausführen, fügen Sie die Eigenschaft der Umgebungsvariablen JVM_ARGS des Skripts config_internal.sh hinzu.
      3. Option 3: Legen Sie die Eigenschaft in der URL jdbc fest.

        Geben Sie den Speicherort der Datei tnsnames.ora als Teil der Verbindungszeichenfolge in den Datenquellen und jps-Dateien an: 

        jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directory

      Hinweis:

      Diese Eigenschaft gilt für die spezifische Datei (Datenquelle, jps-Datei), in der sie angegeben ist.

      Sie können diese Methode mit JDBC-Treiber 18.3 und höher verwenden. Dies gilt für Fusion Middleware 12.2.1.4 (der JDBC-Treiber 19.3 verwendet) und höher.

  4. Verwenden Sie den Alias in der Datenquellendefinitions-URL, indem Sie die Verbindungszeichenfolge durch den Alias ersetzen.
    jdbc:oracle:thin:@soapdb
    Ändern Sie die folgenden Dateien:
    • In Datenquellendateien unter $ASERVER_HOME/config/jdbc/
    • In den Dateien jps-config.xml und jps-config-jse.xml in $ASERVER_HOME/config/fmwconfig/
    Sie können die Datenquellen mit der Oracle WebLogic Server-Administrationskonsole ändern. Sie müssen die jps-config xml-Dateien jedoch manuell bearbeiten. Mit dem Skript update_dbconnect.sh können Sie die Ersetzung in allen genannten Dateien durchführen.

    Gehen Sie zu Code herunterladen, um den Link zum Herunterladen des Skripts anzuzeigen.

  5. Starten Sie jeden Oracle WebLogic Server in der Domain neu.
    1. Stoppen Sie alle WebLogic-Server in der primären Domain (Admin-Server und Managed Server).
    2. Starten Sie den Administration Server in der primären Domain.
    3. Starten Sie nach der Ausführung des Administration Servers die Managed Server.
    4. Prüfen Sie, ob die Verbindungen mit der Datenbank korrekt hergestellt wurden.
  6. Zusätzliche Best Practice: Wenn Sie eine Oracle Database 12c-Version oder eine höhere Version verwenden, sind die Konfigurationswerte für den Oracle Notification Service (ONS)-Host und -Port in den GridLink-Datenquellen nicht erforderlich.
    Die Oracle Notification Service-Liste wird vom Clienttreiber automatisch aus der Datenbank abgerufen. Oracle empfiehlt, dieses Feature zu verwenden, anstatt die Scanadresse oder die Liste der Oracle RAC-Knoten in der ONS-Konfiguration jeder Datenquelle anzugeben. Stellen Sie sicher, dass FAN aktiviert ist und dass die Eigenschaft ONS nodes in jeder Datenquelle leer ist.
    1. Öffnen Sie die Oracle WebLogic Server-Administrationskonsole.
    2. Gehen Sie zu Services, Datenquellen. Wählen Sie den Namen der Datenquelle, Konfiguration und ONS aus.
    3. Stellen Sie sicher, dass die ONS-Knotenliste leer ist.

Netzwerk konfigurieren

Die Konnektivität ist zwischen dem primären On-Premise-Netzwerk und dem sekundären Oracle Cloud Infrastructure-(OCI-)Netzwerk erforderlich. Oracle empfiehlt die Verwendung von Oracle Cloud Infrastructure FastConnect, mit dem Sie über eine dedizierte, private Verbindung mit hoher Bandbreite eine direkte Verbindung zu Ihrem virtuellen OCI-Cloud-Netzwerk herstellen können. Je nach Datenmenge wählen Sie eine geeignete Portgeschwindigkeit aus. Alternativ können Sie Site-to-Site-VPN verwenden, obwohl es niedrigere Bandbreite und variable Latenz, Jitter und Kosten bietet.
  1. Erstellen Sie das VCN und die Subnetze im OCI-Compartment gemäß der Definition unter Auf OCI erforderliche Ressourcen bestimmen. Konfigurieren Sie Oracle Cloud Infrastructure FastConnect (oder Site-to-Site-VPN), um die Kommunikation zwischen Ihrem On-Premise-Netzwerk und dem VCN zu ermöglichen. Weitere Informationen finden Sie unter FastConnect und Site-to-Site-VPN.
  2. Erstellen Sie die erforderlichen Netzwerkregeln in OCI und in der On-Premise-Firewall, und konfigurieren Sie die Quelle, Ziele, Protokolle und Ports, wie in der Tabelle gezeigt.

    Es wird davon ausgegangen, dass der gesamte Traffic innerhalb jedes Subnetzes aktiviert ist.

    Informationen zu Netzwerksicherheitsregeln finden Sie in der OCI-Dokumentation.

    Quelle Target Protokoll und Port Verwendung
    On-Premise-Netzwerk OCI-Mid-Tier-Subnetz SSH (Port 22) Setup und Lebenszyklus
    On-Premise-Netzwerk OCI-Web-Tier-Subnetz SSH (Port 22) Setup und Lebenszyklus (wenn Oracle HTTP Server in OCI verwendet wird)
    On-Premise-Netzwerk OCI-DB-Tier-Subnetz SSH (Port 22) Setup und Lebenszyklus
    On-Premise-DB-Hosts OCI-DB-Tier-Subnetz SQLNET (Port 1521) Für Oracle Data Guard redo transport
    On-Premise-Netzwerk OCI-Web-Tier-Subnetz HTTPS/HTTP (443, 80, 7001, 8888) Zugriff auf Oracle SOA Suite-Services und -Administrationskonsolen
    On-Premise-Netzwerk OCI-Mid-Tier-Subnetz HTTP (7001,7010,8001,8011,8021,9001) Für direkte Prüfungen an Oracle WebLogic Server
    OCI-Web-Tier-Subnetz OCI-Mid-Tier-Subnetz HTTP (7001,7010,8001,8011,8021,9001) Für Konnektivität von den Web-Tier-Komponenten (OCI Load Balancer, Oracle HTTP Server) zu WebLogic-Servern
    OCI-Mid-Tier-Subnetz OCI-DB-Tier-Subnetz SQLNET (1521), ONS (6200) Für Konnektivität von WebLogic Servers zur Datenbank
    OCI-Mid-Tier-Subnetz OCI-SS-Tier-Subnetz Spezifische Informationen finden Sie unter VCN-Sicherheitsregeln für File Storage konfigurieren. So mounten Sie die OCI File Storage-Dateisystemexporte mit NFS.
    OCI-Mid-Tier-Subnetz On-Premise-Mid-Tier-Hosts SSH (Port 22) Für rsync
    OCI-DB-Tier-Subnetz On-Premise-DB-Hosts SQLNET (1521) Für Oracle Data Guard redo transport
    OCI-Mid-Tier-Subnetz OCI-Web-Tier-Subnetz HTTPS (FERNSEHSERIE) (443) Für Rückrufe von der Anwendung zum Frontend

    Hinweis:

    Unter Downloadcode finden Sie Terraformcode zum Erstellen des VCN, der Subnetze und der Sicherheitsregeln.

Oracle Data Guard konfigurieren

Konfigurieren Sie Oracle Data Guard zwischen der primären On-Premise-Datenbank und der Standbydatenbank in Oracle Cloud Infrastructure (OCI).
  1. Konfigurieren Sie Oracle Data Guard zwischen einer primären On-Premise-Datenbank und einer Standbydatenbank in OCI, wie unter Hybrid Data Guard zu Oracle Cloud Infrastructure beschrieben.
    Um die Konfiguration von Oracle Data Guard zu unterstützen, sind Skripte in GitHub verfügbar und werden unter Code herunterladen referenziert.
  2. Prüfen Sie mit der Oracle Data Guard-Befehlszeilenschnittstelle (DGMGRL), ob das Oracle Data Guard-Setup korrekt ist.
    DGMGRL> show configuration verbose
  3. Nachdem Sie die Konfiguration von Oracle Data Guard (Schritt 2) abgeschlossen haben, erstellen Sie dieselben Datenbankservices im OCI-DB-System wie im primären On-Premise-System. Konfigurieren Sie den Service mit der Rolle PRIMARY und mit der Rolle SNAPSHOT_STANDBY.
    Durch die Konfiguration des Service mit beiden Rollen kann der Service automatisch von DG Broker gestartet werden, wenn die Datenbank in eine Snapshot-Standbydatenbank konvertiert wird. Dies ist erforderlich, wenn Sie das sekundäre System ohne vollständiges Switchover validieren möchten.
    Beispiel: Wenn die Primärdatenbank den Datenbankservice soapdb.example.com für den Zugriff auf die PDB verwendet, erstellen Sie denselben Service im sekundären OCI-DB-System. 
    srvctl add service -db $ORACLE_UNQNAME -service soapdb.example.com -preferred ORCL1,ORCL2 -pdb PDB1 -role "PRIMARY,SNAPSHOT_STANDBY"
srvctl modify service -db $ORACLE_UNQNAME -service soapdb.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
srvctl config service -db $ORACLE_UNQNAME -service soapdb.example.com
  4. Wenn der Service in der Primärdatenbank nur mit der Rolle PRIMARY erstellt wurde (Standard), können Sie ihn ändern, um die Snapshot-Standbydatenbankrolle hinzuzufügen.
    srvctl modify service -db $ORACLE_UNQNAME -s soapdb.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. Prüfen Sie die Oracle Recovery Manager-(RMAN-)Policys in der Primärdatenbank, um zu verhindern, dass die Archive-Logs gelöscht werden, bevor sie auf die Standbydatenbank angewendet werden.
    Stellen Sie sicher, dass die Klausel applied on all standby in der Lösch-Policy archivelog von RMAN in der Primär- und Standbydatenbank vorhanden ist.

Datenbankversion und Patchebene

Das Oracle Home in der On-Premise-Datenbank und die Standbydatenbank auf OCI müssen dieselbe Version und dieselbe Patchebene aufweisen. Gehen Sie dazu wie folgt vor:

  • Wenn Sie das Datenbanksoftwareimage beim Provisioning des DB-Systems in OCI auswählen, wählen Sie Alle Versionen anzeigen aus, und wählen Sie dieselbe Datenbankversion und Patchsetebene wie die On-Premise-Datenbank aus.
  • Wenn die Oracle Home-Version der Quelldatenbank nicht mehr in OCI für das Provisioning verfügbar ist, müssen Sie die Quellumgebung auf dieselbe Datenbankpatch-Ebene patchen wie das Datenbank-Home in der Cloud-Umgebung.

Das folgende Szenario ist ein echtes Beispiel für eine Referenz. Das On-Premise-DB-Home ist 19.6 und das OCI-DB-Home ist 19.11.

  1. Führen Sie den Befehl $ORACLE_HOME/OPatch/opatch lspatches aus, um die Patches zu identifizieren, die in der Quell- und Zielumgebung installiert sind.
    $ORACLE_HOME/OPatch/opatch lspatches

    Die folgende Ausgabe wird in diesem Beispiel angezeigt:

    DB-Oracle Home-Patches On Premise DB Oracle HOME-Patches auf OCI

    30676209;LNX64-20.1-RAC ASM-HIT ORA-07445 AUSNAHME AUFGETRETEN CORE-DUMP [KSXPOSDIFQRY()+556]

    30613937; IPCOR TOPO SERVICE FIX IP TYP BUG IN IP-AUSWAHL

    30484981;OJVM RELEASE-UPDATE: 19.6.0.0.200114 (30484981)

    30489227;OCW RELEASE-UPDATE 19.6.0.0.0 (30489227)

    30557433;Datenbankreleaseupdate : 19.6.0.0.200114 (30557433)

    29780459;ERHÖHEN SIE _LM_RES_HASH_BUCKET UND ENTFERNEN SIE ÄNDERUNGEN AUS DEM BUG 29416368 FIX

    30310195;DBSAT MELDETE DEAKTIVIERTE CONSTRAINTS FÜR SHARDING STS_CHUNKS AUF GSMADMIN_INTERNAL.SHARD_TS

    32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E

    31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A

    30432118;ZUSAMMENFASSUNGSANFORDERUNG OBEN VON 19.0.0.0.0 FÜR BUGS 28852325 29997937

    31732095;PERL IN 19C DATABASE ORACLE HOME AUF V5.32 AKTUALISIEREN

    32490416;JDK BUNDLE-PATCH 19.0.0.0.210420.

    32399816;OJVM RELEASE-UPDATE: 19.11.0.0.210420 (32399816)

    32579761;OCW RELEASE-UPDATE 19.11.0.0.0 (32579761)

    32545013;Datenbankreleaseupdate : 19.11.0.0.210420 (32545013)
  2. Vorhandene Patches analysieren: Bestimmen Sie, welche Patches einmalig sind, prüfen Sie, ob sie bereits in den neuen RU-Patches behoben sind oder ob neue Überlappungspatches erforderlich sind, bestimmen Sie, welche von ihnen deinstalliert werden müssen, suchen Sie die entsprechenden Patchdateien für RU usw.
  3. Deinstallieren Sie basierend auf der Analyse die One-off-Patches, die bereits in der neuen RU behoben sind, bevor Sie das RU-Update installieren (sonst verursachen sie Konflikte). In diesem Beispiel werden die On-Off-Patches in Version 19.11 korrigiert. Daher müssen die Patches vor der Installation des 19.11 RU zurückgesetzt werden.
    30676209;LNX64-20.1-RAC  ASM HIT ORA-07445  EXCEPTION ENCOUNTERED  CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE  FIX IP TYPE BUG IN IP SELECTION
  4. Suchen, herunterladen und installieren Sie die RU-Patches. In diesem Beispiel befinden sich die 19.11 RU-Patches im COMBO-Patch 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 und lauten wie folgt:
    32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)  
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)            
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
  5. Suchen, laden und installieren Sie die Overlays, One-offs und anderen Patches, die das OCI-DB-Home auf der RU hat. Beispiel: 
    29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS
30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update)
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
  6. Führen Sie eine ähnliche Analyse für die GI-Patches durch.

Hinweis:

Dieses Beispiel enthält nur das RDBMS-Oracle Home. Das Patchen der lokalen GI-Installation auf derselben Ebene wie die sekundäre ist möglicherweise nicht unbedingt erforderlich:
  • Aus Sicht von Oracle Data Guard ist es nicht unbedingt erforderlich, dieselben GI-Versionen in der Primär- und Standbydatenbank zu verwenden: Oracle Data Guard ist völlig unabhängig von allem in der Datenbank, sodass Sie verschiedene Versionen des Betriebssystems, der Oracle Clusterware-, Hardware- oder Speichersoftware über verschiedene Sites hinweg ohne Einschränkungen bei Versionen oder Zeit ausführen können. (Doc-ID 1265700.1)
  • Unabhängig von Oracle Data Guard muss in einer RAC-DB nicht dieselbe Version in GI- und RDBMS-Versionen vorhanden sein: Ab 18c muss die Version von Oracle Grid Infrastructure (GI)/Clusterware (CRS) immer gleich oder die höchste Version bis zur ersten Ziffer in den möglichen Kombinationen sein. Beispiel: Grid Infrastructure kann unter 18.1.0.0 und Database unter 18.3.0.0 sein. (Doc ID 337737.1)

Es empfiehlt sich, GI auf derselben Ebene wie das DB-Home zu patchen. Wenn Sie das DB-Home mit einem neueren Releaseupdate (RU) patchen müssen, sind viele der Patches für DB und GI üblich, und Sie können OPatchAuto für beide Homes gleichzeitig verwenden.