Error applying patch 10338643:R12.ONT.B. This patch is compatible with: entity 'icx' 'R12.ICX.C'

Issue:

Error when trying to apply Patch 10338643:R12.ONT.B

This patch is not compatible with your current codelines.

This patch is compatible with: entity 'icx' - codeline 'R12.ICX.B'.
Your current on-site codeline for the entity 'icx' is: 'R12.ICX.C'.
You should not apply this patch.
Apply an equivalent patch that is compatible with your current codelines instead.

Solution:

To implement the solution, please execute the following steps:

 1. Unzip the Patch zip file p10338643_R12.ONT.B_R12_GENERIC.zip
 2. In the new directory 10338643, please find the driver file u10338643.drv
 3. Edit this driver file to comment out or remove the following three lines:
    extension fixes 7591737 icx B
    extension includes 7591737 icx B
    extension based on icx B
 4. Run adpatch to apply the patch on your environment. Use this drv file when
     the adpatch utility asks you for the driver file to use.

 Notes:
 1. You need to have proper permissions on the unzipped patch folder to run adpatch from
 2. You must be in Maintenance Mode to apply patches. You can use the AD 
     Administration Utility (adutility) to set Maintenance Mode.
 3. You must ssh or ftp to the env with appmgr access and source the env.
     variables (thereby setting APPL_TOP etc.) before carrying out adpatch command
 4. You must have the Oracle db system and apps schema passwords for the env,
    and appmgr password for the env.

Ref: (Doc ID 1465165.1)

Gather Schema Statistics Is Failing With ORA-20000 Error For Tables Ending With _TAB

Issue:

 FDPSTP failed due to ORA-20000: Unable to analyze TABLE "APPS"."COSTPARAMETERS1358_TAB", insufficient privileges or does not exist
ORA-06512: at "APPS.FND_STATS", line 2457
ORA-06512: at line 1

Cause:

Several tables were created with quotes around their names (all ended with _TAB) during upgrade
however Gather Schema Statistics program (FNDGSCST) does not recognize them and fails.

The csrrsreg.sql script belongs to "Oracle Scheduler" product (CSR)
It registers the XML Schema for Scheduler Rules and creates the
relevant CSR_RULES_B database object to store Scheduler Rules.
It seems that _TAB tables were generated by this script.

Fix: 

*) A simple solution consists in renaming the tables (i.e. removing the quotes), for instance:

alter table "costParameters1358_TAB" rename to costParameters1358_TAB;

However it is recommended to open a new SR with "Oracle Scheduler" product (CSR) team
to validate this solution and to confirm that script csrrsreg.sql is well the cause of this issue.

*) As a workaround the offending tables can be excluded from running statistics.


1. Retrieve the Application ID by running the SELECT statement below:

select application_id from fnd_tables where table_name = <'exact table name'> ;

2. Run the following script once for each table to insert a record
corresponding to it in FND_EXCLUDE_TABLE_STATS, for example:

Begin
fnd_stats.load_xclud_tab('INSERT',<application_id from step 1>,'costParameters1358_TAB');
End;

Check FND_EXCLUDE_TABLE_STATS table has entry of costParameters1358_TAB or "costParameters1358_TAB".


3. Re-run the Gather Schema Statistics or Gather Table Statistics program.

Ref: (Doc ID 1520146.1)

How to run garbage collection in Weblogic

You can manually request that the JVM perform garbage collection. Make sure that full garbage collection is necessary before selecting it on a server instance. When you perform garbage collection, the JVM often examines every living object in the heap.

To request garbage collection:

1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).

2.In the left pane of the Console, expand Environment > Servers.

3.On the Summary of Servers page, select the server instance for which you will request garbage collection.

4. Select Monitoring > Performance.

5.Click Garbage Collect.

6.Garbage Collect calls the JVM’s System.gc() method to perform garbage collection. The JVM implementation then decides whether or not the request actually triggers garbage collection.

7.To activate these changes, in the Change Center of the Administration Console, click Activate Changes. (Not all changes take effect immediately—some require a restart).

