Support for Oracle Cloud

Dbvisit Standby works with Oracle Cloud.

Dbvisit Standby can be used with the Oracle Database Cloud - Database as a Service - with either the pre-installed or the Virtual Image options. 
This can be on-premise to cloud, cloud to cloud, or cloud back to on-premise configurations.

In this article we will set up a Dbvisit Standby configuration entirely within the Oracle Cloud. That is, both the primary and standby databases running within this cloud environment.

Before getting into the example, it is worth pointing out that the Standard Edition option in the Oracle Cloud does not offer any DR type functionality. The Oracle “native” option, Data Guard, is only available with Enterprise Edition, which means that the use case for Dbvisit Standby is the same whether running these databases in the Oracle Cloud or on-premise; to provide DR functionality for Oracle SE customers. The point is that, if you are going to use the SE option in the Oracle Database Cloud Service, you still need to source additional DR protection, this is a fundamental business requirement, and here we can help.

In this example we will create a new Oracle Cloud Database Service, called dbvrep-se-three but, alternatively, you could create the VM alone with the “Oracle Database Cloud Service – Virtual Image” service level option, which comes with the Oracle software installed, but no databases created.

Here you can see details of the newly created dbvrep-se-three service:

Setup connectivity to the new VM:

Because there are a number of tasks I would like to initiate locally, the first thing to do is establish a connection to dbvrep-se-three from my laptop. Here I make use of the SSH keys generated earlier (originally done on the primary server in my configuration, dbvrep-se-two, and copied to my laptop), which were entered as inputs at the service create stage:

Once this is done, I can then SSH to dbvrep-se-three directly, and establish SFTP connectivity, which I find useful. Here you can find additional notes on configuring SSH for use with the Oracle Cloud.

What version of Linux are we running on these provisioned servers? A quick check reveals the following:

