When|How Can We Reverse the Cutover in Oracle Apps R12.2 - YES or No?
Cutover is a Critical Phase and changes would be committed at this level. If you want to cancel the patching cycle you should go for abort.
But still, in some failure states, we can try to recover after the cutover has happened.
I would not recommend these steps and may hamper your system. Because once the patch DB edition has been promoted run DB edition it will not be a good idea to revert from there.
If a cutover error occurs, you should first check the error message and try to determine if the problem can be fixed easily and try to fix that and re-run cutover.
But if you want to revert to the state of the system before the patching cycle was started, you can use the Oracle Database Flashback feature to go back to a designated point in time (a restore point). You should create the restore point just before running the cutover phase.
Before creating the restore point, it is advisable to issue a suitable downtime notification and shut down the web services. This will ensure you do not lose any transactional data, and in effect simply extends slightly the cutover downtime.
Depending on exactly when the failure occurred, you may also need to restore the application tier file systems.
Note:
1) All concurrent managers have been shut down cleanly.
2) There are no current database transactions being performed by any third-party applications.
Steps to enable flashback:
1) Enable flashback parameters
DB_RECOVERY_FILE_DEST_SIZE - Specifies the size of the Fast Recovery Area.
DB_RECOVERY_FILE_DEST - Specifies the physical location of the Flashback recovery files.
SQL>alter system set db_recovery_file_dest_size = 10G scope=BOTH SID='*';
System altered.
SQL>alter system set db_recovery_file_dest = '/archlog/TEST/' scope=BOTH SID='*';
System altered.
2) Specify maximum flashback time
alter system set db_flashback_retention_target=120;
3) Activate Flashback
SQL>alter database flashback on;
4) Create a restore point
SQL>alter system switch logfile;
System altered.
SQL>create restore point BEFORE_CUTOVER_FUNEBS guarantee flashback database;
Restore point created.
SQL>alter system switch logfile;
System altered.
How to restore the DB and Application
Let's say your cutover is failing and now we want to restore it to a flashback
1) shut down the database, then start it up in mount state:
SQL>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>startup mount
ORACLE instance started.
2) Restore the flashback to the specified restore point:
SQL>flashback database to restore point BEFORE_CUTOVER_FUNEBS;
Flashback complete.
3) Start the database in read-only mode:
SQL>alter database open read only;
Database altered.
4) Shut down the database, start it up in mount state, then open it with the resetlogs option:
SQL>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>startup mount
ORACLE instance started.
Total System Global Area 2142679040 bytes
Fixed Size 1346140 bytes
Variable Size 520095140 bytes
Database Buffers 1593835520 bytes
Redo Buffers 27402240 bytes
Database mounted.
SQL>alter database open resetlogs;
Database altered.
5) Disable flashback:
SQL>alter database flashback off;
Database altered.
6) Drop the restore point:
SQL>drop restore point BEFORE_CUTOVER;
Restore point dropped.
7) Set recovery file destination:
SQL>alter system set db_recovery_file_dest='';
System altered.
8) Confirm that Flashback has been deactivated:
SQL>select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------
NO
If cutover has failed at the file system level then we need to restore that as well.
It has 2 scenarios
Scenario 1 - If the log messages indicate that cutover failed before the file systems were switched, do a clean shutdown of any services that are running. Then restart all the services using the normal startup script
Scenario 2 - If the log messages indicate that cutover failed after the file systems were switched.
Then
1) Shut down services started from new run file system
Source the environment on the new run file system.
From $ADMIN_SCRIPTS_HOME, shut down all the services
In a multi-node environment, repeat the preceding two steps on all nodes, leaving the admin node until after all the slave nodes.
2) Switch file systems back
On all nodes where file systems have been switched, run the following command to switch the file systems back:
$ 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>
3) Start up all services from the old run file system
In a multi-node environment, repeat the preceding two steps on all nodes, starting with the admin node and then proceeding to the slave nodes.
Comments
Post a Comment