Re: Data Guard (zero data loss)

Thanks all for the information. I believe that "zero data loss" is required in some cases and data guard can achieve this functionally.

But, how about the performance? Will my online response be seriously affected (instead of a local disk operation to write the redo information, a remote update is required)?

Best regards,
Timmy

"Pete Sharman" <peter.sharman_at_oracle.com> ¼¶¼g©ó¶l¥ó·s»D :b4ilaa0seu_at_drn.newsguy.com...
> In article <3e6bb9a2$1_1_at_mk-nntp-1.news.uk.worldonline.com>, "Paul says...
> >
> >"Timmy Sin" <tswsin_at_yahoo.com> wrote in message
> >news:b49nof$dg3$1_at_news.hk.linkage.net...
> >> Hi All,
> >>
> >> Does anyone have experience on the zero data loss feature with Data
Guard
> >> 9i? It states that modification would be committed only when the redo
> >> information has been at least transferred to one of the standby
databases.
> >> Is this feature practical in real life? How about if the primary and
> >standby
> >> databases are connected by a T1 WAN link?
> >>
> >> Thanks,
> >> Timmy
> >>
> >Surely this requires no more than common sense? The technical mechanism
is
> >irrelevant; if one is going to guarantee no data loss, then there has to
be
> >a successful save in two places before the transaction is committed.
> >
> >Depending on the degree of resilience and recoverability required, one
> >simply evaluates the alternatives available; and then makes a decision.
> >
> >Regards,
> >Paul
> >
> >
>
> Absolutely spot on, Paul. Particularly this bit - "Depending on the
degree of
> resilience and recoverability required". There's so many people out there
who
> *think* they need soemthing and therefore do it, rather than building a
business
> justification for it first. I still remember well having to do an OPS
install
> for a site that had a "mission critical" application. No choice, just do
it.
> When I got to the site, their mission critical app had one table, 40,000
rows.
> THAT WAS IT! THese people had bought a cluster and OPS to support
something
> that could run on a spreadsheet! Oh, and when I questioned them on their
> downtime capacity, nobody was actually using the app yet. This is what
they
> *thought* the requirement might be. Oi vay!
>
> HTH. Additions and corrections welcome.
>
> Pete
>
> SELECT standard_disclaimer, witty_remark FROM company_requirements;
>
Received on Wed Mar 12 2003 - 00:17:42 CST