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"

You can use the session variables ORACLE_HOME, ORACLE_HOME_NAME, CLUSTER_NODES, REMOTE_NODES, and LOCAL_NODE.

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.

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.

SCRIPT PARAMETERS
------ ----------
Concurrent Manager Process (adcmctl.sh) {startstop} Forms Metrics Server (adfmsctl.sh) stop
Forms Server Listener (adfractl.sh) stop (As Applmgr)
Forms Server Listener (adfroctl.sh) stop
Reports Server (adrepctl.sh) stop
WebDB 2.2 Listener (adwlnctl.sh) stop
WebDB 2.5 Listener (adwdbctl.sh) stop
TCF Server (adtcfctl.sh) stop
Forms Metrics Client (adfmcctl.sh) stop
APACHE Listener (adapcctl.sh) stop
Net8 RPC Listener (adalnctl.sh) stop APPS_ Net8
Database Listener (addlnctl.sh) stop
Database (addbctl.sh) 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.

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`" user@example.com

Replace user@email.com 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.

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/adgentns.pl 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:

select DB_NAME from FND_DATABASES;

Locate the server name corresponding to the tier in question:

Query on the Applications tier:

select NAME, SERVER_TYPE from FND_APP_SERVERS, FND_NODES
where FND_APP_SERVERS.NODE_ID = FND_NODES.NODE_ID and
SERVER_TYPE='APPS' and FND_NODES.NODE_NAME=upper('hostname');

Run the following PL/SQL block:

begin
FND_NET_SERVICES.remove_server(', '');
end;
/
commit;
/

- 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/adclonectx.pl 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
./adconfig.sh 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:

127.0.0.1 localhost.localdomain
ip_address node_name.domain_name

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

HOSTNAME=node_name.domain_name

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/adstrtal.sh apps

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.

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

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

Usually for a 11.5.10.2 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 xmlparserv2.zip

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

cd $IAS_ORACLE_HOME

. ../.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/xmlparserv2.zip

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/jtfaoljdepen.zip

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;

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,

$AD_TOP/admin/template

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"/