Det kan finnas scenario när cutover-fasen misslyckades. Det är möjligt att gå tillbaka till tidigare tillstånd för cutover (återställ patchen), om flashback-databasen antingen är aktiverad i databasen eller om vi har tagit fullständig säkerhetskopia före cutover
Jag skulle förklara det med avseende på Database Flashback för att återställa patchen
Jag antar att vi här har Flashback aktiverat i databasen. Vi kan bekräfta det med kommandot
SQL>select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------
Yes
Du kan lära dig mer om Flashback-databasen i länkarna nedan
Flashback Oracle Database
Hur man Flashback när vi har dataguard
Det rekommenderas att övergångsfasen för onlinepatchning ska schemaläggas för en tid då det finns få onlinetransaktioner och batchbearbetningen är minimal. Du bör bekräfta att kritiska samtidiga förfrågningar inte körs under cutover. Du bör också överväga att sätta schemalagda samtidiga förfrågningar på is innan du kör cutover eftersom cutover-fasen annars väntar på att programmet slutförs plus att du kommer att förlora transaktionsdata i händelse av flashback
Låt oss titta på problemfallet
Fall 1
Du kör en online-patchcykel:
$ adop phase=prepare
$ adop phase=apply patches=99999999
$ adop phase=finalize
$ adop phase=cutover
Cutover misslyckas och du måste gå tillbaka till systemets tillstånd innan du körde cutover-fasen.
Om du inte hade kört cutover-fasen, skulle du ha kunnat återställa patch-ansökningsprocessen genom att köra adop abort-fasen. Detta är dock inte möjligt när cutover har körts.
Det finns två huvuddelar för att återställa patchen:
(1) Databasåterställning :Flashback-databas är den snabbaste metoden för att återställa databasändringarna och gå tillbaka till tidpunkten. Vi kan också använda databasåterställningsteknik men det är väldigt tidskrävande
Blinkar tillbaka databasen
a). Stäng först av databasen och starta den sedan i monteringsläge:
SQL>shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL>startup mount ORACLE instance started.
b).Återställ flashback till angiven tid.
SQL>flashback database to time to_data(<time before teh cutover>; Flashback complete.
c).Starta databasen i skrivskyddat läge:
SQL>alter database open read only; Database altered. Check all looks as expected.
d). Stäng av databasen, starta upp den i monteringsläge och öppna den sedan med alternativet 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) Filsystemåterställning :Beroende på när cutover misslyckades, kan du också behöva återställa programnivåns filsystem
Återställa filsystemen
Om du behöver utföra detta steg är villkorat, beroende på om cutover misslyckades innan filsystemen byttes. Du kan identifiera vilka av dessa fall som gäller genom att hänvisa till cutover-loggarna i $NE_BASE/EBSapps/log/adop/
Fall 1 – Om loggmeddelandena indikerar att cutover misslyckades innan filsystemen byttes, gör en ren avstängning av alla tjänster som körs. Starta sedan om alla tjänster med det vanliga startskriptet,
Fall 2 – Om loggmeddelandena indikerar att cutover misslyckades efter att filsystemen byttes, följ stegen nedan för att byta tillbaka filsystemen.
(a) Stäng av tjänster som startat från nytt körfilsystem
1. Käll in miljön på det nya körfilsystemet.
2. Stäng av alla tjänster från $ADMIN_SCRIPTS_HOME (med adstpall) .sh på UNIX).
(b)I en miljö med flera noder, upprepa de två föregående stegen på alla noder och lämna adminnoden tills efter alla slavnoderna.
(c) Byt tillbaka filsystem
På alla noder där filsystem har bytts, kör följande kommando för att byta tillbaka filsystemen:
$ 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)Starta alla tjänster från det gamla körfilsystemet (med adstrtal.sh på UNIX).
(e)I en miljö med flera noder, upprepa de två föregående stegen på alla noder, börja med adminnoden och fortsätter sedan till slavnoderna
Slutsats
När återställningen är klar har du två grundläggande alternativ för att fortsätta:
(a) Avbryt den aktuella korrigeringscykeln, om problemet som krävde att du återställde orsakades av korrigeringarna du försökte använda.
Här är steg för att avbryta en onlinepatchningscykel
Om en lappningscykel misslyckas och problemet inte kan lösas snabbt, är det möjligt att avbryta lappningscykeln och återgå till normal körtid. Patch-utgåvan kommer att tas bort.
Du kan överge en korrigeringscykel (utan att applicera några korrigeringar) genom att köra kommandot:
$ adop phase=abort
Om du avbryter en korrigeringscykel försvinner korrigeringsversionen, men du måste sedan köra rensnings- och fs_clone-faserna innan du startar en ny korrigeringscykel. Rengöringen måste vara en fullständig rensning.
For example:
$ adop phase=prepare
$ adop phase=apply patches=9999999
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone
Alternativt kan du kombinera kommandona avbryt och rensning enligt följande:
$ adop phase=abort,cleanup cleanup_mode=full
(b) Identifiera och åtgärda eventuella andra problem i den aktuella patchningscykeln och fortsätt med patchningen.