In this demo, we'll create two virtual machines, each running Oracle databases. One will be the primary and the other, the standby. Data Guard will be deployed as a high availability solution, and we'll end up failing over from the primary to the standby. All of this will be done using the Azure CLI through the Windows Azure SDK command prompt.

First off, we need to create a resource group, which I'll do using the az group create command, calling it oracle-rg and locating it in the westus. Next, I'll create an availability set with two fault domains and two update domains. Each virtual machine is deployed to the availability set, and I'm using an Oracle Linux image with a preinstalled Oracle 12 server instance. When Azure creates the VM, the ssh keys are automatically downloaded into a .ssh directory on my PC. I will rename the files so they won't be over-written when I create the second VM. Once the VM has been deployed, I'll grab the public IP address that I'll need to connect to the VM via ssh and put it in my local tnsnames file for my sqlplus connection. I'll repeat the process for the second VM. Now that the VMs exist, we need to allow access to port 1521 via a network security group rule. As well as the private network range, I'll add my local PC's IP address to source address prefixes. It's a case of rinse and repeat for the second machine's port access.

With the Infrastructure taken care of, let's log onto oraclevm1 and start setting up the database. So that's ssh using the downloaded key and public IP address from earlier. I'll change to the oracle user and create a database called cdb1. Once that's finished, I'll set the oracle home directory and sid variables. Then fire up a sqlplus session and check the archive log mode, and if not enabled, then enable it, along with force logging. We also need to create standby redo logs in line with the primary database redo logs.

Last but not least, turn on flashback and set standby file management to automatic before exiting the SQL session. We now need to verify the tnsnames and listener files. They don't exist, so I'll need to create them and enter the locations for the primary and standby databases. The listener file has an entry for the data guard manager. After creating those files, we can enable data guard broker via an SQL alter system statement and start the listener. That's us done on the primary server for the moment. Now ssh onto the standby server, create the tnsnames and listener files as we did on the primary machine, and start the listener.

Now we need to restore the primary database to the standby server. To do that from scratch, we need to create an initialization parameter file, create the appropriate directories, and a password file. Next, log into a sqlplus session and start the database using the parameter file. Using the RMAN tool, specify the primary as the target and the standby as the auxiliary, and then run the duplicate target database command. As on the primary VM, we need to enable the data guard broker.

Finally, we need to configure the data guard broker on the primary VM by logging into the data guard manager with the SYS account. First, create the configuration specifying cdb1 as the primary database, add cdb1_stby as the mirror, and enable the configuration. We can now try failing over to the standby database with the data guard manager command switch over. Switch over has succeeded, and the new primary is cdb1_standby.