R12.2 Apps DBA. Powered by Blogger.

adop phase=abort continues to error

No comments :
From the logs session 32 (abort) is failing on all nodes because of failure on primary node. Primary node has failed during the attempt to sync the context file with DB but the s_contextserial values did not match. This can occur when OAM is used to change values but changes not succesfully synced back to the file system.
1. Run the following SQL so we can see the values for s_contextserial that is stored in the DB
SELECT extractValue(XMLType(TEXT),'//host[@oa_var="s_hostname"]'),
EXTRACTVALUE(XMLType(text),'//*[@oa_var="s_contextname"]'),
extractValue(XMLType(TEXT),'//s_contextserial')
from fnd_oam_context_files
where name not in ('TEMPLATE','METADATA')
and (status is null or status !='H')
and EXTRACTVALUE(XMLType(TEXT),'//file_edition_type')='run'
and CTX_TYPE = 'A';

SELECT extractValue(XMLType(TEXT),'//host[@oa_var="s_hostname"]'),
EXTRACTVALUE(XMLType(text),'//*[@oa_var="s_contextname"]'),
extractValue(XMLType(TEXT),'//s_contextserial')
from fnd_oam_context_files
where name not in ('TEMPLATE','METADATA')
and (status is null or status !='H')
and EXTRACTVALUE(XMLType(TEXT),'//file_edition_type')='patch'
and CTX_TYPE = 'A';

2. Compare the results seen in the context file on the RUN and PATCH file system. If necessary update the context file to match that returned in the above SQL. Then retry the abort
/u17/home/ebsuat/fs1/inst/apps/ebsuat_ebsx01appd02/appl/admin/ebsuat_ebsx01appd02.xml: <oa_context_name oa_var="s_contextname">ebsuat_ebsx01appd02</oa_context_name>
/u17/home/ebsuat/fs1/inst/apps/ebsuat_ebsx01appd02/appl/admin/ebsuat_ebsx01appd02.xml: <oa_context_serial oa_var="s_contextserial">690</oa_context_serial>
/u17/home/ebsuat/fs1/inst/apps/ebsuat_ebsx01appd02/appl/admin/ebsuat_ebsx01appd02.xml: <host oa_var="s_hostname">ebsx01appd02</host>
/u17/home/ebsuat/fs2/inst/apps/ebsuat_ebsx01appd02/appl/admin/ebsuat_ebsx01appd02.xml: <oa_context_name oa_var="s_contextname">ebsuat_ebsx01appd02</oa_context_name>
/u17/home/ebsuat/fs2/inst/apps/ebsuat_ebsx01appd02/appl/admin/ebsuat_ebsx01appd02.xml: <oa_context_serial oa_var="s_contextserial">785</oa_context_serial>
/u17/home/ebsuat/fs2/inst/apps/ebsuat_ebsx01appd02/appl/admin/ebsuat_ebsx01appd02.xml: <host oa_var="s_hostname">ebsx01appd02</host>

Can you try bouncing all application tier services for this environment and retry fs_clone? If so, please perform below steps and share us the results.
This has been helped other customers when facing the issue "FS clone cannot be called while a patching cycle is active "
1 shutdown all apps services on RUN and PATCH file systems.
e.g.
. <EBS_ROOT>/EBSapps.env run
cd $INST_TOP/admin/scripts
adstpall.sh apps/apps
. <EBS_ROOT>/EBSapps.env patch
cd $INST_TOP/admin/scripts
adstpall.sh apps/apps
2. On the RUN file system, start up admin server via the following command
. <EBS_ROOT>/EBSapps.env run
cd $INST_TOP/admin/scripts
$ adadminsrvctl.sh start
Ensure the Weblogic Admin Server and Node Manager are running on the Run File
system. You can run the following commands to check the status:
$ adadminsrvctl.sh status
$ adnodemgrctl.sh status
3. Run these in order:
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone force=yes

No comments :

Post a Comment

Note: only a member of this blog may post a comment.