Category: DBaaS

Posted on

12th Day of #Cloud: Thoughts

12 Days of #Cloud: Day 12

After playing with Oracle Database Cloud Service (DBaaS) for past several days, I have mixed feeling. I like quite a lot of features and the amount of automation went into the product. For example, creating an RAC instance and creating a Data Guard instance by picking a check box is pretty awesome. These two configurations are pretty good, in my quick validation. If Oracle development team takes care of few cosmetic items in the Cloud interface to make it consistent across all services and simplify the data entry portion, users like me would start liking and adopting the service. I also expect a lot of automation.

I had two pain points – storage and cloud tooling. The trial account navigation on the Cloud dashboard is too slow as well.

From the Dashboard after you click on a Cloud Service (for example Database Cloud Service or Golden Gate Cloud Service), you get to the screen where you have a button on the top right to open the console.

The Storage Console URL is tied to the data center (not sure why), hence I think the “Open Service Console” button is missing in Storage Cloud Service main screen.

Still, I do not think it is a big deal to generate my storage cloud console URL as my data center is known to Oracle and provide a consistent interface. The URL is https://storageconsole.us2.oraclecloud.com/

When entering storage container information, I have to create URL. Would it be easier to ask me the domain name and container name instead of asking me to coin the URL? From the storage domain name and container name, Oracle developer can easily build the URL.

When I am subscribing to a service, I expect everything latest and greatest, especially the cloud tools to manage my service. I am not sure why I should manually update the cloud tooling to the latest? In my view, updating cloud tooling to latest release must be part of provisioning and automatic ongoing.

When creating a DBaaS service, enabling backup is easy through the GUI. But, if we have to change the backup configuration, it is a lot of manual steps. I would expect a DBaaS modify service GUI similar to the create service GUI where I can change the backup configuration.

These may be minor, and once you are used to the service may not be a big deal. For a new product, the challenge is to get people to get used to the tool. If you turn them off initially with a non-friendly interface, it does not matter how good the product is.

Hope these posts will help you try out Oracle #DBaaS. I will continue to play with Cloud service as long my trial account is active 🙂

Happy New Year!

Posted on

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.