EBS 12.2 quick scripts

How To Check if a Patch is Applied in 12.2.x using SQL*PLUS

In EBS 12.2 we all know that Online patching has been introduced. Thus during a patching cycle if a patch has been applied using adop phase=apply and later we aborted it before the cycle gets complete, the table ad_bugs and ad_applied_patches will not be updated. So we cannot query these two tables. As per metalink note:Doc ID 1963046.1, use the below query to find out if a patch has been applied or not.

**************************************************
select AD_PATCH.IS_PATCH_APPLIED(\'$release\',\'$appltop_id\',\'$patch_no\',\'$language\')
from dual;


Example sql using the APPL_TOP ID for a specific node in a multinode environment (1045 is the APPL_TOP ID):

SELECT adb.bug_number,ad_patch.is_patch_applied('R12', 1045, adb.bug_number)
FROM ad_bugs adb
WHERE adb.bug_number in (20034256);

or for single app tier installations:

select ad_patch.is_patch_applied('R12',-1,20034256) from dual;

expected results:
EXPLICIT = applied
NOT APPLIED = not applied / aborted


Also don't forget to complete the APPL_TOP snapshot using adadmin option.
***********************************************************************

ADOP Online patching concepts

adop phases:

prepare       : Prepare the instance for online patching.
apply         : Apply patch(es) to the Patch Edition.
finalize      : Ready the instance for cutover.
abort         : Abort the patching cycle.
cutover       : Promote the Patch Edition to Run Edition.
cleanup       : Drop obsolete objects and seed data from Old Editions.
actualize_all : Actualize all objects in the Patch Edition.
cleanup_full  : Cleanup and drop Old Editions.
abandon       : yes|no - Abandon failed patches.



adop patch log directory:

<INSTALL BASE>/fs_ne/EBSapps/log/adop


adop patch process cycle steps:

Download any required technology patches and unzip the contents. The patch contents may be unzipped into  $NE_BASE/EBSapps/patch.

1. Prepare the system for patching.

   source <EBS_ROOT>/EBSapps.env run

   $ adop phase=prepare

2. Apply technology patches to the Oracle Home under the Patch f/s using the information below.

   source <EBS_ROOT>/EBSapps.env patch

3. Apply any Oracle E-Business Suite patches planned for this patching cycle

   $ adop phase=apply patches=<patch_list>

4. After all patches have been successfully applied, complete the patching cycle.

   $ adop phase=finalize
   $ adop phase=cutover

Note: Below steps can be done when applications are up and running

5. source <EBS_ROOT>/EBSapps.env run
 
   $ adop phase=cleanup

6. To complete the process and synchronize the technology level between patch and run f/s.

   $ adop phase=fs_clone



adop hotpatch steps (we cannot abort hotpatch and abondon cannot be done):

Hotpatch which can apply directly on run fs

$ adop phase=apply patches=<patch_list> hotpatch=yes

After hotpatch please run phase=cleanup and phase=fs_clone to sync the run fs with patch fs to prepare for next patching cycle



adop re-apply patch forcefully:

If we try to re-apply the patch which is already applied/exists then adop patch terminates
with below message and by default it takes N when prompted. to overcome this we need to
re-apply patch with options=forceapply.
This Patch seems to have been applied already.
Would you like to continue anyway  [N] ? N *


$ adop phase=apply patches=<patch list> hotpatch=yes options=forceapply



 adop deal with "Continue As If It Were Successful" error:

$ adop phase=apply patches=<patch list> abandon=no restart=yes flags=autoskip



To define workers in adop:



$ adop phase=apply patches=<patch list> workers=5



To define patchtop in adop:



$ adop phase=apply patches=<patch list> patchtop=<patch location base>



adop merge patch:



$ adop phase=apply patches=<patch list> merge=yes



Restarting adop From A Failed Session:




 $ adop phase=abort
 $ adop phase=cleanup cleanup_mode=full
 $ adop phase=fs_clone

Then reapply the patch



adop apply for language patch:



$ adop phase=apply patches=18023722_ESA:u18023722.drv



adop non-interactive with patch top and define driver:



$ adop phase=apply options=nocopyportion patchtop=$XLA_TOP/patch/115 patches=driver:xla5584908.drv



adop Steps to follow to skip the failed workers:



1. Use adctrl and select option#8 (This will not be visible) to skip thefailed jobs
2. Restart adop using "restart=yes" parameter

** If the failed jobs are numerous, then better to re-start this patch once again with autoskip option.

ie.  adop restart=no abandon=yes flags=autoskip

This command will restart the patch once again from starting onwards and will skip all the failures if any comes. But make sure to review the log file at the end of the patch application that you have skipped the failures that you want to.




Weblogic Server Smart Update Patching :

Steps to apply weblogic server smart update patch:


Refer Note:
How to Apply WebLogic Server (WLS) Patches Using Smart Update [Video] (Doc ID 876004.1)

1.Download the patch
2.Copy the files (for example, E5W8.jar and WGQJ.jar) and the patch-catalog_xxx.xml from the zip file to the target machine. You do not need the readme file.
Path: $FMW_HOME/utils/bsu/cache_dir

3.cd $FMW_HOME/utils/bsu

To install patch:
./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -patchlist=7FC9 -verbose -install

To Verify:
./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -status=applied -verbose -view | grep 7FC9

To Rollback:
./bsu.sh -remove -patchlist=7FC9 -prod_dir=$FMW_HOME/wlserver_10.3 -verbose

We can also apply the Smart Update patch in graphical (GUI) mode.




Steps to apply opatch on FMW Web Tier HOME :


Set the Environment as below (replace <INSTALL_BASE> path as required):

$ export ORACLE_HOME=$FMW_HOME/webtier
$ export PATH=$ORACLE_HOME/OPatch:$PATH

$ opatch lsinventory


Apply opatch:

$ opatch apply




Steps to apply opatch on FMW oracle_common HOME :


Set the Environment as below:

$ export ORACLE_HOME=$FMW_HOME/oracle_common
$ export PATH=$ORACLE_HOME/OPatch:$PATH

$ opatch lsinventory

Apply opatch:

$ opatch apply




Queries :

 Query to check if a patch is applied in Oracle EBS R12.2.x:

In Oracle E Business Suite (ebs erp) R12.2.x you cannot query the AD_BUGS table to check if patches have been applied..
The AD_BUGS table may have entries for patches that were applied but later the patching cycle was aborted (not really applied).


The way to check whether a patch is really applied is to use the AD_PATCH.IS_PATCH_APPLIED PL/SQL function.

Usage:

select AD_PATCH.IS_PATCH_APPLIED(\'$release\',\'$appltop_id\',\'$patch_no\',\'$language\')
from dual;

Example sql:

SELECT adb.bug_number,ad_patch.is_patch_applied('11i', 1045, adb.bug_number)
FROM ad_bugs adb
WHERE adb.bug_number in (20034256);

or for single app tier installations:

select ad_patch.is_patch_applied('R12',-1,20034256) from dual;

Expected results:

EXPLICIT = applied
NOT APPLIED = not applied / aborted

Note: If you are sure patch is applied, but showing as not applied then do the following workaround.


1. Start adadmin after source the RUN FS env.
2. Select "2. Maintain Applications Files menu" in "AD Administration Main Menu".
3. In "Maintain Applications Files", select "4. Maintain snapshot information".
4. Select "2. Update current view snapshot" in the "Maintain Snapshot Information".
5. Select "1. Update Complete APPL_TOP" in the "Maintain Current View Snapshot Information".


Query to check current AD patchset:

SELECT a.application_short_name, b.patch_level
FROM fnd_application_vl a,fnd_product_installations b
WHERE a.application_id = b.application_id
  and application_short_name = 'AD';



Query to check patches applied correctly and in the expected sequence:



1.1.Run this sql statement:

   select * from ad_adop_session_patches order by end_date desc;

1.2. Run this piece of sql code:

   set pagesize 200;
   set linesize 160;
   column adop_session_id format 999999999999;
   column bug_number format a15;
   column status format a15;
   column applied_file_system_base format a23;
   column patch_file_system_base format a23;
   column adpatch_options format a15;
   column node_name format a15;
   column end_date format a15;
   column clone_status format a15;

   select ADOP_SESSION_ID, BUG_NUMBER, STATUS, APPLIED_FILE_SYSTEM_BASE, PATCH_FILE_SYS   TEM_BASE, ADPATCH_OPTIONS, NODE_NAME, END_DATE, CLONE_STATUS
   from ad_adop_session_patches
   order by end_date desc;


Below are possible values of STATUS column:
N - Not Applied In the current node but applied in other nodes
R - Patch Application is going on.
H - Patch failed in the middle. (Hard Failure)
F - Patch failed in the middle but user tried to skip some failures.
S - Patch Application succeeded after skipping the failed jobs.
Y - Patch Application succeeded.
C - Reserved for clone and config_clone. Indicates clone completed



Query to Check AD and TXK C Patch levels:



SELECT codelevel FROM AD_TRACKABLE_ENTITIES WHERE abbreviation in ('txk','ad');



Restarting adop

1 If you have shut down the workers, or if adop quits while performing processing actions, it saves all the actions completed up to that point in restart files.
Investigate and Patching Utilities resolve the problem that caused the failure,
then restart adop. After you restart adop, it will ask if you want to continue with the previous session (at the point where the processing stopped), or start a new session.
To restart from beginning,  use restart=no abandon=yes
To restart a patch you need to use restart=yes abandon=no .

eg. adop restart=no abandon=yes  phase=apply
If still can not restart,
2 Check the contents of the AD_ADOP_SESSIONS and AD_ADOP_SESSION_PATCHES tables
---------------------------------------------------------------------------------------
2.1
column id format 99
column nn format a10
column nt format a6
select adop_session_id id, prepare_status pr, apply_status ap,
finalize_status fi, cutover_status cu, cleanup_status cl, abort_status ab, status st, node_name nn, node_type nt
from ad_adop_sessions
order by adop_session_id desc;

2.2
column id format 99
column bn format a12
column pr format 99999999
column afs format a40
column pfs format a40
column cs format a9
column nn format a10
column ed format a28
column drv format a28
column pt format a35

select adop_session_id id, bug_number bn, patchrun_id pr, status st,
node_name nn, cast(end_date as timestamp) ed, driver_file_name drv, patch_top  pt
from ad_adop_session_patches
order by end_date desc;

2.3 explanation example of above output
=========================
 Examining the AD_ADOP_SESSIONS table,
 ID P A F C C A S NN         NT
 --- - - - - - - - ---------- ------
3 X P N X N X F test2    master
2 R N N N N Y C test2    master

It looks like the first ADOP cycle (prepare phase) was attempted at session ID 2 and then for some reason it didn't finish and then an abort was  initiated which did finish.  A new ADOP session (ID 3) was attempted but via hotpatch and it failed.  Since this table only reports what went on with ADOP there's no information about adpatch usage, i.e. if it was used before the
 first ADOP cycle or in between session 2 and 3, or after session 3.

2.4 To diagnostic further for the root cause why patch application failed, we need adpatch log for the failed patch xxxx.
cd  $APPL_TOP_NE/../log/adop/<session id>
eg.
 /d01/EBS/VIS/fs_ne/EBSapps/log/adop/<session id>/timestamp/context_name/xxxx/log

3 If you are just wants to start from a fresh page and considering the state of these tables
I would suggest making a manual modification to the  AD_ADOP_SESSIONS table just so it would not hold up ADOP execution due to an
incomplete hotpatch session.
 Do the following:
update ad_adop_sessions set status='C' where adop_session_id=3;

4 restart adop and retest.