Oracle Cloud Infrastructure-Dokumentation

Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

Hier finden Sie Informationen zum Aktualisieren und Patchen des Oracle Exadata Database Service on Cloud@Customer-Systems

Übergeordnetes Thema: Anleitungen

Vom Benutzer verwaltete Wartungsupdates ausführen

Um die Funktionsfähigkeit eines sicheren Oracle Exadata Database Service on Cloud@Customer-Systems aufrecht zu erhalten, müssen Sie die folgenden Aufgaben regelmäßig ausführen:
  • Oracle Grid Infrastructure- und Oracle Database-Software auf den virtuellen Maschinen im VM-Cluster patchen. Informationen und Anweisungen finden Sie unter Exadata Cloud@Customer-System patchen und aktualisieren.
  • Betriebssystem auf den virtuellen Maschinen im VM-Cluster aktualisieren. Informationen und Anweisungen finden Sie unter Gast-VM-Betriebssystem aktualisieren und Oracle Clusterware-Konfiguration und -Administration.

Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

Hier erfahren Sie, wie Patching-Vorgänge auf virtuellen Maschinen der Exadata-Datenbank und Datenbank-Homes mit der Konsole, der API oder der CLI ausgeführt werden.

Informationen und Anweisungen zum Patching des Systems mit dem Utility dbaascli finden Sie unter Oracle Exadata Database Service on Cloud@Customer-System manuell patchen und aktualisieren.

Weitere Informationen und Beispiele für das Einspielen vierteljährlicher Datenbankpatches auf Exadata Cloud@Customer finden Sie im My Oracle Support-Hinweis: How to Apply Database Quarterly Patch on Exadata Cloud Service and Exadata Cloud at Customer Gen 2 (Doc ID 2701789.1).

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: Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

VM-Cluster und Datenbank-Homes patchen und aktualisieren

Hier erfahren Sie, wie Sie Patching-Vorgänge in Grid Infrastructure (GI) auf VM-Clustern und in Datenbank-Homes mit der Konsole oder API ausführen

Übergeordnetes Thema: Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

GI und Datenbank-Homes von VM-Clustern patchen und aktualisieren

Beim Patching eines VM-Clusters werden Komponenten auf jedem der VM-Gäste im VM-Cluster aktualisiert. Das VM-Cluster-Patching aktualisiert die Grid Infrastructure-(GI-)Software, und das Datenbank-Home-Patching aktualisiert die Oracle Database-Software, die von den Datenbanken in diesem Home gemeinsam verwendet wird.

Weitere Informationen zu verfügbaren Patches finden Sie im My Oracle Support-Hinweis https://support.oracle.com/epmos/faces/DocContentDisplay?id=2333222.1.

Beachten Sie die folgenden Best Practices:
  • Da das Patching eines Systems einen Neustart erfordert, sollten Sie die Vorgänge zu einem Zeitpunkt ausführen, zu dem sie für Benutzer minimale Auswirkungen haben.
  • Oracle empfiehlt, dass Sie vor dem Einspielen von Patches ein Backup Ihrer Datenbanken erstellen. Informationen zum Backup der Datenbanken finden Sie unter Datenbankbackup und -Recovery auf Exadata Database Service on Cloud@Customer verwalten.
  • Oracle empfiehlt, dass Ihre Oracle Grid Infrastructure RU-Version nicht länger als 6 Monate hinter Ihrer neuesten Datenbank-RU-Version zurückliegt. Wenn Sie die Datenbankversion aktualisieren, sollten Sie nach Möglichkeit auch die GI-Version aktualisieren.
  • Um eine Datenbank auf eine andere Version als die Datenbankversion des aktuellen Homes zu patchen, verschieben Sie die Datenbank in ein Datenbank-Home, in dem die Zielversion ausgeführt wird. Siehe Datenbank mit der Konsole in ein anderes Home verschieben.
Voraussetzungen für das Patchen und Aktualisieren eines Oracle Exadata Database Service on Cloud@Customer-Systems

Prüfen Sie die neuesten Cloud-Patches, die heruntergeladen und von Oracle auf dem CPS-Host verfügbar gemacht werden, und spielen Sie sie ein.

Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind, um Patching-Fehler zu vermeiden:
  • Das Verzeichnis /u01 im Dateisystem des Datenbankhosts verfügt über mindestens 15 GB freien Speicherplatz zur Ausführung von Patchprozessen.
  • Oracle Clusterware ist im VM-Cluster hochgefahren und gestartet.
  • Alle Knoten des VM-Clusters sind hochgefahren und werden ausgeführt.
GI von VM-Clustern und Datenbank-Homes mit der Konsole patchen und aktualisieren

Hier erfahren Sie, wie Sie mit der Konsole die Historie der Patchvorgänge in VM-Clustern und Datenbank-Homes anzeigen, Patches anwenden und den Status von Patchvorgängen überwachen.

Oracle empfiehlt, dass Sie die Vorabprüfung ausführen, um sicherzustellen, dass das VM-Cluster oder Datenbank-Home die Anforderungen für den Patch erfüllt, den Sie einspielen möchten.

Übergeordnetes Thema: VM-Cluster und Datenbank-Homes patchen und aktualisieren

Grid Infrastructure-Updates mit der Konsole ausführen

Sie lernen, wie Sie Grid Infrastructure-Updates in ein VM-Cluster einspielen.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
    "VM-Cluster" ist standardmäßig ausgewählt.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf das VM-Cluster, in dem Sie einen Patchvorgang ausführen möchten.
  4. Klicken Sie auf der daraufhin angezeigten Seite "VM-Clusterdetails" auf Updates.
  5. Prüfen Sie die Liste der verfügbaren Patches für das VM-Cluster.

    Die Oracle Grid Infrastructure-Softwareimages sind allgemein verfügbare Oracle Grid Infrastructure-Softwareimages, mit denen Sie Ihr Cluster patchen können. Oracle-Images, die für das Patching verwendet werden können, haben den Updatetyp "Patch".

    Die benutzerdefinierten Grid Infrastructure-Softwareimages sind das Grid Infrastructure-Softwareimage, das Sie zuvor erstellt haben.

    Verwenden Sie den Selektor Compartment auswählen, um das Compartment anzugeben, das das Datenbanksoftwareimage enthält.

    Mit dem Filter Region können Sie auf die Softwareimages zugreifen, die in einer anderen Region erstellt wurden.

  6. Klicken Sie auf das Symbol "Aktionen" (drei Punkte) für den betreffenden Patch, und klicken Sie dann auf eine der folgenden Aktionen:
    • Vorabprüfung: Voraussetzungen prüfen, damit der Patch erfolgreich eingespielt werden kann. Oracle empfiehlt dringend, diesen Vorgang auszuführen, bevor Sie einen Patch einspielen. Die Vorabprüfung hat keine Auswirkungen auf die Verfügbarkeit des Clusters, alles bleibt funktionsfähig.
    • Grid Infrastructure-Update einspielen: Wendet den ausgewählten Patch an.
  7. Bestätigen Sie den Vorgang, wenn Sie aufgefordert werden.