Oracle E-Business Suite Applications 12.2.5 New Features

New Features in Oracle apps R12.2.5

This section contains details pertaining to the features that are new or changed since the previous release. Those details are listed where applicable.

Feature Name

1 Enhanced adop user interface

2 New adop monitoring and validation features

3 Support for new EBS Installation Central Inventory

4 Oracle WebLogic Server performance enhancements

5 New 'dualfs' option in standard cloning

1 Enhanced adop user interface

Category	Description	Parameters
Changed UI	The UI of the adop utility has been significantly enhanced, to display more selective information on the console. Messages, prompts and other elements have also been extensively refined to increase the ease of use of the various patching commands.	Dependent on operation

2 New adop monitoring and validation features

Category	Description	Parameters
New features	Progress of an online patching cycle can be followed by running the new Online Patching Monitoring utility (adopmon). This utility can be used to follow the overall progress of a patching cycle, as well as identifying the various individual adop actions being taken.	$ adopmon
	Before you start a new patching cycle by running the prepare phase, you can optionally check your system's readiness by running adop with the 'validate' option. If you do this while a patching cycle is in progress, validation will take place for the cutover phase.	$ adop -validate

3 Support for new EBS Installation Central Inventory

Category	Description	Parameters
New feature	Support for an instance-specific EBS Installation Central Inventory has been introduced as an option for the application tier on UNIX platforms. The inventory is identified by <s_base>/oraInventory/oraInst.loc. This feature is useful where multiple Oracle E-Business Suite installations exist on the same host, helping to avoid issues when fs_clone is run simultaneously on different instances. To use the EBS Installation Central Inventory, all application tier Oracle Homes registered in the global inventory for the instance must be migrated to the new inventory.	Not applicable

4 Oracle WebLogic Server performance improvements

Category	Description	Parameters
New options	A new -DserverType=wlx start argument for managed servers reduces their memory footprint, by preventing startup of the Enterprise JavaBeans (EJB), Java EE Connector Architecture (JCA), and Java Message Service (JMS) services.	-DserverType=wlx
	To reduce oacore startup time, the Portlet Producer libraries are no longer deployed to the EBS domain. A new context variable, s_deploy_portlet, has been introduced to cater for cases where portlet-related configuration is required, such as in instances needing Webcenter integration.	s_deploy_portlet
New mode	The default value of s_forms-c4wsstatus is now set to 'Disabled'.Thus, the formsc4-ws servers are no longer started during a 'start all' operation.	s_forms-c4wsstatus

5 New 'dualfs' option in standard cloning

Category	Description	Parameters
New option	A new 'dualfs' option is available when performing a standard clone, as well as while adding a new node. With the 'dualfs' option, both the run and patch file systems are cloned and configured in a single operation.	dualfs

Ref: (Doc ID 2050998.1)

ORA-00060: deadlock detected while waiting for RESOURCE DB PREP during Online Patching Enablement script (Database Preparation script) execution.

Error details:

ORA-00060: deadlock detected while waiting for RESOURCE DB PREP
begin APPS.ad_zd_mviews.upgrade('APPS','<Materialized View>'); end;

Related Bug:12901059  in R12.2

Workaround:
Re-run the script manually, outside the Online Patching.

SQL>begin APPS.ad_zd_mviews.upgrade('APPS','<Failed Materialized View>'); end;

(Ref: Doc ID 2050998.1)

adop exits with the error "Unable to acquire lock on ad_adop_sessions table." Related to bug: 17650145

Issue:

adop exits with the error "Unable to acquire lock on ad_adop_sessions table." Related to bug: 17650145.

Error details: This error does not appear consistently. It may be caused by another adop process running on the same node in another session, or on other nodes.

Identify Issue:

$ ps -ef | grep adzdoptl.pl

This will check for the existence of other adop sessions. If any are found, wait for them either to complete or error out. If no other sessions exist, log a service request to obtain further assistance.

How To diagnose the "Root Cause" of OPP (java process) consuming High CPU

