RE: VM vs Data Guard for DB redundancy

From: Connor McDonald <mcdonald.connor_at_gmail.com>
Date: Wed, 20 Jul 2016 19:46:04 +0800
Message-ID: <CAB=aETDNbCNOnc2oFFHdppL1qjF20PC+Nt_MtwYihFsEobUDaA_at_mail.gmail.com>



One box can run "n" DG instances

Sent from mobile Android
On 19 Jul 2016 5:10 a.m., "Chitale, Hemant K" <Hemant-K.Chitale_at_sc.com> wrote:

> 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...
>
>
>
>
>
>
>
>
>
>
> 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*
>
> 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 Wed Jul 20 2016 - 13:46:04 CEST

Original text of this message