In der Patchliste wird der Status des Vorgangs angezeigt. Während die Vorabprüfung ausgeführt wird, wird der Patchstatus Checking angezeigt. Während ein Patch eingespielt wird, lautet der Patchstatus Wird angewendet, und der Status des VM-Clusters lautet Wird aktualisiert. Beim Patching sind Lebenszyklusvorgänge für das VM-Cluster und die zugehörigen Ressourcen vorübergehend nicht verfügbar. Wenn das Patching erfolgreich abgeschlossen wird, ändert sich der Patchstatus in Angewendet und der VM-Clusterstatus in Verfügbar. Sie können weitere Details zu einem bestimmten Patchvorgang anzeigen, indem Sie auf Updatehistorie klicken. Das Grid Infrastructure-Patching erfolgt rollierend, Knoten für Knoten. Die Clusterressourcen werden auf jedem Knoten gestoppt und neu gestartet.

Updatevorgang in einem Datenbank-Home mit der Konsole ausführen

Hier erfahren Sie, wie Sie Patches in einem Datenbank-Home einspielen.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
    "VM-Cluster" ist standardmäßig ausgewählt.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf das VM-Cluster, in dem sich das Datenbank-Home befindet.
  4. Klicken Sie auf Datenbank-Homes.
  5. Klicken Sie in der Liste der Datenbank-Homes auf das Datenbank-Home, in dem Sie einen Patchvorgang ausführen möchten.
  6. Klicken Sie auf Updates.
  7. Prüfen Sie die Liste der verfügbaren Patches für das Datenbank-Home.

    Die Oracle Database-Softwareimages sind allgemein verfügbare Oracle Database-Softwareimages, die Sie zum Aktualisieren Ihrer Datenbank verwenden können. Oracle-Images, die für das Patching verwendet werden können, haben den Updatetyp "Patch".

    Die benutzerdefinierten Datenbanksoftwareimages sind das Datenbanksoftwareimage, das Sie im Voraus erstellt haben.

    Verwenden Sie den Selektor Compartment auswählen, um das Compartment anzugeben, das das Datenbanksoftwareimage enthält.

    Mit dem Filter Region können Sie auf die Softwareimages zugreifen, die in einer anderen Region erstellt wurden.

  8. Klicken Sie auf das Symbol "Aktionen" (drei Punkte) für den betreffenden Patch, und klicken Sie dann auf eine der folgenden Aktionen:
    • Vorabprüfung: Voraussetzungen prüfen, damit der Patch erfolgreich eingespielt werden kann. Oracle empfiehlt dringend, diesen Vorgang auszuführen, bevor Sie einen Patch einspielen. Die Vorabprüfung hat keine Auswirkungen auf die Verfügbarkeit des Clusters, alles funktioniert weiter.
    • Datenbankupdate einspielen: Wendet den ausgewählten Patch an.
  9. Bestätigen Sie den Vorgang, wenn Sie aufgefordert werden.

In der Patchliste wird der Status des Vorgangs angezeigt. Während die Vorabprüfung ausgeführt wird, wird der Patchstatus Checking angezeigt. Während ein Patch eingespielt wird, lautet der Status des Patches Wird angewendet, der Status des Datenbank-Homes und der darin enthaltenen Datenbanken lautet Wird aktualisiert. Lebenszyklusvorgänge im VM-Cluster und in dessen Ressourcen sind vorübergehend nicht verfügbar. Patches werden rollierend auf das Datenbank-Home angewendet, Knoten für Knoten, und jede Datenbank im Home wird gestoppt und dann neu gestartet. Dies kann zu einer vorübergehenden Serviceunterbrechung führen. Wenn das Patching erfolgreich abgeschlossen wird, ändert sich der Patchstatus in Angewendet und der Status des Datenbank-Homes in Verfügbar. Sie können weitere Details zu einem bestimmten Patchvorgang anzeigen, indem Sie auf Updatehistorie klicken.

Updatehistorie mit der Konsole anzeigen

Jeder Eintrag in der Updatehistorie stellt einen Patchvorgang dar und gibt an, ob der Vorgang erfolgreich oder nicht erfolgreich war. Sie können nicht erfolgreiche Patchvorgänge wiederholen. Wenn Sie einen Vorgang wiederholen, wird ein neuer Eintrag in der Patchhistorie erstellt.

In den Updatehistorienansichten in der Konsole werden keine Patches angezeigt, die mit Befehlszeilentools wie dbaascli eingespielt wurden.

Übergeordnetes Thema: GI von VM-Clustern und Datenbank-Homes mit der Konsole patchen und aktualisieren

Updatehistorie eines VM-Clusters mit der Konsole anzeigen

Hier erfahren Sie, wie Sie die Historie der Patches anzeigen, die in einem VM-Cluster eingespielt wurden.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
    "VM-Cluster" ist standardmäßig ausgewählt.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf das gewünschte VM-Cluster.
  4. Klicken Sie auf Updatehistorie.

Die Historie der Patchvorgänge für dieses VM-Cluster wird zusammen mit der Historie der Patchvorgänge in seinen Datenbank-Homes angezeigt.

Updatehistorie eines Datenbank-Homes mit der Konsole anzeigen

Hier erfahren Sie, wie Sie die Historie der Patches anzeigen können, die auf einem Datenbank-Home eingespielt wurden.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
    "VM-Cluster" ist standardmäßig ausgewählt.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf das VM-Cluster, in dem sich das Datenbank-Home befindet.
  4. Klicken Sie auf Datenbank-Homes.
    Eine Liste der Datenbank-Homes wird angezeigt.
  5. Klicken Sie in der Liste der Datenbank-Homes auf das gewünschte Datenbank-Home.
  6. Klicken Sie auf Updatehistorie.

