Er kan een scenario zijn waarin de overgangsfase is mislukt. Het is mogelijk om terug te gaan naar de vorige staat van cutover (de patch terugdraaien), als de flashback-database is ingeschakeld in de database of als we een volledige back-up hebben gemaakt voorafgaand aan de cutover
Ik zou het uitleggen met betrekking tot Database Flashback om de patch terug te draaien
Ik neem aan dat hier Flashback is ingeschakeld in de database. We kunnen dat bevestigen met het commando
SQL>select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------
Yes
U kunt meer te weten komen over de Flashback-database via onderstaande links
Flashback Oracle Database
Hoe te flashen als we dataguard hebben
Het wordt aanbevolen om de overgangsfase van Online Patching in te plannen op een moment dat er weinig online transacties zijn en batchverwerking minimaal is. U moet bevestigen dat kritieke gelijktijdige verzoeken niet worden uitgevoerd tijdens het overschakelen. U moet ook overwegen om geplande gelijktijdige verzoeken in de wacht te zetten voordat de cutover wordt uitgevoerd, omdat anders de cutover-fase wacht tot het programma is voltooid en u transactiegegevens verliest in geval van flashback
Laten we eens kijken naar het probleemgeval
Geval 1
U voert een Online Patching-cyclus uit:
$ adop phase=prepare
$ adop phase=apply patches=99999999
$ adop phase=finalize
$ adop phase=cutover
Cutover mislukt en u moet teruggaan naar de toestand van het systeem voordat u de overgangsfase uitvoerde.
Als u de overgangsfase niet had uitgevoerd, had u het proces voor het aanvragen van de patch kunnen terugdraaien door de fase voor het afbreken van de goedkeuring uit te voeren. Dit is echter niet mogelijk als de cutover eenmaal is uitgevoerd.
Er zijn twee hoofdonderdelen om de patch terug te draaien:
(1) Databaseherstel :Flashback-database is de snelste methode om de databasewijzigingen terug te draaien en terug te gaan naar een bepaald punt in de tijd. We kunnen ook de databasehersteltechniek gebruiken, maar dat kost veel tijd
De database terug flashen
a).Sluit eerst de database af en start deze vervolgens op in de aangekoppelde staat:
SQL>shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL>startup mount ORACLE instance started.
b).Herstel de flashback naar de opgegeven tijd.
SQL>flashback database to time to_data(<time before teh cutover>; Flashback complete.
c).Start de database in alleen-lezen modus:
SQL>alter database open read only; Database altered. Check all looks as expected.
d).Sluit de database af, start hem op in mount-status en open hem dan met de resetlogs-optie:
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) Bestandssysteem herstellen :Afhankelijk van wanneer het overzetten is mislukt, moet u mogelijk ook de bestandssystemen van de applicatielaag herstellen
De bestandssystemen herstellen
Of u deze stap moet uitvoeren, is voorwaardelijk, afhankelijk van of de cutover is mislukt voordat de bestandssystemen werden gewijzigd. U kunt identificeren welke van deze gevallen van toepassing is door te verwijzen naar de cutover-logboeken in $NE_BASE/EBSapps/log/adop/
Geval 1 – Als de logberichten aangeven dat de cutover is mislukt voordat de bestandssystemen werden omgeschakeld, sluit u alle actieve services schoon af. Start vervolgens alle services opnieuw met het normale opstartscript,
Geval 2 – Als de logberichten aangeven dat de omschakeling is mislukt nadat de bestandssystemen zijn omgeschakeld, volg dan de onderstaande stap om de bestandssystemen terug te schakelen.
(a) Sluit services af die zijn gestart vanaf het nieuwe run-bestandssysteem
1.Bron de omgeving op het nieuwe run-bestandssysteem.
2.Sluit vanaf $ADMIN_SCRIPTS_HOME alle services af (met adstpall .sh op UNIX).
(b)In een omgeving met meerdere knooppunten herhaalt u de voorgaande twee stappen op alle knooppunten en laat u het beheerdersknooppunt over tot alle slave-knooppunten.
(c) Schakel bestandssystemen terug
Op alle knooppunten waar bestandssystemen zijn omgeschakeld, voer je de volgende opdracht uit om de bestandssystemen terug te schakelen:
$ 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 services op vanaf het oude bestandssysteem (met behulp van adstrtal.sh op UNIX).
(e)In een omgeving met meerdere knooppunten herhaalt u de voorgaande twee stappen op alle knooppunten, te beginnen met het beheerdersknooppunt en ga dan verder naar de slave-knooppunten
Conclusie
Nadat het herstel is voltooid, hebt u twee basisopties om door te gaan:
(a) Breek de huidige patchcyclus af, als het probleem dat u moest herstellen werd veroorzaakt door de patches die u probeerde toe te passen.
Hier zijn stappen om een online patchcyclus af te breken
Als een patchcyclus mislukt en het probleem niet snel kan worden opgelost, is het mogelijk om de patchcyclus af te breken en terug te keren naar de normale runtime-werking. De patcheditie wordt verwijderd.
U kunt een patchcyclus verlaten (zonder patches toe te passen) door het commando uit te voeren:
$ adop phase=abort
Als u een patchcyclus afbreekt, wordt de patcheditie verwijderd, maar u moet dan de fasen opschonen en fs_clone uitvoeren voordat u een nieuwe patchcyclus start. Het opruimen moet een volledige opruiming zijn.
For example:
$ adop phase=prepare
$ adop phase=apply patches=9999999
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone
Optioneel kunt u de opdrachten voor afbreken en opschonen als volgt combineren:
$ adop phase=abort,cleanup cleanup_mode=full
(b) Identificeer en verhelp eventuele andere problemen in de huidige patchcyclus, en ga verder met patchen.