What improvement can we roll out for our Oracle Generation 2 Cloud that would truly take the current Oracle Autonomous Database to the next level? I think the answer lays in the most requested feature for the Autonomous Database which is disaster recovery (DR) that leverages all the fantastic capabilities of Active Data Guard which are available in our Exadata Cloud Service and Database Cloud Service offerings combined with all of the advanced automation and self-management capabilities of the Autonomous Database.
So, now the obvious question is, what exactly is Autonomous Data Guard? Autonomous Data Guard provides a fully managed high availability and disaster recovery configuration across Availability Domains (ADs) with the simple click of a button or REST API call to enable it. ADs are independent and isolated data centers separated by kilometers within a region to make them resilient to disasters. In the case of a disaster after zero data loss is validated and confirmed, Autonomous Data Guard can switchover over to the standby with just a few clicks. In the case of possible data loss, the customer can choose whether they still want to switch over to the standby.
In a nutshell, it utilizes a combination of advancements made in the Oracle Autonomous Database Multitenant architecture with the capabilities of Data Guard to provide you with the most resilient and automated disaster recovery humanly (pun intended, perhaps superhumanly would be a better term) possible.
When will Autonomous Data Guard be available on Autonomous Database? The answer is that it depends on the Autonomous Database service. Autonomous Database Shared (ADB-S, Serverless) is available today with support for Autonomous Database Dedicated (ADB-D) coming in the subsequent future.
Okay, enough of the announcement details and the various technologies utilized, how can you enable it in your Autonomous Database Shared environments? The good news is that it couldn’t be simpler.Whether you are creating a new Autonomous Database – Shared instance (as I have done in this case, creating a brand new instance within my tenant) or using one previously spun up, you can simply navigate to the instance in question as shown below and click “enable” for the Autonomous Data Guard option.
Next, we get a quick notice that enabling Autonomous Data Guard will spin up a Standby database instance which will incur additional service charges which isn’t a surprise as it is yet another resource running in my tenant. I will of course click “Enable Autonomous Data Guard” to continue my adventure in having a full DR environment provisioned and configured for me autonomously with no more than 2 clicks so far.
The excitement begins to mount as I can now see that Autonomous Data Guard is updating my Autonomous Data - Shared instance by provisioning my standby database in another availability domain (AD). Not only that, but if I look closely I can already see a “Switchover” option has appeared which begs to be pressed to test it out as soon as provisioning is complete.
Upon completion, we now see the following screen informing me of success and the updated “Peer State” as "available".
At this point, my DR environment has been fully provisioned and configured by Autonomous Data Guard and is already providing me with the desired protection. Let’s perform a switchover now to the standby database by clicking on “Switchover” which will pull up a dialog confirming that I indeed want to manually switchover to the standby database. I of course will type in the name of my database and click the associated button in the dialog to confirm my wonderful decision to move forward with the switchover.
Now, we wait a short time in excited anticipation to see the switchover in action protecting my data as we go through the role transition. We see the peer state has changed to "Role Change in Progress".
I am then informed that the switchover is complete and that no data loss occurred. Mission complete, but what about my standby database? Don’t I need that re-provisioned? Oh wait, Autonomous Data Guard has already taken care of that for me and is re-provisioning it!! I guess I will just drink my coffee.
Once that completes, I get the good news that my standby database is back up and running and thus my peer state is “Available” again. My data is once again completely protected by Autonomous Data Guard and now I can go get some more coffee.
Alright, the good news is that there is not much else to say thanks to all of the automation built into the system. I suggest taking it for a spin yourselves when you get a chance in whichever region you are running.
Source: oracle.com
Posts
0 comments:
Post a Comment