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

Home -> Community -> Mailing Lists -> Oracle-L -> RE: 0% data loss setup ?

RE: 0% data loss setup ?

From: Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl>
Date: Mon, 08 Mar 2004 13:39:31 +0200
Message-Id: <6.0.1.1.0.20040308132638.43f3c2b0@pop.xs4all.nl>


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) ===

At 03:22 PM 3/8/2004, you wrote:

>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_at_iflexsolutions.com>
> > To: <oracle-l_at_freelists.org>
> > 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_at_sagelogix.com]
> > Sent: Monday, March 08, 2004 9:18 AM
> > To: oracle-l_at_freelists.org
> > 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_at_freelists.org
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/
> > FAQ is at http://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_at_freelists.org
>put 'unsubscribe' in the subject line.
>--
>Archives are at http://www.freelists.org/archives/oracle-l/
>FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Mon Mar 08 2004 - 07:38:35 CST

Original text of this message

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