Failover with Dbvisit on a Linux/Unix cluster (non RAC) system

[Mike Donovan]

As part of the failover with cluster configuration software you will have to customize a number of things like:

1) Specifying which SAN filesystems to mount on the dormant node. These will most likely be the filesystem containing the Oracle database files.
2) Starting Oracle on dormant node.
3) Starting the listener on the dormant node.
4) Starting the various crons for root and Oracle which will activate the backups, application software, maintenance scripts, web servers etc.

Activating the Dbvisit schedule in cron will be part of step 4. As activating the Dbvisit schedule is only a small part of the failover from the active to the dormant mode, we have not developed any special cluster software for this, but rather make Dbvisit flexible enough to integrate with any clustering software.

Oracle can only be active on one node at a time, and therefore Dbvisit is only active on one node.

If the Dbvisit cron was not activated for some reason on the dormant node after failover (now the active node), then Dbvisit on the standby database would start alerting you because it would not find any new archives to apply.

One way to start the crons on the active/dormant nodes is to have 2 cron files on each node for each user that has a cron. For example, create 2 files on each node with the following names:
1) crontab.oracle.active
2) crontab.oracle.dormant

NB: This is the crontab for the user oracle.

The crontab.oracle.active will contain all the cron entries for active node for that user. The file will look something like:

# Dbvisit - Standby Database Technology
00,10,20,30,40,50 * * * * /usr/local/dbvisit/dbvisit orcl >>/dev/null 2>&1
00 * * * * /usr/local/dbvisit/dbvisit -i orcl >>/dev/null 2>&1
# backup with RMAN
00 2 * * * /usr/local/bin/rman_backup.sh

The crontab.oracle.dormant file for oracle would look something like:
# Dbvisit - Standby Database Technology
#00,10,20,30,40,50 * * * * /usr/local/dbvisit/dbvisit orcl >>/dev/null 2>&1
#00 * * * * /usr/local/dbvisit/dbvisit -i orcl >>/dev/null 2>&1
# backup with RMAN
#00 2 * * * /usr/local/bin/rman_backup.sh

As part of the failover you would run the following to activate the crons on the dormant node:
# Activate cron for oracle
su - oracle -c "crontab crontab.oracle.active"

You would run the following on the active node to deactivate the cron (if available):
# De-Activate cron for oracle
su - oracle -c "crontab crontab.oracle.dormant"

[Mike Donovan]

Another method of achieving this would be to write a wrapper script which cron runs which determines if a node/service group is 'online', before performing the intended action (which would be to run Dbvisit in this instance).

Our suggestion is that you consult your vendor's documentation for a platform specific solution.

An example (using Veritas) of this approach is outlined in the following script. This would be run from the cron on both of the primary nodes, and where "ClusterService" is the service group name you supply:

------------------------------
symca !# more tester
if [ `hagrp -state ClusterService -sys symca`="OFFLINE" ]
then

echo "Offline, do not run script"

else

echo "Online, run script"

fi
-------------------------------