Dbvisit Standby and Oracle RAC

Owned by Anton Els (Deactivated)
Last updated: Apr 07, 2016
4 min read

For more information on the installation of Dbvisit Standby on an Oracle RAC configuration please see this section: Install Dbvisit Standby on Oracle RAC and Configure Oracle RAC Primary with Oracle RAC Standby

Dbvisit Standby can be used together with Oracle RAC (Real Application Cluster). RAC allows multiple instances on different nodes to access a shared database on a cluster system. RAC allows scalability and provides high availability. Oracle RAC together with Dbvisit Standby standby database(s) provides high availability and disaster recovery. Dbvisit Standby supports archive logs in Oracle ASM file system.
The standby database can be a RAC standby database (figure 2) or it can be a single instance standby database (figure 3).

Figure 2 – RAC primary database with RAC standby database 

Figure 3 – RAC primary database with single instance standby database

Dbvisit Standby installation with RAC

Dbvisit Standby should be installed on each primary RAC node and on all standby servers.

Dbvisit Standby should be configured separately on each RAC primary node. Please follow the normal Dbvisit Installation, but pay attention to the special RAC comments and instructions. 

Dbvisit Standby considerations with RAC

The Dbvisit Standby Database Configuration file (DDC) created during the setup on each node will have the name of the instance and not the name of the database (dbv_oracle_instance.env).
Dbvisit Standby needs to be scheduled separately on each primary node. It is recommended that Dbvisit Standby is scheduled at different times on each node. For example:


node1 – Schedule every hour at 00, 15, 30, 45
node2 – Schedule every hour at 02, 17, 32, 47


The archive destination location on the standby node must be accessible by all standby nodes in the RAC standby cluster.

Dbvisit Standby RAC Takeover

If a RAC node fails and is unavailable, then Dbvisit Standby on another RAC node can automatically take over the log shipment from the failed node. The Dbvisit Standby RAC Takeover is controlled by the following variables in the dbv{_}oracle_instance.env file:

RAC_TAKEOVER
RAC_TAKEOVER_SID
RAC_TAKEOVER_FORCE

 

RAC_TAKEOVER:

  • Yes = Dbvisit Standby (on this instance) will take over from another instance when that instance is unavailable.
  • No = Dbvisit Standby (on this instance) will NOT take over from another instance when that instance is unavailable. 

RAC_TAKEOVER_FORCE:

  • Yes = Dbvisit Standby (on this instance) will take over from another instance regardless of whether that instance is available or not.
  • No = Dbvisit Standby (on this instance) will NOT take over from another instance unless the instance is not available and RAC_TAKEOVER = Yes. 

 

NOTE: When using RAC_TAKEOVER_FORCE=Y from one of the Oracle RAC nodes, it will ship all logs for all nodes from this node. This is an option you can use to allow you to run Dbvisit Standby on only one of the Oracle RAC nodes (having Dbvisit Standby scheduled on only one of the nodes. It is however required that on initial installation, you must run Dbvisit Standby first on all the RAC nodes to ship logs for that node (thread) and then once you have confirmed that Dbvisit Standby is shipping and applying logs, you can then schedule it to run only from one of the Nodes by setting RAC_TAKEOVER_FORCE=Y one the required node.

 

 

RAC_TAKEOVER_SID

  • Specify the instance name that Dbvisit Standby processing should take over if that instance is unavailable.
  • The instance name must be different to the current instance name.

 

 

Example - 2 Node Primary RAC configuration

If the RAC setup contains 2 nodes (racnode1, racnode2) with instance names RACDB1 and RACDB2, then:
On racnode1 the dbv_RACDB1.env will contain:

RAC_TAKEOVER_SID=RACDB2
RAC_TAKEOVER=Y


On racnode2 the dbv_RACDB2.env will contain:

RAC_TAKEOVER_SID=RACDB1
RAC_TAKEOVER=Y


This ensures that if either node is unavailable, the other node will takeover log shipment to the standby database(s).

Example - 3 Node Primary RAC Configuration

The RAC_TAKEOVER_SID is not too different with a 3 node set up, as for a 2, and you just specify the next node in the sequence in a rolling/circular fashion. So, if the RAC setup contains 3 nodes (racnode1, racnode2, racnode3) with instance names RACDB1, RACDB2 and RACDB3 then:

On racnode1 the dbv_RACDB1.env will contain:

RAC_TAKEOVER_SID=RACDB2
RAC_TAKEOVER=Y



On racnode2 the dbv_RACDB2.env will contain:

RAC_TAKEOVER_SID=RACDB3
RAC_TAKEOVER=Y



On racnode3 the dbv_RACDB3.env will contain:

RAC_TAKEOVER_SID=RACDB1
RAC_TAKEOVER=Y



This ensures that if a particular node is unavailable, the 'next' node will takeover log shipment to the standby database(s). And if there are more than 3 nodes in the RAC configuration then you just follow this same approach and specify the 'next' node, in a rolling/circular fashion.

Standby node setup with RAC

The standby database can be configured as a single instance database or as a RAC database with several instances on different standby nodes.
Single standby database instance (Figure 3 – RAC primary database with single instance standby database)

  • All primary nodes need to send the archive logs to the single standby node.
  • Dbvisit Standby will apply the archives from all threads to the standby database.
  • Dbvisit Standby is scheduled on the standby server using the instance name from one of the primary nodes. Example if the RAC configuration has 2 instances called RACDB1 and RACDB2 and the standby database is called RACDB, then Dbvisit Standby is executed on the standby server using the command:

dbvisit RACDB1
RAC standby database instances (Figure 2 – RAC primary database with RAC standby database)

  • All primary nodes need to send the archive logs to a shared location on the RAC standby cluster.
  • Dbvisit Standby only needs to be scheduled on one standby instance to apply the archives from all threads to the standby database.
  • Dbvisit Standby must be dormant on all the other standby nodes. An automated job can be scheduled to enable Dbvisit Standby if it is detected that the standby node on which Dbvisit Standby is active is no longer available.