Configuring Oracle Database Appliance and Dbvisit Standby v9


An Oracle Database Appliance X6 is similar in many ways to an Exadata, in that it is a pre-tuned machine built to run Oracle databases.
But the cost of buying one of these machines is far less than that of it's Exadata cousin. And with the launch of the X6 series last year, it is the first
the engineered system to support Oracle Standard Edition.
The X6-2S that is used for testing is optimized to run Single Instances and this entry level machine is very appealing to small and medium businesses.
A summary of the details for both parts is shown in the table below:



Cloud Standby

Machine Name





ODA X6-2 S

ODA X6-2 S

Oracle Database as Service (DBaaS)





Oracle Version Standard Edition Standard Edition Standard Edition











DB Storage





Dbvisit Standby

 1. Configuring Dbvisit Standby v8 between a Primary and Standby Oracle Database Appliance (ODA)

The steps required to configure Dbvisit Standby between two ODA machines are similar to a non-ODA setup. However, there are a couple of quirks that need to be kept in mind and we will explore these later on.
Having access to two 'blank' ODA X6-2 (The Dbvisit ODA Datasheet here) machines with just the OS pre-installed to perform some tests. So we could create 2 new Oracle Databases. Knowing we wanted to demo ODA to Oracle Cloud in a separate test, we decided to create an Oracle 12c CDB database with ASM storage (DBV1) and an Oracle 12c non-CDB database with ACFS filesystem storage (DBV2). This was in order to demonstrate as much of the functionality as possible.

After logging into the management URL

creating a Database in ODA couldn't be easier. You simply click 'create database' from the Oracle Database Appliance, Databases tab.

The graphic below shows the creation of the first of the 2 databases DBV1 (12c CDB with ASM).

Once the "Create" button is pressed, the screen displays a creation job that can either be monitored as root via the command line tool (odacli) or graphically via a job.

The creation of the database also generates an Oracle Home. The Oracle Homes for the primary databases are created (if you choose to have 2 instead of 1) with each database creation. However, on the Standby host, if there are not yet any databases there will be no Oracle Homes. Keep this in mind and we'll cover this point again later when creating the Standby DDC.
At this time, we choose to also create the 2nd Database DBV2, opting to create a 2nd Oracle Home and having ACFS as the storage option.

Once these databases were created, we can also view both of them and their associated storages from the command line utility (odacli).

With these created, it's worthwhile to now consider the standby node. Here, we need to pre-create both the standby database storage and add an Oracle Home. In order to demonstrate both the ease of using the command line and the GUI, we decided to create both the storage and the new Oracle Home from the command line as shown below.

Download and copy (SCP) over the Dbvisit Standby v8 binaries to each node.

From there we can proceed with a normal installation of Dbvisit Standby v8

We can then repeat the exercise on the Standby server, also installing dbvserver.

A quick reminder of the Dbvisit Standby v8 Components are shown below

Once the binaries are installed we can start the corresponding processes: dbvnet and dbvagent on the primary server ODAS1 and additionally dbvserver on the standby site ODAS2

From here we can fire up the GUI and proceed with creating the first database configuration.

Click on the "Manage Hosts" tab to add the two ODA hosts.

Once these hosts are in place and the two 'green-ticks' confirm they are accessible, we can move to the next stop of Managing Configurations. The first part of this screen is straightforward and describes the Primary ODA Database details. However, we've chosen to highlight the standby portion of the screen to draw your attention to three points. Firstly, the storage we created on the Standby host was of Type ASM. Second, if we hadn't already created an Oracle home on the standby host, it's a handy reminder to do so before filling out the details here. Third, the unique database name is also worth a mention.

If you create the DB storage as we did earlier then the database unique name is the same as the database name by default.

In the create-dbstorage command, there is the option (-u) to specify a different unique name. We didn't, so when entering a value in the Standby Configuration page, don't be tempted to specify a unique name here as it causes problems later when registering the database.
Here we specified a Unique Name in the "create configurations" of DBV1STBY. We could successfully create the standby database. However, we got the below error when we came to register it.

With the configuration successfully stored and a trial license applied to that configuration, we are ready to create the standby database on ODAS2

