Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle 8i Standby Complete Recovery

Re: Oracle 8i Standby Complete Recovery

From: Pete Sharman <peter.sharman_at_oracle.com>
Date: 16 Oct 2002 19:52:08 -0700
Message-ID: <aol8ko011bq@drn.newsguy.com>


In article <3DADD79B.D4D01AE5_at_apple.com>, Karen says...
>
>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.

THis is not correct when you are using DataGuard in either instant or guaranteed mode. In each of these, LGWR writes synchronously to the standby redo logs. Of course, this also has the greatest performance impact, so you have to balance your performance requirements with your disaster recovery requirementst.
>
>- 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.
>
>- 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 :).
DataGuard has been available since June last year, so I think you'll find most of the bugs have been ironed out by 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?

The performance impact is directly related to the fact that there is more work to do. Depending on the amount of redo generation and the type of network transfer mode (syncrhonous or asynchronous) this could be a greater or lesser impact. It's impossible to make generic statements like "DataGuard will cost you x% in performance downgrade" for these reasons. As always, the only valid measurement is to test it yourself with the application you're intending to use it with.
>
>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?

Depends on how you've set it up. You may have it set up as one mandatory and one optional for example, and then the impact is less if the optional one dies.

>
>Thank you for any answers.

No problems.

Pete
>
>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
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Wed Oct 16 2002 - 21:52:08 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US