Der kan være et scenarie når nedskæringsfasen mislykkedes . Det er muligt at gå tilbage til tidligere cutover-tilstand (rulning af patchen), hvis flashback-database enten er aktiveret i databasen, eller vi har taget fuld backup før cutover
Jeg vil forklare det med hensyn til Database Flashback for at rulle patchen tilbage
Jeg går ud fra, at vi her har Flashback aktiveret i databasen. Det kan vi bekræfte ved at bruge kommandoen
SQL>select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------
Yes
Du kan lære mere om Flashback-databasen i nedenstående links
Flashback Oracle Database
Sådan Flashback, når vi har dataguard
Det anbefales, at online patch-overskæringsfasen planlægges til et tidspunkt, hvor der er få onlinetransaktioner, og batchbehandlingen er minimal. Du bør bekræfte, at kritiske samtidige anmodninger ikke udføres under cutover. Du bør også overveje at sætte planlagte samtidige anmodninger i bero før udførelse af cutover, da cutover-fasen ellers vil vente på, at programmet er færdig, og du vil miste transaktionsdata i tilfælde af flashback
Lad os se på problemtilfældet
Case 1
Du kører en online patch-cyklus:
$ adop phase=prepare
$ adop phase=apply patches=99999999
$ adop phase=finalize
$ adop phase=cutover
Cutover mislykkes, og du skal gå tilbage til systemets tilstand, før du kørte cutover-fasen.
Hvis du ikke havde kørt cutover-fasen, ville du have været i stand til at rulle patch-ansøgningsprocessen tilbage ved at køre adop-afbrydelsesfasen. Dette er dog ikke muligt, når cutover først er kørt.
Der er to hoveddele til at rulle patchen tilbage:
(1) Databasegendannelse :Flashback-database er den hurtigste metode til at rulle databaseændringerne tilbage og gå tilbage til tidspunktet. Vi kan også bruge databasegendannelsesteknik, men det er meget tidskrævende
Blinker databasen tilbage
a). Luk først databasen ned, og start den derefter i mount-tilstand:
SQL>shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL>startup mount ORACLE instance started.
b).Gendan flashback til det angivne tidspunkt.
SQL>flashback database to time to_data(<time before teh cutover>; Flashback complete.
c). Start databasen i skrivebeskyttet tilstand:
SQL>alter database open read only; Database altered. Check all looks as expected.
d). Luk databasen, start den i mount-tilstand, og åbn den derefter med resetlogs-indstillingen:
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) Filsystemgendannelse :Afhængigt af hvornår cutover mislykkedes, skal du muligvis også gendanne applikationsniveauets filsystemer
Gendannelse af filsystemerne
Om du skal udføre dette trin er betinget, afhængigt af om cutover mislykkedes, før filsystemerne blev skiftet. Du kan identificere hvilke af disse tilfælde, der gælder ved at henvise til cutover-logfilerne i $NE_BASE/EBSapps/log/adop/
Tilfælde 1 – Hvis logmeddelelserne indikerer, at cutover mislykkedes, før filsystemerne blev skiftet, skal du foretage en ren lukning af alle tjenester, der kører. Genstart derefter alle tjenester ved hjælp af det normale opstartsscript,
Tilfælde 2 – Hvis logmeddelelserne indikerer, at cutover mislykkedes, efter at filsystemerne blev skiftet, skal du følge nedenstående trin for at skifte filsystemerne tilbage.
(a) Luk tjenester startet fra nyt kørefilsystem
1. Kilde miljøet på det nye kørefilsystem.
2.Luk alle tjenester fra $ADMIN_SCRIPTS_HOME (ved hjælp af adstpall) .sh på UNIX).
(b)I et miljø med flere noder skal du gentage de to foregående trin på alle noder, mens du forlader admin noden indtil efter alle slaveknuderne.
(c) Skift filsystemer tilbage
På alle noder, hvor filsystemer er blevet skiftet, skal du køre følgende kommando for at skifte filsystemerne tilbage:
$ 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)Start alle tjenester fra det gamle kørselsfilsystem (ved brug af adstrtal.sh på UNIX).
(e)I et multi-node miljø, gentag de foregående to trin på alle noder, startende med admin node og fortsætter derefter til slaveknuderne
Konklusion
Når gendannelsen er fuldført, har du to grundlæggende muligheder for at fortsætte:
(a) Afbryd den aktuelle programrettelsescyklus, hvis problemet, der krævede, at du skulle gendanne, var forårsaget af de programrettelser, du forsøgte at anvende.
Her er trin til at afbryde en online patch-cyklus
Hvis en patch-cyklus mislykkes, og problemet ikke kan løses hurtigt, er det muligt at afbryde patch-cyklussen og vende tilbage til normal runtime-drift. Patch-udgaven vil blive slettet.
Du kan forlade en patch-cyklus (uden at anvende nogen patches) ved at køre kommandoen:
$ adop phase=abort
Afbrydelse af en patch-cyklus vil droppe patch-udgaven, men du skal derefter køre oprydnings- og fs_clone-faserne, før du starter en ny patch-cyklus. Oprydningen skal være en fuldstændig oprydning.
For example:
$ adop phase=prepare
$ adop phase=apply patches=9999999
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone
Du kan eventuelt kombinere afbrydelses- og oprydningskommandoerne som følger:
$ adop phase=abort,cleanup cleanup_mode=full
(b) Identificer og ret eventuelle andre problemer i den aktuelle patch-cyklus, og fortsæt med patching.