Oracle Cloud Infrastructure-Dokumentation

Exadata Cloud@Customer-Systeme manuell patchen und aktualisieren

In diesem Thema werden die Verfahren für das Patchen und Aktualisieren verschiedener Komponenten in Exadata Cloud@Customer 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.
  • Software manuell aktualisieren
    Bei Oracle Java VM-, Sommerzeit- und einigen Routine- oder One-off-Patches muss die Software möglicherweise manuell gepatcht werden.
  • Gast-VM-Betriebssystem manuell aktualisieren
    Hier erfahren Sie mehr über die Exadata-Standardtools und -methoden, mit denen Sie die Betriebssystemkomponenten auf den Gast-VMs von Exadata Cloud@Customer aktualisieren können.

Verwandte Themen

Software manuell aktualisieren

Bei Oracle Java VM-, Sommerzeit- und einigen Routine- oder One-off-Patches muss die Software möglicherweise manuell gepatcht werden.

Um das routinemäßige Patching von Oracle Database- und Oracle Grid Infrastructure-Software durchzuführen, empfiehlt Oracle, die von Oracle Exadata Cloud@Customer bereitgestellten Funktionen zu verwenden. Unter bestimmten Umständen kann es jedoch erforderlich sein, die Oracle Database- oder Oracle Grid Infrastructure-Software manuell zu patchen:
  • Oracle Java Virtual Machine-(OJVM-)Patching: Weil Patches für die OJVM-Komponente von Oracle Database nicht im Rolling-Verfahren eingespielt werden können, sind sie nicht in den Routinepatchsets für Exadata Cloud@Customer enthalten. Patches für die OJVM-Komponente von Oracle Database müssen Sie manuell einspielen. Siehe My Oracle Support-Dokument-ID 1929745.1.
  • 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@Customer 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.

Gast-VM-Betriebssystem manuell aktualisieren

Hier erfahren Sie mehr über die Exadata-Standardtools und -methoden, mit denen Sie die Betriebssystemkomponenten auf den Gast-VMs von Exadata Cloud@Customer aktualisieren können.

Sie sind für die Verwaltung von Patches und Aktualisierungen der Betriebssystemumgebung auf den virtuellen Maschinen (VMs) der Datenbankserver verantwortlich. Weitere Informationen zur Aktualisierung von Exadata Database Machine-Servern finden Sie im Oracle Exadata Database Machine-Wartungshandbuch.

Verwandte Themen

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

Betriebssystemupdate vorbereiten

Um ein Betriebssystemupdate für Oracle Exadata Cloud@Customer vorzubereiten, lesen Sie diese Checkliste der Aufgaben.

Führen Sie vor dem Update des Betriebssystems die folgenden Vorbereitungsaufgaben aus:

Ermitteln Sie das neueste Softwareupdate. Bevor Sie mit einem Update beginnen, ermitteln Sie die neueste zu verwendende Software. Prüfen Sie dazu die Exadata Cloud Service-Softwareversionen im My Oracle Support-Hinweis 2333222.1.

Betriebssystem auf allen virtuellen Maschinen eines Oracle Exadata Cloud@Customer-Systems aktualisieren

Um das Betriebssystem auf den virtuellen Maschinen (VMs) von Datenbankservern zu aktualisieren, verwenden Sie das Tool patchmgr.

Hinweis

Kunden, die nicht über die Berechtigung zum Herunterladen von My Oracle Support-Patches verfügen, können das Exadata-Updateutility patchmgr und die neuesten Exadata-Systemsoftwarereleases mit dem Exadata Cloud@Customer Gen2-Utility exadata_updates.sh abrufen. Weitere Informationen finden Sie im My Oracle Support-Dokument 2730739.1.

Das Utility patchmgr verwaltet das gesamte Update einer oder mehrerer virtueller Maschinen remote, einschließlich der Schritte vor dem Neustart, während des Neustarts und nach dem Neustart eines Oracle Exadata Cloud@Customer-Systems.

Sie können das Utility entweder auf einer der virtuellen Oracle Exadata Cloud@Customer-Maschinen 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. Daher müssen Sie das Utility patchmgr mehrmals ausführen, wenn es sich bei dem steuernden System um eine der virtuellen Maschinen in einem VM-Cluster handelt, das Sie aktualisieren. Die folgenden Szenarios beschreiben typische Methoden zur Durchführung der Updates:

  • Nicht-Exadata-System als steuerndes System

    Die einfachste Möglichkeit zum Update des Systems ist ein Update aller virtuellen Maschinen in einem Vorgang mit einem separaten Oracle Linux-Server.

  • Virtuelle Maschine in Exadata als steuerndes System

    Sie können eine virtuelle Maschine verwenden, um die Updates für die restlichen virtuellen Maschinen im VM-Cluster zu steuern. Dann können Sie einen der aktualisierten Knoten verwenden, um das Update auf dem ursprünglichen steuernden System zu steuern. Beispiel: Sie aktualisieren ein Half-Rack-System mit vier virtuellen Maschinen: node1, node2, node3 und node4. Sie können zuerst node1 verwenden, um das Update von node2, node3 und node4 zu steuern. Dann könnten Sie node2 verwenden, um das Update von node1 zu steuern.

