Erinnerung an die Anwendung von Oracle CPU-Patches
by Rackspace Technology Staff
Einführung Dieser Blog beschreibt, wie wichtig es ist, einen ADOP-Zyklus (Application DBA Online Patching Utility) mit fs_clone auszuführen, nachdem Änderungen oder Technologie-Patches an den Home-Verzeichnissen von Weblogic Server (WLS) oder Oracle© Fusion Middleware (FMW) in Ihrem Patch-Dateisystem vorgenommen wurden. Der Blog befasst sich mit einem Problemszenario und erklärt, wie man die damit verbundenen Probleme einfach lösen kann.
Die Phasen des ADOP-Zyklus
Die folgende Abbildung zeigt die Phasen des ADOP-Zyklus:
< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>
Problemgeschichte
Nach der Anwendung von Critical Path Update (CPU) Patches auf eine Oracle Version R12.2 Instanz auf einem Patch-Dateisystem, führte ADOP einen vollständigen Zykluslauf durch (vorbereiten, anwenden, abschließen, umschalten und bereinigen). Nach der Ausführung eines weiteren ADOP-Zyklus für eine andere Aktivität wurde die Instanz auf einen anderen Server geklont.
Bei der Anwendung von WLS-Patches auf die neue geklonte Umgebung trat jedoch ein Konflikt auf. Der Patch wies auf eine Versionsabweichung des WLS hin.
Analyse
Nachforschungen ergaben, dass die CPU-Patches, die zuvor auf WLS und FMW Web Tier und die gemeinsamen Oracle-Home-Verzeichnisse angewendet wurden, nicht im Run- und Patch-Dateisystem enthalten waren.Bei einer weiteren Untersuchung der ADOP-Protokolldateien stellten wir fest, dass die Vorbereitungsdatei das Dateisystem synchronisierte, wir konnten jedoch nicht die Änderungen sehen, die in den Verzeichnissen Oracle\_home und FMW\_home während des Patching-Zyklus vorgenommen wurden.
Abzug:
Aus unserer Analyse ziehen wir die folgenden Schlussfolgerungen:
1. Die Dateisynchronisation in der Vorbereitungsphase gilt nur für die APPL\_TOP.
Die von uns überprüften Protokolldateien zeigen, dass sich Änderungen am Dateisystem vom Lauf APPL\_TOP zum Patch APPL\_TOPfortpflanzen.
2. Nach der Anwendung von Weblogic-Patches wurde `fs_clone` nicht ausgeführt, bevor der nächste ADOP-Zyklus eingeleitet wurde. Daher erscheinen die neuen Patches auch nach Abschluss des zweiten ADOP-Zyklus nicht in den nachfolgenden Instanzen, und sie waren in der geklonten Instanz nicht verfügbar.
Empfehlung
In der Vorbereitungsphase wird das Patch-Dateisystem in der Regel mit dem Run-Dateisystem synchronisiert, indem eine neue Datenbankedition angelegt wird. Dies ist eine standardmäßige inkrementelle Synchronisierung von Dateien, die auf der Anwendungsseite geändert werden.
Um die angewandten Patches zu synchronisieren, rufen Sie txkADOPPreparePhaseSynchronize.pl zum $APPL\_TOP des laufenden Dateisystems aus dem letzten Patching-Zyklus auf oder rufen Sie `fs_clone` auf. In diesem Fall rufen wir nicht das eigentliche `fs_clone` auf. Stattdessen rufen wir FsCloneStage und `sCloneApply für den $APPL_TOPauf, was sehr unsynchronisiert ist.
Die Methode zur Synchronisierung des Dateisystems wird automatisch auf der Grundlage des Konfigurationsänderungsdetektors ausgewählt (`adConfigChangeDetector.pl -detectConfigChanges`)
Die verschiedenen Methoden der Dateisynchronisierung umfassen die folgenden Optionen:
Option 1 - Identifizierung von Patches aus der Datenbank, die beim letzten ADOP angewendet wurden. Führen Sie diese zusammen und wenden Sie sie stillschweigend an. Dieser Prozess nimmt weniger Zeit in Anspruch, da das System nur die nicht angewandten Patches anwendet.
Option 2 - Erstellen Sie das Run-Dateisystem $APPL\_TOP neu oder klonen Sie es auf das Patch-Dateisystem $APPL\_TOP. Dies ist extrem unsynchronisiert und verbraucht mehr Ressourcen.
Option 3 - Verwenden Sie die Software eines Drittanbieters Ihrer Wahl (z. B. `rsync`), um das Dateisystem zu synchronisieren.
Mit prepare übergebene Parameter
Prepare` verwendet die folgenden Parameter:
a) Verwenden Sie die Option "Skipsyncerror" in der ADOP-Vorbereitungsphase, um Fehler und Warnungen zu ignorieren, die auftreten können, wenn die Patch-Anwendung in einem vorangegangenen Patch-Zyklus fehlgeschlagen ist, und zwar als Workaround für Synchronisationsfehler und -ausfälle. Der Standardwert für ist NO.
syntax : `adop phase=prepare skipsyncerror=yes`
b) Verwenden Sie die Option "sync_mode", um die Methode für die Synchronisierung des Patch-Dateisystems mit einem Run-Dateisystem anzugeben. Syntax `adop phase=prepare sync_mode=(delta|patch)`
sync_mode patch - Wendet Patches an, die bereits auf das Dateisystem (Standardmodus) angewendet wurden. sync_mode delta - Kopiert alle Anpassungen und Dateiänderungen. Dieser Modus verwendet den Synchronisationsbefehl aus der Datei delta\_sync\_drv.txt und ist eine neue Funktion von `AD-TXK delta 8`.
ADOP fs_clone Befehl
Mit dem Befehl "fs_clone" wird das gesamte Patch-Dateisystem neu erstellt oder rekloniert, einschließlich aller Konfigurationen und Anpassungen auf dem Patch-Dateisystem in der gleichen Weise wie auf dem Run-Dateisystem. Dies ist genauso ressourcenintensiv wie die Erstellung einer vollständigen Sicherung des laufenden Dateisystems und die anschließende Erstellung eines Patch-Dateisystems.
fs_clone` hat die folgenden nützlichen Befehle:
- -adop phase=fs_clone force=yes ` - Startet einen fehlgeschlagenen Klon von Anfang an neu
- (Standard=NO).
- -adop phase=fs_clone s_fs_backup_count=1` - Legt die Anzahl der Backups der
- das Patch-Dateisystem muss erhalten bleiben, bevor es aus dem Lauf wiederhergestellt werden kann
- dateisystem (Standard=0, es werden keine Sicherungen erstellt).
Die wichtigsten Erkenntnisse
Obwohl die Vorbereitungsphase zu Beginn eines jeden Patching-Zyklus stattfindet, werden die Technologie-Stack-Patches (die mit dem Dienstprogramm `opatch/Smart update` angewendet werden) in der Vorbereitungsphase nicht synchronisiert.
- Prepare synchronisiert keine manuell vorgenommenen Änderungen wie:
- Kompilieren von benutzerdefinierten JSPs.
- Kopieren von Bibliotheken von Drittanbietern.
- Kopieren und Kompilieren von benutzerdefinierten gleichzeitigen Programmen.
- Kopieren und Erstellen von benutzerdefinierten Formularen.
Sie müssen die benutzerdefinierten Patching-Aktionen (wie die zuvor beschriebenen) im benutzerdefinierten Synchronisierungstreiber "adop_sync.drv" in der Vorbereitungsphase hinzufügen.
In der Dateiadop_sync.drvgibt es die folgenden Kategorien von Befehlen:
- Nur einmalig ausführen
- Bei jeder Synchronisierung des Dateisystems ausführen
Um Anpassungen und Dateiänderungen in der Vorbereitungsphase zu kopieren, verwenden Sie den folgenden Befehl :
aDOP phase=prepare sync_mode=(delta|patch)`
Wenn Patches abgebrochen oder Wartungs- oder Release Update Pack (RUP)- Patches angewendet werden, muss `fs_clone` am Ende ausgeführt werden, um das Patch-Dateisystem als exakte Kopie des ausgeführten Dateisystems neu zu erstellen.
Fazit
Wann immer Änderungen am Weblogic Server oder an den Fusion Middleware-Komponenten von E-Business Suite Release 12.2 vorgenommen werden, müssen Datenbankadministratoren unbedingt `fs_clone` ausführen, um sicherzustellen, dass das Patch-Dateisystem mit allen letzten Änderungen aktualisiert wird, die an WLS oder FMW des laufenden Dateisystems vorgenommen wurden.

Recent Posts
Der Bericht über den Zustand der Cloud 2025
Januar 10th, 2025
Google Cloud Hybrid Networking-Muster - Teil 2
Oktober 16th, 2024
Google Cloud Hybrid Networking-Muster - Teil 2
Oktober 15th, 2024
How Rackspace Leverages AWS Systems Manager
Oktober 9th, 2024
Windows Server verhindert Zeitsynchronisation mit Rackspace NTP
Oktober 3rd, 2024