RE: VM vs Data Guard for DB redundancy

From: Chitale, Hemant K <Hemant-K.Chitale_at_sc.com>
Date: Tue, 19 Jul 2016 09:09:40 +0000
Message-ID: <2FE2AA1C5F8DEC478F58DF8DD32BA6370CEE9A56_at_HKWPIPXMB03C.zone1.scb.net>



Connor,

Each DG instance would have to be licensed. So there is a (not insignificant) $$ impact.

Hemant K Chitale

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Connor McDonald Sent: Monday, July 18, 2016 10:36 AM
Cc: ORACLE-L
Subject: Re: VM vs Data Guard for DB redundancy

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

[https://mailtrack.io/trace/mail/4512b5a813f45f23e927264f41b4fff6e2e03fc3.png?u=941627]

On Wed, Jun 29, 2016 at 6:23 AM, Mark W. Farnham <mwf_at_rsiz.com<mailto: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> [mailto: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<mailto: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<mailto: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<http://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

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https://www.sc.com/en/incorporation-details.html
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jul 19 2016 - 11:09:40 CEST

Original text of this message