Die Historie der Patchvorgänge für dieses Datenbank-Home wird zusammen mit der Historie der Patchvorgänge in dem VM-Cluster angezeigt, zu dem es gehört.

Datenbanken mit der Konsole in ein anderes Home verschieben

Sie können die Version einer VM-Clusterdatenbank aktualisieren, indem Sie sie in ein Datenbank-Home verschieben, in dem die gewünschten Oracle Database-Version ausgeführt wird.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
    "VM-Cluster" ist standardmäßig ausgewählt.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf das VM-Cluster, in dem sich die zu verschiebende Datenbank befindet.
  4. Klicken Sie auf Datenbank-Homes.
  5. Klicken Sie in der Liste der Datenbank-Homes auf das gewünschte Datenbank-Home.
  6. Klicken Sie auf Datenbanken.
  7. Klicken Sie in der Liste der Datenbanken auf die gewünschte Datenbank.
  8. Klicken Sie auf "Aktionen", und wählen Sie Datenbank verschieben aus.
  9. Wählen Sie das Zieldatenbank-Home.
  10. Klicken Sie auf Verschieben.
    Die Datenbank wird im aktuellen Home gestoppt und anschließend im Ziel-Home neu gestartet.
  11. Bestätigen Sie den Verschiebevorgang.

Die Datenbank wird im Rolling-Modus verschoben. Die Datenbankinstanz wird Knoten für Knoten im aktuellen Home gestoppt und anschließend im Ziel-Home neu gestartet. Während die Datenbank verschoben wird, werden der Status des Datenbank-Homes und der Datenbank als Wird aktualisiert angezeigt. Für das unter Datenbankversion angezeigte Datenbank-Home-Verzeichnis wird Datenbank wird verschoben angezeigt. Wenn der Vorgang abgeschlossen ist, wird das Datenbank-Home mit dem aktuellen Home aktualisiert. Datapatch wird automatisch als Teil der Datenbankverschiebung ausgeführt, um SQL-Aktionen nach dem Patchen für alle Patches, einschließlich One-offs, im neuen Datenbank-Home abzuschließen. Wenn der Vorgang zum Verschieben der Datenbank nicht erfolgreich war, wird der Status der Datenbank als Nicht erfolgreich angezeigt, und das Feld Datenbank-Home enthält Informationen zur Ursache des Fehlers.

VM-Cluster und Datenbank-Homes mit der API patchen und aktualisieren

Sie können Sie das Patching eines Oracle Exadata Database Service on Cloud@Customer-Systems mit verschiedenen API-Features verwalten.

Informationen zum Verwenden der API und Signieren von Anforderungen finden Sie unter "REST-APIs" und "Sicherheitszugangsdaten". Informationen zu SDKs finden Sie unter "Software Development Kits und Befehlszeilenschnittstelle".

Mit diesen API-Vorgängen können Sie das Patching von VM-Clustern, Datenbank-Homes und Datenbanken verwalten.

VM-Cluster:

  • UpdateVmCluster

Datenbank-Homes:

  • CreateDbHome
  • UpdateDbHome
  • DeleteDbHome

Datenbank:

  • CreateDatabase
  • UpdateDatabase
  • DeleteDatabase

Verwenden Sie UpdateVMCluster, um Oracle Grid Infrastructure im VM-Cluster zu patchen. Verwenden Sie UpdateDbHome, um die Database-Software des Datenbank-Homes zu patchen. Verwenden Sie UpdateDatabase, um eine Datenbank in ein anderes Datenbank-Home zu verschieben und dadurch die Datenbank auf die Version des Zieldatenbank-Homes zu aktualisieren.

Die vollständige Liste der APIs für den Database-Service finden Sie unter "Database-Service-API".

Gast-VM-Betriebssystem aktualisieren

Hier erfahren Sie, wie Sie das Betriebssystemimage auf Oracle Exadata Database Service on Cloud@Customer-VM-Clusterknoten automatisiert über die OCI-Konsole und die APIs aktualisieren.

Mit diesem automatisierten Feature wird das VM-Cluster-Patching vereinfacht und beschleunigt. Das Patching wird weniger fehleranfällig, und die Verwendung von Patch Manager entfällt.

Wenn Sie einen Patch einspielen, führt das System eine Vorabprüfung aus, um sicherzustellen, dass das Exadata Cloud@Customer-VM-Cluster, -Datenbanksystem oder -Datenbank-Home die Anforderungen für diesen Patch erfüllt. Wenn die Vorabprüfung nicht erfolgreich war, wird der Patch nicht eingespielt, und das System zeigt eine Meldung an, dass der Patch nicht eingespielt werden kann, weil die Vorabprüfung nicht erfolgreich war. Außerdem ist ein separater Vorabprüfungsvorgang verfügbar, den Sie vor dem geplanten Update ausführen können.

Übergeordnetes Thema: Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

Unterstützte Softwareversionen und Einschränkungen bei der Aktualisierung

Mindestanforderungen für das Update auf das Exadata-Imagerelease 23.1.0.0.0 (Oracle Linux 8-basiertes Image):

Hinweis

