Hi all,
I've heard Dataguard Real Time Apply feature makes Primary database to
do a bit of overhead processes.Is that true? Is there the source WP or
metalink docs or else?

Thanks in advance.

On Aug 28, 12:18 pm, hikaru <hikaru_naruto2...@yahoo.co.jp> wrote:
> Hi all,
> I've heard Dataguard Real Time Apply feature makes Primary database to
> do a bit of overhead processes.Is that true? Is there the source WP or
> metalink docs or else?
>
> Thanks in advance.

I would start here:

http://download.oracle.com/docs/cd/B....htm#SBYDB0050

Of course I would have started with the documentation before I posted
to any newsgroup.


David Fitzjarrell

Thanks David,

Of course I would have read the document but it doesn't show that
Primary database's overhaed for real-time apply I think. right?

On Aug 28, 2:10 pm, hikaru <hikaru_naruto2...@yahoo.co.jp> wrote:
> Thanks David,
>
> Of course I would have read the document but it doesn't show that
> Primary database's overhaed for real-time apply I think. right?

What, exactly DO you want?


David Fitzjarrell

On Aug 29, 4:39 am, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:
> On Aug 28, 2:10 pm, hikaru <hikaru_naruto2...@yahoo.co.jp> wrote:
>
> > Thanks David,
>
> > Of course I would have read the document but it doesn't show that
> > Primary database's overhaed for real-time apply I think. right?
>
> What, exactly DO you want?
>
> David Fitzjarrell

sorry for unclear qestion.
I would like to know about Primary database's overhaed when I enable
real-time apply even the process takes only a few time.
because my client want to know about that.

On Aug 28, 7:18 pm, hikaru <hikaru_naruto2...@yahoo.co.jp> wrote:
> Hi all,
> I've heard Dataguard Real Time Apply feature makes Primary database to
> do a bit of overhead processes.Is that true? Is there the source WP or
> metalink docs or else?
>
> Thanks in advance.

Your version is?

Aren't you confusing real-time apply with logical standby and its
supplemental logging?

AFAIK real-time apply or delayed apply consume the same amount of
resources, and that is on the standby server for the most part.

Jerome

> Your version is?
>
> Aren't you confusing real-time apply with logical standby and its
> supplemental logging?
>
> AFAIK real-time apply or delayed apply consume the same amount of
> resources, and that is on the standby server for the most part.
>
> Jerome

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.

Thanks

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.

On Aug 29, 4: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.

This is illustrated in the diagram at the link I provided to you; the
process is on the standby server, not the primary, and thus no
additional overhead is produced on the primary.

The documentation explains this fairly well, I think.


David Fitzjarrell

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