Page Comparison

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).

the RAC environment

 section for specific information on the setup of Dbvisit Standby in a RAC environment. 
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 05, 20, 35, 50

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 values:
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 values:
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. 
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:
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
On racnode2 the dbv_RACDB2.env will contain:
RAC_TAKEOVER_SID=RACDB1
This ensures that if either node is unavailable, the other node will takeover log shipment to the standby database(s).

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.