Re: Oracle 8i Standby Complete Recovery

>
> > - the standby server cannot garantee 100% no data loss even with
> > Dataguard because the primary host can go down before the Dataguard
> > copies the changes to the standby.
> >
>
> Not if you configure it so that a commit doesn't count as a commit UNTIL
> it's been sent to the standby, and receipt of its successful transmission
> has been received -which is exactly how you *can* configure Data Guard if
> you so choose.

Objection sustained :). My knowledge is a year behind. I heard this "no data loss" phrase but thought it was just marketing. I'll catch up with the manuals.

There is probably no need to explain the performance impact because it is clear where it's source it. Although I'll have to learn technical details, it does not look
to me upfront that the VCS should be completely thrown out of the window.

>
> >
> > - the DataGuard (and 9iR2) software is relatively new and is probably
> > full of bugs. If your system is critical, you may consider not to test
> > out
> > the Oracle bugs on it. 8i software has plenty bugs as well but they are
> > KNOWN :).
>
> Honestly! Everyone's entitled to their own opinion, of course. But I do
> rather wish less people would post their unsubstantiated opinion here as if
> it counted for anything. Have you actually tested Data Guard? It's not
> exactly difficult to do, and then you'd be able to post some real facts
> about it. It's not "full of bugs": and neither is the product "relatively"
> new, having been in the marketplace for over 12 months now.
>

No, I have not tested the DG! At our site, we are just beginning all this testing.
So far we happily lived with our scripts to ship and apply the log files to both

standby databases. We don't even use managed recovery, just because you need to watch it. 3 minutes allowed data loss, all works perfect.

I don't think I said something incorrect, though. Please notice the word "critical".
It means to me that if there is some bug (maybe even one) that does something to the databases I am responsible for, my head will be on the chopping bar. This
kind of bumps up my requirements for stability.

To give an example, last week, during testing, we created a 9i database listener

to service two 8i and one 9i database. After bouncing one of the 8i databases the listener crashed. This fact was communicated to Oracle, via a TAR, they said "oops, sorry". Remember, all this is about a listener, of a software that was
in production for 12 months or more. It seems to me that the DG is a much bigger
thing and the chances are ...

Anyway, we'll test it and maybe there will be actual bugs to share with the community. In the mean time, maybe you will post some details about how you tested it if you have? Please list the machine type, recovery mode and configuration.

>
> Uh, well (and I'm trying to be polite about this) your first statement in
> this entire post is incorrect as mentioned above precisely because Data
> Guard can be configured to use *LGWR* to synchronously transport redo to the
> standby. Now the source of potential performance impacts should be rather
> obvious: anything that slows down LGWR potentially causes grief on the
> production system, and Data Guard potentially slows it down an awful lot,
> charging it, as it does, with the responsibility of shipping redo to a
> fistful of standby databases. Added to that, you can configure things so
> that the failure to ship to any or all of these standbys causes the primary
> database to be summarily shut down.

It really is obvious now, but thanks for explaining anyway. Received on Sun Oct 20 2002 - 01:30:47 CDT