1. Hybrid-DR-Lösung für Oracle SOA Suite konfigurieren
  2. Umgebung konfigurieren

Umgebung konfigurieren

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

Mit Skripten lassen sich einige der Schritte automatisieren. Diese Skripte automatisieren nicht das vollständige Setup. Daher müssen Sie die Aufgaben abschließen und können die Skripte verwenden, wenn sie referenziert werden.

Unter Code herunterladen finden Sie den Link zum Herunterladen der Skripte, auf die in diesem Dokument verwiesen wird.

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, wie Dual String, verschiedene Verbindungszeichenfolgen und TNS-Alias. Weitere Details und einen Vergleich zwischen den verschiedenen Ansätzen finden Sie im Oracle Fusion Middleware Disaster Recovery Guide. Der TNS-Alias wird verwendet, da eine einmalige Einrichtung erforderlich ist. Die Verwendung eines TNS-Alias bedeutet, dass Sie die WebLogic-Konfiguration nicht jedes Mal ändern müssen, wenn Sie sie in die sekundäre kopieren. Die Verwendung eines TNS-Alias in GridLink-Datenquellen wird beim Starten der FMW-Version 12.2.1.3 unterstützt.

Der TNS-Aliasname ist im primären und sekundären Namen. 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 einen anderen tnsnames.ora-Inhalt verwenden. Sie können es separat von der Domainkonfiguration WebLogic in einem Dateisystem speichern, das nicht zwischen Sites repliziert wird. Wenn sie Bestandteil der Konfiguration ist, können Sie sie 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ären in die Standby-Datenbank kopieren. Jede Site löst den TNS-Alias mit der entsprechenden Verbindungszeichenfolge in jeder Site auf, die nur auf die lokale Datenbank verweist. 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 bietet folgende Vorteile:

  • Da dieselbe DB-Verbindungszeichenfolge in der WebLogic-Domain config verwendet wird, müssen Sie die WebLogic-Konfiguration nicht ändern, nachdem Sie config von der primären in die Standby-Datenbank repliziert haben.
  • Da jede Site nur auf die lokale Datenbank verweist, besteht kein Risiko von Crossconnections zwischen der Middle Tier und der Remote-Datenbank.

Wenn Sie diese Lösung 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 vom 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 von der Primärdatenbank in die Standbydatenbank kopieren oder tnsnames.ora im Standbysystem nach einem Failover oder Switchover aktualisieren, um auf die Sekundärdatenbank 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 dargestellt.
    Oracle empfiehlt, die Zeichenfolge in einer einzigen 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 Datenquellkonfiguration an.

        Um diese Eigenschaft in der WebLogic-Administrationskonsole anzugeben, gehen Sie zu Services, klicken Sie auf Datenquellen, wählen 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 der OPSS-Sicherheit an, um die im Ordner $ASERVER_HOME/config/fmwconfig verfügbaren Dateien jps-config-jse.xml und jps-config.xm zu speichern.

        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, Datei jps), 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 es 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 Hosts der SOA-Mid-Tier bearbeiten.)

      2. Fügen Sie diesen Dateien den 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 der WLST-Befehle und den Konfigurationsassistenten ausführen, müssen Sie diese Eigenschaft in der Umgebung festlegen.
        • Legen Sie die Eigenschaft in der Umgebungsvariablen WLST_PROPERTIES fest, bevor Sie WLST ausführen.
        • 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 jdbc-URL fest.

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

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

      Hinweis:

      Diese Eigenschaft gilt für die spezifische Datei (Datenquelle, Datei jps), 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 (verwendet JDBC-Treiber 19.3) und höher.

  4. Verwenden Sie den Alias in der URL der Datenquellendefinition, indem Sie die Verbindungszeichenfolge durch den Alias ersetzen.
    jdbc:oracle:thin:@soapdb
    Ändern Sie die folgenden Dateien:
    • In Datenquelldateien unter $ASERVER_HOME/config/jdbc/
    • In den Dateien jps-config.xml und jps-config-jse.xml unter $ASERVER_HOME/config/fmwconfig/
    Sie können die Datenquellen mit der Oracle WebLogic Server-Administrationskonsole ändern, 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.

    Unter Code herunterladen finden Sie den Link zum Herunterladen des Skripts.

  5. Starten Sie jede 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. Nachdem der Administrationsserver ausgeführt wurde, starten Sie die verwalteten Server.
    4. Prüfen Sie, ob die Verbindungen korrekt mit der Datenbank hergestellt wurden.
  6. Zusätzliche Best Practice: Wenn Sie eine Oracle Database 12c- oder höhere Version verwenden, sind die Konfigurationswerte für Oracle Notification Service (ONS)-Host und -Port in den Datenquellen GridLink 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 Administration-Konsole.
    2. Gehen Sie zu Services, Datenquellen. Wählen Sie den Datenquellennamen, Konfiguration und ONS aus.
    3. Stellen Sie sicher, dass die ONS-Knotenliste leer ist.

