Re: VM vs Data Guard for DB redundancy

Woody,

You briefly mentioned cost. If that is a factor then the hypervisor you choose will potentially make a huge difference in cost.

Does "no app fail-over" mean you are planning on restarting the middle tier? Perhaps you would be using a load balancer?

Keep in mind that going from the network to the data link layer in the OSI model, the IP address is mapped to the physical or logical MAC address. Each server keeps a cache of these mappings called the ARP cache. If you failover to a different VM with a different MAC address (even if it has the same IP), the middle tier will not know about the new MAC address right away and will continue to try to communicate with the MAC address of the failed VM until a network timeout is reached at which time the middle tier server will send a broadcast message requesting the new MAC address belonging to the IP address it is trying to reach. In other words, it may not be as simple as "no app failover".

Data Guard on the other hand enables the middle tier to see all of the database servers at all times. It can proactively switchover and failover using messages from clusterware called fast application notification (FAN) and transparent application failover (TAF) making maintenance and outages much less painful for the users and the administrators.

VM failover can save on licensing costs and is an acceptable solution as long as you can afford the potential data loss, the time required for recovery and failover, and the middle tier is set up properly. Also, keep in mind that if you are choosing not to license the failover site, you can only have the database binaries mounted to it for ten days per year in total.

Seth Miller

On Tue, Jun 28, 2016 at 10:47 AM, Woody McKay <woody.mckay_at_gmail.com> wrote:

> Hi,
>
> In a few days, I need to start investigating maintenance and viability for
> a DB redundancy solution for 2,700 Oracle 12.1.0.2 databases on Linux.
> Currently, the 2,700 customers are in individual instances, but will be
> looking to put them into PDB's later this year.
>
> Leadership has told me that RAC is not an option to be considered. Only
> Data Guard and VM with external storage. If the VM goes down, the thought
> is to bring up another VM and mount the original storage (san). It's
> obvious what to do with Data Guard.
>
> I thought I'd check with the pros here to see what the rest of the best
> are doing.
>
> What are the best options for DB redundancy? Considering maintenance,
> cost and overall viability. Want to be up 99% and downtime is limited to
> 45 minutes or less.
>
> The VM option sounds interesting. Just bring up a new VM on the same IP
> and mount the same storage - viola. No app fail-over or DNS change, etc.
> Got just one DB cost. You would lose in-flight, but that appears to be
> acceptable.
>
> Thoughts, pros/cons ? Other better solutions?
>
> --
> Sincerely,
>
> WoodyMcKay
>

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