oacore / forms stdout eating up your CPU and I/O? It’s a bug!!

We’re going live ina few weeks and and my performance tests showed me a distrubing trend. The oacore processes would consume about 40% CPU between them and were churning out 8 GB’s of stdout files for each managed servers in a few hours.

Opening an SR gave me a method to create a filter that would filterout these message but I had to use the EBS scritps to start and stop these managed servers then. And I liked the WL control console 🙂

After a bit of further digging, I chanced upon Oracle Doc ID 1981206.1, which points to bug 18345006.


After applying the patch jbo messages are no longer being thrown into teh std out, and the CPU and I/O are very normal now

ADOP Says Maintenance Mode Needed during Online Patching!!

While applying an online patch today, ADOP failed during the apply phase with the error

AutoPatch error: You must be in Maintenance Mode to apply patches.
You can use the AD Administration Utility to set Maintenance Mode.

Now, this message should never come in an online patch as oracle did away with the Maintenance mode feature with 12.2.4. So what could be the problem?

Several hours and 100’s of log files later, it was found that the tnsnames.ora did not have the proper entry for <SID>_PATCH tns entry. It should have the EBS_PATCH service name in it. The fix was quick – my entry went from






Lo & behold – APPLY phase went through without any issues. Now, if only Oracle had more meaningful error messages 🙂

Access Forms Directly in 12.2.4 | APP-FND-01542

To access forms directly in 12.2.4, we need to go to URL


If you have out of the box configuration, you will get the error

APP-FND-01542: This Applications Server is not authorized to access this database

To get this working, you need to modify your current run context file, and chnage the “s_appserverid_authentication” value from SECURE to OFF. Then run Autoconfig on RUN FS.

Rapidclone fails at adaddnode.pl ORA-10143 & ORA-06512 Oracle EBS 12.2.4

In Oracle EBS 12.2.4, Rapidclone automatically runs adaddnode.pl. In My case, the adcfgclone.pl appsTier errored out with the below error

sqlplus /nolog @/<serverlocation>/ad/11.5.0/patch/115/sql/adadmdat.sql APPS apps apps 
Updating tables... 

ERROR at line 1: 
ORA-01403: no data found 
ORA-06512: at line 159

Going though the adadmdat.sql, I see that it is trying to update the current view snapshot entries. Going through the requirements for Rapidclone on 12.2, I saw that running a full maintin current view snapshow was required.

So on the sourcenode, I ran adadmin and updated the current view snapshot. It takes about 1 hours. After this, remove the entry for the new appltop frmo ad_appl_top and re-run adaddnode.pl

perl adaddnode.pl -appsuser=apps -appspass=apps