How do I recover the Applications context file if it is lost or deleted accidentally?

The Applications context file can be retrieved by running the adclonectx.pl script.

To retrieve the applications tier context file,

• Execute the following command on the applications tier. 

perl <COMMON_TOP>/clone/bin/adclonectx.pl retrieve

• On being prompted for the context file to be retrieved, select the option of retrieving the applications tier context file that has been lost and retrieve it to the default location specified by the script.

The above command can be used only when the <INST_TOP> is still intact. In case the <INST_TOP> has also been lost accidentally, the applications tier context file may be retrieved as follows:

• Execute the following command on the database tier:

perl <ORACLE_HOME>/appsutil/clone/bin/adclonectx.pl retrieve

• On being prompted for the context file to be retrieved, select the option of retrieving the applications tier context file that has been lost.
• While confirming the location for the context file, set it to any existing directory with write permission.
• Once the context file has been generated in the specified location, move it to the location specified for the context file in the context variable 's_contextfile'.

To retrieve the database tier context file,

• Execute the following command on the database tier:

perl <ORACLE_HOME>/appsutil/clone/bin/adclonectx.pl retrieve

• On being prompted for the context file to be retrieved, select the database tier context file and retrieve it to the default location specified by the script.

++++++++++++++++++++++++++++++++

svrhrsuas2:[SVRSUPT]:/u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin:>

# perl adclonectx.pl retrieve

                     Copyright (c) 2002 Oracle Corporation

                        Redwood Shores, California, USA

                        Oracle Applications Rapid Clone

                                 Version 12.0.0

                      adclonectx Version 120.23.12010000.1

Running:

/u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin/../jre/bin/java -Xmx600M -classpath /u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin/../jlib/ojdbc14.jar:/u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin/../jlib/xmlparserv2.jar:/u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin/../jlib/java oracle.apps.ad.context.RetrieveContext

Log file located at /u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin/RetrieveContext_03301309.log

Database Host [svrhrsuas2]:cgvmhrsudb2

Database Host Domain [singiri.com]:

Database Port [1521]:1525

Database SID:SVRSUPT

APPS Schema Name [APPS]: apps

APPS Schema Password: apps

The following context files are available:

[1] SVRSUPT_svrhrsuas2 (APPL_TOP Context)

[2] SVRSUPT_ svrhrsuas 1 (APPL_TOP Context)

[3] SVRSUPT_ svrhrsudb (Database Context)

Select the context to retrieve [1]:1

Destination file path [/home/SVRSUPT/apps/SVRSUPT_svrhrsuas2/appl/admin/SVRSUPT_svrhrsuas2.xml]:

Retrieved context file to /home/SVRSUPT/apps/SVRSUPT_svrhrsuas2/appl/admin/SVRSUPT_svrhrsuas2.xml

Log file location: /u401/app/oracle/SVRSUPT/apps/apps_st/comn/clone/bin/RetrieveContext_03301309.log

++++++++

Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12 (Doc ID 387859.1)

++++++++

SQL*Loader-643: error executing INSERT statement for table ...

ERROR :-

“SQL*Loader-643: error executing INSERT statement for table “SVR_STG"."STG_XML_FILES"

ORA-03113: end-of-file on communication channel

SQL*Loader-2026: the load was aborted because SQL Loader cannot continue.”

Reason : XML - EVENT :

Solution :-

 $ connect / as sysdba
 SQL>  alter system set events '31156 trace name context forever, level 0x400';

           System altered.

SQL> exit
    

Following syntax works -

SQL> alter system set events '31156 trace name context forever, level 0x400';

System altered.

Correct method to set the event in the SPFILE is to use the below SQL syntax:

SQL> alter system set event='31156 trace name context forever, level 0x400' scope=spfile;

or

SQL> alter system set event='31150 trace name context forever, level 0x400' scope=spfile;

The instance must be restarted for the events to take effect.

Other way to set the event at database level is to set it in parameter file using the syntax below -

event="31150 trace name context forever, level 0x400"

or

event="31156 trace name context forever, level 0x400"

If you are using SPFILE then you may have to generate the pfile from SPFILE using the steps from below note-

How to Modify the Content of an SPFILE Parameter File (Doc ID 137483.1)

Modify the PFILE parameter value with a text editor and save the file, e.g. -

*.event='31150 trace name context forever, level 0x4000'