Dies sind nur die Mindestanforderungen. Wenn Sie Grid Infrastructure und/oder Oracle Database so aktualisieren möchten, dass sie die Exadata 23.1-Anforderungen erfüllen, wird empfohlen, auf die neuesten verfügbaren Versionen von Grid Infrastructure und Oracle Database und nicht auf das Minimum zu aktualisieren.
  • Exadata-Image (Gastbetriebssystem): Exadata-Imagerelease 22.1.0 (Mai 2022) oder 21.2.10 (März 2022). Systeme, auf denen Versionen älter als 21.2.10 ausgeführt werden, müssen zunächst auf mindestens 22.1.0 (Mai 2022) oder 21.2.10 (März 2022) aktualisiert werden, bevor ein Update auf 23.1.0.0.0 durchgeführt werden kann. Dies gilt sowohl für Speicher- als auch für Datenbankserver.
    • Neben kleineren Versionsupdates für die Exadata-VM-Clusterimages können Sie ein Update auf eine neue Hauptversion vornehmen, wenn die aktuell installierte Version 19.2 oder höher ist. Beispiel: Wenn das VM-Cluster auf Version 20 ausgeführt wird, können Sie es auf Version 21 aktualisieren.
    • Die letzten 4 (N bis N-3) oder mehr Nebenversionen jeder Hauptversion der VM-Clusterimages sind über die Konsole zum Einspielen verfügbar.
  • Oracle Grid Infrastructure: Das Exadata-Imagerelease 23.1.0.0.0 unterstützt die folgenden Mindestversionen oder neueren Oracle Grid Infrastructure-Versionen.
    • Release 19c: Version 19.15, April 2022 Release Update (RU) und neuer (Standard)
    • Release 21c: Version 21.6, April 2022 Release Update (RU) und höher
  • Oracle Database: Die Exadata-Systemsoftware 23.1 unterstützt die folgenden Mindestversionen oder höher für neue Datenbankinstallationen.
    • Release 19c: Version 19.15, April 2022 Release Update (RU) und neuer (Standard)
    • Zusätzliche unterstützte Datenbankreleases unter Market Driven Support oder Quarter Updates Ausnahmegenehmigung:
      • Release 12.2.0.1, Releaseupdate (RU) 12.2.0.1.220118 (Jan 2022)
      • Release 12.1.0.2, Bundle Patch 12.1.0.2.220719 (Jul 2022) - erfordert Patch 30159782
      • Release 11.2.0.4, Bundle Patch 11.2.0.4.210119 (Jan 2021) - erfordert Patch 30159782, Patch 33991024
  • Wenn ein Wartungsvorgang für die Exadata-Infrastruktur innerhalb der nächsten 24 Stunden geplant ist, ist das Exadata-Imageupdatefeature nicht verfügbar.
  • Nachdem das VM-Cluster auf Exadata Database Service-Gast-VM-BS 23.1 upgegradet wurde, können Sie diesem VM-Cluster eine neue VM oder einen neuen Datenbankserver hinzufügen, wenn auf der Exadata Cloud@Customer-Infrastruktur eine Exadata-Systemsoftwareversion 22.1.16 und höher ausgeführt wird.
    Hinweis

    Das Upgrade auf Exadata-Systemsoftware 23.1 für die Exadata Cloud@Customer-Infrastruktur ist ab dem Updatezyklus vom Februar 2024 verfügbar.

Übergeordnetes Thema: Gast-VM-Betriebssystem aktualisieren

Gast-VM-Betriebssystem mit der Konsole aktualisieren

Um das Gast-VM-Betriebssystem mit der Konsole zu aktualisieren, müssen Sie Werte in die erforderlichen Felder eingeben.

Hinweis

Nachdem das VM-Cluster auf Exadata Database Service Gast-VM-BS 23.1 upgegradet wurde, können Sie diesem VM-Cluster eine neue VM oder einen neuen Datenbankserver hinzufügen, wenn in Exadata Cloud@Customer Infrastructure eine Exadata-Systemsoftwareversion 22.1.16 und höher ausgeführt wird.

Das Upgrade auf Exadata System Software 23.1 für Exadata Cloud@Customer-Infrastruktur ist ab dem Updatezyklus vom Februar 2024 verfügbar.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der Cloud-VM-Cluster auf den Namen des Clusters, das Sie patchen möchten, um die Clusterdetails anzuzeigen.
  4. Klicken Sie auf Updates (BS).
  5. Prüfen Sie die Liste der verfügbaren Softwareupdates, und suchen Sie den einzuspielenden Betriebssystempatch.
  6. Klicken Sie auf das Symbol "Aktionen" (drei Punkte) am Ende der Zeile mit dem betreffenden Patch, und klicken Sie dann auf eine der folgenden Aktionen:
    • Vorabprüfung ausführen. Bei der Vorabprüfung werden die Voraussetzungen geprüft, um sicherzustellen, dass der Patch erfolgreich eingespielt werden kann. Oracle empfiehlt dringend, den Vorabprüfungsvorgang auszuführen, bevor Sie einen Patch einspielen. Der Grund dafür sind die häufigen Veränderungen in einer Datenbank. Bei der Vorabprüfung, die Sie direkt vor der Ausführung eines Patches ausführen, werden möglicherweise Fehler gefunden, die bei der vorherigen Vorabprüfung nicht gefunden wurden.
      Hinweis

      Wenn die Vorabprüfung nicht erfolgreich verläuft, zeigt das System im Dialogfeld Exadata-BS-Imageupdate anwenden eine Meldung an, dass die letzte Vorabprüfung nicht erfolgreich war. Oracle empfiehlt, die Vorabprüfung erneut auszuführen. Klicken Sie am Ende der Zeile mit dem BS-Patch auf das Aktionssymbol (drei Punkte), um das Dialogfeld anzuzeigen.
    • Exadata-BS-Imageupdate einspielen. Dieser Link zeigt das Dialogfeld "Exadata-Imageupdate einspielen" an, mit dem Sie den Patch einspielen. Im Dialogfeld werden der Name des Datenbanksystems angezeigt, das Sie patchen, die aktuelle Version der Datenbank und die neue Version der Datenbank nach Einspielen des Patches. Um den Prozess zu starten, klicken Sie auf Exadata-BS-Imageupdate anwenden.
    • OCID kopieren. Damit wird die Oracle Cloud-ID kopiert. Diese kann bei der Fehlerbehebung bei einem Patch oder bei der Kontaktaufnahme mit dem Support verwendet werden.
      Hinweis

      Während der Einspielung des Patches:
      • "Vorabprüfung ausführen" und "BS-Imageupdate anwenden" sind nicht verfügbar. Nach Abschluss des Patches sind diese Aktionen wieder verfügbar.
      • Wenn für die Exadata-Infrastruktur, die dieses VM-Cluster enthält, eine Wartung geplant ist, die mit dem Patching-Vorgang in Konflikt steht, verläuft das Patchen nicht erfolgreich, und das System zeigt in einer Meldung den Grund dafür an. Führen Sie den Patchvorgang nach Abschluss der Infrastrukturwartung erneut aus.
  7. Bestätigen Sie den Vorgang, wenn Sie aufgefordert werden.