[oracle@dbvrep-se-three ~]$ uname -a 
Linux dbvrep-se-three 2.6.39-400.109.1.el6uek.x86_64 #1 SMP Tue Jun 4 23:21:51 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux 
[oracle@dbvrep-se-three ~]$ cat /etc/*-release 
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch 
Oracle Linux Server release 6.4 
Red Hat Enterprise Linux Server release 6.4 (Santiago) 
Oracle Linux Server release 6.4

With a clear view of this, we can now download the most recent version of Dbvisit Standby v7 for the platform (OEL6 in this case) from the Dbvisit website. Once complete, we then upload the file to the server. In the following, I have done so using FileZilla, and putting it to /tmp, but you free to select another location for this as you see fit:

Dbvisit Standby needs to be installed on both servers in our configuration, and so the installation files need to uploaded to both VMs. This is an important point to remember, because we will walk through this only once in the following example.
The installation process is a well documented one in the Dbvisit Standby online user guide – and a good place to begin is the prerequisites checklist.

Following the installation instructions, we need to run the first part of this process as a user with root permissions. Because of this, we need to log onto dbvrep-se-three as the user opc – who is then able to sudo to root – unlike the oracle user whose access is restricted in this respect:

So first, we create a home directory for the installation. I go with the suggested default of /usr/dbvisit, and change ownership of this to the “oracle” user:

Moving then to the /tmp directory, where I uploaded the installation package, we unzip and untar the Dbvisit Standby files:

From here we cd into dbvisit > installer – and chmod the install file, install-dbvisit, itself:

Now that the permissions have been adjusted, we are ready to perform the installation, which is to be done as the oracle user. So, I login accordingly as oracle, kick off the installation process (./install-dbvisit), and accept the defaults presented:

You are, of course, welcome to change these values, but the default options make good sense and are more than acceptable. They are:

Install directory - /usr/dbvisit (should be amended to what you have chosen) 
Default user - oracle 
Dbvnet port - 7890 
Dbvnet password - admin 
Dbvnet start after install - yes 
Dbvserver protocol - https 
Dbvserver https port - 8443 
Dbvserver default user - admin 
Dbvserver default password - admin 
Dbvserver - start after installation - yes

Afterwards the complete log of the installation process will look something like the following:

Thank you. Configuration is complete. Installation will commence now. 
>>> Installing Standby - the Dbvisit disaster recovery software... 
Installing product files... 
Updating and migrating existing DDC files in /usr/dbvisit... 
> Removing old DDC files with appended timestamps 
Updating and migrating existing DDC files in /usr/dbvisit/standby... 
> Removing old DDC files with appended timestamps 
Removing old product files... 
Dbvisit Standby installation complete. 
>>> Installing Dbvnet - the Dbvisit network layer... 
>>> Adjusting init script templates for product dbvnet... 
Please find some init script templates in the following directory: 
/usr/dbvisit/dbvnet/conf/init.d 
These templates will allow your Systems Administrator to automatically start Dbvserver after a database server reboot. 
Templates are available for Sun Solaris, IBM AIX, and the Linux flavours OpenSuSE, RedHat/Centos/Fedora & Debian/Ubuntu. 
>>> Starting Dbvnet daemon, please wait... 
Dbvnet is up and running on the following ip address and port: niop://10.196.243.122:7890 
>>> Installing Dbvserver - the Dbvisit web interface... 
>>> Adjusting init script templates for product dbvserver... 
Please find some init script templates in the following directory: 
/usr/dbvisit/dbvserver/conf/init.d 
These templates will allow your Systems Administrator to automatically start Dbvserver after a database server reboot. 
Templates are available for Sun Solaris, IBM AIX, and the Linux flavours OpenSuSE, RedHat/Centos/Fedora & Debian/Ubuntu. 
>>> Starting Dbvserver daemon, please wait... 
Dbvserver is up and running. Please point your browser to the following URL to log in to the Dbvisit web interface: 
https://10.196.243.122:8443 
Login user name is 'admin' (password 'admin') 
>>> Dbvisit product and component installation is now complete. 
>>> NEXT STEPS: CONFIGURE DBVISIT STANDBY VIA COMMAND LINE INTERFACE (CLI): 
cd /usr/dbvisit/standby 
./dbvisit_setup 
Note: Dbvisit can also be configured and run through a (GUI) web browser. 
Dbvserver (dbvserverd) must be installed and started for this. 
>>> IMPORTANT - PLEASE NOTE THE FOLLOWING REQUIREMENTS BEFORE CONTINUING: 
> The Dbvisit Standby, Dbvnet, and Dbvserver software must be installed on both the primary and standby servers. 
> For network communication between the primary and standby server via Dbvnet port number 7890 must not be blocked by your firewalls. 
> Dbvnet must be up and running on both the primary and standby servers at all times. 
> If you wish to use Dbvserver, the Dbvisit web interface, then please ensure port 8443 is open on your servers' firewalls, as well. 
>>> Thank you for using Dbvisit software!

If working with the defaults, as I have done, once the installer has completed you will be able to see the dbvserver (webserver) and dbvnet (communication channel) processes that have been started:

So, in theory, you should be able to connect to the Dbvisit Standby web based interface once Dbvserver is up and running. Interestingly however, in the install output file a URL for this is provided, but it provides an “internal” IP only accessible with the Oracle Database Cloud in the 10.x range as follows (run ifconfig on the VM to see this):
https://10.196.243.122:8443

You will not be able to connect using this from outside the Oracle Cloud but rather need to substitute it for the external IP which has been provided, and is viewable from the service detail page. In my case, it looks as follows:
https://129.191.2.72:8443

Once this external IP has been identified, we also need to open up ports used by Dbvisit Standby, which are blocked by default, in order to establish a connection. A “brute force” method would be to come into the Security Lists screen, as per below, and modify the Inbound Policy for all ports for this VM to “Permit (Allow packets)”:

A more refined (and more secure!) approach is to look to only open those ports which are really needed (7890, 8081 and 8443), which we will do here. So, under Oracle Compute Cloud Service > Network select the option to “Create Security Application”, provide a logical name for this, TCP type, and open the port for Dbvnet https (8443) or http (8081) if you have selected that:

Then under the Security Rules screen, we can make use of this new Security Application, choosing to apply this to our server dbrep-se-three – a process which is initiated by clicking “Create Security Rule”. Again, you need provide a name for this, select the Security Application, set the Security IP Lists to “public-internet” to receive external traffic, and the destination (the machine this rule applies to) as your VM target, which is dbvrep-se-three in our case. Then hit create to activate this new rule:

Once this has been enabled, you should now be able to bring up the Dbvisit Standby web interface, running on Dbvserver, which appears as below. When using the https option, you may receive a warning about a potentially unsafe connection (depending on your browser), but you can ignore this and proceed:

Worth pointing out again is that this installation process must be performed on BOTH your source and target machines; that is, the software installation and Dbvserver port configuration.

The next step then is to open ports to enable each of the VMs in the configuration to communicate with the other, by adding an entry in the /etc/hosts file. This resolves the internal IP (not the external one) for the machine on the other side to its given name, and will look something like this:

10.196.243.122                  dbvrep-se-three

Once added, when you ping the server names they should resolve to the internal IP, although they will not return successful as there are additional ports which are yet to be opened to enable this communication. This is also the case when running the Dbvnet connection test, which is initiated as per the following, run from the (install_location)/dbvisit/dbvnet location:

As mentioned, this result is expected at this time as we have yet to open the Dbvnet communication ports – 7890 by default. The process for doing so follows the pattern we looked at for Dbvserver, and that is first create a new Security Application for this tcp port:

Next, harness this within a new Security Rule on each of the VMs in our configuration; the primary server (dbvrep-se-two) and the standby server (dbvrep-se-three):

Once enabled, you can then run the Dbvnet utility test – from both sides – to check that the communication channel is now open and working. A successful test is as follows, and should complete very quickly:

A final step before creating a new configuration is to create the location (a directory) known as archdest on both servers. This is the location Dbvisit Standby will deliver the archive logs to (from Primary to DR) and retrieve them from on the DR side. Although this location is not technically required on the primary side initially, it pays to create it now as it will be needed should a Graceful Switchover (role reversal) action take place. I create the following, with full permissions to this directory, for the oracle user:

/u03/app/oracle/archdest

So, at this point, we have installed Dbvisit Standby on both of our servers and enabled communication on the required ports. We are now ready to create a new Dbvisit Standby configuration encompassing a primary and DR server pair, and the outcome of this is the production of the DDC file: the Dbvisit Standby Database Configuration file. The key point to make here is that, even though our servers and databases are entirely within the Oracle Cloud environment, the steps from hereon in are standard, and the same as doing this on any other on-premise/cloud/mixed system.

You have a couple of options when it comes to configuring this partnership and creating the standby database. Many users prefer the CLI interface, which is an option we offer, but in this example I will go with the web based interface, as that is perhaps slightly more intuitive for newer users.

Below we log into the web interface running on the primary server, dbvrep-se-two, with the default password (admin), and then to the Setup menu – option 3 “New Dbvisit Setup”:

In the following 3 short clips, we walk through aspects of configuring this new Dbvisit Standby partnership using the servers we have set up, create a new standby database, and finally run some basic operations with the application.

Demo 1: Configuration step – setting up the partnership and generating the DDC file

Demo 2: Creating a new standby database

Demo 3: Using Dbvisit Standby to keep your standby database up to date