Re: Why I don't Like Data Guard
Date: Wed, 08 Jan 2014 11:56:38 -0700
Message-ID: <52CD9F66.2000906_at_1001111.com>
> -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' ------------------------------ Date: Tue, 7 Jan 2014 10:45:00 -0600 Subject: Re: Why I don't Like Data Guard was Re:
> Oracle RAC thread From: Andrew Kerber <andrew.kerber_at_gmail.com> I am not trying to start an argument, but I do want to point out that the steps to change a dataguard IP address are trivial. Once
> you change it on the server, you change it on the service name entry in the tns file. Done. If you make the mistake of using an IP address in the log_archive_dest_2 setting, then you have a
> problem. But using a service name option, the change is trivial. Also, I am not clear how using scripts in any way changes the maintenance requirements. Whether using scripts or dataguard, you
> still need to check the status daily, and make sure logs are getting applied, and make sure you have enough archive log space, etc. Also, using dataguard you know your archive logs on your primary
> are not getting deleted before being shipped to your standby, which gives an added level of safety. However, I do admit that if cost is your primary consideration, using standard edition with
> manual apply is cheaper, I just dont see that it is any easier.
Although trivial it is more work. In attempting to respond I realized that part of the reason for my dislike is simply I don't have the scripts ported to Data Guard. A whole 1-2 hours work I'm sure.
> From: Hans Forbrich <fuzzy.graybeard_at_gmail.com> Subject: Re: Why I don't Like Data Guard
>>Evidently you have not seen the Cloud Control take on Data Guard.
No I have not. However, I suspect there is a pretty competent (expensive) team doing it.
>... I suspect there will be a "Why I don't like Cloud Control" response
> to that one.
Will "Why I Don't Like OEM" be enough? It will be the last one. :) ASM next I think, RAC, then OEM
> From: "Mark W. Farnham" <mwf_at_rsiz.com>
>
> I find the analysis below to be useful, though not quite complete:
>
> ther 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.
Agreed, very useful if used appropriately
> 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.)
The above requirement should be fulfilled using RAC.If you need RAC use RAC. As long as the standby instance is not open it does not need to be licensed.
> 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?
I beg, borrow and plead for every chance I get. See below
> 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.
Agree 100%
> 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
Thank you for the example, I was looking for something at the other extreme.
> 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.
It can be, I find many shops have not done a basic analysis to determine "critical systems" and the business directive is "everything, immediately".
Paul.Houghton_at_admin.cam.ac.uk wrote
> > We use dataguard as a ship and apply system. Takes one spfile parameter, and an RMAN script to purge old logs. I would have thought that scripts add complexity. > We had a lot of trouble deciding which logs to remove using a scripted system. Clearly knowledge is required to administer it, but then so would a scripted solution, > and indeed everything we do. We don't do all the automatic failover stuff. It is really nice to be able to switch roles of the standby and primary, which I don't > know if you could do with a scripted solution.
>
> I am a permanent employee, so I want the solution that costs me least work. Amen to that.
Interesting, you just hit the biggest weakness. We just did a simulated electrical failure for a client from 5PM Jan 1 to 5PM Jan5 to take advantage of the reduced load during the period. Switching the roles is slightly more work than with DataGuard, but involves moving controlfiles and redo logs "Stop, we never delete anything, this is production, save it somewhere safe" Always a little nerve-wracking. We had no issues, and the test went as well as such things can, but.....
I had not considered operating DG in the mode you described. Given that managing the primary/standby relationship is easier/less stressful I think you've provided the basic reason to use DG if the customer has an Enterprise license.
Thanks to all
YMMV
Dave
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jan 08 2014 - 19:56:38 CET