Übergeordnetes Thema: Gast-VM-Betriebssystem aktualisieren

Rollbacks oder Wiederholungen bei nicht erfolgreichen Gast-VM-Betriebssystemupdates mit der Konsole ausführen

Um das Gast-VM-Betriebssystem mit der Konsole zu aktualisieren, müssen Sie Werte in die erforderlichen Felder eingeben.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf den Namen des Clusters, das Sie patchen möchten, um die Clusterdetails anzuzeigen.

    Wenn das Update nicht eingespielt werden konnte, wird auf der Seite VM-Clusterdetails ein Banner mit den Optionen Rollback und Anwenden wiederholen angezeigt.

    Wählen Sie eine geeignete Option aus.

    1. Klicken Sie auf Anwenden wiederholen.

      Das Dialogfeld Exadata-BS-Imageupdate einspielen wird mit den Optionen Exadata-Imageupdate einspielen und Vorabprüfung ausführen angezeigt.

      Wählen Sie eine geeignete Option aus.

      (oder)

    2. Klicken Sie auf Rollback.

      Das Dialogfeld Rollback-Vorgang bestätigen wird angezeigt.

      Klicken Sie auf Rollback, um den Vorgang zu bestätigen.

  4. Sie können auch das Exadata-Imageupdate auf der Seite Updates (BS) einspielen.

Übergeordnetes Thema: Gast-VM-Betriebssystem aktualisieren

Gast-VM-Betriebssystem mit der API aktualisieren

Hier finden Sie die Liste der API-Aufrufe zum Aktualisieren des Gast-VM-Betriebssystems.

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-APIs und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter Software Development Kits und Befehlszeilenschnittstelle (CLI).

Mit diesen API-Vorgängen können Sie ein Upgrade von Oracle Grid Infrastructure in einem VM-Cluster durchführen und die Updatehistorie des Clusters anzeigen:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

Die vollständige Liste der APIs finden Sie unter Database-Service-API.

Oracle Grid Infrastructure auf einem Oracle Exadata Database Service on Cloud@Customer-VM-Cluster aktualisieren

Hier erfahren Sie, wie Sie ein Upgrade von Oracle Grid Infrastructure auf einem Oracle Exadata Database Service on Cloud@Customer-VM-Cluster mit der Oracle Cloud Infrastructure-Konsole oder -API vornehmen.

Durch das Upgrade können Sie Oracle Database Homes und Datenbanken bereitstellen, die die aktuelle Oracle Database-Software verwenden.

Übergeordnetes Thema: Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

Oracle Grid Infrastructure upgraden

Ein Upgrade von Oracle Grid Infrastructure (GI) auf einem VM-Cluster umfasst Upgrades aller Compute Nodes der Instanz. Das Upgrade wird im Rolling-Modus, d.h. für die einzelnen Knoten der Reihe nach ausgeführt.

  • Oracle empfiehlt, eine Vorabprüfung für Upgrades auszuführen, um Probleme zu identifizieren und zu beheben, die ein erfolgreiches Upgrade verhindern würden.
  • Sie können den Fortschritt des Upgradevorgangs überwachen, indem Sie die zugehörigen Arbeitsanforderungen anzeigen.
  • Wenn ein Wartungsvorgang für die Exadata-Infrastruktur innerhalb der nächsten 24 Stunden geplant ist, ist das GI-Upgradefeature nicht verfügbar.
  • Während des Upgrades können Sie keine anderen Verwaltungsvorgänge ausführen, wie das Starten, Stoppen oder Neustarten von Knoten, das Skalieren der CPU, das Provisioning oder Verwalten von Datenbank-Homes oder Datenbanken, das Wiederherstellen einer Datenbank oder das Bearbeiten von IORM-Einstellungen. Die folgenden Data Guard-Vorgänge sind für das VM-Cluster, auf dem ein GI-Upgrade durchgeführt wird, nicht zulässig:
    • Data Guard aktivieren
    • Switchover
    • Failover zu der Datenbank, die das VM-Cluster verwendet (ein Failover-Vorgang zu Standbydatenbanken in anderen VM-Clustern ist möglich)
Oracle Grid Infrastructure-Upgrade mit der Konsole verwalten

Mit der Konsole können Sie vor dem Upgrade von Oracle Grid Infrastructure (GI) eine Vorabprüfung vornehmen und den GI-Upgradevorgang ausführen.

Vorabprüfung des VM-Clusters vor dem Upgrade mit der Konsole ausführen

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der Cloud-VM-Cluster auf den Namen des Clusters, das Sie patchen möchten, um die Clusterdetails anzuzeigen.
  4. Klicken Sie auf Updates.
  5. Klicken Sie auf das Aktionssymbol (drei Punkte) am Ende der Zeile, in der das Oracle Grid Infrastructure-(GI-)Upgrade aufgeführt wird, und klicken Sie dann auf Vorabprüfung ausführen.
  6. Bestätigen Sie im Dialogfeld Bestätigen, dass Sie ein Upgrade durchführen möchten, um die Vorabprüfung zu starten.
Oracle Grid Infrastructure eines VM-Clusters mit der Konsole aktualisieren

Hinweis

  • Wenn Sie ein Upgrade von Grid Infrastructure auf 23ai planen, stellen Sie sicher, dass für jede ASM-Datenträgergruppe der Wert für compatible.rdbms auf 19.0.0.0 und höher gesetzt ist.
  • Mindestanforderungen für das Upgrade von Grid Infrastructure von 19c auf 23ai:
    • Exadata-Gast-VM mit Exadata-Systemsoftware 23.1.8
    • Exadata-Infrastruktur, auf der Exadata-Systemsoftware 23.1.x ausgeführt wird
Hinweis

Derzeit wird das Grid Infrastructure-Upgrade von 19c auf 23ai für VM-Cluster mit einem Knoten nicht unterstützt.
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der Cloud-VM-Cluster auf den Namen des Clusters, das Sie patchen möchten, um die Clusterdetails anzuzeigen.
  4. Klicken Sie auf Updates.
  5. Klicken Sie am Ende der Zeile mit dem Oracle Grid Infrastructure-(GI-)Upgrade auf das Aktionssymbol (drei Punkte), und klicken Sie dann auf Grid Infrastructure upgraden.
  6. Bestätigen Sie im Dialogfeld "Grid Infrastructure aktualisieren", dass Sie die GI aktualisieren möchten, indem Sie auf Grid Infrastructure upgraden klicken.

    Wenn Sie keine Vorabprüfung ausgeführt haben, können Sie in diesem Dialogfeld auf Vorabprüfung ausführen klicken, um vor dem Upgrade Ihre Cloud-VM-Cluster zu prüfen.

