Microsoft Azure -> Microsoft Azure

1. Introduction

The purpose of this Deployment guide is to demonstrate the way in which Dbvisit Standby software can be used within the Azure Cloud Hosting Space. In this guide, we focus on both the Primary and Standby databases being hosted on MS Azure Windows 2016 Virtual Machines.  In another document, we focus on 'On-Premise Primary' to Standby in the Azure Cloud. A link that document can be found here

2. Initial Setup and Configuration

2.1 Provisioning the Servers

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 both Virtual Machines will be 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 and the VM was created. This process was then repeated for the 2nd VM.  

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


Connecting to each of the VM is via Microsoft Remote Desktop.  

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


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

In addition to the 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

Summary Details of the 2 VMs  are as follows :


Primary Server DetailsStandby Server Details

Name: dbvwin2016

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

Name: dbvwin2016DR

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 Servers 

Connect to each of the servers using the Microsoft Remote Desktop details provided earlier and copy and 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 and a database running ARCHIVELOG mode pre-created under the new dbvisit user.  



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 each Network Security Group for each node and, also inbound and outbound firewall rules need to be added to the VMs themselves.

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.

Perform the same task on each server.

In addition to this, add inbound and outbound firewall 'port' rules to the servers themselves.





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)




At this stage, the servers are 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

On the primary server (dbvwin2016) install the core components, leaving the box for the central console (Dbvserver) unchecked. 




Once the correct username and password have been entered and verified the binaries will be installed.

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

e.g. Dbvnet on the Primary Server

Dbvagent on the Primary Server

Installation Summary


Repeat the steps on the Standby Server this time also opting to install the Central Console


Dbvnet Configuration on the Standby Server.


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

Each of the VMs was created using the same Virtual Network, therefore each host is already resolvable from the other using their machine name.


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'


The configuration 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, edit the SPFILE parameters if required and then check there is enough space in the Source and Dest temp locations.

Click Submit.  The progress can be monitored from the resulting icon in the status bar.

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.