Recreate the SPFILE from the modified PFILE.

++++++++++++++++++++++++++++

Debugging requires the DEBUG CONNECT SESSION system privilege

Error : Issue with Debugging using PL/SQL Developer

ORA - 0131: Insufficient privilegesNote: Debugging requires the DEBUG CONNECT SESSION system privilege

Solution : 

grant DEBUG CONNECT SESSION to  <user_name> ;

grant DEBUG ANY PROCEDURE to <user_name>  ;

Ex User is apps :

SQL> grant DEBUG CONNECT SESSION to apps;

Grant succeeded.

SQL> grant DEBUG ANY PROCEDURE to apps;

Grant succeeded.

SQL> exit:

RC-50004: Fatal: Error occurred in ApplyDatabase: Control file creation failed / RC-00118 'Error occurred during creation of database

Error : in ApplyDBTier_01291502.log file

Exception occurred: java.sql.SQLException: ORA-01017: invalid username/password; logon denied

    Trying to connect using SID as ServiceName.DomainName

getConnectionUsingServiceName() -->

    JDBC URL: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sudb2.corp.singiri.com)(PORT=1525))(CONNECT_DATA=(SERVICE_NAME=SUP1.corp.singiri.com)))

    Exception occurred: java.sql.SQLException: Listener refused the connection with the following error:

ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

    Connection could not be obtained; returning null

-------------------ADX Database Utility Finished---------------

RC-00118: Error occurred during creation of database

Raised by oracle.apps.ad.clone.ApplyDatabase

StackTrace:

java.lang.Exception: Control file creation failed

     at oracle.apps.ad.clone.ApplyDatabase.doConf(ApplyDatabase.java:635)

     at oracle.apps.ad.clone.ApplyDatabase.doApply(ApplyDatabase.java:473)

     at oracle.apps.ad.clone.ApplyDatabase.<init>(ApplyDatabase.java:366)

     at oracle.apps.ad.clone.ApplyDBTier.<init>(ApplyDBTier.java:110)

     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

     at java.lang.reflect.Constructor.newInstance(Constructor.java:501)

     at oracle.apps.ad.clone.util.CloneProcessor.run(CloneProcessor.java:67)

     at java.lang.Thread.run(Thread.java:637)

Solution A:

Step 1: To verify the apps password is valid ,which you provided by Target server while running adcfgclone.pl on dbTier

(Or)

Workaround:

1. Modify the Contextfile 'CTXORIG.xml', whcih is created by the pre-cloning script, which is found under the Database $ORACLE_HOME/appsutil/clone/context/db directory :

ORIGINAL :

<DB_LISTENER oa_var="s_db_listener" default=""><Name of the SOURCE DB listener></DB_LISTENER>

ACTION :

UPDATE the file with the SID name of the TARGET Instance, e.g. TEST :

<DB_LISTENER oa_var="s_db_listener" default=""><Name of the TARGET DB listener></DB_LISTENER>

Please Note :

The modification can be implemented after the pre-cloning STEPS - before STARTING the 'adcfgclone dbTier' . This works best when done on the target system, after you have copied the files from source.

If the Clone has already failed, the workaround/solution would be :

1. correct the s_db_listener value in the Target context file named '<SID>_<Hostname>.xml' located under the DB $ORACLE_HOME/appsutil

2. shutdown the target Database

3. execute 'perl adcfgclone.pl dbTier <physical Path to the DB Tier Contextfile>

 Error B:

System parameter file is $RDBMS_ORACLE_HOME/network/admin/clone_dbclone/listener.ora

Log messages written to $RDBMS_ORACLE_HOME/network/admin/clone.log

Error listening on: (ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROCclone))

TNS-12555: TNS:permission denied

TNS-12560: TNS:protocol adapter error

TNS-00525: Insufficient privilege for operation

Linux IA64 Error: 1: Operation not permitted

  

Solution B :

Please Apply the following solution:

1- change permission /var/tmp/ . oracle

[root@dbclone tmp]# chmod -R 777 .oracle/

++++++1153204.1,1329400.1,1350709.1 & 603104.1 ++++++

Forms Process (FRMWEB) Consumes 100% of CPU in Oracle Applications R12

SYMPTOMS

On Oracle Applications R12 when checking the top processes on the OS level for the middle tier, you find that forms process (frmweb)

