Building Disaster Recovery Serviceguard Solutions Using Metrocluster with 3PAR Remote Copy

PACKAGE STATUS STATE AUTO_RUN NODE
hrdb_sc down halted disabled unowned
2. Enable all nodes in the Metrocluster for the Site Controller Package.
# cmmodpkg –e –n SFO_1 –n SFO_2 -n SJC_1 –n SJC_2 hrdb_sc
3. Start the Site Controller Package.
# cmmodpkg -e hrdb_sc
The Site Controller Package along with RAC stack will start up on the local site (San Francisco).
4. Check the Site Controller Package log file to ensure clean startup.
Configuring client access for Oracle database 10gR2 RAC
In Oracle Database 10gR2 RAC, the Oracle Clusterware configuration provides Virtual IP addresses
(VIPs) through which database clients who are external to the cluster connect to the database.
Oracle listeners gather information about service availability on the RAC servers and assist in
making client connections to the RAC instances. In addition, they provide failure notifications and
load advisories to clients, therefore enable fast failover of client connections and client-side
load-balancing. These capabilities are facilitated by an Oracle 10g feature called FAN. For more
information on Fast Application Notification, see the following documents:
http://www.oracle.com/technology/products/database/clustering/pdf/twpracwkldmgmt.pdf
http://www.oracle.com/technology/deploy/availability/pdf/
MAA_WP_10gR2_ClientFailoverBestPractices.pdf.
FAN capabilities can be accessed by the client application using the FAN API directly or by using
FAN-integrated clients provided by Oracle.
The Metrocluster RAC configuration uses two Oracle sub-clusters in a single SGeRAC cluster. At
any time, you can access a given database through only one of the Oracle sub-clusters. It is referred
to as the active sub-cluster for the database. The client connectivity features mentioned above
related to fast failover and load balancing are available from the active sub-cluster. When the
database fails over to the other sub-cluster, the same features are available from that sub-cluster.
However, the client connections must be made to the VIPs configured in that Oracle sub-cluster.
There are several factors that limit the speed of client reconnection when the database fails over
across sub-clusters.
Steps that occur when any database fails over as follows:
1. Ensures that the database is completely shut down at the formerly active sub-cluster.
2. Fails over the disk device group to the newly active sub-cluster so that the database replica
LUNs become available for read/write access.
3. Starts the CVM disk groups and CFS mount points for the database at the newly active
sub-cluster, and then starts the RAC database there.
While these steps are being performed, client connections cannot be made to the database. Also,
there is no FAN event delivered to indicate site failover, so existing client connections may be
susceptible to delays as long as the TCP keep alive timeout in some cases, before a reconnect is
attempted.
To automatically reconnect clients to the database on a site failover, the Oracle Net service names
must include VIPs configured at both sub-clusters. For Example:
hr_serv1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = SFO_1v.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = SFO_2v.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = SJC_1v.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = SJC_2v.hp.com)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA=
(SERVICE_NAME=hr_serv1)
Configuring Oracle RAC database in a SADTA 93