Re: VM vs Data Guard for DB redundancy

Good thoughts Seth.

I hadn't thought about the middle tier or load balancers. We have a kick-off meeting tomorrow and I'll bring these items up with the main system architects (I'm only charged with the DB part).

I've implemented old-school physical standbys, but not the newer versions of Data Guard. Thanks, I'll have to read more on FAN and TAF. The app side uses jdbc.

Woody

On Tue, Jun 28, 2016 at 1:13 PM, Seth Miller <sethmiller.sm_at_gmail.com> wrote:

> 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
>>
>
>

-- 
Sincerely,

WoodyMcKay

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