Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Configuration of OEM with RAC

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.

To manage the RAC system with the help of the OEM console and the management server requires a certain amount of discipline at the RAC nodes and instances. The steps to configure such requirements will be covered briefly with the help of an example.

This example assumes a cluster with two node clusters, with node names RAC1 and RAC2.

db_name=V920  # database name
Instance on host RAC1 : V9201
Instance on host RAC2 : V9202

Configuration Steps

Ensure that the /var/opt/oracle/oratab file exists and it has an entry for the database (not for the instance) on each of the nodes.


Check that both nodes are properly configured. The command lsnodes gives the node name on each of the nodes.

Command> lsnodes ?l -n

Ensure that the global service daemon is running on each of the nodes.

Configure the listener.ora file using port 1545 (as an example) on both the nodes.

(PORT = 1545)) )
(ORACLE_HOME = /uo1/app/oracle/product/920)
(SID_NAME = V9201) ))

Since the listener is not running on the default port of 1521, the local_listener parameter in the init.ora of the instances will need to be set so that dynamic service registration will work properly.

local_listener = "(address=(port=1545)(protocol=tcp)(host=rac1))"

On the second node change the references of listener_N1 to listener_N2 and change the host=rac1 to host=rac2.

Configure tnsnames.ora on all nodes.

An example of the tnsnames.ora file is shown below.

(PORT=1545)) )



Note that the intelligent agent on the node will use the tnsnames.ora file. The service_names parameter is the combination of the init.ora parameters <service_names>.<db_domain> with the dot "." separating the two values. The tnsnames.ora file is the same on all nodes, except the order of the addresses in the address_list section of the alias is different.

Test SQL*Net connections - if the listener.ora file, local_listener parameter, tnsnames.ora file, and the sqlnet.ora file are properly configured it should be possible to successfully connect to the V10g, V10g1, and V10g2 aliases from all nodes.

From the first node test the following connections:

> sqlplus system/manager@v10g
> sqlplus system/manager@v10g1

From the second node test the following connections:

> sqlplus system/manager@v10g
> sqlplus system/manager@v10g2

Start the intelligent agent on both nodes. To start, use the command agentctl start.

Check the $ORACLE_HOME/network/agents/services.ora file for correct discovery. The contents of this file help to understand the correctness of the configuration. If any problems are noticed, set a higher trace level and check the message.

To set up trace level 16, add the following line in the $ORACLE_HOME/network/admin/snmp_rw.ora file:


From the Enterprise Manager Console, discover the nodes rac1 and rac2. This will create one entry as under the Databases folder with a subfolder called Instances. The Instances folder will contain a subfolder named Cluster Database Instances. Within this folder, the two instances and should be visible.

An important point to note is that in the case where ORACLE_HOME is shared by multiple RAC nodes (Cluster File system implementations or NFS situations), it is not possible to start the Intelligent Agent on both nodes simultaneously, since the $ORACLE_HOME/network/agent/*.q files would be overwritten each time the agent is started.

Therefore, Oracle recommends three options to avoid this. Follow one of these options to handle the shared Oracle Home situation.

Install the Intelligent Agent for each node in its own Oracle Home location, distinct from the shared Oracle home location. Copy or link the tnsnames.ora and listener.ora to the Intelligent Agent's Oracle home location from the shared Oracle home. Then, start the Intelligent Agent using Intelligent Agent's Oracle home.

For RAC systems like HP TruCluster and PolyServe Matrix Server-based Linux RAC, it is possible to use the Context Dependent Symbolic Link (CDSL) facility to separate the $ORACLE_HOME/network directory from the shared Oracle Home installation without having to physically install the Intelligent Agent on each node in the cluster. This employs using a specific keyword in the filename (or a symbolic link) that distinguishes the name of the current member node of the cluster.

Beginning with version 9.2.x, the Intelligent Agent can store the binary state files (*.q) into an alternate directory rather than use the hard-coded $ORACLE_HOME/network/agent directory. This functionality is very similar to the CDSL method listed in option 2 above.

To force the agent to read and write the binary state files to/from an alternate location, the environment variable ora_oemagent_dir must be set prior to starting the agent. For example, the following would force the agent to read and write its state files to the /usr/oracle/agent directory:

export ORA_OEMAGENT_DIR=/usr/oracle/agent
agentctl start

For more details and updates, please refer to the Oracle MOSC Note (158295.1).


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational