On Aug 29, 2:17 am, vitalis...@gmail.com wrote:
> On Aug 29, 9:52 am, hikaru <hikaru_naruto2...@yahoo.co.jp> wrote:
>
> > Thanks Jerome,
> > The version is 10.2.0.3 physical standby on RAC environment.
> > I think real-time apply contributes in a failover duration and
> > synchronous level during read only mode.
> > but it is not necessary if our system does'nt need to get those
> > advantages.
> > Even worse if Primary database gets overhead even if slightly.
> > That's why I would like to know about overhead of Primary database.
>
> Real-time apply, in comparison with delayed apply, won't generate any
> overhead on the primary database. The redo data is directly applied
> from the standby redo log as it is written instead of being applied
> when the standby redo log is archived: the mechanism is relevant to
> the remote site only.

I'm putting myself out on a limb with a chainsaw on the wrong side of
me saying anything here, but here goes:

I have this vague memory of being in a user group presentation about
this, which pointed out that the synchronous talking between lgwr on
the primary and RFS on the standby (as show in figure 6.1 in the doc
David alluded to) allows network latency to affect logging on the
primary. Maybe it only applies to modes other than maximum
performance mode. Maybe lack of performance doesn't have to come from
slight amounts of lgwr overhead, but rather delays in talking to
lgwr... or is a wait state overhead?

I don't have any access to either a system or the ug's papers just
now, but the vague memory is enough to make me say something here,
perhaps someone else can say if it is correct or not. I do remember
thinking at the time, "boy, that's just like the RFS problem I had in
8i, except they seem to have maybe better configuration and error
handling of it now."

Feel free to pull the start cord on the chainsaw.

jg
--
@home.com is bogus.
bye-bye Mr. Joybubbles! http://cfx.signonsandiego.com/uniont...27engress.html