Potrebbe esserci uno scenario in cui la fase di cutover non è riuscita. È possibile tornare allo stato di cutover precedente (ripristinare la patch), se il database di flashback è abilitato nel database o se abbiamo eseguito un backup completo prima del cutover
Lo spiegherei rispetto a Database Flashback per eseguire il rollback della patch
Presumo che qui abbiamo Flashback abilitato nel database. Possiamo confermarlo usando il comando
SQL>select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------
Yes
Puoi saperne di più sul database Flashback nei link sottostanti
Database Oracle Flashback
Come eseguire il Flashback quando abbiamo dataguard
Si consiglia di pianificare la fase di cutover dell'applicazione delle patch online per un periodo in cui ci sono poche transazioni online e l'elaborazione batch è minima. Dovresti confermare che le richieste simultanee critiche non vengono eseguite durante il cutover. Dovresti anche considerare di sospendere le richieste simultanee programmate prima di eseguire il cutover, altrimenti la fase di cutover attenderà il completamento del programma e inoltre perderai i dati della transazione in caso di flashback
Esaminiamo il Caso Problema
Caso 1
Stai eseguendo un ciclo di patch online:
$ adop phase=prepare
$ adop phase=apply patches=99999999
$ adop phase=finalize
$ adop phase=cutover
Il cutover non riesce e devi tornare allo stato del sistema prima di eseguire la fase di cutover.
Se non avessi eseguito la fase di cutover, saresti stato in grado di ripristinare il processo di applicazione della patch eseguendo la fase di interruzione dell'adozione. Tuttavia, ciò non è possibile una volta eseguito il cutover.
Esistono due parti principali per eseguire il rollback della patch:
(1) Ripristino database :Il database Flashback è il metodo più veloce per eseguire il rollback delle modifiche al database e tornare indietro nel tempo. Possiamo anche utilizzare la tecnica di ripristino del database, ma ciò richiede molto tempo
Eseguire il flashing del database
a). Innanzitutto, arrestare il database, quindi avviarlo in stato di montaggio:
SQL>shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL>startup mount ORACLE instance started.
b).Ripristina il flashback all'ora specificata.
SQL>flashback database to time to_data(<time before teh cutover>; Flashback complete.
c).Avviare il database in modalità di sola lettura:
SQL>alter database open read only; Database altered. Check all looks as expected.
d).Chiudi il database, avvialo in stato di montaggio, quindi aprilo con l'opzione resetlogs:
SQL>shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL>startup mount ORACLE instance started. Database mounted. SQL>alter database open resetlogs; Database altered.
2) Ripristino del file system :a seconda di quando il cutover non è riuscito, potrebbe essere necessario ripristinare anche i file system del livello dell'applicazione
Ripristino dei file system
La necessità di eseguire questo passaggio è condizionale, a seconda che il cutover abbia avuto esito negativo prima che i file system fossero cambiati. Puoi identificare quale di questi casi si applica facendo riferimento ai registri di cutover in $NE_BASE/EBSapps/log/adop/
Caso 1:se i messaggi di registro indicano che il cutover non è riuscito prima del passaggio dei file system, eseguire un arresto pulito di tutti i servizi in esecuzione. Quindi riavvia tutti i servizi utilizzando il normale script di avvio,
Caso 2:se i messaggi di registro indicano che il cutover non è riuscito dopo il passaggio dei file system, segui i passaggi seguenti per ripristinare i file system.
(a) Chiudere i servizi avviati dal nuovo file system di esecuzione
1.Source l'ambiente sul nuovo file system di esecuzione.
2.Da $ADMIN_SCRIPTS_HOME, chiudere tutti i servizi (usando adstpall .sh su UNIX).
(b)In un ambiente multi-nodo, ripeti i due passaggi precedenti su tutti i nodi, lasciando il nodo admin fino al termine di tutti i nodi slave.
(c) Ripristino dei file system
Su tutti i nodi in cui sono stati commutati i file system, eseguire il comando seguente per ripristinare i file system:
$ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl \ -action=ctxupdate \ -contextfile=<full path to new run context file> \ -patchcontextfile=<full path to new patch file system context file> \ -outdir=<full path to out directory>
(d)Avvia tutti i servizi dal vecchio file system di esecuzione (usando adstrtal.sh su UNIX).
(e)In un ambiente a più nodi, ripeti i due passaggi precedenti su tutti i nodi, iniziando con il nodo admin e poi procedendo ai nodi slave
Conclusione
Al termine del ripristino, hai due opzioni di base per procedere:
(a) Interrompi il ciclo di patch corrente, se il problema che ha richiesto il ripristino è stato causato dalle patch che stavi tentando di applicare.
Ecco i passaggi per interrompere un ciclo di patching online
Se un ciclo di patch non riesce e il problema non può essere risolto rapidamente, è possibile interrompere il ciclo di patch e tornare al normale funzionamento di runtime. L'edizione della patch verrà eliminata.
Puoi abbandonare un ciclo di patch (senza applicare alcuna patch) eseguendo il comando:
$ adop phase=abort
L'interruzione di un ciclo di patch eliminerà l'edizione della patch, ma è necessario eseguire le fasi di cleanup e fs_clone prima di iniziare un nuovo ciclo di patch. La pulizia deve essere una pulizia completa.
For example:
$ adop phase=prepare
$ adop phase=apply patches=9999999
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone
Facoltativamente, puoi combinare i comandi di interruzione e pulizia come segue:
$ adop phase=abort,cleanup cleanup_mode=full
(b) Identificare e risolvere eventuali altri problemi nel ciclo di patch corrente e procedere con l'applicazione delle patch.