To find the "Root Cause" for OPP (java) processes consuming High CPU.  Most of the time it is due to un-optimized "Template Code" that causes slowness. This document helps to identify the "Template code" that could be the potential cause. It could be either Standard Template Code (provided by Oracle) or Custom (designed by in-house team).

Issue:

Below Steps to Identify/Resolve the OPP (java) process issue.

1. Identify <PID> of OPP that is spinning. Use top (or) prstat
2. Generate the java thread dump.
  2.1 $kill -3
3. Get “thread ID” which consumes High CPU. Use this command.
  3.1 $ ps -eLo pid,ppid,tid,pcpu,comm | grep <PID>
4. Convert the “thread ID” to Hexadecimal which helps to identify the “Template code” (potential cause).
5. Resolution - Optimizing the Template code.

(Ref: Doc ID 2028617.1)

What is ADOP in Oracle Apps R12.2

ADOP is Online Patching utility tool. It will Perform all the below tasks required to apply the patch in R12.2.

*)  Reads the patch metadata to determine patch dependencies and requirements.
*)  Attempt to recover previously failed patching session (if any).
*)  Reads and validate the patch/product driver files.
*)  Compare the version numbers of existing files against the patch files and Backs up all existing        files         that will be changed by the patch.
*)  Copy the files from patch.
*)  Archive files in libraries.
*)  Relinks executable s, Generates forms, reports, messages, graphics, and Java archive (JAR) files.
*)  Compiles JSP files and invalid database objects. Update into database objects.
*)  Runs AutoConfig if required.
*)  Save all the patches information into the database.

All tasks are similar to what adpatch utility used to do earlier in R12.1.

Next : Patching Procedure in oracle apps R12.2

Oracle Apps R12.2 File System Architecture

Below is the File System Architecture details in Oracle apps R12.2.

ISG Architecture in Oracle Apps R12.1 and R12.2

Below is the Architectural changes between Oracle Apps R12.1 and R12.2 for ISG (Integrated SOA Gateway) setup.

Patching procedure in oracle apps R12.2

From R12.2 onwards oracle has introduced online patching functionality.

Phases of ADOP(online patching):

In R12.2.0 we have ADOP – AD Online Patching instead of adpatch. There are five phases or life cycles of ADOP which are:

1) PREPARE

2) APPLY

3) FINALIZE

4) CUTOVER

5) CLEANUP

1. Prepare phase - Used to start a new online patching cycle.

$ adop phase=prepare

2. Apply phase - Used to apply one or more patches to the patch edition of an Oracle E-Business Suite system:

$ adop phase=apply patches=637432,654376 workers=8

3. Finalize phase - Used to perform the final patching operations that can be executed while the application is still online:

$ adop phase=finalize

4. Cutover phase - Used to perform the transition to the patched environment:

$ adop phase=cutover

5. Cleanup phase - Used to remove old objects that are no longer needed:

$ adop phase=cleanup

Abort command:

If necessary, an online patching cycle can be terminated, with the actions taken being discarded.

The command to perform this operation is:

$ adop phase=abort

The Online Patching Cycle:

(Note: This abort command is only available up to (but not including) the cutover phase. After cutover, the system is running on the new edition, and abort is no longer possible for that patching cycle.)

Current Patchset level of oracle apps R12

Below script or steps to know the current Patchset level of oracle apps R12.

Back-end:

Step 1:

Source the .env file of oracle application

Step 2:

Run the below query.

$AD_TOP/sql/adutconf.sql

Front-end:

Login to Oracle Application

Goto System Administrator (Responsibility)

---- > Goto OAM (Oracle Application Manager)

----> OAM Support Cart

----> Support Cart

----> Application Signature

----> Collect

----> Check the Product Information box

----> Click on View  (eyeglasses)

Unexpected Error On R12.2 Home Page

Error Message:

