Posts Tagged ‘Oracle Application’

APP-PAY-06153 System Error Procedure INITFORMS at Step 1

February 18th, 2018, posted in Oracle
Share

Problem : 


APP-PAY-06153: System Error : Procedure INIT_FORMS at Step 1

Cause: The procedure INIT_FORMS has created an error at Step 1.

Action : Contact your system administrator quoting the procedure INIT_FORMS and Step 1.

APP-PAY-06153,System Error,Procedure INIT_FORMS at Step 1,Step 1,Oracle Appps Error,APP-PAY Error,APP PAY 06153,Oracle Administrator,Oracle Apps,Oracle Application,Oracle EBS,Oracle Apps DBA,Oracle DBA,the procedure INIT_FORMS


Solution :

Navigate : System Administrator->Profile->System

APP-PAY-06153,System Error,Procedure INIT_FORMS at Step 1,Step 1,Oracle Appps Error,APP-PAY Error,APP PAY 06153,Oracle Administrator,Oracle Apps,Oracle Application,Oracle EBS,Oracle Apps DBA,Oracle DBA,the procedure INIT_FORMS

Click find

APP-PAY-06153,System Error,Procedure INIT_FORMS at Step 1,Step 1,Oracle Appps Error,APP-PAY Error,APP PAY 06153,Oracle Administrator,Oracle Apps,Oracle Application,Oracle EBS,Oracle Apps DBA,Oracle DBA,the procedure INIT_FORMS

Assign Site: FA: Vision Operations

Save and close

Navigate:->Human Resource->Work Structure->Organization

APP-PAY-06153,System Error,Procedure INIT_FORMS at Step 1,Step 1,Oracle Appps Error,APP-PAY Error,APP PAY 06153,Oracle Administrator,Oracle Apps,Oracle Application,Oracle EBS,Oracle Apps DBA,Oracle DBA,the procedure INIT_FORMS

Form is opened

Share

Clearing Cache In R12

January 3rd, 2018, posted in Oracle
Share

For clearing EBS middle tier cache :

Login to front end application.
Navigate to Functional Administrator responsibility 
Click on (Core Services) Tab
Click on Caching Framework
Select ‘Global Configuration’ on left side menu
Clear All Cache

Finally Bounce the apache and oacore services.

Share

How To Change Java Heap Size In R12 To Avoid Java.Lang.OutOfMemoryError: Java Heap Space Error?

December 24th, 2017, posted in Oracle, Solaris
Share

Recently we had encountered a situation, wherein end users where not able to get the R12 login page and
it just hangs, but all the opmn processess were up and running – adopmnctl.sh status gives status as
alive for all the components viz., HTTP, oafm, oacore & forms. The same environment was available and
end users were able to access without any isuses 15 minutes before. This error happens only when
multiple people login to the same page and perform simillar activity like employee self service form
etc. So where and what exactly could be the problem.

This is how we approached and resolved the issue.

First we checked apache error log. The following error was reported in the error log.

==============================================================
[warn] [client IP Address ] oc4j_socket_recvfull timed out
[error] [client IP Address ] mod_oc4j: There is no oc4j process (for destination: application://oacore) available to service request.
[error] [client  IP Address] mod_oc4j: request to OC4J [servername:OC4J AJP Port Range for Oacore]
failed: Connect failed
==============================================================

Above error message does give us a hint that the problem is with oacore, but as i said earlier the oacore is alive according to opmn.

Next, we verified the oacore log file.

($INST_TOP/logs/ora/10.1.3/opmn/oacore_default_group_1/oacorestd.err)

Error Message in the file

=======================================================
Exception in thread “OC4JMonitorThread” java.lang.OutOfMemoryError: Java heap space
=======================================================

While checking the error in file, parallely we opened another window to see the CPU and memory usage and we could see one java process was taking more than 100% CPU. This process was spawned by the opmn -d process and the process id didnt match with the oacore process id. Hint: adopmnctl.sh status will give the status as well the process id. It looked like a end client java process.

At this stage we had 3 options.

1. Kill the java process which is consuming high cpu.
2. Bounce oacore component
3. Adjust java (jvm) memory parameters

Each of the above options has its own implications and advantages. To minimize the downtime we decided  to kill the java processes, and the moment we killed the java process, all the browsers which were hanging reported instantaneously Internal Server Error. This proved to be a bad decision.

So we moved to the next option, bouncing the oacore service which we are sure will resolve the issue  (temporarily) and it did as expected. Basically when you bounce the services all the existing
connections and processess will be released which results in more available memory when you re-start the services.

Ok, now we tackled the problem and provided a temporary solution but we need to find a long term solution. This is option 3, adjusting java memory size.

Steps to change the heap size.

First, you need to identify how much is the maximum heap size that you can set. Click here.

Once you had identified the maximum heap size, we need to change the configuration files to make it
permanent.

Step 1: Edit opmn.xml file.

Location : $INST_TOP/ora/10.1.3/opmn/conf/

Open opmn.xml

Search for string Xms or Xmx or module-id=”OC4J”

This search should lead you to below location

‘<‘process-type id=”oacore” module-id=”OC4J” status=”enabled” working-dir=”$ORACLE_HOME/j2ee/home”‘>’
‘<‘category id=”start-parameters”‘>’
‘<‘data id=”java-options” value=”-server -verbose:gc -Xmx512M -Xms128M ……]

