La preparazione della fase di adozione è la prima fase del ciclo di applicazione delle patch in linea nella versione R12.2. Adop esegue molte azioni nella fase. Di seguito è riportata la sequenza delle attività
1. Verifica se eseguire una pulizia, che sarà necessaria se l'utente non è riuscito a richiamare la pulizia dopo la fase di cutover di un precedente ciclo di patch online .
2.Convalida la configurazione del sistema per garantire che il sistema sia pronto per avviare un ciclo di patching online.
3.Verifica se il database è pronto per l'applicazione di patch online :
a)Verifica se l'utente del database è abilitato all'edizione. In caso contrario, adop esce immediatamente con un errore.
b) Verifica se il servizio patch è stato creato. adop richiede l'esistenza di uno speciale servizio di database allo scopo di connettersi all'edizione patch. Questo servizio viene creato automaticamente, ma la sua esistenza continua viene convalidata ad ogni preparazione.
c) Verifica se il trigger di accesso esiste ed è abilitato. Se il trigger di accesso è mancante o il servizio patch non è stato creato, adop proverà automaticamente a risolvere il problema in modo che possa procedere. Se non può farlo, uscirà con un messaggio di errore.
d) Verifica l'integrità del dizionario dei dati del database. Se viene rilevata una corruzione, adop esce con errorease 12.2.
e) Verifica che sia stato eseguito E-Business Suite Technology Codelevel Checker (ETCC) per verificare che tutte le patch richieste siano state applicate al database.
4.Verifica la configurazione del sistema su ciascun nodo del livello dell'applicazione. Viene convalidata una serie di impostazioni critiche per garantire che ogni nodo del livello dell'applicazione sia correttamente registrato, configurato e pronto per l'applicazione di patch.
Verifica il file system, utilizzando lo script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Questo script verifica lo spazio del file system, le connessioni al database, le password di app/sistema/Weblogic, la convalida del file di contesto e così via
E produce anche un report che mostra le informazioni sui tablespace più importanti. Questo rapporto viene creato in $APPL_TOP/admin/$TWO_TASK/out.
5.Verifica l'esistenza di "Applicazione di patch online in corso" (ADZDPATCH) programma simultaneo. Questo programma impedisce l'avvio di determinati programmi simultanei predefiniti e, pertanto, deve essere attivo mentre è in corso un ciclo di patch (ovvero, mentre esiste un'edizione di patch del database).
Il flusso del processo è
a.Se il programma ADZDPATCH non è stato ancora richiesto per l'esecuzione, viene inviata una richiesta.Se non esiste, viene segnalato l'errore di seguito
ERRORE alla riga 1:
ORA-20008:non è definito un gestore simultaneo in grado di eseguire programmi simultanei
ADZDPATCH
b. Viene determinato lo stato di ADZDPATCH. Se è in sospeso, potrebbe essere in attesa del completamento di un programma incompatibile. Dopo che l'incompatibilità è stata eliminata, il suo stato passerà a In esecuzione e consentirà di procedere con la fase di preparazione. All'utente viene visualizzato un messaggio in tal senso.
c.La fase successiva dipende dal fatto che i gestori simultanei siano in esecuzione:
i.Se i gestori simultanei sono tutti inattivi, la fase di preparazione continua, con ADZDPATCH che entra nello stato di sospeso (con la priorità più alta) fino all'avvio dei gestori.
ii.Se i gestori simultanei sono parzialmente attivi, ma non c'è non è definito alcun manager in grado di eseguire ADZDPATCH, la fase di preparazione uscirà con un errore.
iii.Se i gestori simultanei sono attivi ed è definito uno che può eseguire ADZDPATCH, l'elaborazione verrà ripetuta finché ADZDPATCH non cambia lo stato da in attesa di esecuzione. La fase di preparazione continua.
ADZDPATCH viene annullato al termine della fase di cutover.
Se vuoi che un programma personalizzato non venga eseguito nel ciclo di patch, dovrai renderlo incompatibile con questo programma
6.Invoca lo script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl per sincronizzare le patch che sono stati applicati all'esecuzione APPL_TOP, ma non alla patch APPL_TOP. Lo script dipende dal repository adop per le patch che sono state applicate durante l'esecuzione APPL_TOP ma non dalla patch APPL_TOP.
it Identifica le patch che sono state applicate all'esecuzione APPL_TOP e le applica alla patch APPL_TOP. I seguenti passaggi vengono eseguiti automaticamente:
a.Le patch che devono essere applicate alla patch APPL_TOP vengono identificate dal database.
b.Le patch unite vengono applicate dall'utilità adop.
L'utilità adop identifica le patch delta da applicare, e li applica silenziosamente alla patch corrente APPL_TOP. Poiché questa procedura richiede solo l'applicazione di patch delta, richiede meno tempo
In alcune circostanze, il metodo di sincronizzazione in stile delta (incrementale) potrebbe non riuscire quando si applicano una serie di patch all'edizione della patch. Ciò può verificarsi se il ciclo di patch precedente includeva patch che non venivano applicate correttamente ed era seguito da patch successive che correggevano il problema.
Il parametro skipsyncerror consente di specificare che si prevede che eventuali errori di sincronizzazione nella fase di preparazione vengano corretti automaticamente nella sincronizzazione che avviene con le patch successive.
Se il valore del parametro viene passato come 'yes', la prima patch da sincronizzare verrà eseguita con il flag 'autoskip' impostato.
Importante:è tua responsabilità controllare i file di log e correggere eventuali errori in la successiva fase di applicazione o per confermare che la sincronizzazione con le patch successive ha risolto il problema.
Un esempio di utilizzo di questo parametro potrebbe essere il seguente.
a.Si esegue adop phase=prepare.
b.La fase non riesce con un errore durante il tentativo di sincronizzare i file system di esecuzione e patch. Cioè, il tentativo di sincronizzare una patch non riesce, ma è noto che una patch successiva risolverà il problema.
c. Esamina i file di registro e conclude che gli errori di sincronizzazione verranno corretti automaticamente nella sincronizzazione che richiede place con le patch successive.
d.Esegui il comando adop phase=prepare skipsyncerror=yes per riavviare la fase di preparazione. Questa volta, l'applicazione della patch non riuscita nella preparazione precedente verrà ritentata con il flag "autoskip" impostato.
Sincronizzazione delle personalizzazioni
Il metodo di sincronizzazione del file system predefinito in stile delta (incrementale) gestisce le patch ufficiali ma non sincronizza le personalizzazioni applicate manualmente. Esempi di azioni di patching che non sono sincronizzate per impostazione predefinita includono:
Compilazione di JSP definiti dall'utente
Copia di alcune librerie di terze parti
Copia e compilazione di programmi simultanei definiti dall'utente
Copia e generazione di moduli definiti dall'utente
Per includere azioni di patch personalizzate nella sincronizzazione del file system predefinita, è necessario includere i comandi richiesti nel driver di sincronizzazione personalizzato, $APPL_TOP_NE/ad/custom/adop_sync.drv . Aggiungerai le tue personalizzazioni alla seguente sezione del file:
#Inizio personalizzazione
…
#Fine personalizzazione
Tutte le azioni definite in questo file verranno eseguite automaticamente da adop durante la fase di preparazione. Tieni presente che ci sono due categorie di comandi personalizzati in adop_sync.drv:quelli che vengono eseguiti una sola volta e quelli che vengono eseguiti a ogni sincronizzazione del file system (durante la fase di preparazione dell'adozione).
Importante:adop_sync. drv non è attualmente ripristinato al suo file modello in nessun momento. Di conseguenza, dopo il cutover (e prima della successiva fase di preparazione), dovresti rivedere il contenuto di adop_sync.drv e assicurarti che i requisiti per i tuoi comandi personalizzati continuino a essere soddisfatti.
7.Controlla l'esistenza di una patch nel database edizione e ne crea uno se non lo trova.
a) Nel database viene creata un'edizione patch.
b) Tutti gli oggetti di codice nell'edizione patch iniziano come puntatori a oggetti di codice nell'edizione run. Gli oggetti di codice nell'edizione patch iniziano come "oggetti stub" leggeri che puntano alle definizioni degli oggetti effettive, che sono ereditate dalle edizioni precedenti. Gli oggetti stub occupano uno spazio minimo, quindi l'edizione della patch del database è inizialmente di dimensioni molto ridotte.
c) Quando le patch vengono applicate all'edizione della patch, gli oggetti di codice vengono attualizzati (viene creata una nuova definizione) in quella edizione.
8.Richiama lo script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl per confermare che la connessione del database all'edizione della patch funzioni.
Articoli correlati
Adozione spiegata in R12.2
Riepilogo del ciclo di patch online R12.2