(WebAppServletContext.java:2181)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1491)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused by: org.xml.sax.SAXParseException; systemId: /oracle/apps/fnd/attributesets/Buttons; lineNumber: 1; columnNumber: 40; /oracle/apps/fnd/attributesets/Buttons<Line 1, Column 40>: XML-20108: (Fatal Error) Start of root element expected.
at oracle.xml.parser.v2.XMLError.flushErrorHandler(XMLError.java:422)
at oracle.xml.parser.v2.XMLError.flushErrors1(XMLError.java:287)
at oracle.xml.parser.v2.NonValidatingParser.parseRootElement(NonValidatingParser.java:414)
at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:355)
at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:226)
at oracle.cabo.share.xml.ParserAdapter.parse(Unknown Source)
at oracle.cabo.share.xml.TreeBuilder.parse(Unknown Source)
at oracle.cabo.share.xml.TreeBuilder.parse(Unknown Source)
at oracle.adf.mds.internal.parse.ParserUtils.createNode(ParserUtils.java:283)
at oracle.adf.mds.internal.parse.ParserUtils.createNode(ParserUtils.java:115)
at oracle.adf.mds.adapters.DBAdapter.getElementData(DBAdapter.java:324)
Cause:
org.xml.sax.SAXParseException; systemId: /oracle/apps/fnd/attributesets/Buttons; lineNumber: 1; columnNumber: 40; /oracle/apps/fnd/attributesets/Buttons<Line 1, Column 40>: XML-20108: (Fatal Error) Start of root element expected.
at oracle.xml.parser.v2.XMLError.flushErrorHandler(XMLError.java:422)
at oracle.xml.parser.v2.XMLError.flushErrors1(XMLError.java:287)
at oracle.xml.parser.v2.NonValidatingParser.parseRootElement(NonValidatingParser.java:414)
at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:355)
at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:226)
at oracle.cabo.share.xml.ParserAdapter.parse(Unknown Source)
at oracle.cabo.share.xml.TreeBuilder.parse(Unknown Source)
at oracle.cabo.share.xml.TreeBuilder.parse(Unknown Source)

Cause:

The SQL profiles are setting optimizer_features_enable to 10.1.0.5 and this setting is not going to work with EBR , which is an 11g feature.

This is explained in:

Bug 19830345 - QUERY RETURNS NO ROWS AGAINST SOME TABLES PROTECTED BY VPD

Fix:

1. run this query to discover all the profiles that set the OFE parameter to 10.1.0.5 :

SELECT o.name, d.comp_data
FROM SQLOBJ$ o, SQLOBJ$DATA d
WHERE o.signature = d.signature
AND o.category = d.category
and COMP_DATA like '%10.1%'
ORDER BY o.name;

2. For each o.name run this :

exec DBMS_SQLTUNE.DROP_SQL_PROFILE ( '')

3) Re-test the issue.

Ref. (Doc ID 1937429.1)

R12: "FRM-92101:There was a failure in the Forms Server during startup" Error When Attempting to Launch Forms

We are facing an error when Attempting to launch forms in oracle application R12.

Issue:

FRM-92101 : There was a failure in the Forms Server during startup.

This could happen due to invalid configuration. Please look into the web-server log file for details.
Details...

Java Exception:
oracle.forms.net.ConnectionException: Forms session <3> failed during startup: no response from runtime process
at oracle.forms.net.ConnectionException.CreateConnectionException(Unknown Source)

Cause:

The forms executable was not relinked successfully.   The "failed during startup: no response from runtime process" error message occurs when first trying to initialize the forms process versus actually performing a forms function.

The most common cause for the failed relink is that the file "ldflags" in $ORACLE_HOME/lib32 is missing or pointing to an incorrect location.

Fix:

Step 1:

$ cd $ORACLE_HOME/lib32
$ rm ldflags
$ ln -s $ORACLE_HOME/lib/ldflags ldflags

Step 2:

Stop the web tier services (adopmnctl.sh stop) and relink the form executable.

$ cd $ORACLE_HOME/forms/lib32/
$ make -f ins_forms.mk install

Step 3:

Start the web tier services (adiopmnctl.sh start) and launch the forms.

Ref. (Doc ID 454427.1)