Why I don't Like Data Guard was Re: Oracle RAC thread

  • From: Dave Morgan <oracle@xxxxxxxxxxx>
  • To: Oracle-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 07 Jan 2014 08:49:34 -0700

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


Other related posts: