On Premise -> Amazon AWS EC2

1. Introduction

The purpose of this Deployment guide is to demonstrate the way in which Dbvisit Standby software can be installed on an Amazon AWS EC2 instance. In this guide, we focus on the Primary being located 'on-premise' and a Standby database hosted in AWS.  In another document, we focus on both the Primary and Standby databases hosted in AWS.

A link that document can be found here

2. Initial Setup and Configuration

2.1 Provisioning the Standby Server

Connect to AWS EC2 Dashboard and Select 'Launch Instance' 

In this guide we are going to install and configure Dbvisit Standby on Oracle Linux, choosing the AMI (ami-0d25886d) from the Community AMIs. This is Step 1 in the launch instance wizard.

Click select.

Step 2  "Choose an Instance Type": The allows you to select from a range of Amazon Instance Types.  The "learn more" link directs you to more information about the instance types and how they might suit your computing needs.  For the purpose of this guide only, we have chosen t2.small.

Step 3: Configure the Instance Details.  Here we choose the defaults,

Step 4 "Add Storage".  We also accept the defaults here as a 30GB disk is more than enough for the demo purposes.

Step 5 "Add Tags".  Create a Tag with Key = "Name" and Value = "dbvaws01"

Step 6 "Configure Security Group".  Here, we've chosen an existing security group with ports 22 (SSH), 4433 (dbvserver), 7890 (dbvnet) and 7891 (dbvagent) enabled within the INBOUND security rules.

The final step is to review and Launch the new instance making sure that if the 'Choose an existing key pair' option is selected that the .pem file is accessible by yourself.

I have access to the dbvAWS.pem file so I clicked the tick box and then proceeded with "Launch Instance"

Once the launch is initiated, the running instance can be viewed from within the EC2 dashboard, Instances submenu

The 'primary' server in this guide is an Oracle Virtualbox VM running locally.  The network is configured to have two adapters, one bridged and one host only. For it to be internet facing, the dbvisit dbvnet and dbvagent processes must listen on the IP that is visible from the router. This means, when the request to the externally facing (office) IP address on one of the dbvisit ports comes in, the router is able to forward this to the VM.

The machine name is dbvlab01 and the Ipv4 Public IP of the AWS instance dbvaws01 has been added to the local host's file.

On the AWS server dbvaws01, the IP address of our office router has been added to the /etc/hosts file, so that a ping of server dbvlab01 resolves to this address which in turn finds the VM via the bridged network adaptor.  This has not been added to the guide for apparent reasons.

An overview of both Primary and Standby machines is shown in the table below.

Primary Server DetailsStandby Server Details

Name: dbvlab01

Hosted: Oracle Virtualbox Running Locally

vCPUs : 2

OS: Oracle linux EL6

Memory : 3G

Storage : 60G


Edition: Enterprise Edition

Database : XE

Dbvisit Base: /usr/dbvisit/standby

Standby Version: 8.0.20

Name: dbvaws01

Hosted: Amazon AWS EC2

vCPUs : 1

OS: Oracle Linux EL7

Memory : 2G

Storage : 30G


Edition: Enterprise Edition

Database : XE

Dbvisit Base: /usr/dbvisit/standby

Standby Version: 8.0.20

2.2 Preparing the AWS Standby Instance: dbvaws01

Connect to the server with key pair specified on creation (dbvAWS) as the ec2-user and 'sudo su -' to the root user.  As the root user, prepare the directory that will be the Dbvisit Standby Base.

The latest version of the Dbvisit Standby software has already been downloaded locally.  As the ec2-user, scp this to the instance, then as root change the ownership and unpack the installation files.

Now the AWS instance is ready for the next stage of installing the Dbvisit Standby software.

3. Install, Configure and Run the Standby software

3.1 Installing and Configuring the Software

This server, dbvaws01, will be the standby server to install all the components.  Here is the link to the full installation guide. It is summarised below. Navigate to where the unpacked files are

Accept the defaults for the dbvnet configuration and choose dbvlab01 as the remote host.

Dbvnet Summary Configuration.

Dbvagent Summary configuration on the Standby Server

Once the core components are installed, continue with another install of the Dbvserver component.

If necessary add the IP address for the dbvaws01 server to its own /etc/hosts

Dbvserver Summary configuration.

The final summary should show all the components installed, and at this stage, the installer can be exited.

The same installation has already been performed on the on-premise host, dbvlab01. The only difference is that there is no dbvserver to configure on this host.

