The previous article in this series is an introduction to Oracle Cloud Infrastructure (OCI) Database Services and contains the basic steps to provision an Oracle Database in OCI.
Now, let’s explore how to set up a standby database with Data Guard, creating backups, and examining the nuances of multi-tenant (pluggable databases) and client networking. This article only covers virtual machine (VM) databases. (There are a number of differences when dealing with Bare Metal and Exadata databases that will not be covered.)
Data Guard
Setting up Data Guard in an on-prem environment is often a difficult and error-prone process. There are many dependencies and prerequisites that must be met, and troubleshooting errors can be challenging. OCI has simplified the process by making the setup of Data Guard a single-click feature.
Setting up Data Guard for a typical on-prem database would require setting up a second environment to host the standby database. OCI eliminates this step by making the provisioning of the second database environment part of the Data Guard setup.
Starting at the DB System Details screen in OCI for the database you have provisioned, click on Databases under the Resources header in the left pane. There should be a single database displayed on the screen. To the right of the database details, click on the three dots and select Enable Data Guard. The dialog screen will look similar to the screen that was used to provision the original database, with a few less options.
Despite the simplified process, there is no magic to set up the standby database. Oracle is setting it up the same way that an administrator would. The original VM is cloned to create the standby VM. The standard clone scripts for the clusterware and database homes are then executed on the new VM. The new database and associated clusterware resources are subsequently updated to reflect a new unique database name. Oracle uses Recovery Manager (RMAN) duplicate to do the rest of the database conversion to a standby. Finally, Data Guard Manager (DGMGRL) is used to configure and start the Data Guard replication process.
Once the Data Guard setup is complete, an orange icon will be present next to the database name in the UI, indicating that the database is protected with Data Guard. More details about the standby database can be found by clicking on the database name and selecting Data Guard Associations under the Resources header in the left pane. From this screen, you have the ability to perform a switchover to, or reinstatement from the primary database. From the standby database screen, the only option is to perform a failover.
Testing showed a switchover to take about 10 minutes from the UI. However, the actual time it took for my standby database to become the primary and open successfully was much less. The actual switchover commands are executed with DGMGRL and are logged in detail on the VM. The switchover to standby process started about 30 seconds after I clicked the UI button. The standby database became the primary and was open about 50 seconds after that. The scripts then perform a number of checks and validations before returning the status of complete back to the UI. Performing a switchover back to the original database showed similar results and timing.
Backup, Restore, and Clone
Creating database backups has also been simplified to a single click. Found in the same menu as the Data Guard setup is the option to Create Backup. The only available option in the Create Backup dialog is to provide a name. When the backup is complete, it will show up under the available backups, which can be shown by clicking on the name of the database in the UI.
Behind the scenes, the database is backed up using RMAN. The backup files can be seen in the RMAN catalog. The backup files are saved to a Swift object store. They are not saved locally on the VM. The database uses a media management library to send the files directly to the object store over sbt_tape device-type channels.