Re: VM vs Data Guard for DB redundancy

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