With the latest version of Dbvisit Standby 8, it automatically detects if Oracle Restart or Clusterware is available on the standby server. With an ODA machine, this is obviously present. However, in this case, we want to register the database with the odacli command line utility, not from here, so be sure to have this set to "No"

We can monitor the progress of the task via its icon on the "Active Task List" and watch each step until the Successful Task completion.
Before we can perform the registration of the standby database on the 2nd ODA machine we need to ensure that the database is opened in READONLY mode and before we do that we need to ensure there is a log gap of zero between the 2 databases.
Fortunately, this can easily be achieved with the GUI as shown below.

  1. View the current log gap

     2. Send and Apply logs if required, the double check the log gap again.

     3. Select the database action icon

    4. Choose "START READ-ONLY" for the database on Node 2

If you don't open the database as READONLY before attempting to register it, you get the error.

However, with the database in the correct mode:

Once registered, don't forget to stop and mount the standby ready for applying archive logs.
It is fair to say at this point the differences end and the running of the standby with our software is as seamless as if ODA was not a consideration.
We can send/apply logs and perform a graceful switchover.

The configuration is automatically updated to reflect this switchover.

Using the ODA machines, both as a new technology and with our software, relatively straightforward. 

2. Configuring Dbvisit Standby v8 between a Primary Oracle Database Appliance (ODA) and Standby DBaaS

We are now going to explore creating the standby database within a host that is a Database as a Service (DBaaS). This is also known as an Oracle Private Cloud.

We'lll use the 2nd database created on ODAS1 (DBV2) as the primary and create a new Service within my Oracle Cloud account to act as the standby.
DBV2 is a small 12c Non-CDB database with ACFS filesystems and all the files residing on the /u02 mount point

We created the following host (service): DBVCLD01 with Service Level of "Oracle Database Cloud Service"

It's easier and quicker to accept this Service Level and drop the pre-created ORCL database than it is to opt for a Virtual machine as this is literally a 'bare bones' machine with no Oracle binaries or mounted filesystems.
Upload a private key created earlier with keygen and click create. The service takes around 20mins to complete.

Once completed, you can add access rules to make available the ports relevant to Dbvisit Standby v8. The defaults are port 7890 for dbvnet, 7891 for the agent and 4433 for the GUI/observer. We chose to create one rule (dbv_ports) covering the port range 4430-7899.

To access the host as root, simply connect as the opc user (who has sudo access) with the key that was uploaded when the service was created, and sudo -s to root. From here you can make the /usr/dbvisit directory and change the ownership to be oracle:oinstall. Also as root, edit the /etc/hosts file to add an entry for the primary node: ODAS1.

It's also worth pointing out that on the Primary node, an entry pointing to the cloud host: dbvcld01 needs to be added to the /etc/hosts file and the firewall ports need opening on this side too. Then the binaries can be transferred and installed. As this cloud host is to be the standby server, it's best to install the dbvserver component here.

Once the binaries are installed, start them up, including dbvserver for the GUI.

Now we can proceed to use the GUI

and first enter details for the two hosts:

Then create a Database configuration. In this configuration, the filesystem is ACFS so I choose No for ASM:

Once the configuration was saved, we created a new Standby Database, in this case, opting to register the Standby database with the clusterware services installed on the cloud host.

With the Standby created and in-sync, the final test was to perform a graceful switchover to show how easy it is to transition (role reversal) your primary database from being hosted on your ODA to a disaster recovery option hosted within the cloud. To do this, we first ensured the two databases were in sync by running a log gap report.

Then we opted for a graceful switchover.

Throughout the process, each step is displayed in real-time by clicking on the graceful switchover icon on the taskbar and once complete a successful tick appears.

This can also be verified by the configurations tab, whereby the primary and standby destinations have been updated to reflect the switch.

Now your primary database is running from within your own Oracle Private cloud. The process is so slick you forget that the standby (or when it's a new a primary) is running in the cloud.

In summary, it was demonstrated that by using Dbvisit Standby v8 and Oracle Database Appliance customers using Oracle Standard Edition can easily achieve a solution that includes high performance hardware for your on-premise primary and standby databases or for an on-premise primary to a cloud hosted standby. All of this at a fraction of the cost of Exadata+Data Guard+Enteprise Edition. Even though we're already familiar with the Dbvisit Standby product, using the ODA commands or GUI  didn't distract from the ease of managing your DR solution in this way.