Oracle Cloud Infrastructure-Dokumentation

Exadata Cloud Infrastructure-Systeme manuell patchen und aktualisieren

In diesem Thema werden die Prozeduren für das Patchen und Aktualisieren verschiedener Komponenten in Exadata Cloud Service außerhalb der Cloud-Automatisierung beschrieben.

Informationen zum Patchen und Aktualisieren mit dbaascli finden Sie unter "Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen".

Hinweis

Weitere Informationen zum Erzielen eines kontinuierlichen Service während Patching-Vorgängen finden Sie im Whitepaper Anwendungscheckliste für kontinuierlichen Service für MAA-Lösungen.

Verwandte Themen

Übergeordnetes Thema: Exadata Cloud Infrastructure-Systeme patchen und aktualisieren

Oracle Database- und Oracle Grid Infrastructure-Software manuell patchen

Bei Sommerzeit- und einigen Routine- oder One-off-Patches müssen Sie die Software möglicherweise manuell patchen.

Um das routinemäßige Patching von Oracle Database- und Oracle Grid Infrastructure-Software durchzuführen, empfiehlt Oracle, die von Oracle Exadata Database Service on Dedicated Infrastructure bereitgestellten Funktionen zu verwenden. Unter bestimmten Umständen kann es jedoch erforderlich sein, die Oracle Database- oder Oracle Grid Infrastructure-Software manuell zu patchen:
  • Sommerzeit-Patching: Weil Patches für die Sommerzeitdefinitionen von Oracle Database nicht im Rolling-Verfahren eingespielt werden können, sind sie nicht in den Routinepatchsets für Exadata Cloud Infrastructure enthalten. Patches für die Sommerzeitdefinitionen von Oracle Database müssen Sie manuell einspielen. Siehe My Oracle Support-Dokument-ID 412160.1.
  • Nicht routinemäßiges oder One-off-Patching: Wenn ein Problem auftritt, das einen Patch erfordert, der nicht in einem Routinepatchset enthalten ist, arbeiten Sie mit Oracle Support Services zusammen, um den richtigen Patch zu finden und einzuspielen.

Allgemeine Informationen zum Patching von Oracle Database finden Sie in den Informationen zu Patchsetupdates und Anforderungen in der Upgradedokumentation zu Oracle Database für Ihr Release.

Exadata Cloud-VM-Cluster-BS manuell aktualisieren

Sie können die Betriebssysteme von Exadata-Compute Nodes mit dem Tool patchmgr aktualisieren.

Dieses Utility verwaltet die gesamte Remoteaktualisierung eines oder mehrerer Compute Nodes, einschließlich der Schritte vor, während und nach dem Neustart. Sie können das Utility entweder auf einem Exadata-Compute Node oder auf einem anderen Server mit Oracle Linux ausführen. Der Server, auf dem Sie das Utility ausführen, wird als "steuerndes System" bezeichnet. Sie können das steuernde System nicht für sein eigenes Update verwenden. Wenn das steuernde System einer der Exadata-Compute Nodes in einem System ist, das Sie aktualisieren, müssen Sie daher einen separaten Vorgang auf einem anderen steuernden System ausführen, um diesen Server zu aktualisieren.

Die folgenden beiden Szenarios beschreiben typische Methoden zur Durchführung der Updates:

Szenario 1: Nicht-Exadata-System als steuerndes System

Die einfachste Möglichkeit zum Aktualisieren des Exadata-Systems ist ein Update aller Exadata-Compute Nodes im System mit einem separaten Oracle Linux-Server.

Szenario 2: Exadata-Knoten als steuerndes System

Sie können einen Exadata-Compute Node verwenden, um die Updates für die restlichen Compute Nodes im System zu steuern, und anschließend mit einem der aktualisierten Knoten das Update auf dem ursprünglichen Exadata-Treiberknoten steuern.

