You might consider MAXIMUM AVAILABILITY as well. As long as the standby is
up, it behaves like MAXIMUM PROTECTION. However,if the standby fails, the
primary will stay up and running, at the cost of potential dataloss.
MAXIMUM PROTECTION theoretically halves your MTBF. This you don't want. You
might think of adding a second standby, eventually configuring a TIMELAG
into that one as well. A large pecentage of all errors to systems come from
human beings. DG will propagate your error perfectly and immediately to the
standby. Having a standby with a timelag, to be able to revert to a
pre-human-error situation, and a standby without for immediate failaver
will probably meet your needs at the cost you (your manager) can/want to
afford. The second standby adds to your availability. RMAN can some kind
of solution, but you need to be very carefull in selecting storage. For
real safety the redundant datacopy should be on another site, most likely
your tapedrive isn't, leaving you with the risk of transaction loss. I a
simular situation I set up a configuration with one remote standby, appr.
60 miles / 90 kilometer away, and one local standby. When there is enough
bandwith and VERY few latency you might be able to have the remote in
syncmode as well.
For another customer of mine I setup a single standby solution, SYNC
AFFIRM, MAX AVAILABILTY. Their remote is appr. 500 meters away, and they
have there own fiber between the sites. It's serving appr. 7 databases,
varying from email-system with 10's of thousands of clients, and health
insurance stuff. Their software is 'home-grown', and Transparent
Application Failover-aware. A failover will take 30 sec - 3 minutes. No
transactions lost, just a small hick-up in service.
Regards, Carel-Jan
=== If you think education is expensive, try ignorance. (Derek Bok) ===
We have a similar "must never, ever lose a single committed transaction" requirement here. To meet it, we are using Dataguard. With MAXIMUM PROTECTION and Sync Affirm transactions to the Physical Standby, commits do not complete/return control to the session until the log record is written to the Physical Standby site. The down side is, lose the Physical and transactions stop on the primary as well. As with most things, there is a cost.
FWIW,
John P Weatherman Oracle Database Administrator Advance America
> [Original Message] > From: <k.sriramkumar@xxxxxxxxxxxxxxxxxx> > To: <oracle-l@xxxxxxxxxxxxx> > Date: 3/8/2004 5:58:52 PM > Subject: RE: 0% data loss setup ? > > Hi Tim, > > I appreciate your Excellent coverage of RMAN. I have a doubt here. Pls help me to understand. > > <Quote> > To ensure you don't lose a single committed transaction, get the stuff onto tape, as quick as you can > </Unquote> > > My understanding is that, > > 1. RMAN repository is in a different machine( To provide redundancy) > 2. We will have to wait till the redo is archived and then write the archived log to tape ASAP(using RMAN). > > In this case, if we have a half redo and the machine hosting the DB server crashes, how would we recover( Assuming the half redo is lost)? > > Best Regards > > Sriram Kumar > > > -----Original Message----- > From: Tim Gorman [mailto:tim@xxxxxxxxxxxxx] > Sent: Monday, March 08, 2004 9:18 AM > To: oracle-l@xxxxxxxxxxxxx > Subject: Re: 0% data loss setup ? > > > > DISCLAIMER: > This message contains privileged and confidential information and is intended only for the individual named.If you are not the intended recipient you should not disseminate,distribute,store,print, copy or deliver this message.Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted,corrupted,lost,destroyed,arrive late or incomplete or contain viruses.The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > -----------------------------------------------------------------
---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