almost consumes 100% of the CPU.

CAUSE

The root cause of the issue is that returning rows from LOVs in core forms causes the forms process to grow up into memory depending

on the number of rows returned.

When an end user login to forms and start working with LOV within core forms sometimes and according to the search criteria that the

user will provide to filter the results in LOV, it may fetch huge numbers of records in which causes the frmweb process to grow very

large, and in extreme cases this can even lock up the current process or even the whole machine.

So when executing a LOV query, every row is fetched into memory on the middle tier, the frmweb process can get extremely large, and

the larger it gets the more likely it is to start paging.

Eventually it starts consuming excessive CPU just paging the process in and out of memory, which is probably what you can see here in

this case as the amount of memory consumed when the LOV records are fetched into memory obviously depends on the amount of data

in each record.

This has been mentioned in the following bug:

Bug 6519700 - ESC: CSE: R12SIP: 6513826 FRMWEB RUNAWAY PROCESS CONSUMING 100% CPU-MIDDLE TIER

Solution :

To implement the solution, please execute the following steps:

Please be aware :

This solution has been identifed for a Forms Configuration using the SOCKET mode, whic is not the default mode in EBS R12.

You can use the solution also for the SERVLET mode - in this case you have to add the FORMS_RECORD_GROUP_MAX to the

default.env file.

Step 1.  Stop all services on the middle tier.

Step 2.  Set following forms environment variables:

FORMS_RECORD_GROUP_MAX to 10000 or if that proves too restrictive, increase it to 20000 or 30000. The higher the value is set may

impact existing resourses where that should be considered when changing it.

FORMS_CATCHTERM=0

In order to set the above forms variables so next time autoconfig run does not override those values, do the

following steps :

Step 1:-  For Forms Variable "FORMS_CATCHTERM" the context vairable name is: "s_forms_catchterm" and you can update the context file

located in ($INST_TOP/appl/admin/<SID_HOSTNAME.xml>)

Step 2:-  For other forms variable "FORMS_RECORD_GROUP_MAX" there is no variable defined in Autoconfig for that one and have to

customize the autoconfig for the forms variables to set that environment as following:

a).  Go to the autoconfig Template folder:

            $cd $AD_TOP/admin/template

b).  Create new directory named (custom)

$ mkdir custom

c). Make sure that new directory has same file permissions as ($AD_TOP/admin/template)

d). Copy the following autoconfig template to the new custom directory:

$cp $AD_TOP/admin/template/APPLSYS_ux.env $AD_TOP/admin/template/custom/APPLSYS_ux.env

e). Edit the file copied file under custom directory and add the following 2 lines at the end of section:

####################################

# Oracle Forms environment variables

####################################

FORMS_RECORD_GROUP_MAX=10000

export FORMS_RECORD_GROUP_MAX

f).  Save and exit from the file.

g). Next time autoconfig run, it will read the custom directory and check for any customizations there.

Step 3:- Run Autoconfig on the middle tier and make sure it is completed successfully.

Step 4:-  Startup all services.

Step 5:- Monitor the forms process to see its CPU usage, and you will see that form process usage is reduced and not causing any more CPU

consumption up to 100% as before.

Step 6:- Migrate the solution as appropriate to other environments.

IMPORTANT NOTE: If you find that setting (FORMS_RECORD_GROUP_MAX=30000) still too restrictive for certain LOV's then Oracle

product team needs to consider redesigning the LOV's in their form and at that time raise a new SR with the Oracle Support team so

they can raise a new bug with development for that specific LOV to get it redesigned but this may happen ONLY in RARE cases.

+++++++++(Doc ID 745711.1)+++++++++++

The Java.lang.OutOfMemoryError: Java Heap Space Error which means that the JVM ran out of memory

The Java.lang.OutOfMemoryError: Java Heap Space Error which means that the JVM ran out of memory and so we need to increase the value of the -Xmx to a higher value.

The recommended number of JVM's and memory will depend on how many CPU's you have on your system.

Please follow the following :

Take a backup of the file $INST_TOP/apps/SID_HOSTNAME/ora/10.1.3/opmn/conf/opmn.xml

A) Increase nprocs(JVM's) =”half of the number of CPU's you have”

It depends on the number of cpu's you have.

If you have 6 cpus in server you can increase this JVM upto “3”.

B) Now we have to increase the memory for JVM.