Beispiel: Sie aktualisieren ein Exadata-Half-Rack-System mit vier Compute Nodes: node1, node2, node3 und node4. Verwenden Sie zunächst node1, um die Aktualisierungen von node2, node3 und node4 zu steuern. Verwenden Sie anschließend node2, um die Aktualisierung von node1 zu steuern.

Das steuernde System benötigt SSH-Zugriff mit dem Root-Benutzer auf jeden Compute Node, der vom Utility aktualisiert wird.

Übergeordnetes Thema: Exadata Cloud Infrastructure-Systeme manuell patchen und aktualisieren

BS-Aktualisierungen vorbereiten

Ermitteln Sie die neueste verfügbare Softwareversion, und prüfen Sie die Konnektivität zum richtigen yum-Repository.

Achtung:

Installieren Sie NetworkManager nicht auf der Exadata Cloud Infrastructure-Instanz. Wenn Sie dieses Package installieren und das System neu starten, führt dies zu einem weitreichenden Zugriffsverlust auf das System.
  • Bevor Sie mit den Aktualisierungen beginnen, lesen Sie das Dokument Exadata Cloud Service Software Versions (Dok.-ID 2333222.1), um die neueste zu verwendende Software- und Zielversion zu ermitteln.
  • Bei einigen Schritten im Aktualisierungsprozess müssen Sie ein YUM-Repository angeben. Die URL des YUM-Repositorys lautet: 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    Regions-IDs sind Textzeichenfolgen, mit denen Oracle Cloud Infrastructure-Regionen identifiziert werden (Beispiel: us-phoenix-1). Eine vollständige Liste der Regions-IDs finden Sie unter Regionen.

    Sie können den folgenden curl-Befehl ausführen, um die neueste Version des YUM-Repositorys für Ihre Exadata Cloud Service-Instanzregion zu ermitteln: 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    In diesem Beispiel wird die neueste Version des YUM-Repositorys für die Region "US West (Phoenix)" zurückgegeben: 
    curl -s -X GET http://yum-us-phoenix-1.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
<a href="18.1.4.0.0/">18.1.4.0.0/</a> 01-Mar-2018 03:36 -
  • Um BS-Updates einspielen zu können, muss das VCN des Systems so konfiguriert sein, dass der Zugriff auf das YUM-Repository möglich ist. Weitere Informationen finden Sie unter Option 2: Servicegatewayzugriff auf Object Storage und YUM-Repositorys.

So aktualisieren Sie das Betriebssystem auf allen Compute Nodes einer Exadata Cloud Infrastructure-Instanz

Prozedur zum Aktualisieren aller Compute Nodes mit patchmgr.

Die folgende Prozedur basiert auf folgenden Annahmen:

  • Das System verfügt über zwei Compute Nodes: node1 und node2.
  • Die Zielversion ist 18.1.4.0.0.180125.3.
  • Jeder der zwei Knoten wird als steuerndes System für die Aktualisierung auf dem jeweils anderen Knoten verwendet.
  1. Erfassen Sie die Umgebungsdetails.
    1. Stellen Sie mit SSH als Benutzer root eine Verbindung zu node1 her, und führen Sie den folgenden Befehl aus, um die Exadata-Version zu ermitteln:
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. Wechseln Sie zum Benutzer "grid", und identifizieren Sie alle Compute Nodes im Cluster.
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. Konfigurieren Sie das steuernde System.
    1. Wechseln Sie zurück zum Benutzer root auf node1, und prüfen Sie, ob bereits ein SSH-Schlüsselpaar (id_rsa und id_rsa.pub) vorhanden ist. Falls nicht, generieren Sie es.
      [root@node1 .ssh]#  ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory
[root@node1 .ssh]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.fraad1client.exadataclientne.oraclevcn.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. Verteilen Sie den Public Key an die Zielknoten, und verifizieren Sie diesen Schritt. In diesem Beispiel gibt es nur den Zielknoten node2.
      [root@node1 .ssh]# scp -i ~opc/.ssh/id_rsa ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
