12 Days of #Cloud: Exploring #DBaaS with Data Guard

12 Days of #Cloud: Day 11

After a few failed attempts, I was successful in creating a Data Guard DBaaS Instance. Since I was playing with a trial account, the resources were limited. I guess when I had another database running, there is not much storage left to create two instances in Data Guard configuration. Anyway, that is my guess.

Creating a Data Guard DBaaS service is pretty similar to creating a standard DBaaS instance. Choose “Create Instance” from the Oracle Database Cloud Service. Notice that I chose “Enterprise Edition – Extreme Performance” as the software edition. You can create a Data Guard configuration using any Enterprise Edition option, but only Extreme Performance gives you the “Active Data Guard”.  Though an Oracle Data Guard configuration can contain one primary database and up to thirty standby destinations, the Oracle Data Guard configuration in Database Cloud Service includes one primary database and one standby database. Oracle Active Data Guard (also known as real-time query) provides read-only access to the physical standby database while it is synchronized with the primary database.

 

 

 

 

 

 

If you choose the software edition as Enterprise Edition, you will get the bottom portion to configure standby database. Click the check box to enable Data Guard configuration.

 

 

 

 

 

 

 

 

Once you click on the Create Service in the summary screen, it takes about 50 minutes to create Data Guard instance, which includes

  • Primary Instance VM and database
  • Standby Instance VM and standby database
  • Listener and TNSNAMES.ORA configurations
  • Data Guard Configuration with standby database running in read-only mode for queries
  • Perform service reliability checks on both nodes

Click on the DBaaS instance to view details. The screenshot below shows the two nodes and their status.

Note, -dg01 is my primary database node and -dg02 is my standby database node.

The menu beside the node names as well as on the top includes three additional items related to Data Guard.

  • Switchover: A switchover operation enables the primary database to switch roles with its standby database. There is no data loss during a switchover. After a switchover, each database continues to participate in the Oracle Data Guard configuration in its new role.
  • Failover: A failover operation changes a standby database to the primary role in response to a primary database failure. The current primary database is shut down.
  • Reinstate: After performing a failover to the standby database, you may be able to restore your original disaster-recovery solution by reinstating the failed primary database. You can use the Data Guard broker’s reinstate capability to make the failed primary database a viable standby database for the new primary.

Use the public IP address to log into each Linux node. I see the two nodes pretty identical.

Connect to the primary database (the result is same from standby as well) and query V$DATAGUARD_CONFIG.

The tnsnames.ora is identical on both nodes, with pretty exhaustive configuration entries. The CDB, as well as PDB have FAILOVER configuration.

There are eight services running on both nodes. The naming is pretty self-explanatory.

And there are eight tnsnames.ora entries as well. I have only one PDB, if there are more PDBs, I guess more services and more TNSNAMES.ORA entries would be created.

The log transport configuration on primary database is:

The dbaascli utility has options to manage the Data Guard database roles. Before I start using dbaascli, applying the best practice I learned and updating the cloud toolset to the latest version on both nodes.

$ dbaascli dbpatchm –run -toolsinst -rpmversion=16.4.5.1_161213.1526

$ dbaascli dataguard status

$ dbaascli dataguard status –details yes

Enough of exploring the configurations. Let’s do some real Data Guard operations. First, I am going to use the Cloud Database Service Console to do a switchover – the current primary (-dg01) will become standby, and the current standby (-dg02) will become primary.

Just for the sake of completeness, I am going to create a table under user Bill. After the switchover will validate the table on the new primary database for existence.

Click on the Cloud Service menu and choose “Switchover”.

Voila, the role is reversed. No intervention! Took about 5 minutes.

And the table still exist.

SQL also shows the database role is reversed.

I am assuming the Cloud Service is using the dbaascli tool for switchover, failver, reinstate operations. Let me use dbaascli to perform a manual failover.

$ dbaascli dataguard status

$ dbaascli dataguard failover

The current primary database is now shutdown (abort), and the standby database is made primary. No active standby database.

$ dbaascli dataguard status

The ORA-16661 message is a good indication that the physical standby database can be reinstated. Let’s try using dbaascli.

$ dbaascli dataguard reinstate

$ dbaascli dataguard status

Well, forgot to mention that the standby database we have is in fact “Active Data Guard (Real-time Query)”.

Check the OPEN_MODE in V$DATABASE as well as try to query the database.

 

12 Days of #Cloud: Backup #DBaaS to Cloud Container

12 Days of #Cloud: Day 10

In a previous post, I talked about enabling backups on a #DBaaS instance where backups were disabled when the instance was created. Today I show you how to create a database with Cloud Backup enabled at the time of creating the instance. To store backups on the Oracle Cloud, we need to first create a storage container.

From the dashboard, choose Storage Cloud Service. And note down the REST Endpoint URL.

The page also shows the data center. Mine is us2. Go to the Storage Console to create a new storage container to store the backups. The storage console URL is https://storageconsole.us2.oraclecloud.com where you need to substitute the correct data center instead of us2. Thanks to Gokhan for the help.

Login prompt appears:

Input the Storage Cloud REST Endpoint URL and your Cloud account username/password to get to the Storage Console. Choose “Create Container”

For regular backups and file storage needs, choose Standard. For archive backups, choose Archive. Archive Storage Service is ideally suited for infrequently accessed large-scale data sets.

I created two containers. When using these containers for backup or for storage, Oracle DBaaS expects a URL that includes the domain name and container name. The format of  the URL is https://<identity-domain>.storage.oraclecloud.com/v1/Storage-<identity-domain>/<backup-container>

If the backup container is in the same identify domain as your database, then the URL may be shortened to Storage-<identity-domain>/<backup-container> Thanks to Scott Spendolini for this info.

Now, to Cloud Database console to create an instance. Everything is pretty similar to the first Instance I created, except for the backup configuration.

Backup destination is “Both Cloud Storage and Local Storage”. The Cloud Storage Container is the REST URL for my Storage Cloud + Container Name. If you check on the “Create Cloud Storage Container”, you can specify the name of a non-existing storage container. I provided the name of an existing container (Backup001) and my domain name is usatomtrial. The Complete URL is https://usatomtrial.storage.oraclecloud.com/v1/Storage-usatomtrial/Backup001.

After about a day of running database, I can see using RMAN that the backups are happening successfully.

Here are the default RMAN configurations.

Notice
CONFIGURE CHANNEL DEVICE TYPE ‘SBT_TAPE’ MAXPIECESIZE 2 G PARMS ‘SBT_LIBRARY=libopc.so, ENV=(OPC_PFILE=/u01/ app/oracle/product/12.2.0/dbhome_1/dbs/opcDBBKCL1.ora)’;
The backups are scheduled through root cron. Database backup is scheduled once a day, and archive log backups are done every 30 minutes. You may adjust the frequency if needed.

Though backups are scheduled, an on-demand backup can be performed from the Database Cloud Console.

You may also initiate a recovery from the Database Cloud Console.

The options are to recover using the latest backup (full + archivelog backups available), or specified datetime, or specified SCN.

Click Recover, and hopefully, you will have a recovered database without DBA intervention.