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.
# database name
Instance on host RAC1 : V9201
Instance on host RAC2 : V9202
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.
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.
(ADDRESS = (PROTOCOL = TCP)(HOST = RAC1)
(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
Configure tnsnames.ora on all
An example of the tnsnames.ora
file is shown below.
(INSTANCE_NAME=V10g1) ) )
(INSTANCE_NAME=V10g2) ) )
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 V10g.acme.com 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
> sqlplus system/manager@v10g1
From the second node test the
> 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
From the Enterprise Manager
Console, discover the nodes rac1 and rac2. This will create one
entry as V10g.acme.com 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 V10g1.acme.com and V10g2.acme.com 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:
For more details and updates,
please refer to the Oracle MOSC Note (158295.1).