Das steuernde System benötigt SSH-Zugriff als root-Benutzer auf jede virtuelle Maschine, die aktualisiert wird.

Das folgende Verfahren basiert auf einem Beispiel mit folgenden Annahmen:

  • Das System verfügt über zwei virtuelle Maschinen: node1 und node2.
  • Die Zielversion der Exadata-Software ist 18.1.4.0.0.180125.3.
  • Jeder Knoten wird als steuerndes System verwendet, um den jeweils anderen Knoten zu aktualisieren.
  1. Erfassen Sie die Umgebungsdetails.
    1. Stellen Sie mit SSH eine Verbindung zu node1 als Benutzer opc her.

      Ausführliche Anweisungen finden Sie unter Verbindungen zu Compute Nodes mit SSH herstellen.

    2. Starten Sie eine Befehlsshell mit dem Benutzer root.
      sudo su -
    3. Führen Sie den folgenden Befehl aus, um die aktuelle Exadata-Softwareversion zu ermitteln.
      imageinfo -ver
      Beispiel:
      # imageinfo -ver 
19.2.13.0.0.200428
    4. Wechseln Sie zum Benutzer grid, und identifizieren Sie alle Knoten im Cluster.
      su - grid
      olsnodes
      Beispiel:
      olsnodes
node1
node2
  2. Konfigurieren Sie das steuernde System.
    1. Wechseln Sie zurück zum Benutzer root auf node1, und prüfen Sie, ob ein SSH-Schlüsselpaar (id_rsa und id_rsa.pub) vorhanden ist. Falls nicht, generieren Sie es.
      ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory

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.example.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.
      scp -i ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
      ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
      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.
      cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Laden Sie patchmgr in /root/patch auf dem steuernden System (in diesem Beispiel node1) herunter.

      Sie können das patchmgr-Bundle mit der My Oracle Support-Patch-ID 21634633 von Oracle Support herunterladen. Rufen Sie immer das neueste verfügbare Exadata-Updateutility patchmgr ab, um ein Exadata-Systemsoftwarerelease zu installieren.

      Weitere Informationen finden Sie auch unter dbnodeupdate.sh und dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr: My Oracle Support Doc ID 1553103.1.

    5. Dekomprimieren Sie das Bundlepatchmgr.

      Je nach heruntergeladener Version kann der Name Ihrer ZIP-Datei auch anders lauten. 

      cd /root/patch/18.1.4.0.0.180125.3
unzip dbserver.patch.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
    6. Erstellen Sie in dem Verzeichnis, welches das Utility patchmgr enthält, die Datei dbs_group mit einer Liste der zu aktualisierenden virtuellen Maschinen. Nehmen Sie die Knoten auf, die mit dem Befehl olsnodes in Schritt 1 aufgelistet werden, mit Ausnahme des steuernden Systems. In diesem Beispiel enthält dbs_group nur node2.
      cd /root/patch/18.1.4.0.0.180125.3/dbserver_patch_5.180228
cat dbs_group
node2
  3. Führen Sie eine Patching-Vorabprüfung aus.
    ./patchmgr -dbnodes dbs_group -precheck -iso_repo zipped_iso_file -target_version target-version -nomodify_at_prereq
    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 System aus dem Backup unter Umständen nicht wieder in den ursprünglichen Zustand versetzt werden.

    Die Ausgabe sollte dem folgenden Beispiel ähneln:

    ./patchmgr -dbnodes dbs_group -precheck -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -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.
    ./patchmgr -dbnodes dbs_group -backup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts
    Hinweis

    Stellen Sie sicher, dass Sie das Backup an dieser Stelle durchführen, bevor Änderungen am System vorgenommen werden.

    Die Ausgabe sollte dem folgenden Beispiel ähneln:

    ./patchmgr -dbnodes dbs_group -backup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -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 virtuellen Zielmaschinen. 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 das Update aus. Damit der Updateprozess nicht unterbrochen wird, verwenden Sie den Befehl nohup. Beispiel:
    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts &

    Die Ausgabe sollte dem folgenden Beispiel ähneln:

    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -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 der Exadata-Software auf der aktualisierten virtuellen Maschine.
    imageinfo -ver
18.1.4.0.0.180125.3
  8. Wiederholen Sie die Schritte 2 bis 7 dieses Verfahrens mit der aktualisierten virtuellen Maschine als steuerndes System, um die verbleibende virtuelle Maschine zu aktualisieren. In diesem Beispiel verwenden Sie node2, um node1 zu aktualisieren.
  9. Führen Sie als root auf jeder virtuellen Maschine den Befehl uptrack-install aus, um die verfügbaren ksplice-Updates zu installieren.
    uptrack-install --all -y
    uptrack-install --all -y

Zusätzlicher Betriebssystempackages installieren

Lesen Sie diese Richtlinien, bevor Sie zusätzliche Betriebssystempackages für Oracle Exadata Cloud@Customer installieren.

Sie können Betriebssystempackages auf Oracle Exadata Cloud@Customer 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.