Friday, February 27, 2009

How To Find The Version Of A pld File?

The *.pld files are the source code of *.pll files which are the source of the executable *.plx files.

The *.pld file itself does not get installed. To find the version of the *.pld file you need to look into the corresponding *.pll file.

The *.pll files are located in $AU_TOP/resource

To identify the version of pld file XYZ.pld you can use the following string at OS level:

adident Header $AU_TOP/resource/XYZ.pll

Wednesday, February 25, 2009

How To Check The inventory.xml/comps.xml Or Any Oracle XML File Is Correct

You can check the inventory.xml/comps.xml ( any XML file) using the "LoadXML" option in Opatch utility.
The command is :

> opatch util LoadXML -xmlInput "xml_file"

For example :
If the xml file to be checked is "/u01/oracle/visndb/10.2.0/inventory/ContentsXML/comps.xml "
then the command will be

opatch util LoadXML -xmlInput /u01/oracle/visndb/10.2.0/inventory/ContentsXML/comps.xml

The Opatch output will be:


opatch util LoadXML -xmlInput comps.xml
Invoking OPatch

Oracle interim Patch Installer version
Copyright (c) 2005, Oracle Corporation. All rights reserved..

UTIL session

Oracle Home : /u01/oracle/visndb/10.2.0
Central Inventory : /etc/oraInventory
from : /u01/oracle/visndb/10.2.0/oraInst.loc
OPatch version :
OUI version :
OUI location : /u01/oracle/visndb/10.2.0/oui
Log file location : /u01/oracle/visndb/10.2.0/cfgtoollogs/opatch/opatch-2009_Feb_25_05-34-19-CST_Wed.log

Invoking method loadxml
Please enter the complete path to the XML file to load:
(enter both the dir. path and the file name)"

You entered: "comps.xml".
XML file is OK.

OPatch succeeded.


If the XML file is incorrect, Opatch will chow an error like:


opatch util LoadXML -xmlInput D:\11G\db_1\inventory\ContentsXML\comps.xml
Invoking OPatch

Oracle interim Patch Installer version
Copyright (c) 2005, Oracle Corporation. All rights reserved..

UTIL session

Oracle Home : /u01/oracle/visndb/10.2.0
Central Inventory : /etc/oraInventory
from : /u01/oracle/visndb/10.2.0/oraInst.loc
OPatch version :
OUI version :
OUI location : /u01/oracle/visndb/10.2.0/oui
Log file location : /u01/oracle/visndb/10.2.0/cfgtoollogs/opatch/opatch-2009_Feb_25_05-34-19-CST_Wed.log

