The examples provided are of Dbvisit Standby Version 8.0.x, there should not be any changes on how this is being implemented in Dbvisit Standby Version 10
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
- 1. Introduction
- 2. Initial Setup and Configuration
- 3. Install, Configure and Run the Standby software
- 3.1 Installing and Configuring the Software
- 3.2 Start the GUI and Create the DDC
- 3.3 Create the Standby Database
- 3.4 Performing Basic Tasks
- 3.5 Performing Graceful Switchover
- 3.6 Activate the Standby Database
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.
In the User Name box, 'Oracle' was entered. However, further on into the installation it was realised that choosing a more generic name such as dbvisit (admin is a reserved word and not allowed) would have made more sense. Creating a Windows VM meant that the Oracle binaries needed also to be installed (unlike when you chose an Oracle pre-built VM in Azure where the platform is Linux and the binaries are pre-installed). The installation of the Oracle binaries insisted that the installing user not be an administrator and suggested to create a new user. Therefore it was not possible to use the oracle user to install the binaries and instead user dbvisit was created. This, in turn, meant the $ORACLE_HOME didn't have 'oracle' in the directory_path. (A minor annoyance, but still worth a mention to think about the users before creating the VMs)
It was decided to keep this in the guide as an information point.
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.
Throughout this guide, no mention is made about the licensing implications of running Oracle software on Microsoft Azure. The setup we have here has been built for demonstration purposes and falls within the scope of the Microsoft Azure 'free-trial'. Further information regarding Oracle Licenses in the cloud can be found here. Also Licensing Oracle Software in the Cloud Computing Environment.
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 Details
|Standby Server Details
OS: Windows 2016 Datacenter
Edition: Enterprise Edition
Dbvisit Base: C:\Program Files\Dbvisit
Standby Version: 184.108.40.20691
OS: Windows 2016 Datacenter
Edition: Enterprise Edition
Dbvisit Base: C:\Program Files\Dbvisit
Standby Version: 220.127.116.1191
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.
One other point to note. It was found to be easier to pre-create the user for the Oracle install rather than choose this option as part of the binary installation. The reason for this, when the user is created as a windows administrator, the password policy is adhered to. However, when a password is chosen as part of the binary installation unless you are confident the password adheres to the correct security policy no check is made until the create user step is reached. If the password doesn't fit the security standards, the installation fails and exits.
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.
Perform the same task on each server.
In addition to this, add inbound and outbound firewall 'port' rules to the servers themselves.
When using 'New Rule Wizard', note that the default 'Action' for the outbound rule is 'Block the connection'. This needs to be set to 'Allow the connection' which is the default action for a new 'Inbound Rule'
Windows 2016 Datacenter runs IPv6 by default. This must be disabled as the final step to allowing connections between the servers.
Begin by 'un-checking' the IPv6 and then select the 'properties' of IPv4, then 'Advanced' and Enter an 'Interface metric'
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)
For further information regarding the pre-requisites for installing Dbvisit Standby v8 can be found here.
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).
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
Repeat the steps on the Standby Server this time also opting to install the Central Console
Dbvnet Configuration on the Standby Server.
The dbvagent installation on the standby server is not shown as the defaults were accepted.
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)
Since version 8.0.20 Dbvisit Standby has a new parameter DBVSERVER_PUBLIC_HOST (parameter public_address in dbvserver.conf)
Rather than accepting the default hostname prompt here, the public-facing IPv4 address Cloud Host should be used. Public-facing IPv4 address that will be supplied to the Agents (Dbvagent) to be used for pushing information back to the Central Console. This is the externally resolvable address supplied to dbvagent, not an additional listener address on dbvserver itself.
3.2 Start the GUI and Create the DDC
The following browsers are supported when using the Dbvisit Standby Web Based interface (latest versions recommended)
Future support for the following browsers are planned:
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.
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.
If either of the Host Names displays an x here, then check the firewall rules, the IPv6 settings, and the network security group rules for each server.
A useful test is to use telnet on the Dbvisit agent port to check connectivity
If a blank screen is returned then the port is open and available
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'
We've opted not to show the DDC file creation from this installation due to the binaries being installed under a user that wasn't Oracle and don't want to add misdirection to the worked example. Instead, refer to the userguide section on creating the DDC.
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
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.