Versions Compared

Old Version 2

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

...

Dbvisit Standby needs to be installed on all the Primary nodes, the same as above, once this is complete, also install Dbvisit Standby on the Standby server following the exact same steps. 

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, dbvlin101 dbvrlin301 is the a primary server and dbvlin102 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:

...

Test 1: Basic Status Check

Code Block
languagetext
oracle@dbvlin101oracle@dbvrlin301[/usr/dbvisit/dbvnet]: ./dbvnet-test -s dbvlin102dbvrlin305:7890

>>> Determining Dbvnet status on server dbvlin102dbvrlin305:7890...


    Dbvnet on server dbvlin102dbvrlin305:7890 is running.

 

Test 2: Full Test - 10MB file is copied (and verified) between primary and standby

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


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


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


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


  > Retrieving file "dbvnet-test.tmp" from server dbvlin102dbvrlin305: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.

...

Dbvnet can be stopped and started using the dbvnetd executable located in the dbvnet sub directory (example - /usr/dbvisit/dbvnet).  Below is an example of stopping and starting the Dbvnet background processes:

Code Block
languagetext
oracle@dbvlin101oracle@dbvrlin301[/usr/dbvisit/dbvnet]: ./dbvnetd stop
oracle@dbvlin101oracle@dbvrlin301[/usr/dbvisit/dbvnet]: ps -ef|grep dbvnet
oracle   12641 12446  0 09:20 pts/1    00:00:00 grep dbvnet
oracle@dbvlin101oracle@dbvrlin301[/usr/dbvisit/dbvnet]: ./dbvnetd start
oracle@dbvlin101oracle@dbvrlin301[/usr/dbvisit/dbvnet]: ps -ef|grep dbvnet
oracle   12643     1  0 09:20 pts/1    00:00:00 ./dbvnetd start
oracle   12644 12643  0 09:20 pts/1    00:00:00 ./dbvnetd start
oracle   12645 12643  0 09:20 pts/1    00:00:00 ./dbvnetd start
oracle   12646 12643  0 09:20 pts/1    00:00:00 ./dbvnetd start
oracle   12647 12643  0 09:20 pts/1    00:00:00 ./dbvnetd start
oracle   12649 12446  0 09:20 pts/1    00:00:00 grep dbvnet
oracle@dbvlin101[/usr/dbvisit/dbvnet]:

 

You should run the above tests from both the primary and run the above tests from all primary nodes in the RAC configuration as well as the standby servers to ensure communication between primary and standby servers can be established.  Once this is done you can continue to the next step which is the creation of a Dbvisit Standby Database Configuration (DDC) file.

...

To access this interface you can use http or https and the specified port you specified during installation.  The default is https with port 8443 and you should be able to connect to the web based frontend using the following url: https://yourservername:8443 

 

Example below is connecting to the GUI on dbvlin101 (172.16.1.111) using https and port 8443.  

When asked for a username and password you need to provide the username and password specified during installation.

 

Image Removed

 

Summary

If you followed the above steps you should now have Dbvisit Standby installed on both your primary and standby servers.  

You are now ready to move on to the next step which is to configure Dbvisit Standby.yourservername:8443 

 

Example below is connecting to the GUI on dbvrlin301 (172.16.1.131) using https and port 8443.  

When asked for a username and password you need to provide the username and password specified during installation.

 

Image Added

Summary

If you followed the above steps you should now have Dbvisit Standby installed on both your primary and standby servers.  

 

You are now ready to move on to the next step, which is to configure Dbvisit Standby by creating Dbvisit Standby Configuration (DDC) files on the primary nodes 

 

Note
titleImportant

DDC files should be created on the primary nodes - this is where the master copy of the DDC files are located and maintained.  

A copy of the DDC file will be transferred and maintained on the standby server by Dbvisit Standby.  

You should not manually create or modify the DDC file on the standby server.  

All DDC creation and changes should be made from the primary servers.