Netzwerk konfigurieren

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. Sie wählen eine geeignete Portgeschwindigkeit basierend auf der Datenmenge aus. Alternativ können Sie Site-to-Site-VPN verwenden, obwohl es geringere Bandbreite und variable Latenz, Jitter und Kosten bietet.
  1. Erstellen Sie das VCN und die Subnetze im OCI-Compartment, wie unter Ermitteln der auf OCI erforderlichen Ressourcen definiert. 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 Quelle, Ziele, Protokolle und Ports, wie in der Tabelle dargestellt.

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

    Informationen zu Netzwerksicherheitsregeln finden Sie in der OCI-Dokumentation.

    Quelle Ziel 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 Servers
    OCI-Web-Tier-Subnetz OCI Mid-Tier-Subnetz HTTP (7001.7010.8001.8011.8021.9001) Für die 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) Zur Konnektivität von WebLogic-Servern mit der Datenbank
    OCI Mid-Tier-Subnetz OCI-FSS-Tier-Subnetz Weitere 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-Middle Tier-Hosts SSH (Port 22) Für rsync
    OCI-DB-Tier-Subnetz On-Premise-Datenbankhosts SQLNET (1521) Für Oracle Data Guard redo transport
    OCI Mid-Tier-Subnetz OCI-Web-Tier-Subnetz HTTPS (443) Für Rückrufe von der Anwendung an das 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 Oracle Data Guard zu konfigurieren, sind Skripte in GitHub verfügbar und werden in 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 Oracle Data Guard konfiguriert haben (Schritt 2), erstellen Sie dieselben Datenbankservices im OCI-DB-System wie im primären On-Premise-System. Konfigurieren Sie den Service mit der PRIMARY-Rolle und der SNAPSHOT_STANDBY-Rolle.
    Durch die Konfiguration des Service mit beiden Rollen kann der Service automatisch von DG Broker gestartet werden, wenn die Datenbank in eine Snapshot Standby-Datenbank konvertiert wird. Dies ist erforderlich, wenn Sie das sekundäre System validieren möchten, ohne einen vollständigen Switchover durchzuführen.
    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ären Datenbank nur mit der Rolle PRIMARY (Standard) erstellt wurde, können Sie ihn ändern, um die Snapshot Standby-Rolle 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ären Datenbank, um zu verhindern, dass die Archive Logs gelöscht werden, bevor sie auf die Standby-Datenbank 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 der Standbydatenbank vorhanden ist.

Informationen zu Datenbankversion und Patchebene

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

  • Wenn Sie das Datenbanksoftwareimage während des DB-System-Provisionings in OCI auswählen, wählen Sie Alle Versionen anzeigen aus, und wählen Sie dieselbe Datenbankversion und dieselbe Patchset-Ebene wie bei der 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 derselben Datenbank-Patch-Ebene wie das Datenbank-Home in der Cloud-Umgebung patchen.

Das folgende Szenario ist ein echtes Beispiel für Referenzzwecke. 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 in der Quell- und Zielumgebung installierten Patches zu identifizieren.
    $ORACLE_HOME/OPatch/opatch lspatches

    In diesem Beispiel wird folgende Ausgabe ausgegeben:

    DB-Patches für Oracle Home 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-RELEASEUPDATE: 19.6.0.0.200114 (30484981)

    30489227;OCW-RELEASEUPDATE 19.6.0.0.0 (30489227)

    30557433;Datenbankreleaseupdate: 19.6.0.0.200114 (30557433)

    29780459;ERHÖHEN _LM_RES_HASH_BUCKET UND ZURÜCKSETZEN VON ÄNDERUNGEN VOM BUG 29416368 FIX

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

    32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E

    31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A

    30432118;ZUSAMMENFÜHRUNGSANFORDERUNG OBEN AM 19.0.0.0.0 FÜR BUGS 28852325 29997937

    31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32

    32490416;JDK-BUNDLE-PATCH 19.0.0.0.210420

    32399816;OJVM-RELEASEUPDATE: 19.11.0.0.210420 (32399816)

    32579761;OCW-RELEASEUPDATE 19.11.0.0.0 (32579761)

    32545013;Datenbankreleaseupdate: 19.11.0.0.210420 (32545013)
  2. Analysieren Sie die vorhandenen Patches: Bestimmen Sie, welche Patches One-offs sind, prüfen Sie, ob sie bereits in den neuen RU-Patches korrigiert sind oder ob neue Überlappungspatches benötigt werden, bestimmen Sie, welche Patches 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 korrigiert wurden, bevor Sie das RU-Update installieren (sonst verursachen sie Konflikte). In diesem Beispiel werden die On-off-Patches in 19.11 korrigiert, sodass die Patches vor der Installation der 19.11 RU zurückgerollt werden müssen.
    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. RU-Patches suchen, herunterladen und installieren. In diesem Beispiel befinden sich die 19.11 RU-Patches im Kombinations-Patch 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 und sind:
    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, herunterladen und installieren Sie die Überlagerungen, One-offs und anderen Patches, die das OCI-DB-Home über der RU enthält. 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 Patching der On-Premise-GI-Installation auf derselben Ebene wie bei der sekundären Installation ist möglicherweise nicht unbedingt erforderlich:
  • Aus Sicht von Oracle Data Guard ist es nicht unbedingt erforderlich, dass dieselben GI-Versionen in der Primär- und Standbydatenbank vorhanden sind: Oracle Data Guard ist völlig unabhängig von der Datenbank, sodass Sie verschiedene Versionen des Betriebssystems, Oracle Clusterware, Hardware oder Speichersoftware auf verschiedenen Sites ohne Einschränkungen bei Versionen oder Zeit ausführen können. (Dokument-ID 1265700.1)
  • Unabhängig von Oracle Data Guard muss dieselbe Version in GI- und RDBMS-Versionen in einer RAC-DB nicht mehr verwendet werden: Ab 18c muss die Oracle Grid Infrastructure-(GI-)/Clusterware-(CRS-)Version jederzeit bis zur ersten Stelle in den möglichen Kombinationen gleich oder die höchste Version sein. Beispiel: Grid Infrastructure kann unter 18.1.0.0 und Database unter 18.3.0.0 gespeichert sein. (Dokument-ID 337737.1)

Es wird empfohlen, GI auf derselben Ebene wie das DB-Home zu patchen. Wenn Sie das DB-Home in einem neueren Releaseupdate (RU) patchen müssen, werden viele der Patches für DB und GI häufig verwendet. Außerdem können Sie OPatchAuto für beide Homes gleichzeitig verwenden.