Oracle Grid Infrastructure-Upgrade mit der API verwalten

Hier finden Sie die Liste der API-Aufrufe zur Verwaltung des Oracle Grid Infrastructure-Upgrades.

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-APIs und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter Software Development Kits und Befehlszeilenschnittstelle (CLI).

Mit diesen API-Vorgängen können Sie ein Upgrade von Oracle Grid Infrastructure in einem VM-Cluster durchführen und die Updatehistorie des Clusters anzeigen:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

Die vollständige Liste der APIs finden Sie unter Database-Service-API.

Oracle-Datenbanken upgraden

Hier erfahren Sie, wie Sie mit der Konsole und der API ein Upgrade einer Exadata-Datenbankinstanz auf Oracle Database 19c und Oracle Database 23ai durchführen.

Das Upgrade wird durchgeführt, indem die Exadata-Datenbank in ein Datenbank-Home verschoben wird, das die Zielsoftwareversion verwendet. Zeitpläne für das Oracle Database-Release und die Softwareunterstützung finden Sie unter Release Schedule of Current Database Releases (Dok.-ID 742060.1).

Verwandte Themen

Übergeordnetes Thema: Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

Voraussetzungen für das Upgrade von Oracle-Datenbanken

Prüfen Sie die Liste der Voraussetzungen für das Upgrade einer Oracle Database-Instanz in Exadata Cloud@Customer.

  • Um auf 19c upzugraden, ist Oracle Linux 7 die Mindestanforderung, und um ein Upgrade auf 23ai, Oracle Linux 8, ist die Mindestanforderung. Anweisungen zum manuellen Aktualisieren des Betriebssystems finden Sie unter How to update the Exadata System Software (DomU) to 19 from 18 on the Exadata Cloud Service in OCI.
  • Die Oracle Grid Infrastructure kann die Version 19c oder 23ai für Oracle Database 19c haben. Oracle Grid Infrastructure muss jedoch Version 23ai für Oracle Database 23ai sein. Anweisungen zum Verwenden der Oracle Cloud Infrastructure-Konsole oder der API für das Upgrade von Grid Infrastructure finden Sie unter Exadata Grid Infrastructure upgraden. Wenn für Grid Infrastructure Patches verfügbar sind, empfiehlt Oracle, diese vor einem Datenbankupgrade einzuspielen.
  • Sie benötigen ein verfügbares Oracle Database Home, das die vier neuesten Versionen von Oracle Database 19c oder Oracle Database 23ai verwendet, die in Oracle Cloud Infrastructure verfügbar sind. Informationen zum Erstellen eines Datenbank-Homes finden Sie unter Oracle Database Home auf Exadata Cloud@Customer mit der Konsole erstellen. Sie können je nach Ihren Patching-Anforderungen von Oracle veröffentlichte Softwareimages oder ein benutzerdefiniertes Datenbanksoftwareimage zum Erstellen von Datenbank-Homes verwenden.
  • Sie müssen sicherstellen, dass alle integrierbaren Datenbanken in der Containerdatenbank, für die ein Upgrade ausgeführt wird, geöffnet werden können. Integrierbare Datenbanken, die während des Upgrades nicht vom System geöffnet werden können, können zu einem Upgradefehler führen.
Um ein Upgrade durchführen zu können, muss die Oracle-Datenbank mit den folgenden Einstellungen konfiguriert sein:
  • Die Datenbank muss sich im Archive-Logmodus befinden.
  • Für die Datenbank muss Flashback aktiviert sein.

Weitere Informationen zu diesen Einstellungen finden Sie in der Oracle Database-Dokumentation zur Releaseversion Ihrer Datenbank.

Oracle-Datenbank upgraden

Machen Sie sich vor dem Upgrade der Datenbank mit den folgenden Verfahren vertraut, um die Datenbank für das Upgrade vorzubereiten.

  • Bei Datenbankupgrades kommt es zu Ausfallzeiten der Datenbank. Berücksichtigen Sie dies bei der Planung Ihres Upgrades.
  • Oracle empfiehlt, die Datenbank zu sichern und die neue Softwareversion auf einem Testsystem oder einer geklonten Version der Datenbank zu testen, bevor Sie ein Upgrade einer Produktionsdatenbank durchführen. Informationen zum Erstellen eines manuellen On-Demand-Backups finden Sie unter On-Demand-Backups mit dem bkup_api-Utility erstellen.
  • Oracle empfiehlt, eine Vorabprüfung vor einem Upgrade Ihrer Datenbank auszuführen, damit Sie alle Probleme ermitteln können, die vor der geplanten Ausführung des Upgrades behoben werden müssen. Der Vorabprüfungsvorgang wirkt sich nicht auf die Datenbankverfügbarkeit aus und kann jederzeit ausgeführt werden.
  • Wenn Ihre Datenbanken Data Guard verwenden, können Sie entweder die Primär- oder die Standbydatenbank als Erstes upgraden.
  • Ein Upgradevorgang kann nicht ausgeführt werden, während ein automatischer Backupvorgang ausgeführt wird. Oracle empfiehlt, vor dem Upgrade automatische Backups zu deaktivieren und ein manuelles Backup auszuführen. Weitere Informationen finden Sie unter On-Demand-Backups mit dem bkup_api-Utility erstellen und Automatische Backupkonfiguration anpassen.
  • Nach dem Upgrade können Sie keine automatischen Backups verwenden, die vor dem Upgrade erstellt wurden, um die Datenbank auf einen früheren Zeitpunkt wiederherzustellen.
  • Wenn Sie ein Upgrade einer Datenbank durchführen, die Software der Version 11.2 verwendet, ist die resultierende Datenbank der Version 19c eine Nicht-Containerdatenbank (Nicht-CDB).
Ausführung des Upgradevorgangs durch den Datenbankservice