Here nproc is number oc4j instance.

So to find out how much memory we need to increase multiply Xms with nproc :

Xms x nproc = max memory

Note :Make sure that your application tier memory has that much free memory available.

For example if you have 6 nproc and 256 for Xms,

That means we need 256x6 which is 1536 So we need to increase Xmx to Xmx1536

Meaning :

In $INST_TOP/apps/SID_HOSTNAME/ora/10.1.3/opmn/conf/opmn.xml

server -verbose:gc –Xmx1536M -Xms256M -XX:MaxPermSize=256M -XX:NewRatio=2-XX:+PrintGC TimeStamps

Do not run autoconfig just yet just bounce all application tiers.

After you test and you are happy with the outcome you can make these changes in the context file then ran autoconfig to make the changes permanent.

JVM: Guidelines to setup the Java Virtual Machine in Apps Ebusiness Suite 11i and R12 (Doc ID 362851.1)

Number of JVMs:

1) For OACoreGroup:

Assumption: eBusiness Suite  is running in a 2-tier environment (middle tier in a separate machine)

- Start witn no more than 100 active users per JVM/OC4J instance.

- Start with 1 active JVM/OC4J instance per CPU core, though newer/faster chip families may support more than 1 JVM/OC4J instance per CPU core, depending upon threading, memory, I/O capabilities, etc.  Confirm with appropriate hardware vendor for best results. 

- Watch out for available memory (make sure that you have enough memory to run all the configured JVMs/OC4J instances without swapping)

Note: Each 'core' in a multi-core system is considered to be a separate CPU. For example, a dual quad-core chip would be the same as stating 2 x 4 x CPU  or 8 CPUs.

In regards to hyper-threading cores, “virtual CPUs,” etc., in theory the same thing applies, but in some cases it may not equate to the exact same as a separate core.  One could tune greater then a single CPU, but not treating the same as two CPUs, four CPUs, etc., depending upon the chip architecture.  Confirm with appropriate hardware vendor for best results. 

2) For  FormsGroup:

For the forms servlet, the actual JVM/servlet usage is minimal, and a single JVM can normally handle up to 100-250 forms users.

Note: that depends on the type of forms. For more complex forms, those numbers are likely to be substantially lower

Notes: 
a) The number of jvms (oc4j in R12) is configured by the autoconfig variables s_oacore_nprocs, s_disco_nprocs, s_forms_servlet_nprocs (11i), s_forms_nprocs (R12) and s_xmlsvcs_nprocs. 
     (these variable should be updated in the $CONTEXT_FILE using the autoconfig editor from OAM)
b) In 11i, those changes are made in the $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.conf file, while in R12 in the $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml

Heap Configuration:

1) For OACore, start with the following configuration:

For R12.0 and 11i:

       -Xmx512M -Xms256M -XX:MaxPermSize=128M 
       -XX:NewRatio=2 -XX:+PrintGCTimeStamps

For R12.1 and higher:

      -Xmx1024M -Xms512M -XX:MaxPermSize=256M
      -XX:NewRatio=2 -XX:+PrintGCTimeStamps

     Also, ensure you add the following parameter to the DBC file:

     JDBC\:oracle.jdbc.maxCachedBufferSize=262144

Ex:

From :-

oacore_jvm_start_options -Xmx1024M -Xms1024M

oacore_jvm_stop_options -Xmx1024M -Xms1024M

<oacore_nprocs oa_var="s_oacore_nprocs">1</oacore_nprocs>

[oracle@ svrprdsa1 admin]$ ps -ef|grep  s_oacore_nprocs $CONTEXT_FILE

                        <oacore_nprocs oa_var="s_oacore_nprocs">1</oacore_nprocs>

TO :-

oacore_jvm_start_options -Xmx1024M -Xms512M

oacore_jvm_stop_options -Xmx1024M -Xms512M

<oacore_nprocs oa_var="s_oacore_nprocs">2</oacore_nprocs>

[oracle@svrprdsa1 admin]$ ps -ef|grep  s_oacore_nprocs $CONTEXT_FILE

                        <oacore_nprocs oa_var="s_oacore_nprocs">2</oacore_nprocs>

Adjust the heap sizes accordingly to minimize garbage collection frequency and user pause times due to full garbage collections.