id_rsa.pub

[root@node2 ~]# ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
[root@node2 ~]# date
Wed Feb 28 03:33:45 UTC 2018
    3. Fügen Sie auf dem Zielknoten (node2 im Beispiel) den Root Public Key von node1 zur Root-Datei authorized_keys hinzu.
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Laden Sie dbserver.patch.zip als p21634633_12*_Linux-x86-64.zip auf das steuernde System (in diesem Beispiel node1) herunter, und dekomprimieren Sie die Datei. Informationen zu den Dateien in diesem ZIP-Archiv finden Sie unter dbnodeupdate.sh and dbserver.patch.zip: Updating Exadata Database Server Software with the DBNodeUpdate Utility and patchmgr (Dok.-ID 1553103.1).
      [root@node1 patch]# mkdir /root/patch
[root@node1 patch]# cd /root/patch
[root@node1 patch]# unzip p21634633_181400_Linux-x86-64.zip
Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
   creating: dbserver_patch_5.180228.2/ibdiagtools/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
  inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
 extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
  inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
   creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
  inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
   creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
  inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
  inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
  inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
  inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
  inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
   creating: dbserver_patch_5.180228.2/linux.db.rpms/
  inflating: dbserver_patch_5.180228.2/md5sum_files.lst
  inflating: dbserver_patch_5.180228.2/patchmgr
  inflating: dbserver_patch_5.180228.2/xcp
  inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
  inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
  inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
  inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
  inflating: dbserver_patch_5.180228.2/exadata.img.env
  inflating: dbserver_patch_5.180228.2/README.txt
  inflating: dbserver_patch_5.180228.2/exadataLogger.pm
  inflating: dbserver_patch_5.180228.2/patch_bug_26678971
  inflating: dbserver_patch_5.180228.2/dcli
  inflating: dbserver_patch_5.180228.2/patchReport.py
 extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
   creating: dbserver_patch_5.180228.2/plugins/
  inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
  inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
  inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
  inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
  inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
  inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
  inflating: dbserver_patch_5.180228.2/patchmgr_functions
  inflating: dbserver_patch_5.180228.2/exadata.img.hw
  inflating: dbserver_patch_5.180228.2/libxcp.so.1
  inflating: dbserver_patch_5.180228.2/imageLogger
  inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
  inflating: dbserver_patch_5.180228.2/fwverify
    5. Erstellen Sie die Datei dbs_group mit der Liste der zu aktualisierenden Compute Nodes. Nehmen Sie die Knoten auf, die mit dem Befehl olsnodes in Schritt 1 aufgelistet werden, mit Ausnahme des steuernden Systemknotens. In diesem Beispiel sollte dbs_group nur node2 enthalten.
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. Führen Sie eine Patching-Vorabprüfung aus.
    Hinweis

    Führen Sie die Vorabprüfung mit der Option -nomodify_at_prereq aus, um Änderungen am System zu verhindern, die sich auf das im nächsten Schritt angefertigte Backup auswirken könnten. Andernfalls kann das Backup möglicherweise kein Rollback des Systems auf den ursprünglichen Status durchführen. 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    Die Ausgabe sollte dem folgenden Beispiel ähneln: 
    [root@node1 dbserver_patch_5.180228]# ./patchmgr -dbnodes dbs_group -precheck -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -nomodify_at_prereq

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. Sichern Sie das aktuelle System.
    Hinweis

    Dies ist die richtige Phase zur Durchführung des Backups, bevor Änderungen am System vorgenommen werden. 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    Die Ausgabe sollte dem folgenden Beispiel ähneln: 
    [root@node1 dbserver_patch_5.180228]#  ./patchmgr -dbnodes dbs_group -backup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. Entfernen Sie alle benutzerdefinierten RPMs aus den Ziel-Compute-Nodes, die aktualisiert werden. Benutzerdefinierte RPMs werden in den Vorabprüfungsergebnissen gemeldet. Dazu gehören auch RPMs, die nach der Bereitstellung des Systems manuell installiert wurden.
    • Wenn Sie ein System der Version 12.1.2.3.4.17011 aktualisieren und die Ergebnisse der Vorabprüfung krb5-workstation-1.10.3-57.el6.x86_64 enthalten, entfernen Sie das Element. (Dieses Element gilt für diese Version als benutzerdefiniertes RPM.)
    • Entfernen Sie nicht exadata-sun-vm-computenode-exact oder oracle-ofed-release-guest. Diese beiden RPMs werden während des Updateprozesses automatisch verarbeitet.
  6. Führen Sie den Befehl nohup aus, um die Aktualisierung auszuführen.
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    Die Ausgabe sollte dem folgenden Beispiel ähneln:
    [root@node1 dbserver_patch_5.180228]# nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -allow_active_network_mounts &

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
NOTE    Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
*********************************************************************************************************

