RE: Why I don't Like Data Guard was Re: Oracle RAC thread
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle@xxxxxxxxxxx>, "'Oracle-L'" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 7 Jan 2014 12:03:29 -0500
I find the analysis below to be useful, though not quite complete:
Other features of Data Guard that *might* justify excess cost and
maintenance that immediately come to mind are:
1) the mode where lgwr rather than arch is responsible for propagation of
redo to the standby. Of course you need to justify for any performance hit
as well, but it varies by the value of reducing the chances of losing a
committed transaction in a site disruption, not the outage time allowed.
2) Even more cost, but active data guard if the value of feathering out
queries nearly current and/or feeds to decision support with minimal
overhead to the transaction system is cost justified. (Including the
possibility that this cost is offset by avoiding the need for RAC.)
Of course negotiations and license requirements regarding getting the
required service levels for the least total cost of ownership may get
complex.
For example, if your business continuation plan allows for a very long
outage in the event of a site disaster, what rules have you negotiated for
testing the recovery of your backups on alternate equipment?
Do you have an organization you trust or contract with that has its own
Oracle licenses where your backups can be recovery tested? Manual log
shipping *might* be quite cost effective in that arrangement.
I'm sure there are other issues that do not immediately come to mind. There
are certain bits of Dataguard that function as a voluntary strait jacket to
make doggone sure recovery will complete. If you roll your own you miss out
on (at least) the two features I listed above (that you might not need), you
may gain some flexibility, but it is up to you to make sure you have all the
pieces you need for various recovery scenarios.
So I do not think that analysis is quite as black and white as listed below,
but certainly those are issues to consider.
The cost of outage time per unit time is also probably not linear or
calendar invariant. The "shooting fish in a barrel" real world example is
payroll: An outage of a week or two might be cost free unless the outage
falls on certain days. Even on the most sensitive day an outage of a few
hours might be tolerable, but too long an outage to deliver payroll (and
taxes!) may become expensive indeed. But that leads directly into
operational costs of consolidation, where the most costly outage per unit
time may become the rule for an entire complex of systems. And that is a
long discussion indeed.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Dave Morgan
Sent: Tuesday, January 07, 2014 10:50 AM
To: Oracle-L
Subject: Why I don't Like Data Guard was Re: Oracle RAC thread
On 01/02/2014 08:55 AM, Jeremy Schneider wrote:
> Dave, I'm curious why you would opt for manual log ship and apply instead
of Data Guard?
> Also, why do you say that "Data Guard is expensive"? Do you just mean
that enterprise edition is expensive?
> -Jeremy
Thanks for the intro ;)
> On Mon, Dec 30, 2013 at 1:15 PM, Dave Morgan <oracle@xxxxxxxxxxx
<mailto:oracle@xxxxxxxxxxx>> wrote:
> On Mon, Dec 23, 2013 at 8:07 PM, Chris King <ckaj111@xxxxxxxx
<mailto:ckaj111@xxxxxxxx>> wrote:
> We're architecting a new system, and will need 99.5%
> availability. Looking
>
> I believe this is the wrong metric to use. As others have pointed out
it is equivalent to
> ~40hours/year. The correct question is what is the longest outage the
business can afford
> for any single event?
>
> 15 minutes, 1 hour, 4 hours?
>
> If the business claims less than 15 minutes they should have real
reasons, DataGuard is expensive.
>
> My standard is a simple automatic log ship and apply system from the
old days. Train the
> sysadmins to do the failure-over and you can meet a 15 minute
deadline during business hours.
>
> Cheap, easy, tested, robust, runs with 3-5 hours of scheduled downtime
per year. Every year.
>
First, yes Enterprise edition is expensive, however, if you NEED what Data
Guard supplies then it is cheap at the price.
However, Data Guard has a much higher maintenance cost also. This
maintenance cost is extra administrator time.
Data Guards are dependent on each other. Data Guards require knowledgeable
DBAs and sysadmins. In order to be really successful with Data Guard one
needs sophisticated developers who can do TAF or auto-magically reread the
tnsnames source upon connection failure. So for cases where the business can
afford an outage of 15 minutes or so, I can provide a cheaper, more robust
solution.
Now that we know where not to use it, lets agree what Data Guard is for and
when it should be used.
Most businesses can afford an outage of 15-30 minutes. The only business
that can't are those whose transactional databases are intimately involved
in the sales process. Telecoms, banking, and airlines for example.
Any time the business claims a need of < 15 minute outages make sure you
understand why! Loss of revenue or real time access are usually the only
real needs, almost everything else fails an ROI test.
If the business has a valid need and DataGuard is chosen to meet it, the
first objective , I think, is to be able to perform an automated fail over
and the worst any of the "important" clients experience is a 30 second
hiccup.
How long is the above going to take? What are you going to use while
building and testing the above architecture? What are the total man hours
involved?
I can build you a ship and apply system for the time of a single recovery
and it will take far less admin time than a Data Guard system. The sysadmins
can shut it down, move it, change IP address, whatever they want and as soon
as it stands back up it starts working again, as if nothing happened. Shall
we go through the steps required to change a Data Guard IP address?
The ship and apply system is simple and easily understood.
Nothing more than 2 sql scripts and 3 ten line shell scripts or windows
batch files.
The 2 databases are completely independent.
Why would I use Data Guard when the business does not need "instantaneous"
recovery?
Why would I use Data Guard when the infrastructure supports synchronous
writes between data centres?
I do not consider more billable hours a valid reason :)
Again I apologize for the aggressive tone of the "Why I Don't Like" subject
line.
TIA
Dave
--
Dave Morgan
Senior Consultant, 1001111 Alberta Limited dave.morgan@xxxxxxxxxxx
403 399 2442
--
Dave Morgan
Senior Consultant, 1001111 Alberta Limited dave.morgan@xxxxxxxxxxx
403 399 2442
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