org.xml.sax.SAXParseException: : XML-20125: (Fatal Error) Attribute value should start with quote.
at oracle.xml.parser.v2.XMLError.flushErrorHandler(
at oracle.xml.parser.v2.XMLError.flushErrors1(
at oracle.xml.parser.v2.NonValidatingParser.parseAttrValue(
at oracle.xml.parser.v2.NonValidatingParser.parseAttr(
at oracle.xml.parser.v2.NonValidatingParser.parseAttributes(
at oracle.xml.parser.v2.NonValidatingParser.parseElement(
at oracle.xml.parser.v2.NonValidatingParser.parseRootElement(
at oracle.xml.parser.v2.NonValidatingParser.parseDocument(
UtilSession failed: OracleHomeInventory gets a null Vector of installed products


Tuesday, February 24, 2009

'ORA-01918:user 'ADSEUL_US' does not exist' during application of patch 5726010

patch 5726010 is one of the pre requisite patches for the upgrade to R12 from 11i. This script has 2 sql scripts (adgncons.sql and adgrants.sql) which are to be run against the instance. additionally, a third script(adcrtbsp.sql), generated by adgncons should also be run.

adgncons.sql has run successfully. but the following error is thrown during the adcrtbsp.sql run.

ORA-01918: user 'ADSEUL_US' does not exist

This error can be safely ignored. ADSEUL_US is a demo EUL for Discoverer.

The one that is needed is EUL_US, which is a standard EUL used when you run / create workbooks in Business Intelligence, for example :

Financials Intelligence, HRMS Intelligence, Purchasing Intelligence etc

Monday, February 23, 2009

Rapidwiz error while installing Applications Release12

When attempting to install Oracle Applications Release 12, the following error occurs during rapidwiz post-installation checks

checking URL = http://.:8000/OA_HTML/AppsLogin
RW-50016: Error: - {0} was not created:

Processing DriverFile = /stage/StageR12/startCD/Disk1/rapidwiz/template/adriapps.drv
Executing service control script:
/oracle/R12/inst/apps/TWO_oraclesvr05/admin/scripts/ start
ERROR : Timed out( 100000 ): Interrupted Exception
You are running version 120.11

The issue is caused by a wrong setup in /etc/hosts file. The local host and server are setup in the same line in the hosts file.

To resolve this, backup the hosts file and make the following change. localhost
'IP' 'host.domain' 'host'

Friday, February 20, 2009

Tables used by adpatch

Important tables for ADPATCHFiled under: Oracle Application R12, Oracle Applications 11i
Here are some of the important tables used by and updated by ADPATCH utility.

This table holds the various APPL-TOP’s in the Oracle Applications installation that have ever been patched.

AD_APPLIED_PATCHES holds information about the “distinct” Oracle Applications patches that have been applied. If 2 patches happen to have the same name but are different in content (eg. “merged” patches), then they are considered distinct and this table will therefore hold 2 records.

AD_BUGS holds information about the various Oracle Applications bugs whose fixes have been applied (ie. patched) in the Oracle Applications installation.

This table holds information about the patch drivers that comprise a patch.

This table holds the various versions of Oracle Applications files (real files, not “pseudo-files”), that have ever been patched or executed in the Oracle Applications installation.

AD_FILES is the “files repository”. It contains information about the various files that have been patched in the Oracle Applications installation.Some entries are “pseudo-files” and not real files, (eg. directories) in which case some of the columns are not applicable and would then hold the value “DUMMY”

NLS patches (or more specifically, NLS patch drivers) pertain to a language or multiple languages. This table holds that language (or multiple languages).

This table holds information about the various Mini Packs contained in a patch (driver)

AD_PATCH_RUN_BUG_ACTIONS holds the various actions present in “applied” bug (fix). If Autopatch determined not to apply a bug (fix), then this table will not hold any records for that “unapplied” bug fix.

Even though a patch may have been applied on an Oracle Applications installation, some actions in some of its included bugs (fixes) may not have got executed if the “Autopatch” utility determined that it was not necessary to execute those actions. In such cases, EXECUTED_FLAG is set to N.

This table holds information about the bugs fixed in a specific run of Autopatch.AD_PATCH_RUN_BUGS holds information about the various bugs fixed in a specific run of Autopatch.
Even though a patch may have been applied on an Oracle Applications installation, some bugs (fixes) contained in it may not get applied due to some reason. In such cases, the REASON_NOT_APPLIED column holds the reason.

AD_PATCH_RUNS holds information about the various invocations of Autopatch for applying Oracle Applications patches to a specific release of an Oracle Applications installation.
If multiple drivers are run in one invocation of Autopatch, they result in multiple records in this table. These multiple records will all have the same SESSION_ID (because they arose from one Autopatch invocation), but different TASK_NUMBER’s. The TASK_NUMBER’s in this case will be numbered sequentially as 1, 2, 3, etc.Note that when the database driver of a Maintenance Pack is applied, it bumps up the release version by creating a new record in
AD_RELEASES, which is then pointed to by the UPDATED_TO_RELEASE_ID column of the old record.

AD_RELEASES holds the various Oracle Applications releases that an installation of Oracle Applications has gone through in its entire life cycle.
It should be noted that START_DATE_ACTIVE, END_DATE_ACTIVE and BASE_RELEASE_FLAG are loosely-maintained informational columns and are not accurately maintained, and therefore should not be relied upon heavily.

This table holds distinct information about the various actions that are (often repeatedly) performed by Autopatch as part of applying patches.

Thursday, February 19, 2009

How to Audit Potential Attempts to Break a Username/Password.

How to enable audit to trace a user/terminal who is trying to break in
username and password in the database? This is also a good way to Audit
unsuccessful database login attempts.

Do the following steps to enable auditing:

1. Modify the "init.ora" file, usually located in the "$ORACLE_HOME/dbs"
directory to enable the AUDIT_TRAIL parameter.

AUDIT_TRAIL can be set to one of the following values:

DB or TRUE enables systemwide auditing where audited records are written to the database audit trail, the SYS.AUD$ table
OS enables systemwide auditing where audited records are written to the operating system's audit trail.

NONE or FALSE disables auditing.


2. Stop/Start the instance to make the parameter effective.

3. Enable the following audit option


4. Then query AUD$ as the following example

SQL> select returncode, action#, userid, userhost, terminal from aud$

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

The return code 1017 means ORA-1017 "invalid username/password; logon denied"
Indicating that host WPRATA-BR tried to break in username/password.

Wednesday, February 18, 2009

RapidWiz log files for Oracle Applications Release 12

During the installation of Release 12 using RapidWiz, the following log files are created.

Before the installation starts:
The Rapidwiz Configuration File is saved in 3 locations:-

Database Tier:
RDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDBTechStack_.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ohclone.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/make_.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/installdbf.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/adcrdb_.log RDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDatabase_.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME//adconfig.log RDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME//NetServiceHandler.log

Applications Tier(s):

Inventory Registration:

In case of any issues during the installation, we can use these log file locations for the trouble shooting.

Tuesday, February 17, 2009

Script to find Apache, Java, JRE, Forms version for Oracle E-Business Suite R12

The shell script below can be used to collect Apache, Java, Client JRE, Forms, Perl, PL/SQL versions and Forms communication mode from a Oracle R12 environment. This script should be run only in a *nix environment against a R12 instance only.

The script shows the output on screen, which is also captured in the file "zz_.txt" which is created in the current directory

echo "Script Started "
## The script shows output on screen and creates file named hostname_date.txt file in current ## directory
## Collect the Apache version
echo "*****Apache Version*****"
$IAS_ORACLE_HOME/Apache/Apache/bin/httpd -v
echo " "
## Collect perl version
echo "*****perl version******"
$IAS_ORACLE_HOME/perl/bin/perl -v|grep built
echo " "
## Collect Java version
echo "******Java Version******"
sh -c "`awk -F= '$1 ~ /^JSERVJAVA.*$/ {print $2}' $ADMIN_SCRIPTS_HOME/` -version;"
echo " "
## Collect client JRE version
echo "*****Client JRE version*****"
cat $FORMS_WEB_CONFIG_FILE|grep sun_plugin_version| cut -c 1-35
echo " "
## Collect Forms version
echo "*****Forms Version*****"
$ORACLE_HOME/bin/frmcmp_batch|grep Forms| grep Version
echo " "
## Collect PL/SQL Version
echo "*****PL/SQL Version****"
$ORACLE_HOME/bin/frmcmp_batch|grep PL/SQL|grep Version
echo " "
## Collect Forms communication mode
echo "****Forms Communication Mode****"
cat $FORMS_WEB_CONFIG_FILE|grep serverURL=
echo "If the serverURL parameter has no value then Forms is implemented in socket mode else it is servlet"
echo " "
echo "Script Completed Successfully and it has generated the file zz`hostname`_`date +%m%d%y.%H%M`.txt file in current directory"
echo "Script completed "
) 2>&1 | tee zz`hostname`_`date +%m%d%y.%H%M`.txt

Monday, February 16, 2009

Error while running after upgrading database to from

The following error was encountered while running on the database tier to create the context file.

Could not Connect to the Database : ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux Error: 2: No such file or directory

Connecting to the VISN11 database instance...

Connection paramaters values:
Database server hostname ==> NGLINUX05.NEWGEN.COM
Database listener port ==> 1542
Database SID ==> VISN11
Database schema name ==> apps

Could not Connect to the Database : ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux Error: 2: No such file or directory

AC-40000: Error: Exception - java.sql.SQLException: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

The problem was that the database was not registered with the listener.

SQL> show parameter local_listener;

------------------------------------ ----------- ------------------------------
local_listener string

The value for LOCAL_LISTENER is missing, so automatic instance registration is not taking place
We can correct this by setting the LOCAL_LISTENER parameter:

SQL> alter system set local_listener='(ADDRESS =(PROTOCOL=TCP)(';

System altered.

SQL> alter system register;

System altered.

SQL> exit

Now adbldxml runs successfully.

Thursday, February 12, 2009

Creating the Central Inventory when it is lost or corrupted

Oracle Universal Installer enables you to set up the Central Inventory on a host or register an existing Oracle home with the Central Inventory, when it is lost or corrupted. You can set up the Central Inventory by using the -attachHome flag of Oracle Universal Installer using the following syntax

./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="Oracle_Home_Location" ORACLE_HOME_NAME="Oracle_Home_Name"
"CLUSTER_NODES={node1,node2,...}" LOCAL_NODE="node_name"


In a cluster installation, if you don't pass the CLUSTER_NODES session variable, Oracle Universal Installer takes it from the $ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml file.

You may pass the REMOTE_NODES variable if you want to specify the list of remote nodes. If you want to set up the Central Inventory in the local node, you need to pass the -local flag and the REMOTE_NODES variable empty. The syntax is as follows:

./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="Oracle_Home_Location" ORACLE_HOME_NAME="Oracle_Home_Name"
"REMOTE_NODES={}" -local

When you use the -local flag, it performs the action on the local node irrespective of the cluster nodes specified.

For a non-Real Application Clusters setup, you need not pass the LOCAL_NODE variable, and the CLUSTER_NODES variable is empty. The syntax is as follows:

./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="Oracle_Home_Location" ORACLE_HOME_NAME="Oracle_Home_Name"

If the Central Inventory does not already exist, Oracle Universal Installer creates the Central Inventory in the location specified by the oraInst.loc file.

Wednesday, February 11, 2009

How to Clean up the UNIX Environment After Install Fails

Complete the following steps to clean up after an 11i install has failed:

1. The first step to cleaning up an 11i install is to make sure that all the Application processes are shutdown. Here is a list of processes that need to be shut down. Processes should be shut down in this order.


------ ----------
Concurrent Manager Process ( {startstop} Forms Metrics Server ( stop
Forms Server Listener ( stop (As Applmgr)
Forms Server Listener ( stop
Reports Server ( stop
WebDB 2.2 Listener ( stop
WebDB 2.5 Listener ( stop
TCF Server ( stop
Forms Metrics Client ( stop
APACHE Listener ( stop
Net8 RPC Listener ( stop APPS_ Net8
Database Listener ( stop
Database ( stop

2. Verify that the processes are shut down by using a ps -ef and grep for the process. For example

After the processes are shut down you can proceed with the following steps:

3. Delete the oraInst.loc file. This file will be recreated when Rapidwiz starts again.

4. Delete the oraInventory directory

5. All the files in the APPL_TOP and ORACLE_BASE directories can be removed. If a similar file structure is used for the next install confirm the base directories exist with the correct owner and group

6. If you are changing the directories' structures, delete the config.txt and create a new one. If the directories are the same you may reuse the existing config.txt file.

Tuesday, February 10, 2009

Linux Server Sends Email Alert when logged in as root

We can enable the linux server to automatically send a notification email to predefined email address everytime someone logs in as root to the host. To configure the automatic email alert notification to a default email address on each incident of root log on on the server, use the following guide.
Login to the server using as root ID.
Ensure that you’re at home directory of root. open the .bash_profile for editing using vi editor as shown below

vi .bash_profile

Scroll down to the end of the file and add the following line:

echo 'ALERT - Root Shell Access on:' `date` `who` mail -s "Alert: Root Access from `who cut -d"(" -f2 cut -d")" -f1`"

Replace with the actual email account address that you want to the root access alert notification been sent to. Note that you can change the text contains in the email alert too. The text starting with first ALERT is written as email body, and you can add in other info such as host name or change the wordings. The second Alert is the email title which you can enter your own text.

Friday, February 6, 2009

Change the hostname of an Applications Tier using AutoConfig

The following method can be used to change an Applications Tier hostname using AutoConfig.

- Deregister the current Applications server

as the owner of the Oracle Applications file system and current database instance runt eh following command:

perl $AD_TOP/bin/ appspass= \
contextfile= path-to-context-file -removeserver

If you already changed the information of your existing AutoConfig Context file and have not done the above step, then you can manually update the Net Services Topology Model using the following syntax:

Locate the System Name:
The System name is the database name
Verify with sql query:


Locate the server name corresponding to the tier in question:

Query on the Applications tier:

SERVER_TYPE='APPS' and FND_NODES.NODE_NAME=upper('hostname');

Run the following PL/SQL block:

FND_NET_SERVICES.remove_server(', '');

- Create a new context file using the following syntax (skip this step if you have changrd the context file previously and had manually removed the tier server):

cd $APPL_TOP/admin
perl $AD_TOP/bin/ contextfile=$CONTEXT_FILE

This will create a new Context file of the format _.xml in the current working directory

- Shutdown all Application services

- Reseed the Net Services Topology Model.

The Net Services Topology Model is automatically updated by running AutoConfig.

cd /bin
./ contextfile= path-to-context-file appspass=apps-password

- Change the machine hostname

Change the hostname at O/S level at this stage
If you use /etc/hosts ensure you remember to update the entries.

Linux Red Hat Platforms Only:

Verify that the /etc/hosts file contains entries that are similar to the following: localhost.localdomain
ip_address node_name.domain_name

Verify that the /etc/sysconfig/network file contains an entry that is similar to the following:


Check to see if the /etc/sysconfig/networking/profiles/default/network file exists. If it does, remove it.

If you changed any files in the previous steps, reboot the system.

- Start the Applications Tier Services

Rerun APPSORA.env and start the Applications Tier Services using the script from the new directory:

$COMMON_TOP/admin/scripts/SID_newhostname/ apps

Thursday, February 5, 2009

How to disable remote root logins using SSH in linux

For security reasons, it is best to disable remote root logins to a server. This can be done by the following steps.

- SSH into server and login as root.

- navigate to the directory /etc/ssh/sshd_config and open the file sshd_config for editing

- Scroll down the SSH server configuration file and locate the line below:

#PermitRootLogin yes

- Uncomment the line by removing the hash symbol (#), and then change the “yes” to “no”.

PermitRootLogin no

- Save and quit the config file.

- Restart SSH server using the following command at the prompt

/etc/rc.d/init.d/sshd restart

- remote root logins have now been disabled.

Wednesday, February 4, 2009

How to load all the java files required in an Oracle Applications Instance

- Verify all the java files listed in the adldjava.drv under the location $AD_TOP/admin/driver

Usually for a environment, the following jar files are present.

loadjava asf java/jar asfleadshare.jar

loadjava asg java/jar asgmtran.jar

loadjava csf java/jar csflf.jar

loadjava csf java/jar csflf.jar

loadjava cz java/jar czdb.jar

loadjava eam java/jar eampmsch.jar

loadjava eam java/jar eamwkbch.jar

loadjava ecx java/jar ecxutils.jar

loadjava fnd java/3rdparty/stdalone

loadjava fnd java/jar fndsec.jar

loadjava ibe java/jar ibeeos.jar

loadjava ieu java/jar ieutrans.jar

loadjava inv java/jar invdbtrx.jar

loadjava pay java/jar payproc.jar

loadjava pay java/jar payutil.jar

loadjava per java/jar perimage.jar

loadjava per java/jar perkpiclient.jar

loadjava wms java/jar wmscrtzn.jar

loadjava xtr java/jar xtrintrp.jar

- run adadmin and select the following options

- Generate JAR files

- Generate Applications Files menu

- Generate product JAR files

Answer "YES" when "Do you wish to force regeneration of all jar files? " is asked

- Reload those JAR files

- Under adadmin, select the following options

- Compile/Reload Applications Database Entities menu

- Reload JAR files to database

This will load the jar files listed in $AD_TOP/admin/driver/adldjava.drv

- Verify the loaded java objects using the query

select count(*) from dba_objects where owner = 'APPS' and object_type like '%JAVA%';

- Reload following jar files manually since they are not loaded by adadmin, according with the output of the $AD_TOP/admin/driver/adldjava.drv


. ../.env

loadjava -user apps/apps -v -force -resolve $CSF_TOP/java/jar/csflf.jar

loadjava -user apps/apps -v -force -resolve $CZ_TOP/java/jar/czdb.jar

loadjava -user apps/apps -v -force –resolve $EAM_TOP/java/jar/eampmsch.jar

loadjava -user apps/apps -v -force -resolve $EAM_TOP/java/jar/eamwkbch.jar

loadjava -user apps/apps -v -force -resolve $ECX_TOP/java/jar/ecxutils.jar

loadjava -user apps/apps -v -force -resolve $ECX_TOP/java/jar/ecxprocess.jar

loadjava -user apps/apps -v -force -resolve $FND_TOP/java/3rdparty/stdalone/

loadjava -user apps/apps -v -force -resolve $FND_TOP/java/jar/fndcct.jar

loadjava -user apps/apps -v -force -resolve $INV_TOP/java/jar/invdbtrx.jar

loadjava -user apps/apps -v -force -resolve $INV_TOP/java/jar/invlabel.jar

loadjava -user apps/apps -v -force -resolve $ITG_TOP/java/jar/itgv1.jar

loadjava -user apps/apps -v -force -resolve $JTF_TOP/java/jar/

loadjava -user apps/apps -v -force -resolve $PER_TOP/java/jar/perimage.jar

loadjava -user apps/apps -v -force -resolve $PER_TOP/java/jar/perkigfclient.jar

loadjava -user apps/apps -v -force -resolve $PER_TOP/java/jar/perkpiclient.jar

loadjava -user apps/apps -v -force -resolve $WMS_TOP/java/jar/wmscrtzn.jar

loadjava -user apps/apps -v -force -resolve $XTR_TOP/java/jar/xtrintrp.jar

- Remove the classes comes with $PAY_TOP/java/jar/payproc.jar - These classes should not be in the database and they are not in the fresh database either :

dropjava -user apps/apps -verbose $PAY_TOP/java/jar/payproc.jar

- Run adadmin and select "compile APPS schema" option to validate all the invalid objects and verify if any invalid JAVA Objects left using sql below, there shouldn't be any.

select object_type, dbms_java.longname (object_name), status

from dba_objects

where owner = 'APPS'

and object_type like '%JAVA%' order by 1,2,3;

Tuesday, February 3, 2009

Oracle supplied file to understand context file variables

Oracle supplies a file to understand the context variables in the system. To get an understanding of the variables, check file 'adctxinf.tmp' that exists under the directory,


This file explains all the variables that are listed in the context file for that instance. Sample is shown below.

oa_doc oa_level="detail" oa_var="s_proxyhost" title="Fully qualified Proxy Server Host Name" tooltip="Fully qualified Proxy Server Host Name" description="Fully qualified Proxy Server Host Name" editable="Yes"/