The default value for Maximum (-Xmx) and Minimum (-Xms) heap sizes are 512M and 128M respectively.

Again here you have options, you can set both Xms and Xmx has the same value as Xmx if you feel all your sessoins require higher memory or set a lower value for Xms and the maximum value for Xmx. Dont forget to change the values under ‘<‘category id=”stop-parameters”‘>’

opmn.xml also contains jvm configurations for other components – oafm & forms.

Step 2: Edit oc4j.properties file.

Location : ($INST_TOP/ora/10.1.3/j2ee/oacore/config)

This step is optional since we had already made changes in opmn.xml but there is no harm in making the change here. This step will come handy for troubleshooting specific components of Oracle viz., configurator, iSupplier or any other option which heavily utilizes/consumes CPU/memory.

Search for string Xms or Xmx or wrapper.

Option 1: If you find any of the above parameters change the values corresponding to the value you had  mentioned in opmn.xml or even more than that, as long as you dont exceed the maximum heap size limit.

Option 2: If you DO NOT find any of the above parameters, then make an entry like this, under the heading “# Java Object Cache Configuration Parameters”

wrapper.bin.parameters=-Xms[Value]M -Xmx[Value]M -XX:NewSize=256M -XX:MaxNewSize=256M

Step 3: Edit Applications Context file

vi $CONTEXT_FILE

Location: $INST_TOP/appl/admin/SID_hostname.xml

search for string s_oacore_jvm_start_options

Change Xms and Xmx value. Repeat the same step for parameter s_oacore_jvm_stop_options.

Changes made in Step 3 will take effect the next time you run autoconfig, whereas Step 1 & 2 changes will take effect the next time you bounce opmn services, but the values are not permanent in the sense these will be wiped off next time you run autoconfig. Yes you can preserve the changes by placing it inbetween Begin and End customizations.

You can also increase the Garbage Collection threads parameter (-XX:ParallelGCThreads) to a higher value if you have JDK 1.5 or more than 2 cpus or more memory. For more information on this you can refer to Metalink Note: 362851 – Guidelines to setup the JVM in Apps Ebusiness Suite 11i and R12.

Share

oc4j_socket_recvfull Timed Out

December 20th, 2017, posted in Oracle, Solaris
Share
[Wed Nov 1 11:37:28 2016][warn] [client 10.10.1.61] oc4j_socket_recvfull timed out
[Wed Nov 1 11:37:28 2016] [error] [client 10.10.1.61] [ecid: 1509525146:10.10.7.85:1275:0:45,0] mod_oc4j:
request to OC4J bi.erp.com:21500 failed: recv failed (errno=4)

 

Troubleshooting MOD_OC4J_0080 MOD_OC4J_0058 MOD_OC4J_0035 MOD_OC4J_0121 MOD_OC4J_0013 Errors In the HTTP Server error_log file [ID 329456.1]

The MOD_OC4J* errors basically convey that the HTTP Server (through mod_oc4j) is unable to communicate with the OC4J instance in question. Some of the possible causes are :

  • 1. Internet Explorer (KeepAlive) Bug
  • 2. Firewalls
  • 3. Connection timeouts between HTTP Server/mod_oc4j & OC4J
  • 4. OC4J instance running short on memory
  • 5. OC4J JVMs loaded
  • 6. Application(s) blocking up OC4J

Connection timeouts between HTTP Server/mod_oc4j & OC4J

In $ORACLE_HOME/Apache/Apache/conf/httpd.conf, increase the Timeout directive value to, say, 600 seconds. (This should be smaller than the Firewall timeout setting, if any)

In $ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf below the tag add the following:

Oc4jCacheSize 0

Oc4jConnTimeout 600 (This is again in seconds &, again, should be smaller than the Firewall timeout setting, if any)

Update the configuration as follows:

$ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct ohs
$ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server

Share

Disable Auditing In A 11G Database

November 18th, 2017, posted in Oracle Queries
Share

In a RAC Database :

 

SQL> ALTER SYSTEM SET audit_trail=NONE SCOPE=spfile sid='*';
System altered.
SQL>

Note : Restart the database to have the change take affect, or do a rolling restart, one instance at a time.




In a Single Instance Database :

 

SQL> ALTER SYSTEM SET audit_trail=NONE SCOPE=spfile ;
System altered.
SQL>

Note : Restart the database to have the change take affect.

Share