Machen Sie sich mit den Vorgängen vertraut, die vom Datenbankservice während des Upgradeprozesses ausgeführt werden.

  • Führt eine automatische Vorabprüfung aus. Dadurch kann das System Probleme ermitteln, die behoben werden müssen, und den Upgradevorgang stoppen.
  • Legt einen garantierten Restore Point fest, sodass bei einem Upgradefehler ein Flashback ausgeführt werden kann.
  • Verschiebt die Datenbank in ein benutzerdefiniertes Oracle Database Home, das die gewünschte Zielsoftwareversion verwendet.
  • Führt den Assistenten für Datenbankupgrades (DBUA) aus, um das Upgrade auszuführen.

Übergeordnetes Thema: Oracle-Datenbanken upgraden

Nicht erfolgreiches Upgrade einer Oracle-Datenbank zurücksetzen

Wenn das Upgrade nicht erfolgreich abgeschlossen wird, können Sie ein Rollback ausführen.

Details zum Fehler werden auf der Seite Datenbankdetails in der Konsole angezeigt. Damit können Sie die Fehler analysieren und beheben.

Bei einem Rollback wird Ihre Datenbank auf den Status vor dem Upgrade zurückgesetzt. Alle während und nach dem Upgrade vorgenommenen Änderungen an der Datenbank gehen dabei verloren. Die Rollback-Option wird in einer Bannermeldung angeboten. Diese wird auf der Seite mit den Datenbankdetails einer Datenbank nach einem nicht erfolgreichen Upgradevorgang angezeigt. Weitere Informationen finden Sie unter Nicht erfolgreiche Datenbankupgrades mit der Konsole zurücksetzen.

Nach dem Upgrade einer Oracle-Datenbank

Beachten Sie nach einem erfolgreichen Upgrade Folgendes:

  • Prüfen Sie, ob automatische Backups für die Datenbank aktiviert sind, wenn Sie sie vor dem Upgrade deaktiviert haben. Weitere Informationen finden Sie unter Automatische Backupkonfiguration anpassen.
  • Bearbeiten Sie den Oracle Database-Parameter 
    COMPATIBLE
    entsprechend der neuen Oracle Database-Softwareversion. Weitere Informationen finden Sie unter Was ist Oracle Database-Kompatibilität?.
  • Wenn die Datenbank eine Datei database_name.env verwendet, stellen Sie sicher, dass die Variablen in der Datei so aktualisiert wurden, dass sie auf das 19c-Datenbank-Home verweisen. Diese Variablen sollten während des Upgradeprozesses automatisch aktualisiert werden.
  • Wenn Sie ein Upgrade einer Nicht-Containerdatenbank auf Oracle Database Version 19c ausführen, können Sie die Datenbank nach dem Upgrade in eine integrierbare Datenbank konvertieren. Anweisungen zum Konvertieren Ihrer Datenbank in eine integrierbare Datenbank finden Sie unter How to Convert Non-CDB to PDB (Dok.-ID 2288024.1).
  • Wenn das alte Datenbank-Home leer ist und nicht wiederverwendet wird, können Sie es entfernen. Weitere Informationen finden Sie unter Oracle Database Home mit der Konsole löschen.
Oracle Database-Upgrade mit der Konsole verwalten

Oracle empfiehlt, die Vorabprüfung zu verwenden, um sicherzustellen, dass die Datenbank die Anforderungen für den Upgradevorgang erfüllt.

Vorabprüfung für Oracle Database-Upgrade oder Upgrade mit der Konsole ausführen

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf den Namen des VM-Clusters mit der Datenbank, die Sie upgraden möchten.
  4. Klicken Sie in der Liste der Datenbanken auf der Seite VM-Clusterdetails auf den Namen der Datenbank, die Sie upgraden möchten, um die Seite Datenbankdetails anzuzeigen.
  5. Klicken Sie auf das Menü "Aktionen", und wählen Sie Upgrade aus.
  6. Wählen Sie im Dialogfeld "Datenbank upgraden" Folgendes aus:
    • Oracle Database-Version: Der Dropdown-Selektor listet nur Oracle Database-Versionen auf, die mit einem Upgrade von der aktuellen Softwareversion kompatibel sind, die von der Datenbank verwendet wird. Die Zielsoftwareversion muss höher als die aktuelle Version der Datenbank sein.

    • Zieldatenbank-Home: Wählen Sie ein Datenbank-Home für Ihre Datenbank aus. Die Liste der Datenbank-Homes ist auf die Homes beschränkt, in denen die neuesten Versionen der Oracle Database 19c-Software verwendet werden. Wenn Sie die Datenbank in das neue Datenbank-Home verschieben, wird das Upgrade der Datenbank auf die Major-Release-Version und die Patching-Ebene des neuen Datenbank-Homes durchgeführt.

  7. Klicken Sie auf eine der folgenden Optionen:
    • Vorabprüfung ausführen: Mit dieser Option wird eine Vorabprüfung für Upgrades gestartet, um Probleme mit der Datenbank zu identifizieren, die vor einem Upgrade behoben werden müssen.
    • Datenbank upgraden: Mit dieser Option wird der Upgradevorgang gestartet. Oracle empfiehlt, erst dann ein Upgrade auszuführen, wenn Sie eine erfolgreiche Vorabprüfung für die Datenbank durchgeführt haben.
Nicht erfolgreiche Datenbankupgrades mit der Konsole zurücksetzen

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf den Namen des VM-Clusters, das die Datenbank mit dem nicht erfolgreichen Upgrade enthält.
  4. Suchen Sie die Datenbank mit dem nicht erfolgreichen Upgrade, und klicken Sie auf ihren Namen, um Details anzuzeigen.
  5. Die Datenbank muss oben auf der Detailseite ein Banner mit der Schaltfläche Rollback und Details zu den Problemen anzeigen, die den Upgradefehler verursacht haben.
  6. Klicken Sie auf Rollback.
  7. Bestätigen Sie im Dialogfeld Rollback bestätigen, dass Sie ein Rollback zur vorherigen Oracle Database-Version initiieren möchten.
