Dbvisit Standby’s new Network Layer is one of the exciting features that was introduced in version 7. This has been improved further in version 8 and 9.
Dbvnet’s functionality removes the dependency earlier Dbvisit Standby versions had on SSH for providing network communication between the primary and standby nodes. By making use of Dbvnet, no additional SSH software is required to be installed, configured or maintained on Windows.
When using UNIX based systems, Dbvisit Standby can now be configured to make use of the new Dbvnet (default option). If required, SSH is still fully supported by Dbvisit Standby and can be configured and used on Unix based systems only. Password-less SSH authentication must be enabled between the primary and standby nodes if using Dbvisit Standby with SSH as the communication layer.
Dbvnet is started as a background process and is run independently from the already known GUI (Dbvserver) or Dbvisit Agent (dbvagent) processes.
Dbvnet provides the following key features:
- Independence of SSH-based client/server network communication
- Secure network communication
Dbvnet is located in the DBVISIT_BASE directory under the dbvnet sub-directory. Example Dbvisit Standby directory structure below:
2. The Dbvnet Command Line Options
2.1. Obtain quick help options
To show the Dbvnet full help from the command line you can specify the -h or --help command line option.
-h [ --help ] This message
2.2. Start or Stopping Dbvnet
Dbvnet runs as a background process. To start and stop dbvnet use the "-d" flag with either start, stop or status keywords.
Dbvnet daemon process control:
start : this will start the dbvnet daemon process on Unix;
stop : the stop command will terminate the dbvnet daemon process;
status : the status command will provide the state of the dbvnet daemon process;
killpid: removes the pid-file of the dbvnet daemon process.
2.3. The Dbvnet Configuration File
The configuration file can be specified with the -c flag. However, it is not required, as the default configuration file located in the "DBVISIT_BASE/dbvnet/conf" directory will be used.
It is possible to specify a custom configuration file if required using the -c flag. This might be useful to connect to different dbvnet servers using different configurations.
-c [ --config ] arg [-c config_file] It is optional to specify configuration file if one is not present in the default location. The default configuration file is located in DBVISIT_BASE/dbvnet/conf sub directory The default configuration file is called dbvnet.conf Example: -c /usr/dbvisit/dbvnet/conf/dbvnet.conf
2.4. The Dbvnet Port
The default port used by Dbvnet is 7890. It is possible to change this or to run different dbvnet configurations on the same server. This will require you to either specify different configuration files that have different specified settings, or you can specify the required options on the command line using the command line options. To specify the Dbvnet port from the command line, use the "-p" flag followed by the port number.
In this case, if the port being specified is used with the start command, this will be the port to listen on. If you are performing a remote execution or copy of a file, the port specified will be the one used to connect to the remote server.
-p [ --port ] arg [-p remote_port] This is optional as the remote server port can be specified in the Dbvnet configuration file which is the recommended approach. This parameter can be set to overwrite the configuration file
2.5. Executing a Remote Command
Dbvnet can perform two key functions:
- The execution of a remote command
- Copy of a file from current to the remote server
Dbvnet must be running on the remote server
Starting with Dbvisit Standby version 9.0.10 dbvnet parameters remote_address and remote_port are no longer present in dbvnet configuration file. You have to specify each time remote server address and remote server port when you run manually dbvnet command (with -e switch) or manually try to copy file (-f switch)
./dbvnet -e "uname -n" -a kiwi81 -p 7890
If you configured the [local] and [remote] sections in the dbvnet.conf file, you would have listed the local server (also referred to as the client) and the remote system (also referred to as the remote dbvnet server). You can easily execute remote commands by using the "-e" flag.
The argument following the "-e" flag must be enclosed in double quotes (to cater for spaces or arguments that might be part of the remote command to be executed).
-e [ --command ] arg [-e remote_command] This is one of the key options. To execute a remote command, you can specify the command with the -e flag. It is important that you specify the full path of the command to execute. Example if you want to execute "uname -a" command on the remote server, you have to specify the full path to the uname executable. Example: -e "/bin/uname -a"
2.6. Remote Copy of Files
As mentioned above, Dbvnet has two core functions, to execute remote commands and to allow files to be copied between the primary and standby servers.
This file copy is done by making use of two flags "-f" and "-o". The first flag "-f" specifies the local file to be copied to the remote server. The "-o" flag is used to specify the file location and name on the remote server.
-f [ --file ] arg [-f file] This is optional as the file to be transferred -o [ --output ] arg [-o file] This is optional as the file name on server side to be transferred
2.7. Dbvnet Command Summary
When running Dbvnet without any parameters or with the "-h" flag, you will be displayed with a full usage (help), example:
3. The Dbvnet Configuration
Dbvnet does not have a large number of configuration options. In this section, we will cover the configuration file and the parameters you should be familiar with.
IMPORTANT: The only parameters that should require change is:
The passphrase is used to establish a secure encrypted connection between the source and target
The listener address is the local address on which the dbvnet server will listen
The listener port is by default 7890 and is the TCP port dbvnet will be listening on for incoming connections
The remote address is optional and can be the same as the local - but using the remote (target) systems address (hostname) here is recommended
The remote port is the remote systems dbvnet port
Other parameters should not be modified unless instructed by Dbvisit Support.
Example Configuration File:
4. Start and Stop Dbvnet (Server)
Dbvnet can be stopped and started using the dbvnet executable located in the dbvnet subdirectory (example - /usr/dbvisit/dbvnet) when using Linux (Unix) based systems and when using Windows-based systems using the Windows Services to stop and start the "Dbvnet" service.
4.1. Linux (UNIX)
Below is an example of stopping and starting the Dbvnet background processes on Linux (Unix).
Once the Dbvnet background processes are started, you will notice 1 process running (in earlier versions of Dbvnet there used to be more than one process running by default)
Starting and stopping Dbvnet on Windows-based systems is done via the Windows Services.
Below is an example showing the Windows service details for the Dbvnet Service. From here you can stop/start dbvnet.
It is recommended that this process be left with "Startup Type" as "Automatic"
5. 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.
5.1. Test 1: Performing a Basic Status Check
The first check is to run a remote command. This can be done by using the "-e" flag when running dbvnet.
It is important to note that before you can run this command, you should have the client and server configuration settings in the dbvnet.conf file.
From the above test, you can see that Dbvnet was able to successfully establish a connection between server dbvlin101 and dbvlin102.
5.2. Test 2: Copy a file between primary and standby
Before you start the Create Standby Database process: Run the above tests from both the primary and standby servers to ensure communication between primary and standby servers can be established after a new installation.
Once this is done you can continue to the next step, the creation of a Dbvisit Standby Database Configuration (DDC) file.
5.3. Test 3: Test using "system readiness" function
When installing Dbvisit Standby, it is important that once the installation on the Primary and the Standby servers are complete and all required processes are started (Dbvnet, Dbvagent and Dbvserver) that we then test the network connectivity between the primary and standby.
This process can help confirm that network communication is working before you continue creating DDC files or if upgrading - performing the DDC file upgrade.
The command to test connectivity is: dbvctl -f system_readiness
A series of questions will be asked, for example, the remote server name. We recommend you run this command on the primary as well as the standby to ensure network connectivity is working prior to continuing with creating or upgrading DDC files.
Below is an example using the "system readiness" function:
6. The Dbvnet Passphrase
It is important that the same password is used on both the primary and standby dbvnet configurations.
7. Troubleshooting Dbvnet
The default port used for Dbvnet is 7890, it is important to make sure this port is open on both primary and standby servers. Ensure there is no firewall in between these systems blocking this port.
To review if Dbvnet is running and listening on port 7890 the "netstat" utility can be used. This option is available on both Linux (UNIX) based systems as well as Windows.
7.1. Reviewing the Dbvnet Port - Linux
The netstat and lsof commands can be used to identify if Dbvnet is running and/or what is using port 7890.
The examples below show how you can use these two commands to identify if port 7890 is in use and what is listening/using this port:
From the above, we can see that something is listening on port 7890. This is a good indication of if Dbvnet is already running. If you see the above but Dbvnet is not running, that indicates something else might be using port 7890.
To further investigate what is using port 7890, you can make use of the "lsof" command. This command must be executed as the "root" user. Using the lsof command with the parameter "-i" with the port number 7890 we can see what application is using this port. From the command below we can see that Dbvnet is indeed the process listening on this port.
Another test you can perform to make sure there is no firewall blocking the two systems is the "nc" (netcat) utility and the well known "telnet" utility.
Example 1 using netcat "nc": nc -vtz <remote_ip_address> <dbvnet_port
Example 2 using telnet: telnet <remote_ip_address> <dbvnet_port>
Note - the key line is line 3 -> "Connected to..."
When using Amazon AWS EC2, make sure you have the dbvnet port 7890 open in your Security Groups in use.
Also, make sure you review your local Linux firewall (IPtables)
Dbvnet can listen on local ports, but if there is a firewall in between blocking the port 7890, Dbvnet will not be able to communicate between the two servers.
7.2. Reviewing the Dbvnet Port - Windows
Using the netstat and tasklist commands you can find out if Dbvnet is running, or identify what is using port 7890.
In the example below, Dbvnet is running on both Primary and Standby using port 7890. The commands netstat and task list are used to show that Dbvnet is listening on port 7890.
From the above, we can see that something is listening on port 7890 and that a connection was established to this port.
Using the process ID shown in the last column (2396 in this example) we can use the tasklist command to identify the process using port 7890
7.3. Testing Network Bandwidth
This section will cover the steps using the "iperf" utility to test network bandwidth and connectivity between the primary and standby servers.
The iperf utility can be downloaded from here - https://iperf.fr/. For more detail on the usage of this utility, please see the website.
The use of this utility is highlighted in the documentation here as it can help you troubleshoot network connectivity and bandwidth problems.
The iperf utility is not part of Dbvisit Standby. This is an external 3rd party product which you can use to test network connectivity between two servers.
Using this utility is recommended on Test systems.
Start iPerf on the one system as a server - use the -s switch - using a specific port with the -p switch. Example to run a test on port 7890 (make sure dbvnet is stopped).
The command on Server A would be: iperf3.exe -s -i 1 -p 7891
Example on Server A:
It will wait here and appear to hang. Now start on the second server (remote server) a client connection (using the -c switch) and transfer example 100MB of data (using the -n <size> switch). Make sure you specify the same port as you did on server A which is set with the -p <port> switch.
The command to be executed on server B to transfer data to server A is: iperf3 -n 100M -i 1 -c serverA -p 7891
As soon as you start the command on the "client" server (which is server B in this case), you will see output appearing on both Server A and Server B. Once complete, you can review and analyze the output.
There are a number of options available in the iperf utility. It might be good to also test with larger files, example 1024M and monitor.
Example Server B Output (Client):
Example Server A Output:
The output provided by the iperf utility can help you establish the bandwidth of your network link during a specific port.
This can be useful to test when you have an environment where packet shaping is happening on certain ports.
8. Using XCOPY
This option is only available from 7.0.38. However, using Dbvnet is recommended.
On Windows (Recommended 2008 R2 and above) you can enable the use of "xcopy" for the shipping of archive logs.
This option is only used for the transfer of archive logs from the primary to standby during normal operation.
All other operations will still use Dbvnet.
To enable this option, set the following values in the primary DDC file where DEST_SHARE. This is the share location on the standby server where the archive logs are copied to (same location as the Dbvisit ARCHDEST).
For example: If the ARCHDEST is e:\dbvisit_archdest\testdb, and the share location is created as "dbvisit_testdb" and points at this directory, you will use \\server_name\dbvisit_testdb as the parameter.
If for instance, DEST_SHARE location is different from the ARCHDEST location, ARCHDEST needs to be adjusted in the DDC file to be pointing to the DEST_SHARE location. This way, applying of logs on the standby will not fail.
Note: It is important to make sure the user running Dbvisit Standby has access to this share on the standby server.
If a Graceful Switchover is performed, this value must be updated in the new primary.
9. Using SSH (UNIX Only)
When using Dbvisit Standby version 9 on Unix based systems, you can also configure the use of SSH instead of using Dbvnet.
On Windows-based systems, Dbvnet is the only option when using Dbvisit Standby version 9.
The key requirement for using SSH is to ensure SSH user equivalence between the primary and standby servers.
IMPORTANT: If you have Oracle RAC configured:
If you already have Oracle RAC configured, you will already have SSH equivalence between the RAC nodes - this is one of the pre-requisites when using Oracle RAC. In this case, you do not have to re-generate any SSH keys on the RAC nodes as they would already have them configured. The requirement is to make sure you can ssh between the primary and standby servers without passwords. So, in this case, you then have to extend the ssh equivalence not just between the RAC nodes, but also between the primary and standby (where both the primary and standby could potentially be RAC).
If you need to create new keys and configure SSH equivalence between the nodes, the following can be used as a guideline to do this:
If using Oracle Linux 5 and above or RHEL 5 and above you can easily make use of the following commands:
To Generate the required keys:
To Update the remote server's authorized keys file:
For example, if you have two servers Primary Node and Standby Node and are using the "oracle" Unix account you can follow these steps to enable SSH User Equivalence:
On primary node as the oracle Unix account:
ssh-keygencommand and press enter, accepting null values when asked for a pass-phrase (do not supply a pass-phrase). The required DSA keys will be created in the
ssh-copy-idcommand to update the local and remote authorized_keys files:
On StandbyNode as the oracle Unix account:
ssh-keygencommand and press enter. Accept null values when asked for a pass-phrase (do not supply a pass-phrase). The required DSA keys will be created in
ssh-copy-idcommand to update the local and remote
Following the above steps, you should now be able to SSH between the primary and standby servers without being asked for a password. For example, running the following you should not be asked for any passwords and should just echo back the date from the remote server:
On Standby Node:
If you do not have the option to use the
ssh-copy-id command you can update the
authorized_keys file manually. Detailed steps to perform this are explained in the Dbvisit Standby v7 User Guide here:
9.1. Dbvisit Standby Required Changes to Enable the Use of SSH
Once you have SSH user equivalence configured, you can now update the following values in the Dbvisit Standby DDC file on the primary server:
9.2. If using SSH Banner
If you are using an SSH banner, this can effect the use of SSH for Dbvisit Standby.
You need to review the banner size (lines) and you can specify: SSH_SKIP_OUTPUT_LINES in the Dbvisit Standby DDC file to tell Dbvisit Standby to ignore these lines.
Example if the SSH Banner looks like this one below, we can see 3 lines are used:
To tell Dbvisit Standby to ignore this banner, set the following value in the DDC file:
- Set the
DBVNET_PORTto a null (empty) value.
- Ensure that the
SSH_PORTis specified (default is 22).
- Set the CP variable to the full path of the
scpcommand. In most cases this will be
- Set the RSH variable to the full path of the ssh command. In most cases this will be
You should now be able to run Dbvisit Standby as normal and it will make use of SSH instead of Dbvnet