On Premise -> Microsoft Azure

1. Introduction

The purpose of this Deployment guide is to demonstrate the way in which Dbvisit Standby 8.0 software can be used within the Azure Cloud Hosting Space. In this guide, we focus on the Primary being located 'on-premise' and a Standby database hosted in MS Azure Cloud.  In another document, we focus on both the Primary and Standby databases hosted in the Azure Cloud.

A link that document can be found here


2. Initial Setup and Configuration

2.1 Provisioning the Standby Server

Connect to Azure Portal and Select 'Compute' from the options for 'New'

In this guide, we are going to install and configure Dbvisit Standby on Windows so the Azure Virtual Machine will run Windows Server 2016 Datacenter.

Clicking "create" directed us to a wizard with the following Steps.

Step 1  "Basics": configures the name of the VM and adds an 'Admin User', Subscription and Resource Group. License details are also entered here.  Choosing No for the Windows Server License here means the daily cost of the VM increases as the Windows Server License costs are bundled into the daily price for the VM.

There was already resource group 'dbvresgrp' created during a previous VM creation.


Step 2 "Choose Virtual Machine Size".  The size of both VMs in this Guide is DS11 Standard consisting of 2 vCPUs, 14GB Memory and 28GB local SSD.  

Specify the name of a new Virtual network (1) and Network Security Group (2).

The defaults were accepted for step 4 the VM was created. 

Then, 'click' on the VM icon on the taskbar to view.


Connecting to the VM is via Microsoft Remote Desktop.  

Within the dashboard home section, the connect icon downloads the RDP file required to connect.  

 The password can be stored and the connection details adjusted to reflect the machine name instead of just the IP.

In addition to this, clicking on the Redirection option allows a local drive to be mapped to the Machine. This was useful for copying both the Oracle and Dbvisit Standby binaries

The primary server is a Local Oracle Virtualbox Windows 2012 machine running Oracle 12.1.0.2. Dbvisit Standby v8 has already been installed and configured on this machine and a 12c Database is running.

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


Primary Server DetailsStandby Server Details

Name: dbvwin202

Hosted: Oracle Virtualbox Running Locally

vCPUs: 2

OS: Windows 2012

Memory: 3G

Storage: 75G

Version: 12.1.0.2

Edition: Enterprise Edition

Database: LAA

Dbvisit Base: C:\Program Files\Dbvisit

Standby Version: 8.0.14.19191

Name: dbvwin2016DR

Hosted: Microsoft Azure

vCPUs: 2

OS: Windows 2016 Datacenter

Memory: 14G

Storage: 28G

Version: 12.1.0.2

Edition: Enterprise Edition

Database: LAA

Dbvisit Base: C:\Program Files\Dbvisit

Standby Version: 8.0.14.19191

2.2 Preparing the Azure Server


Connect to the server using the Microsoft Remote Desktop details provided earlier and copy then unzip the required binaries for the Oracle and Dbvisit Installations from the local mapped drive.



In-depth details regarding the Oracle Binaries installation are outwith the scope of this guide. However, Oracle 12c binaries were installed under a new user 'oracle'.  



In order for Dbvisit Standby to communicate between the 2 hosts, and to enable access to the GUI frontend, 3 ports need to be made available.  These are 7890 (Dbvnet), 7891 (Dbvagent) and 4433 (dbvserver: GUI). To do this, security rules need to be added to the Network Security Group for the Azure VM. In addition to this, inbound and outbound firewall rules need to be added to both the Primary and Standby servers.

E.g. For the Network Security Group Associated with the DR machine


Configure additional Inbound and Outbound Security rules.  For ease, a range encompassing all 3 ports can be used (as is shown here). But for maximum security create one rule per port. 

Inbound Rules

Outbound rules.

On both Primary window host and standby, windows host add inbound and outbound firewall 'port' rules.  




Once the firewall rules for inbound and outbound connections have been configured, ensure that the oracle user has the 'Log on as a service' Permission and is a member of the groups 'Local Administrators','ORA_DBA' and 'ORA_OraDB12Home1_DBA' (if 12c is used)



2.3 Networking Considerations for On-Premise Primary

The local VirtualBox VM needs to be configured to be 'internet facing'.  To do this, add an additional network adapter of type 'Bridged Adapter' 

Then remove all Static IP settings and allow the machine to choose an IP via DNS.


At this stage, the Azure server 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

Unzip installer following the instructions in the dbvisit installation guide as an admin user (in this guide: user oracle). 

https://dbvisit.atlassian.net/wiki/spaces/DS8QSG/pages/104431667/Installing+Dbvisit+Standby#InstallingDbvisitStandby-5.InstallingDbvisitStandbyonWindows

As the Azure server (dbvwin2016DR) will be the standby server, install all the components.



At the end of the installation, the component configuration will automatically be launched


Dbvnet Summary Configuration.

Dbvagent Summary configuration on the Standby Server

Installation Summary on the Standby Server

As part of the installation of Dbvisit Standby on Windows. The services for each component are created and automatically started (e.g. from DR Server)

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

https://dbvwin2016DR:4433


  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.

C:\app\oracle\dbvisit_arch

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

Create a New Configuration.  Fill out the relevant entries then click 'Submit'


In Standby version 8.0.14 it is possible to enter the license details during the DDC creation, this option was chosen during the creation of this DDC file.

The new configuration, 'AZR' 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, New Database if required and then check there is enough space in the Source and Dest temp locations.

edit the SPFILE parameters, if required, and then check there is enough space in the Source and Dest temp locations.


Click 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


https://dbvisit.atlassian.net/wiki/display/DS8QSG/Dbvisit+Standby+Scheduling

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 2 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 normal.

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 whilst 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


3.5.5 Monitor the Activity



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