Updatehistorie einer Datenbank mit der Konsole anzeigen

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Wählen Sie Ihr Compartment aus.
    Für das ausgewählte Compartment wird eine Liste der VM-Cluster angezeigt.
  3. Klicken Sie in der Liste der VM-Cluster auf den Namen des VM-Clusters mit der Datenbank, die Sie upgraden möchten.
  4. Klicken Sie in der Liste der Datenbanken auf der Seite "VM-Clusterdetails" auf den Namen der Datenbank, für die Sie die Upgradehistorie anzeigen möchten.
  5. Klicken Sie auf der Seite "Datenbankdetails" auf Aktualisierungshistorie.
Oracle-Datenbanken mit der API upgraden

Hier finden Sie die Liste der API-Aufrufe zum Upgraden von Oracle-Datenbanken.

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-APIs und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter Software Development Kits und Befehlszeilenschnittstelle (CLI).

Verwenden Sie die folgenden APIs, um Datenbankupgrades zu verwalten:
  • getDatabaseUpgradeHistoryEntry
  • ListDatabaseUpgradeHistoryEntries
  • UpgradeDatabase

Die vollständige Liste der APIs finden Sie unter Database-Service-API.

Oracle Exadata Database Service on Cloud@Customer-System manuell patchen und aktualisieren

In diesem Thema wird beschrieben, wie Sie verschiedene Komponenten in Oracle Exadata Database Service on Cloud@Customer außerhalb der Cloud-Automatisierung patchen und aktualisieren. Informationen zum Patching und zur Aktualisierung 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 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 Standard-Exadata-Tools und Techniken, mit denen Sie die Betriebssystemkomponenten auf den Gast-VMs von Oracle Exadata Database Service on Cloud@Customer aktualisieren können.

Verwandte Themen

Übergeordnetes Thema: Oracle Exadata Database Service on Cloud@Customer-System patchen und aktualisieren

Software manuell aktualisieren

Bei 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 Database Service on 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:
  • 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 Database Service on 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 Standard-Exadata-Tools und -methoden, mit denen Sie die Betriebssystemkomponenten auf den Gast-VMs von Oracle Exadata Database Service on 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: Oracle Exadata Database Service on Cloud@Customer-System manuell patchen und aktualisieren

Betriebssystemupdate vorbereiten

Um ein Betriebssystemupdate für Oracle Exadata Database Service on 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 Database Service on 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 Database Service on Cloud@Customer-Systems.

Sie können das Utility entweder auf einer der virtuellen Maschinen von Oracle Exadata Database Server on Cloud@Customer 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 Database Server on Cloud@Customer installieren.

Sie können Betriebssystempackages auf Oracle Exadata Database Service on 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.

Lösen von Abhängigkeitsproblemen im Zusammenhang mit zusätzlichen Nicht-Exadata-Softwarepaketen für DOMU-Upgrades

Wenn Sie Nicht-Exadata-Softwarepackages über die von Oracle bereitgestellten Packages hinaus installiert haben und die Vorabprüfung bei einem DOMU-Upgrade aufgrund von Konflikten zwischen und von Oracle installierten RPMs nicht erfolgreich verläuft, können Sie die Konflikte wie im Folgenden beschrieben lösen und mit dem Upgrade fortfahren.

Bei Updates, bei denen die Hauptversion von Oracle Linux nicht geändert wird, können Sie mit dieser integrierten Funktion zusätzliche Nicht-Exadata-Softwarepackages im Rahmen des Exadata-Datenbankserverupdates aktualisieren. Es vereinfacht die Behandlung von Packageabhängigkeitsproblemen, die auftreten können, wenn solche Nicht-Exadata-Softwarepackages im System vorhanden sind.

Sie können die Vorabprüfung iterativ ausführen, um Abhängigkeitsprobleme zu identifizieren und zu beheben, die mit den zusätzlichen Nicht-Exadata-Softwarepackages verknüpft sind. Sobald die erforderlichen Updates verstanden sind, können Sie das Exadata-Datenbankserverupdate sicher ausführen und die zusätzlichen Packages in einem einzigen, koordinierten Vorgang aktualisieren.

Stellen Sie sicher, dass die Konfigurationsdatei auf dem Zielserver vorhanden ist, um das Setup eines temporären YUM-Repositorys für Nicht-Exadata-Softwarepackages auszulösen.

  • Dateispeicherort: /etc/exadata/additional-packages.txt
  • Eigentum und Berechtigungen: Diese Datei muss Eigentum des Benutzers root sein und nur vom Benutzer geändert werden können.

Wenn die Datei vorhanden ist, wird sie verwendet, um Informationen zu den erforderlichen Nicht-Exadata-Softwarepackages zu erfassen und ein temporäres YUM-Repository einzurichten und zu aktivieren. Wenn die Datei nicht vorhanden ist, ist kein Repository konfiguriert.

Sie können auch einen symbolischen Link unter /etc/exadata/additional-packages.txt erstellen, der auf eine Konfigurationsdatei verweist, die sich an anderer Stelle befindet – in der Regel auf einem freigegebenen Mount.

Dateiformat

Die Datei muss eine Liste der Nicht-Exadata-Softwarepackages enthalten, wobei jeder Eintrag in einer neuen Zeile steht. Folgende Formate werden unterstützt:

  • http(s)://path/to/package.rpm: Vollständige URL zur RPM-Datei
  • /full/path/to/package.rpm: Absoluter Pfad zu einer lokalen RPM-Datei
  • repo:package.rpm: Referenz auf ein Package in einem vorhandenen YUM-Repository
Hinweis

  • Wenn Sie das Format repo: verwenden, stellen Sie sicher, dass das referenzierte Repository in der YUM-Konfiguration des Zielservers definiert ist.
  • Lokale Dateien können sich in lokalen Standardverzeichnissen, NFS-Mounts oder ACFS-Mounts befinden.
Beispiel: additional-packages.txt

/u01/elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm
/u01/elfutils-libelf-devel-0.190-2.el8.x86_64.rpm
/u01/keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm
https://example.com/packages/krb5-devel-1.18.2-28.0.1.el8_10.x86_64.rpm
https://example.com/packages/memstrack-0.2.5-2.el8.x86_64.rpm
/u01/pigz-2.4-4.el8.x86_64.rpm
/u01/sssd-nfs-idmap-2.9.4-3.0.1.el8_10.x86_64.rpm
https://example.com/packages/timedatex-0.5-3.el8.x86_64.rpm
https://example.com/packages/zlib-devel-1.2.11-25.el8.x86_64.rpm