Application Version R12.1.1
DB Version 126.96.36.199
During upgrade from R12.1.1 to R12.1.3 . When i was running ATG patch 8919491, during relinking phase in patch sesseionall application program with adrelink, got failure on MSC product.
Relink of module “MSONEW” failed.
Relink of module “FEMCCE” failed.
Relink of module “MSRNEW” failed.
Relink of module “MSCCPP” failed.
Relink of module “MSCMON” failed.
Relink of module “MSCNEW” failed.
Relink of module “MSCNSP” failed.
Relink of module “MSCNSPNM” failed.
Relink of module “MSCPCL” failed.
Relink of module “MSCPDW” failed.
Relink of module “MSCPRG” failed.
Relink of module “MSCSDW” failed.
Relink of module “MSCSLD” failed.
Relinking module ‘MSCXGCAL’ in product msc …
collect2: ld returned 1 exit status
make: *** [/d01/oracle/VIS/apps/apps_st/appl/msc/12.0.0/bin/MSCCPP] Error 1
Done with link of msc executable ‘MSCCPP’ on Wed Mar 5 11:44:50 IST 2014
It asks us whether we want to continue patch session as Normal or else Stop
NO-Will stop the patch session and YES will allows us continue patching as if normal.
So to exit patch session type NO and once patch session ends. we have to perform below work around.
To fix this problem, we are required to replace the following line under the Linux section of file ” $AD_TOP/bin/adrelinknew.sh”:
CPP_LDFLAGS=' -L$(ORACLE_HOME)/lib -L$(ORACLE_HOME)/lib/stubs -lclntsh'
CPP_LDFLAGS=' -L$(ORACLE_HOME)/lib -L$(ORACLE_HOME)/lib/stubs -lclntsh -Wl,--noinhibit-exec'
I was upgrading R12.2.0 to R12.2.2, as part of the upgrade i was applying 12.2.2 AD and TXK patches.
When i was running adop phase=prepare in patching cycle. I faced below error:
ERROR at line 1:
ORA-20008: No Concurrent Manager is defined that can run concurrent program
ORA-6512: at "APPS.AD_ZD_ADOP", line 240
Set the Run filesystem / environment and run command:
FNDLOAD apps/apps 0 Y UPLOAD $FND_TOP/patch/115/import/afcpprog.lct $AD_TOP/patch/115/import/US/adzdpatch.ldt - CUSTOM_MODE=FORCE
Ref: Metalink Note:
ORA-20008 When Running "adop phase=prepare" (Doc ID 1587419.1)
VERY SOON I WILL POST THE UPGRADE STEPS FOR R12.2.0 to R12.2.2
In Release 12, Oracle E-Business Suite patches are grouped into codelines. A codeline begins with a point release (for example, Release 12.0) consisting of a unique set of product features, and progresses to include all the patches created to maintain that point release. The initial Release 12.0 point release introduced codelineA. Additional point releases introduce new codelines, each identified by a unique letter. For example, Release 12.1 introduced codeline B, and Release 12.2 introduces codeline C.
Codelines and their associated codelevels ease the tracking of patch prerequisites, dependencies, and compatibilities.
Patches associated with codelines not only implement a set of product features for that point release, but also provide fixes to that set of features. This unique set of product features for a point release is referred to as a a codelevel, and assigned a unique number. The following diagram illustrates the relationship between codelines and codelevels in the context of Oracle E-Business Suite Release 12.
Further, codelevels identify patches for individual products. For example, if Oracle General Ledger (GL) is associated with your system, codelevel R12.GL.A.1 is the first set of fixes to codelevel R12.GL.A, R12.GL.A.2 is the second, and so on. Codelevels are cumulative – each one contains the initial set of features plus all the fixes created to date for that product or product family.
There are a three different modes in which adpatch can be run and few options I can provide while we are applying the patches.
Different Modes are:
iii. non interactive mode
If you are applying a large number of patches, use the options nocompilejsp, nocompiledb, noprereq, and novalidate to speed up the application of the patches.
Recompiling Java Server Pages (JSP) pages and database objects can be performed at the end of the patching process. We can even avoid these compiling of jsp’s and database objects using different options
The following Modes and options will give clear idea about the advanced patching.
Test mode will display all the files adpatch will replace and the actions it will take, but does not actually apply the patch. The syntax for using this mode is as below
$ adpatch apply=no
There are times when Oracle may require the install of a patch before running AutoInstall to install or upgrade Oracle Applications. The patch usually updates AutoInstall itself or one of the utilities it calls during the installation. The syntax for this mode is:
$ adpatch preinstall=y
Non Interactive Mode:
For running adpacth in this mode we need to be create an AutoPatch defaults file, which contains information for running adpatch against the different drivers.
Adpatch different Options:
The options can be used to enable or disable certain functions during application of the patch. For example, you may want to prevent compiling jsp’s and Database objects
during the application of a patch. The syntax for this would be:
$ adpatch options=nocomilejsp,nocompiledb
Most of the cases we follow the bellow Options to reducing downtime for the Application patch in oracle applications.
Novalidate : Prevents adpatch from validating all schema connections
Noprereq : Prevents adpatch from checking the existence of prerequisite patches
Nocompiledb : Prevents adpatch from compiling database objects
Nocompilejsp : Prevents adpatch from compiling JSP objects
Noautoconfig : Prevents adpatch from running autoconfig
Nogenerateportion : Prevents adpatch from compiling forms, menus, and plls
Hidepw : Prevents passwords from being displayed in log files
Hotpatch : Allows adpatch to be run when the instance is not in maintenance mode