Versions Compared

Old Version 6

changes.mady.by.user Anton Els (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Miroslav Sivon (Deactivated)

Saved on

Key

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

Table of Contents

Dbvisit Standby version 7 is making use of a new directory structure in comparison to the previous version 5 and 6.  The default location on Linux for version 5 and 6 was /usr/local/dbvisit but in version 7 the default location changed to /usr/dbvisit.  You can however still install version 7 into any other custom location, example /opt/dbvisit.  It is recommended not to install Dbvisit Standby in the home directory of the oracle Unix account (/home/oracle).

...

Note

When installing Dbvisit Standby in a Oracle RAC environment Oracle Grid Infrastructure version 11.1 and higher is recommended.

Using version 10.2 for ASM storage is not recommended and will limit the functionality of Dbvisit Standby - Graceful Switchover will not be possible.

 

Dbvisit Standby will be installed on all the servers in an Oracle RAC configuration.  For example if you are using a four node cluster, you need to install Dbvisit Standby on all four nodes as well as on the Standby server(s).

...

Note

Before you continue with the next step you need to make sure you follow Step 1 to 5 above on all the servers in the standby configuration.  When doing this, it is important to make sure the Dbvnet password provided during installation is the same on all the servers where you are installing Dbvnet.  This password is used for secure communication and if different passwords are used between the primary and standby servers, you will not be able to establish a connection between these servers using Dbvnet.

Step 6:  Testing Dbvnet Communication

...

Align

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:

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.


Step 6:  Testing Dbvnet Communication

Once you have Dbvisit Standby installed on all the servers, it is important to make sure that the communication between the Primary and Standby servers are working.  This can be done by making use of the Dbvnet Test utility provided with the Dbvisit Standby installation - dbvnet-test, which is located under the dbvnet sub directory.  When using the default path this utility will be in /usr/dbvisit/dbvnet/dbvnet-test

...

  1. To perform a basic status check which confirms that the primary and standby server can communicate using Dbvnet:
    • dbvnet-test [-s|--status] SERVER[:PORT]
  2. To perform a more detail check, testing network connectivity, you can run the following:
    • dbvnet-test [-f|--fulltest] SERVER–fulltest] TMPDIR SERVER:PORT

 

In the example below, dbvrlin301 is a primary server and dbvrlin305 is the single instance standby server.  Dbvisit Standby was installed using default values and no additional configuration has been performed at this stage.  Dbvnet and Dbvserver is running on both nodes, but only Dbvnet is required and used for these tests:

...

Code Block
languagetext
oracle@dbvrlin301[/usr/dbvisit/dbvnet]: ./dbvnet-test -f /tmp dbvrlin305:7890


>>> Determining Dbvnet status on server dbvrlin305:7890...
    Dbvnet on server dbvrlin305:7890 is running.


>>> Running file transfer round trip on server dbvrlin305:7890...
    Creating file '/tmp/dbvnet-test.tmp' containing 10 MB of data... - done.


  > Transferring 'dbvnet-test.tmp' to server dbvrlin305:7890
    Progress: 0%...20%...40%...60%...80%...100% [2609 KB/s] - done.


  > Retrieving file "dbvnet-test.tmp" from server dbvrlin305:7890
    Progress: 0%...20%...40%...60%...80%...100% [4599 KB/s] - done.


    Comparing checksums: all three checksums (local/remote/local) are identical. File
    transfer round trip finished successfully.

...