Re: VM vs Data Guard for DB redundancy

From: Seth Miller <sethmiller.sm_at_gmail.com>
Date: Tue, 19 Jul 2016 12:05:29 -0500
Message-ID: <CAEueRAWLs_9fXrmHnOAV=ohJfvQrR2JdujaJ8vCruEOsEbDkvQ_at_mail.gmail.com>



Fernando,

Can you provide some context for this?

What comment from which individual are you responding to?

On Tue, Jul 19, 2016 at 11:12 AM, Fernando N. de Souza <fnantes_at_gmail.com> wrote:

> Or you could have only one standby db in flashback mode.
>
> On Jul 17, 2016 10:37 PM, "Connor McDonald" <mcdonald.connor_at_gmail.com>
> wrote:
>
>> For me ... the nice thing with DataGuard is customisable latency.
>>
>> Because its rarely hardware etc nowadays that causes a "disaster"....its
>> that errant installation script that did
>>
>> drop table THE_MOST_IMPORTANT_TABLE_IN_MY_COMPANY;
>>
>> and it doesn't matter how many VM's you have floating around if you only
>> have 1 database :-)
>>
>> So I can have 1 DG with 'zero' latency, 1 DG with 2hours latency, 1 with
>> a day etc etc etc...
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 29, 2016 at 6:23 AM, Mark W. Farnham <mwf_at_rsiz.com> wrote:
>>
>>> 365.25 * .01 = 3.6525 days. I think you're quoting for a few more 9's.
>>>
>>>
>>> -----Original Message-----
>>> From: oracle-l-bounce_at_freelists.org [mailto:
>>> oracle-l-bounce_at_freelists.org] On Behalf Of Stefan Koehler
>>> Sent: Tuesday, June 28, 2016 4:11 PM
>>> To: woody.mckay_at_gmail.com; ORACLE-L
>>> Subject: Re: VM vs Data Guard for DB redundancy
>>>
>>> Hey Woody,
>>> well before going into any technical details, you need to define clearly
>>> what your RPO and RTO is about. I mean you already mentioned an uptime of
>>> 99% and max downtime of 45 minutes, but in what scale? Per month? Per year?
>>> Per week? Per day? With system maintenance windows or not? For example a
>>> downtime of 99% per year is 5.256 minutes which does not really fit to your
>>> 45 minutes, but a downtime of 99% per day is 14,4 minutes which does not
>>> really fit to your 45 minutes as well.
>>>
>>> After you got these detailed requirements from the business owner, you
>>> need to clarify RPO in detail ("You would lose in-flight, but that appears
>>> to be acceptable" is not enough definition at all).
>>>
>>> There may be also legal statements (e.g. like from BSI in Germany -
>>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Hochverfuegbarkeit/BandB/B8_Datenbanken.pdf),
>>> which clearly state that only a virtualization solution is not sufficient
>>> for RDBMS HA, but this is country/environment dependent of course. You
>>> should check this with your state and planned systems.
>>>
>>> Be also aware that virtualization only catch host failures. You still
>>> have to deal with logical and physical corruption (and detection) on RDBMS
>>> level, which has to be set in relation to your defined RPO / RTO and
>>> database size, etc..
>>>
>>> Best Regards
>>> Stefan Koehler
>>>
>>> Freelance Oracle performance consultant and researcher
>>> Homepage: http://www.soocs.de
>>> Twitter: _at_OracleSK
>>>
>>> > Woody McKay <woody.mckay_at_gmail.com> hat am 28. Juni 2016 um 17:47
>>> geschrieben:
>>> >
>>> > 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
>>>
>>>
>>> --
>>> http://www.freelists.org/webpage/oracle-l
>>>
>>>
>>>
>>
>>
>> --
>> Connor McDonald
>> ===========================
>> blog: connormcdonald.wordpress.com
>> twitter: _at_connor_mc_d
>>
>> "If you are not living on the edge, you are taking up too much room."
>> - Jayne Howard
>>
>> *Fine print: Views expressed here are my own and not necessarily that of
>> my employer*
>>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jul 19 2016 - 19:05:29 CEST

Original text of this message