In JDK 1.6, the JVM detects that you have a server class machine (2 or more CPUs with 2GB or more memory), and will automatically enable Parallel Throughput Garbage Collector. The number of GC threads defaults to the number of CPUs on the machine. If you are running multiple JVMs on the same machine, or if your machine has more than 2 CPUs, to avoid the GC threads to be overly active you should reduce the number of GC threads by using:

      -XX:+UseParallelGC -XX:ParallelGCThreads=2

In most cases, using 2 GC threads should be sufficient. If you are using heap size of over 1GB, you can experiment with 4 GC threads and see if it gives you better performance. 

2) If using Forms in Servlet mode, the following configuration for FormsGroup should be enough for most of the cases:

      -Xmx256M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2

Notes: 
a) The heap is configured by the following autoconfig variables:
    11i: s_jvm_options, s_forms_jvm_options
    R12: s_oacore_jvm_start_option, s_forms_jvm_start_options, 
    (these variable should be updated in the $CONTEXT_FILE using the autoconfig editor from OAM)
b) In 11i, those changes are made in the $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.properties file, while in R12 in the $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml

Additional Recommendations:

1) R12 comes with Forms configured in servlet mode by default, because it is easier to setup if you need features like SSL. However, Forms in servlet mode may have some performance degradation, depending on the network capacity. For this reason, if performance is a concern, you may consider run Forms in socket mode, as it is more efficient than servlet mode.

2) Although the setup of those parameters can be temporarily done manually changing (jserv.conf and jserv.properties in 11i; opmn.xml in R12), the correct way to update those parameters is using the context editor, update the variables s_oacore_nprocs and s_forms_servlet_nprocs, and then run autoconfig.

3) Oracle Development recommends to be on the last ATG rollup patch, which is currently ATG-rollup7 (Note.783600.1).

4) Make sure to have the following setting in the jserv.properties (11i) or oc4j.properties file (R12) file:
wrapper.bin.parameters=-DLONG_RUNNING_JVM=true

If there is any entry in jserv.properties setting -DCACHEMODE, either comment it out or remove that entry:
#wrapper.bin.parameters=-DCACHEMODE=LOCAL

5) Check also recommended patches for Performance issues in:
Note 244040.1  - Oracle E-Business Suite Recommended Performance Patches

6) AIX accepts only the parameters "-Xmx" -Xms". The reminder of the parameters should not be used on those platforms. More 
More info about JDK parameters on AIX can be found at 
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.60_26%2Fvm626%2FJ9%2FGC%2Fxmxoption.html

++++++++++++++++

Increasing Number of JVMs Allocated to oacore Process Causes Login Problems (Doc ID 731115.1)

monitor_jdbc_conn.sql - Script to monitor JDBC connections in Apps eBusiness Suite (Doc ID 557194.1)

1454792.1 & 1061482.1

APP-PAY-06882 and APP-FND-01388 Errors When Executing Quickpay

CHANGES

Cloned Production Instance. This is working in Production, but not in the new Test instance

  

CAUSE

The pay_action_parameter TAX_LIBRARIES is not correct. It should point to the same directory as

the LD_LIBRARY_PATH.

1.- SQL> select * from pay_action_parameters where parameter_name like 'TAX%';

PARAMETER_NAME PARAMETER_VALUE

--------------- --------------------------------------------------

TAX_LIBRARIES /Prod/applmgr/1159/pay/11.5.0/vendor/quantum/lib

 2.- echo $LD_LIBRARY_PATH

/usr/lib:/Test/applmgr/1159/pay/11.5.0/vendor/quantum/lib:/Test/product/806/network/jre11/lib/i

86/native_threads:/Test/product/806/network/jre11/lib/linux/native_threads:/Test/product/806/li

:/usr/X11R6/lib:/usr/openwin/lib:/Test/product/iAS/Apache/jdk/lib

SOLUTION

Please update path for TAX_LIBRARIES to include the fully qualified path in Test instead of Production. This

path should be the same as the $LD_LIBRARY_PATH.

Conn apps/<appspwd>

SQL> update pay_action_parameters

set PARAMETER_VALUE = '/Test/applmgr/1159/pay/11.5.0/vendor/quantum/lib'

where PARAMETER_NAME = TAX_LIBRARIES;

SQL> commit;

++++++++1186805.1++++++++