Versions Compared

Old Version 8

changes.mady.by.user KrupeshD

Saved on

compared with

New Version 9

changes.mady.by.user KrupeshD

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

Align

Dbvisit Standby considerations with RAC

Please see 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 :(2 Nodes)

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

Example :(3 Nodes)

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

On racnode2 the dbv_RACDB2.env will contain:
RAC_TAKEOVER_SID=RACDB3

On racnode3 the dbv_RACDB3.env will contain:
RAC_TAKEOVER_SID=RACDB1

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.

Specific RAC settings

The following settings are specific to RAC

INSTANCE_CLAUSE_FOR_ARCHIVE_LOG_CURRENT
This affects the log switch behavior to change the alter the logswitch command in RAC from "alter system archive log" to "alter system archive log instance INSTANCE_NAME". This has the affect that a logswitch is done local to an instance and not database wide.

INSTANCE_CLAUSE_FOR_ARCHIVE_LOG_CURRENT values:
Yes = Log switch will be done local to the instance.
No = Log switch will be done for the whole database (default).