I can't speak for Conner but in a similar scenario for myself, the
different standbys have different purposes and couldn't be combined into
one database.
The zero latency standby would be for failover in case the primary goes
down. I certainly wouldn't want to wait for the standby to flashback and
apply *N* hours of logs before it could become my new primary.
The *N*-2 hours standby has a completely different purpose. I'm not using
that standby for failover, I'm using it as a copy of production as of two
hours ago so I export a copy of a table before it was dropped or do a
point-in-time recovery and switchover my application to the second before
some bad code was rolled out.
The N-24 hours might be a source for copy data for which I could use
snapshot standby to open the database and scrub the data before snapping
off copies for dev/test.
On Tue, Jul 19, 2016 at 12:11 PM, Fernando N. de Souza <fnantes@xxxxxxxxx>
wrote:
Sorry. I was referring to the idea of having multiple standby dbs with
different latencies.
--
Fernando.
To educate a man in mind and not in morals is to educate a menace to
society.
Theodore Roosevelt
On Tue, Jul 19, 2016 at 1:05 PM, Seth Miller <sethmiller.sm@xxxxxxxxx>
wrote:
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@xxxxxxxxx
wrote:
Or you could have only one standby db in flashback mode.
On Jul 17, 2016 10:37 PM, "Connor McDonald" <mcdonald.connor@xxxxxxxxx>
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@xxxxxxxx> wrote:
365.25 * .01 = 3.6525 days. I think you're quoting for a few more 9's.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Stefan Koehler
Sent: Tuesday, June 28, 2016 4:11 PM
To: woody.mckay@xxxxxxxxx; 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: @OracleSK
Woody McKay <woody.mckay@xxxxxxxxx> hat am 28. Juni 2016 um 17:47geschrieben:
viability for a DB redundancy solution for 2,700 Oracle 12.1.0.2 databases
Hi,
In a few days, I need to start investigating maintenance and
on Linux.
Currently, the 2,700 customers are in individual instances, butwill be looking to put them into PDB's later this year.
the thought is to bring up another VM and mount the original storage
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,
(san). It's obvious what to do with Data Guard.
best are doing.
I thought I'd check with the pros here to see what the rest of the
downtime is limited to 45 minutes or less.
What are the best options for DB redundancy? Considering
maintenance, cost and overall viability. Want to be up 99% and
same IP and mount the same storage - viola. No app fail-over or DNS
The VM option sounds interesting. Just bring up a new VM on the
change,
etc.
Got just one DB cost. You would lose in-flight, but that appearsto be acceptable.
--
Thoughts, pros/cons ? Other better solutions?
--
Sincerely,
WoodyMcKay
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
Connor McDonald
===========================
blog: connormcdonald.wordpress.com
twitter: @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*
