Actually, it depends on the situation.. whether the cutover failed before the file systems were switched or not. You can identify this using the cutover logs stored in the adop cutover log file ($NE_BASE/EBSapps/log/adop/<current_session_id>/ cutover_<timestamp>/ for your session ID). If the cutover failed before the file systems were switched, then you are lucky.. as you just need to shut down all the application services, you just restore your db (for instance using flashback feature), and then start all the application services using the run edition environment like in your standard startup procedure.
Read -> Oracle E-Business Suite Release 12.2: Backup and Recovery Guidelines For Online Patching (adop) Cutover (Doc ID 1584097.1)Read -> http://ermanarslan.blogspot.com/2014/07/ebs-122-recovering-cutover-problems.htmlIf the log file indicates that cutover failed after the file systems were switched, then you have to follow a different action plan. That is, if the file systems were switched, then you need to switch back the file systems in order to roll back your application tier to its state before the cutover phase. What you need to do is as follows:
Source the environment on the current run file system.
Shut down all the application services using the standard procedure (adstpall.sh)
Switch back the file system using txkADOPCutOverPhaseCtrlScript.pl.
Usage :
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>
Lastly, start up all services from the new run file system using the standard procedure. (Source run edition environment and use the adstrtal.sh script to start all the application services.)
--This is a risky process. So better follow -> Oracle E-Business Suite Release 12.2: Backup and Recovery Guidelines For Online Patching (adop) Cutover (Doc ID 1584097.1)
Locked
