Re: Oracle 8i Standby Complete Recovery

"Karen Abgarian" <abvk_at_apple.com> wrote in message news:3DADD79B.D4D01AE5_at_apple.com...
> Some ideas that come to mind:
>
> - 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.

> - there are other options except for standby server. For example, the
> VCS cluster has better chances to provide 100% no data loss because
> even if the host does go down, the filesystems can be mounted from
> another box and Oracle can do instance recovery.

Configured in its toughest way, Data Guard *does* provide 100% no data loss.

> - you will have to do a lot of automation work if you are not using
> Dataguard. First of all, the managed recovery switches off if it
> encounters any problems, e.g. a network failure. It does not switch
> back on, and archived log files generated during the period it was
> off need to be manually transfered to standby and applied. You will
> need a mechanism to watch it and transfer files. What you might find
> yourself doing is to ignore the managed recovery and write your own
> scripts to transfer files. On that route, you will encounter a lot of
> obstacles if you try to make it close to what Dataguard does.
>
> - 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.

> - when planning for failover implementation, you need to know your
> requirements. There are other things to consider except for data loss.
> For example, how quickly the system needs to become available. You
> also need to define the types of disaster you are trying to protect your
> system from. And to get an idea what it's going to cost you (your
> company).
>
> I have seen several posts mentioning the performance impact by
> DataGuard. I am pretty sure there's got to be some, but maybe somebody
> could elaborate on this and let me know what this performance impact
> is due to?

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.

> Another question I am trying to get answered: how does DG manage
> TWO standby databases? What happens with redo data if one of them
> is temporarily unavailable?

It depends. You can configure some standbys to be 'must send to' destinations, and others to be 'desirable to send to'. The point about Data Guard is that it's up to you how you configure it. The failure to archive to 'must send to' destinations *can* cause the primary to shutdown, or might cause nothing very much to happen for the interim, followed by a massive catch up operation when transmission becomes possible again.

HJR
> Thank you for any answers.
>
> Regs
> AK
>
>
> Chris Forbis wrote:
>
> > I am looking into ways of recovering in the case of a major failer on
> > a primary server. I have the idea to create a standby server, and
> > this seems to take care of much of the work. The problem I see is
> > when the primary system fails, and a log switch has not happened in
> > the last 4 minutes, It seems I loss that 4 minutes of data because the
> > log has not been archived and moved.
> >
> > Ideas of how to get 100% no data loss?
> >
> > Thanks
> >
> > Chris
>
Received on Thu Oct 17 2002 - 06:22:30 CDT