In the /home/oracle directory of each server two scripts (dbv_start and dbv_stop) were created to start and stop the dbv* processes quickly.  The dbv_start is shown below, dbv_stop is similar just with the stop command instead of start.

To test that the connectivity is working from on-premise to the standby machine, try to telnet on each of the dbvisit ports (7891, 7890 and 4433). e.g. on the dbvagent port 7891 

Similarly, we can test the opposite direction, from cloud to on-prem.

3.2 Start the GUI and Create the DDC

Download and install either Chrome or Firefox.
From within the browser navigate to the https://<dbvserver_host>:4433. In this case, the standby node



Click 'Advanced' and add the security exception to proceed to the login screen

Enter the default username/password of admin/admin and proceed to the first screen, manage hosts.

Enter each of the hosts in turn, specifying the passphrase used at creation time. 

Return to the Main Menu and then proceed on to creating the DDC

The creation of the DDC file is shown in the following steps.  

Firstly Create a directory for ARCHSOURCE and ARCHDEST parameters.  

The former is only required in the event of a Graceful switchover when the Primary becomes a Standby database.  In this example, the same location is created on each server.

To create a DDC from the GUI. Choose the Manage Configurations Tab

Create a New Configuration.  Fill out the relevant entries then click 'Submit'  Careful to select the correct value for ORACLE_HOME on the remote host if the installation location differs as it does here.

The new configuration, 'XE' can be viewed and edited from the 'Manage Configurations' Tab.

3.3 Create the Standby Database

3.3.1 Creating the Standby with the GUI

Choose the Create Standby Database Tab from the Home Screen.

Select your configuration

Select New Database

Then check there is enough space in the Source and Dest temp locations before proceeding to Submit.

Click on the Create Standby Task to view the progress

The task has completed when a small green 'tick' appears on the task icon.

3.3.2 Creating the Standby with the CLI

To Create the Standby database with the command line is shown below

3.4 Performing Basic Tasks

Some examples of basic tasks are outlined below.  Please refer to the online documentation for more details on each command.  

3.4.1 Log Gap Report

Run a log gap report from the Primary Site

Also from the GUI

3.4.2 Log Transfer

Sending the logs from the Primary via the CLI

Apply Logs at the Standby Site via the GUI

3.4.3 Daemon Status

Start the Daemons for automatic send/apply from the GUI Database Actions Tab. 

The lightning bolt icon manages the daemon processes.

When started on both sites they Log gap managed automatically and if no natural log switches have occurred, the daemon will also signal a log switch to keep the standby LAG to the desired amount. More information regarding the daemon settings can be found here in Section 4


3.4.4 Starting Standby Database in Readonly Mode

From the Database Actions Tab choose the Database Icon.  This allows the user to perform database actions on each node.

Before the Standby Database can be opened in readonly mode, there must be a log gap of 0 between the two systems.

Select the Standby Host, review the current status and Select Start READ ONLY.

Now, the status is Read Only for the standby database.

To switch back again.  Choose Restart

Now the Standby is back in recovery mode, and the logs can be applied as usual.

3.5 Performing Graceful Switchover

The following screenshots show a Graceful Switchover from one Cloud Standby to the other using the GUI.  A first pre-requisite is to ensure that the daemons started earlier are not running while the switchover is in progress.

3.5.1 Check the Status of the Daemons

If the daemons have been started in the previous step, they need to be stopped before performing a graceful switchover.

3.5.2 Graceful Switchover Icon GUI

3.5.3 Check Log Gap is Zero and Click Submit

3.5.4 Locate the Task on the Task Bar and Monitor the Activity

Verify the Switch of hosts in the Configurations tab.

3.5.5 Verify the New Roles within each of the Databases

Verify the new database roles within the database

3.6 Activate the Standby Database

It is possible to activate the Standby Database and make it become the new Primary.  This is also called failover to the standby database.

The assumption is that the original Primary site has been lost and needs to be rebuilt.  

From the Central Console/GUI Choose the "Activate Standby Database Command."

3.6.1 Choose the Activate Standby Database

3.6.2 Select the Configuration

3.6.3 Monitor the Task from The Task Bar

3.6.4 Verify the Status within the Database

3.6.5 Manage Configurations Tab Implications

Now the Manage Configurations Tab has the option to choose the hosts. This allows you to either accept the current configuration with the new Primary (old Standby site) or start again with the original Primary site and depends on the circumstances of the Activation.