Wednesday, July 8, 2015

ADOP failed jobs

From AD.4 and TXK.4 , autoskip option for failed jobs is turned off. -- (flags=noautoskip).

Before this, autoskip was enabled (flags=autoskip) and so autoskip.log needs to checked after patch application and before cutover.


From Ad.4, a new option wait_on_failed_job is available to deal with failed jobs.

This will allow the user to use adctrl to update the workers and jobs when a job has failed.

The option is valid only for SQL failures anyhow.


In the case of failures during the "generate" portion of a patch,
i.e Forms, Reports etc the generation code(fs actions like genpll etc) does not obey the wait_on_failed_job parameter.
As with previous EBS releases, if form or report generation failed the worker returns success
and then populates the list of failures in a text file.

This is then read by manager code and the manager throws the prompt:

***
Continue as if it were successful :
***


There is no token entry in a defaults file for prompt “Continue as if successful”.
 The autoskip flag was used to pipe a "no/yes" value for ALL these prompts.
 Currently there is no flag or option to address individual failed prompts.
 The flags=noautoskip is now the default with AD.Delta 4 and TXK Delta 4, therefore a response of "no" is passed to these prompts
 so the patch session terminates as follows:

AutoPatch could not find a response to the above prompt
or found an incorrect response in the defaults file.


You must run AutoPatch in an interactive session
and provide a correct value.

Tuesday, July 7, 2015

Some Useful queries for ADOP and patching

SQL> select * from fnd_oam_context_files where name not in ('TEMPLATE', 'METADATA');
SQL> SELECT abbreviation, codelevel FROM AD_TRACKABLE_ENTITIES WHERE abbreviation in ('txk','ad');
SQL> select ad_patch.is_patch_applied('R12',-1, bug_number ) from dual;
    select release_name from apps.fnd_product_groups;
     AD_ADOP_SESSION_PATCHES:
SQL> select ADOP_SESSION_ID, BUG_NUMBER, ADPATCH_OPTIONS, CLONE_STATUS, STATUS, NODE_NAME from AD_ADOP_SESSION_PATCHES
order by ADOP_SESSION_ID,END_DATE;
AD_ADOP_SESSIONS:
SQL> select ADOP_SESSION_ID, PREPARE_STATUS, APPLY_STATUS, FINALIZE_STATUS, CUTOVER_STATUS, CLEANUP_STATUS, ABORT_STATUS, STATUS,
ABANDON_FLAG, NODE_NAME from AD_ADOP_SESSIONS order by ADOP_SESSION_ID;
SQL> select * from fnd_nodes;
SQL> select * from ad_appl_tops;
select BUG_NUMBER, ADPATCH_OPTIONS from AD_ADOP_SESSION_PATCHES where BUG_NUMBER = '';

SQL> select ADOP_SESSION_ID, PREPARE_STATUS, APPLY_STATUS,
     CUTOVER_STATUS, CLEANUP_STATUS, ABORT_STATUS, STATUS
     from AD_ADOP_SESSIONS
     order by ADOP_SESSION_ID;
   
     These status values are updated when a step has completed, and are as follows:

N denotes that the phase has not been completed
0 denotes that cutover/force_shutdown has started
1 denotes the "force_shutdown" step has successfully executed
3 denotes the "db_cutover" step has successfully executed
4 denotes the "fs_cutover" step has successfully executed
6 denotes the "force_startup" step has successfully executed
Y denotes that the phase is done

SQL> select ADOP_SESSION_ID,BUG_NUMBER,ADPATCH_OPTIONS, CLONE_STATUS,STATUS,NODE_NAME
from AD_ADOP_SESSION_PATCHES
order by ADOP_SESSION_ID;