RE: Oracle High Availability Question(s)

If you really hate Dataguard, you might consider old fashioned physical backups with continuous recovery.  

You’ll have to keep track of things.

You’ll have to ship the redo logs and apply them.

Switching over, switching back, failing over, and reinstantiating a backup target for the redo logs has to all be manually done by you.  

This has worked reliably since 6.0.37.x (prior to that there could be a race condition that corrupted redo logs, which in turn required reinstantiating the backup target.  

Now this is a lot of monkeying around, but the individual steps are transparent commands either to Oracle or the OS. It was annoying enough, though, that once Dataguard was made into a product convenience features were added to the point that it does require a fair learning curve.  

And of course as an integrated product using Dataguard to drive continuous physical recovery created the opportunity to apply recovery across the wire instead of waiting for a redo log to be full (or switching prematurely) and waiting for arch to archive the online redo log before you ship it from arch.  

Also if you’re directly causing and monitoring all the moving parts, then you know exactly what to do if there is a failure. If (rarely, at least it should be) some part of Dataguard stops working, it might be confusing and possibly scary to get it restarted.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rich J Sent: Wednesday, February 14, 2018 4:00 PM To: oracle-l_at_freelists.org
Subject: Re: Oracle High Availability Question(s)  

On 2018/02/14 14:39, Scott Canaan wrote:

We are currently using Data Guard and we hate it. It’s the only place we use it and we were never given any training on it, so we threw it together as best we could. Every time we have to do anything with it (including patching), we pray that it will recover and continue working.

What we have proposed is to go to Linux clustering instead, eventually going to Libvert, eliminating the Data Guard and moving the fault tolerance to the cluster. The app is not Data Guard aware, so when a failover does occur, the app stops working until someone manually points it to the other server and restarts it. Linux clustering would solve that problem.

If Linux clustering is an option, perhaps a multi-node hyper-converged solution like ones from Simplivity or Nutanix is also an option? I'm not sure that gets you out of the Data Guard game though, depending on how you're using it.

I only mention that because I'm looking in that direction for a possible platform migration myself, and we have ADG.

Rich  

--
http://www.freelists.org/webpage/oracle-l