Friday, April 18, 2008

How to determine the Oracle Application Server Metadata Repository (Portal repository) Version

This post is a 10gAS post and not an ERP one.

Here is the situation: You are analyzing the latest release of CPU patches / updates and the patch readme says "apply this patch only if you have xxxx version of portal metadata repository". Now you want to find out what version of the repository do you have in your environment. These steps will help identify the repository version:



1. login to Enterprise Manager - Application Server Control using the application server control URL.
2. Open the file portlist.ini under $PORTAL_ORACLE_HOME/install and this file will reveal the port on which Application Server Control component will listen.
3. Ensure that the Application Server Control service is running in the services panel.
4. Generally you would use ias_admin usercode and password to login.
5. Once you login, under the 'standalone Instances', choose your portal instance.
6. In the resulting screen, choose portal:portal under 'System Components'.
7. The resulting screen shows something like this:

OracleAS Metadata Repository Used By Portal



Status Up
Name udsard
Start Time Apr 13, 2008 10:04:36 AM
Database Version 10.2.0.3.0
Repository Version 10.1.2.0.2


Now you know your repository version !

- Aravind Kamath

Sunday, April 13, 2008

RW-50010: Error: - script has returned an error

Last couple months I was held up with some personal stuff that kept me away from my tech blogs. Today I will share a couple of issues that we faced while setting up a 11.5.10.2 instance on a windows 2003 server and their resolution.

==

Cannot execute Install for database ORACLE_HOME

There was an error while running the command - E:\oraerp\uviserpdb\9.2.0\temp\UVISERP_usearvp405\adrun9i.cmd APPS APPS
The process tried to write to a nonexistent pipe.

RW-50010: Error: - script has returned an error: 1
RW-50004: Error code received when running external process.

==

We encountered the above error on the database server while rapid install was in the process of installing the vision database. The error was quite deceptive. After checking basic things like read write permissions etc, I came across a suggested solution to reduce the %NUMBER_OF_PROCESSORS% environment variable to less than 12. Our server has 16 CPUs and hence rapid installer (rather the java program which is invoked by rapid installer) was expecting the number of cpus to be less than 12. The suggested solution was to change the NUmBER_OF_PROCESSORS environment variable to 12 or less and reboot the server. Once, that is done clean up the failed install and start over again.

I did not want to clean up a failed install. I came up with the following approach instead:

- Defined a new environment variable with the same name (NUMBER_OF_PROCESSORS) at user level (the owner of the db file system / user-code with which rapid install was being run) and assigned a value of 12.
- Instead of a clean up, I restarted the installation with restart option : RapidWiz.cmd -restart

Once this was done, we got past the error and the installation continued. The joy of overcoming this issue was short lived when I saw the following error 10 minutes after I sorted out the first one:

==

"Cannot execute update of the OUI Inventory for database ORACLE_HOME\n";

There was an error while running the command - E:\oraerp\uviserpdb\9.2.0\temp\UVISERP_usearvp405\adrun9i.cmd APPS APPS
The process tried to write to a nonexistent pipe.

RW-50010: Error: - script has returned an error: 1
RW-50004: Error code received when running external process.

Registering local Oracle Home located at E:\oraerp\uviserpdb\9.2.0 to central oracle inventory
RC-00126: Update inventory failed.
null
Raised by oracle.apps.ad.clone.util.OracleHomeCloner

==

The last three lines of error was obtained from the Oracle Inventory logs.

This was due to the fact that we already had a 10g database running on the same server for some other application. The oracle inventory was created by 10g installation. However, all oracle installations will try to update the same Oracle Inventory. 11.5.10.2 brings in 9.2.0.6 database as part of the tech stack and this would not update the oracle inventory created by oracle 10g. I employed the following workaround to get past this issue:

- Renamed the whole existing oracle folder containing the inventory
- Ran rapid install and the new inventory was created. Installation was successful.

Also, ours is a two node install with no apps components on db server. So i can rename the inventory created by 9.2.0.6 instance any time and bring back the 10g inventory if 10g oracle home needs to be patched.

- Aravind Kamath