Vorbereitung der Adop-Phase ist die erste Phase im Online-Patching-Zyklus in R12.2. Adop führt in dieser Phase viele Aktionselemente aus. Hier ist die Abfolge der Aktivitäten.
1. Überprüft, ob eine Bereinigung durchgeführt werden soll, die erforderlich ist, wenn der Benutzer die Bereinigung nach der Umstellungsphase eines vorherigen Online-Patch-Zyklus nicht aufgerufen hat .
2.Überprüft die Systemkonfiguration, um sicherzustellen, dass das System bereit ist, einen Online-Patch-Zyklus zu starten.
3.Überprüft, ob die Datenbank für das Online-Patching vorbereitet ist :
a)Überprüft, ob der Datenbankbenutzer für die Bearbeitung freigegeben ist. Wenn nicht, wird Adop sofort mit einem Fehler beendet.
b) Prüft, ob der Patch-Dienst erstellt wurde. Adop erfordert, dass ein spezieller Datenbankdienst existiert, um sich mit der Patch-Edition zu verbinden. Dieser Dienst wird automatisch erstellt, aber sein Fortbestehen wird bei jeder Vorbereitung validiert.
c) Prüft, ob der Anmeldeauslöser existiert und aktiviert ist. Wenn der Logon-Trigger fehlt oder der Patch-Service nicht erstellt wurde, versucht Adop automatisch, das Problem zu beheben, damit es fortfahren kann. Wenn dies nicht möglich ist, wird es mit einer Fehlermeldung beendet.
d)Überprüft die Integrität des Datenbankdatenverzeichnisses. Wenn eine Beschädigung gefunden wird, wird Adop mit einem errorease 12.2 beendet.
e) Prüft, ob der E-Business Suite Technology Codelevel Checker (ETCC) ausgeführt wurde, um sicherzustellen, dass alle erforderlichen Patches auf die Datenbank angewendet wurden.
4. Prüft die Systemkonfiguration auf jedem Knoten der Anwendungsebene. Eine Reihe kritischer Einstellungen werden validiert, um sicherzustellen, dass jeder Knoten der Anwendungsebene korrekt registriert, konfiguriert und zum Patchen bereit ist.
Überprüft das Dateisystem mit dem TXK-Skript $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Dieses Skript prüft den Speicherplatz des Dateisystems, Datenbankverbindungen, Apps/System/Weblogic-Passwörter, Kontextdatei-Validierung usw.
Und es erstellt auch einen Bericht mit Informationen zu den wichtigsten Tabellenbereichen. Dieser Bericht wird in $APPL_TOP/admin/$TWO_TASK/out erstellt.
5. Überprüft, ob "Online-Patching läuft" (ADZDPATCH) vorhanden ist paralleles Programm. Dieses Programm verhindert, dass bestimmte vordefinierte gleichzeitige Programme gestartet werden, und muss daher aktiv sein, während ein Patch-Zyklus im Gange ist (dh während eine Datenbank-Patch-Edition existiert).
Der Prozessablauf ist
a.Falls die Ausführung des ADZDPATCH-Programms noch nicht angefordert wurde, wird eine Anforderung gesendet. Wenn es nicht existiert, wird der folgende Fehler gemeldet
FEHLER in Zeile 1:
ORA-20008:Es ist kein Concurrent Manager definiert, der gleichzeitige Programme ausführen kann
ADZDPATCH
b.Der Status von ADZDPATCH wird ermittelt. Wenn es aussteht, wartet es möglicherweise auf die Beendigung eines inkompatiblen Programms. Nachdem die Inkompatibilität behoben wurde, ändert sich ihr Status in wird ausgeführt, und die Vorbereitungsphase kann fortgesetzt werden. Eine entsprechende Meldung wird dem Benutzer angezeigt.
c.Die nächste Stufe hängt davon ab, ob die Concurrent Manager ausgeführt werden:
i.Wenn alle gleichzeitigen Manager ausgefallen sind, wird die Vorbereitungsphase fortgesetzt, wobei ADZDPATCH in den Status „Ausstehend“ (mit der höchsten Priorität) wechselt, bis die Manager gestartet werden.
ii.Wenn die gleichzeitigen Manager teilweise, aber vorhanden sind Ist kein Manager definiert, der ADZDPATCH ausführen kann, wird die Vorbereitungsphase mit einem Fehler beendet.
iii. Wenn die gleichzeitigen Manager aktiv sind und einer definiert ist, der ADZDPATCH ausführen kann, wird die Verarbeitung in einer Schleife ausgeführt, bis ADZDPATCH den Status von ändert anstehend zum Laufen. Anschließend wird die Vorbereitungsphase fortgesetzt.
ADZDPATCH wird abgebrochen, wenn die Umstellungsphase abgeschlossen ist.
Wenn Sie möchten, dass ein benutzerdefiniertes Programm nicht im Patch-Zyklus ausgeführt wird, müssen Sie es mit diesem Programm inkompatibel machen wurden auf den Lauf APPL_TOP angewendet, aber nicht auf den Patch APPL_TOP. Das Skript hängt vom Adop-Repository für Patches ab, die auf den Lauf APPL_TOP angewendet wurden, aber nicht auf den Patch APPL_TOP.
it Identifizieren Sie die Patches, die auf den Lauf APPL_TOP angewendet wurden, und wenden Sie sie auf den Patch APPL_TOP an. Die folgenden Schritte werden automatisch ausgeführt:
a.Die Patches, die auf den Patch APPL_TOP angewendet werden müssen, werden aus der Datenbank identifiziert.
b.Die zusammengeführten Patches werden vom Adop-Dienstprogramm angewendet.
Das Adop-Dienstprogramm identifiziert die anzuwendenden Delta-Patches, und wendet sie stillschweigend auf den aktuellen Patch APPL_TOP an. Da dieses Verfahren nur die Anwendung von Delta-Patches erfordert, ist es weniger zeitaufwändig
Unter bestimmten Umständen kann die (inkrementelle) Synchronisierungsmethode im Delta-Stil fehlschlagen, wenn eine Reihe von Patches auf die Patch-Edition angewendet werden. Dies kann passieren, wenn der vorherige Patch-Zyklus Patches enthielt, die nicht richtig angewendet wurden, und nachfolgende Patches folgten, die das Problem behoben haben.
Mit dem Parameter skipsyncerror können Sie angeben, dass Sie erwarten, dass alle Synchronisierungsfehler in der Vorbereitungsphase automatisch in der Synchronisierung behoben werden, die mit nachfolgenden Patches stattfindet.
Wenn der Wert des Parameters als „yes“ übergeben wird, wird der erste zu synchronisierende Patch mit gesetztem „autoskip“-Flag ausgeführt.
Wichtig:Es liegt in Ihrer Verantwortung, die Protokolldateien zu überprüfen und etwaige Fehler zu korrigieren die anschließende Anwendungsphase oder um zu bestätigen, dass die Synchronisierung mit nachfolgenden Patches das Problem behoben hat.
Ein Beispiel für die Verwendung dieses Parameters wäre wie folgt.
a.Sie führen „adop phase=prepare“ aus.
b.Die Phase schlägt mit einem Fehler fehl, wenn versucht wird, die Run- und Patch-Dateisysteme zu synchronisieren. Das heißt, der Versuch, einen Patch zu synchronisieren, schlägt fehl, aber es ist bekannt, dass ein nachfolgender Patch das Problem beheben wird.
c. Sie untersuchen die Protokolldateien und kommen zu dem Schluss, dass die Synchronisierungsfehler automatisch in der Synchronisierung behoben werden, die dauert mit nachfolgenden Patches ersetzen.
d. Sie führen den Befehl adop phase=prepare skipsyncerror=yes aus, um die Vorbereitungsphase erneut zu starten. Dieses Mal wird die Anwendung des Patches, der bei der vorherigen Vorbereitung fehlgeschlagen ist, mit gesetztem Flag „Autoskip“ erneut versucht.
Synchronisieren von Anpassungen
Die standardmäßige (inkrementelle) Methode der Dateisystemsynchronisierung im Delta-Stil verarbeitet offizielle Patches, synchronisiert jedoch keine manuell angewendeten Anpassungen. Beispiele für Patch-Aktionen, die standardmäßig nicht synchronisiert werden, sind:
Benutzerdefinierte JSPs kompilieren
Kopieren einiger Bibliotheken von Drittanbietern
Kopieren und Kompilieren benutzerdefinierter nebenläufiger Programme
Kopieren und Generieren von benutzerdefinierten Formularen
Um benutzerdefinierte Patch-Aktionen in die standardmäßige Dateisystemsynchronisierung aufzunehmen, müssen Sie die erforderlichen Befehle in den benutzerdefinierten Synchronisierungstreiber $APPL_TOP_NE/ad/custom/adop_sync.drv . Sie fügen Ihre Anpassungen dem folgenden Abschnitt der Datei hinzu:
#Begin Customization
…
#End Customization
Alle in dieser Datei definierten Aktionen werden von Adop während der Vorbereitungsphase automatisch ausgeführt. Beachten Sie, dass es zwei Kategorien von benutzerdefinierten Befehlen in adop_sync.drv gibt:solche, die nur einmal ausgeführt werden, und solche, die bei jeder Dateisystemsynchronisierung (während der Adop-Vorbereitungsphase) ausgeführt werden.
Wichtig:Die Datei adop_sync. drv-Datei wird derzeit zu keinem Zeitpunkt auf ihre Vorlagendatei zurückgesetzt. Daher sollten Sie nach der Umstellung (und vor der nächsten Vorbereitungsphase) den Inhalt von adop_sync.drv überprüfen und sicherstellen, dass die Anforderungen für Ihre benutzerdefinierten Befehle weiterhin erfüllt werden.
7.Überprüft die Datenbank auf das Vorhandensein eines Patches Edition und erstellt eine, falls keine gefunden wird.
a)Eine Patch-Edition wird in der Datenbank erstellt.
b)Alle Code-Objekte in der Patch-Edition beginnen als Zeiger auf Code-Objekte in der Run-Edition. Code-Objekte in der Patch-Edition beginnen als leichtgewichtige „Stub-Objekte“, die auf die eigentlichen Objektdefinitionen verweisen, die von früheren Editionen geerbt wurden. Stub-Objekte verbrauchen nur minimalen Speicherplatz, daher ist die Datenbank-Patch-Edition anfänglich sehr klein.
c) Wenn Patches auf die Patch-Edition angewendet werden, werden Codeobjekte in dieser Edition aktualisiert (mit einer neuen Definition erstellt).
8. Ruft das Skript $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl erneut auf, um zu bestätigen, dass die Datenbankverbindung zur Patch-Edition funktioniert.
Verwandte Artikel
Adop erklärt in R12.2
R12.2 Zusammenfassung des Online-Patch-Zyklus
