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.
