Dbvisit Standby considerations with RACThe 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 TakeoverIf 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: | No Format |
|---|
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 |
|---|
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: | No Format |
|---|
RAC_TAKEOVER_SID=RACDB2
RAC_TAKEOVER=Y |
On racnode2 the dbv_RACDB2.env will contain:
| No Format |
|---|
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: | No Format |
|---|
RAC_TAKEOVER_SID=RACDB2
RAC_TAKEOVER=Y |
On racnode2 the dbv_RACDB2.env will contain:
| No Format |
|---|
RAC_TAKEOVER_SID=RACDB3
RAC_TAKEOVER=Y |
On racnode3 the dbv_RACDB3.env will contain:
| No Format |
|---|
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.
|