2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. Verifizieren Sie nach Abschluss des Updates die Version des Kernels auf dem aktualisierten Compute Node.
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. Wenn das steuernde System ein Compute Node ist, der aktualisiert werden muss (wie in diesem Beispiel), wiederholen Sie die Schritte 2 bis 7 dieser Prozedur mit einem aktualisierten Compute Node als steuerndes System, um den verbleibenden Compute Node zu aktualisieren. In diesem Beispiel verwenden Sie node2, um node1 zu aktualisieren.
  9. Führen Sie auf jedem Compute Node den Befehl uptrack-install als "root" aus, um die verfügbaren ksplice-Updates zu installieren.
    uptrack-install --all -y

Zusätzlicher Betriebssystempackages installieren

Lesen Sie diese Richtlinien, bevor Sie zusätzliche Betriebssystempackages für Oracle Exadata Database Service on Dedicated Infrastructure installieren.

Sie können Betriebssystempackages auf Oracle Exadata Database Service on Dedicated Infrastructure installieren und aktualisieren, dürfen dabei aber den Kernel oder InfiniBand-spezifische Packages nicht ändern. Der technische Support von Oracle, einschließlich Installation, Test, Zertifizierung und Fehlerbehebung, erstreckt sich jedoch nicht auf Nicht-Oracle-Software, die Sie installieren.

Beachten Sie außerdem, dass beim Hinzufügen oder Aktualisieren von Packages separat von einem Oracle Exadata-Softwareupdate bei diesen Packagezusätzen oder -updates Probleme auftreten können, wenn Sie ein Oracle Exadata-Softwareupdate einspielen. Es können Probleme auftreten, weil zusätzliche Softwarepackages neue Abhängigkeiten hinzufügen, die ein Oracle Exadata-Update unterbrechen können. Aus diesem Grund empfiehlt Oracle, höchstens minimale Anpassungen vorzunehmen.

Wenn Sie zusätzliche Packages installieren, empfiehlt Oracle Skripte, um das Entfernen und die Neuinstallation dieser Packages zu automatisieren. Wenn Sie nach einem Oracle Exadata-Update zusätzliche Packages installieren, prüfen Sie, ob die zusätzlichen Packages noch kompatibel sind und ob Sie diese Packages weiterhin benötigen.

Weitere Informationen finden Sie im Oracle Exadata Database Machine-Wartungshandbuch.

Tooling auf Exadata Cloud Infrastructure-Instanzen aktualisieren

Cloudspezifisches Tooling wird auf den Exadata Cloud Infrastructure-Gast-VMs für lokale Vorgänge verwendet, darunter dbaascli-Befehle.

Das Cloud-Tooling wird automatisch von Oracle aktualisiert, wenn neue Releases verfügbar gemacht werden. Bei Bedarf können Sie die Schritte unter Cloud-Tooling mit dbaascli aktualisieren ausführen, um sicherzustellen, dass Sie die aktuelle Version des Cloud-Toolings auf allen virtuellen Maschinen im VM-Cluster verwenden.