2. Initial Setup and Configuration
2.1 Provisioning the Severs
Connect to OCI Portal and navigate to the Database section from the menu on the left.
This option will direct you to the Bare Metal, VM and Exadata Page from which we can go ahead and create our first DB System.
The compartment (1) offered was the root of our Dbvisit account and the (2) DB system name of the primary is 'dbvlab01'. (3) is showing availability domain AD-1
The basic configuration of 1 node and 1 core was chosen as well as Oracle Standard Edition (5)
I generated a private and public set of key files using ssh-keygen from my local Linux machine.
I could then import this file as shown by (1) in the image. (2) We also opted to have the License costs included in the billing rather than BYOL.
Move on to chosing the details for the VCN (1), Subnet (2), Security Groups (3) and interesting named 'Hostname prefix' (4)
This hostname prefix is actually the hostname of your node or VM after the creation.
Once the network settings are in place we can move to the next page. Here we specify the Database Name (1), version (2)
If the database will have a pluggable database and it's name (3). There is a note (4) to say workload type is fixed at OLTP as DSS is not supported with Standard Edition. In this example we have left the automatic backup un-checked and can proceed to Create the DB System. (5)
The screen changes to show info about your new system and it remains yellow whilst it is still provisioning.
Whilst this is provisioning, we can create a 2nd host that will be the standby server. The values are all the same except the name and 'Hostname prefix' has been set to 'dbvlab02'
The DB systems home screen now shows the 2 systems in the Provisioning State
Provisioning these databases can take up to 1 hour, so it's worthwhile at this point to add the Dbvisit Port details to the default Security List provisioned with your Virtual Cloud Network (VCN)
Within this Default List, add a rule that allows traffic via the Dbvisit communication Ports. These are 7890 (Dbvnet), 7891 (Dbvagent) and 4433 (dbvserver: GUI).
Navigating back to the DB systems section we can see that they are now available and we are able to connect using the public key added during creation.
|Primary Server Details||Standby Server Details|
Edition: Standard Edition
Dbvisit Base: /usr/dbvisit
Standby Version: 9.0.02
Edition: Standard Edition
Dbvisit Base: /usr/dbvisit
Standby Version: 9.0.02
2.2 Preparing the Servers
Connect to each of the cloud hosts with ssh, specifying the public key uploaded when creating the service, as user opc. I have added an entry locally with the public ip of each node.
From here execute sudo -s to switch to the root user and create the dbvisit directory in /usr. Also vi the /etc/hosts file to reflect the internal IP address of the other node in each case. (dbvlab01 : 10.0.0.3 and dbvlab02 : 10.0.0.4)
Download the latest version of Dbvisit Standby for OEL7 and SCP to each of the cloud hosts /tmp as the opc user.
From there chown to oracle:oinstall and move to the /home/oracle on each host.
For OEL7, in addition to the changes made in the security list, we must also add entries into the iptables of each node (dbvlab01 shown).
At this stage, these servers are ready for the next stage of installing the software.
3. Install, Configure and Run the Standby software
3.1 Installing and Configuring the Software
Unzip, Untar and the run the dbvisit installer following the instructions in the dbvisit installation guide as the user oracle.
On the node dbvlab02, the dbvserver (option 5) and Automatic Failover (option 6) was also installed.
A 3rd host could be configured for hosting the dbvserver or the observer. Careful to ensure during the dbvnet configuration on each node that the correct hosts are specified for source and destination. The output from the installation on node2 is shown below for reference.
Repeat the installation on node 1 but install only the core components (Dbvisit Standby Cli, Dbvnet, Dbvagent)
Once the software has been installed on both nodes. Start the processes.
Additionally, on the standby node, start the dbvserver and observer processes
Once the processes are started a test can be performed to check communication between the nodes and that all is correct with the security list entry and the iptable (firewall) configuration. The package telnet was installed on each node to perform the tests.
Firstly, test that we can communicate to dbvlab02 from dbvlab01 across the dbvserver port 4433.
Then repeat from dbvlab02 for one of the other ports (e.g. 7891).
Optionally uninstall telnet after this test has confirmed communication.
3.2 Start the GUI and Create the DDC
Start a web browser and navigate to the https://<dbvserver_host>:4433 and accept the exception.
Enter the default username/password of admin/admin and proceed to the first screen, manage hosts.
Click "New" and enter each of the hosts in turn, specifying the passphrase used at creation time (kiwi123 here).
Successfully adding hosts that can be contacted by the GUI will result in a green tick.
Return to the Main Menu and then proceed on to creating the DDC
Now that hosts have been added the Manage Configurations Tab is available, click on it to create the DDC file. For the time being we will leave the observer.
Click on 'New' to create a New Configuration. The source host (1) is dbvlab01, the standby host (2) is dbvlab02 and click the slider to use ASM (3) and add +ASM1 for the instance.
For the rest of the configuration, accept the pre-filled entries, add a your license key at this stage if it is to hand and click submit. The DDC will be added and displayed similar to the image below.
Now we can proceed with the CSD (Standby creation)
3.3 Create the Standby Database
Select the Create Standby Database option from the main menu.
Once a series of pre-requisite checks have been performed the New Database radio button is selected.
Accept the defaults and check that the /usr/tmp location is a suitable location for the rman backup. Alternatively the creation could be handled either in parallel or with transportable media and details of each of the options can be found in the main Version 9 documentation. However this is a small database of 2.77GB a default creation is adequate.
Click Submit. The progress can be monitored from the resulting icon in the status bar.
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 Transfer
First send the logs to the standby site
Progress can be monitored by clicking on the Icon in the Task Bar
Once the icon is green we can then apply them.
And similarly monitor this task from the taskbar.
3.4.2 Log Gap Report
Run a log gap report from the Primary Site from the GUI
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 if started earlier are not running whilst the switchover is in progress.
3.5.1 Graceful Switchover Icon
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 Configuration Switch within the GUI
3.5.7 Verify the New Roles within each of the Databases
Verify the new database roles within the database
3.6 Configuring the Observer
The observer process was started earlier so it can be simply added within the Manage Configurations Tab. However before starting it, a 2nd graceful switchover (1) has been performed and it was confirmed that hosts have returned to their original setup (2)
The Observer be added (3) by clicking on the "new" icon. Add in the observer host of dbvlab02 and the default passphrase of admin900
Clicking on the 'Monitor' means the system observer is actively watching the configuration for the DDC 'DEV' with the default settings.
Once this is enabled it can be further configured via the settings icon to add notifications with either slack or email and user defined scripts can be added.
Further information on the observer can be found in the online documents section dedicated to the Automatic failover option.