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.

JBO DEBUG LOGGING ON WITHOUT -D FLAG, NOTICE LEVEL AND PROD MODE=TRUE

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

ORCL = (DESCRIPTION=
(ADDRESS=

(PROTOCOL=tcp)(HOST=mydbserver1)(PORT=1521))
(CONNECT_DATA=(SID=ORCL))
)

to

ORCL_PATCH = (DESCRIPTION=
(ADDRESS=

(PROTOCOL=tcp)(HOST=mydbserver1)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=EBS_PATCH)
(INSTANCE_NAME=ORCL)
)

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

http://hostname.domain:port/forms/frmservlet

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... 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

declare 
* 
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

OPATCH_JAVA_ERROR = OPatch Exception While Trying to Check for Mini Patchset

We were applying a pre req patch before upgrade from 12.1.1 to 12.1.3. After sourcing the environment , I did OPATCH lsinventory and it gave expected output. After that when we applied OPATCH apply, it errored out with the message
OPATCH_JAVA_ERROR=OPatch Exception While Trying to Check for Mini Patchset

Looking in My Oracle Support did not give much clue. The Note ID 971783.1 OPATCH_JAVA_ERROR=OPatch Exception While Trying to Check for Mini Patchset’ while applying patch using opatch 1.0.0.0.x. This note suggested removing the ‘&’ and ‘<‘ character from the bug description section in the /etc/config/inventory file. However, my inventory file did not have any such characters except the XML tags, which I couldn’t remove.

Our Solution

It was then that I noticed that the patch was unzipped into a path which had a space in the folder name. We renamed the folder to a simpler name, without spaces and the patch proceeded normally.

Oracle EBS Platform Migration – A Quick note

 

 

I read around for strategies on platform migration of EBS R12 and 11g DB. There are paths defined by Oracle which guides such migrations. Given below is a high level description of an oracle endorsed approach of App-Tier migration process.  DB migration is a separate topic and should be dealt as such.

Note:

  1. Most of the application tier migration can be done in advance and a very minimal downtime is required. However DB tier migration will require downtime (you have to move the 2 TB data from one place to other!)
  2. The below steps are explained in detailed in the note (438086.1) which was my reference.

 

  • Pre-Requisites
  1.     OS system requirements in the new platform target machine.
  2.     Software requirements on source and target machine (zip, JDK, perl etc)
  3.     Apply the latest AD Patch (R12.AD.B.DELTA.3 for 12.1)
  4.     Upgrade to EBS 12.0.4 or higher
  5.     Apply the latest Autoconfig template patches
  6.     Apply the latest Rapidclone Patches
  7.     Apply Platform Migration Patches & Additional Patches (No Patched advised for 12.1.x at this point of time)
  8.     Run Autoconfig on Source system
  9.     Run adpreclone in source system
  10.     Run maintain snapshot (And this must complete successfully)
  11.     Identify Tech Stack Updates to be done to the Target machine after the migration. This is done by using technology Stack Inventory utility
  • ¬†¬† ¬†Migration tasks
  1.     Generate and upload the manifest of customer-specific files. This is used to generate a custom migration patch. The custom migration patch created is specific to specific upgrade only and contains all the files contained in the APPL_TOP that are binary specific to the new target platform. This patch is therefore applied in the new environment.
  2.     Copy the Source System to the Target System
  3.     Install JDK and InfoZip utilities on the Target System
  4.     Copy the Source System Context File to the Target System
  5.     Clone the Applications Context File on the Target System
  6.     Install the Application Tier Technology Stack
  7.     Run AutoConfig setup phase on the Target System
  8.     Download and apply the customer-specific update with AutoPatch
  9.     Review Component Versions and Technology Stack patch level
  10.     Regenerate File System Objects
  11.     Clean Nodes
  12.     Run AutoConfig to complete the Target System configuration
  • Finishing tasks
  1.     Update Third Party Extensions.
  2. Review and update Target System Application Tier Settings and Customizations
  3. Update printer settings
  4. Update Oracle Workflow configuration settings
  5. Verify the APPLCSF variable setting
  6. Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERS
  7. Start all services on the Target System

 

Reference:

Application Tier Platform Migration with Oracle E-Business Suite Release 12 ID : 438086.1

Change user_name in FND_USER from back-end

PROBLEM: Identify a method to update the existing usernames in FND_USER to a value matching the Active Directory username. This is required for implementing stuff like Single Sign On (SSO). The process works fine when done from ERP Application front end, however a simple update of the FND_USER table from back-end does not work.

CAUSE: The reason why a simple update of FND_USER doesn’t work is that Oracle uses Workflows (WF) to maintain this information and when we update the FND_USER the foreign key references in the Workflow are not updated automatically.

SOLUTION:We can use the oracle provided procedure APPS.FND_USER_PKG.CHANGE_USER_NAME () to change the username as well as update the related WF tables.

I tested this on my username SARATHJ and changed it to SARATHJ1. All the responsibilities that existed for the user SARATHJ still exists for the changes user SARATHJ1. I validated this from both back-end and front-end. I could also login to the Application with my old password and work. A script can be written using this API and we can use SQL Loader to import data from a spreadsheet (.xls file) into a table in the Database. Then the API can be called in a loop to update the records. A pseudo code for the same is given below:

1. Place the usernames.xls in the interface directory

2. Run SQL Loader and import data into a loading table in the Database.

3.  SQL Script

a. For each row in loading table, call the API.
b. COMMIT every 500 rows