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

Home -> Community -> Usenet -> c.d.o.server -> Re: redo log stats

Re: redo log stats

From: Taki P <nospam_at_localhost.spamwarn>
Date: Wed, 10 Jan 2001 02:02:16 +0100
Message-ID: <EtO66.1327$K12.3373@nntpserver.swip.net>

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:979085327.15378.0.nnrp-12.9e984b29_at_news.demon.co.uk...
>
> Taki P wrote in message ...
> >
> >Then space requests event occurences are inspired by the
 server-side
> >user processes. And the worst case number is approx. 'switches x
> >processes'? (But then, hmm, could not some background process
 (SMON?)
> >also cause this space request event?) Must user process also wait
 for
> >a complete checkpoint, during log switch (with included dirty
 buffers
> >completly written by DBWR)?
>
> No - a 'reasonable' number is approx:
> 'switches x typical number of concurrent transactions'
> a 'slightly surprising' number would be:
> 'switches x concurrent processes'

Ah, well, at first I typed 'concurrent redo-generating processes' but then (before sending it) I felt that to be too much of a invented term and maybe even a bit redundant. So I shortened it to 'processes'. I must have lost "transactions" from my dictionary cache. :-)

> A worst case could be very high - this typically
> would be caused by having log_buffer too small.

I assume user processes don't cause more than one event per process per switch, then worst case must be about 'switches x typical number of concurrent transactions'. Maybe I'm missing something obvious here.

>
> User processes do not wait for the checkpoint to
> complete, the wait at this point is simply for
> Oracle to finish writing the old redo log and
> open the file for the new redo log. This can
> actually take a small number of seconds (see
> Steve Adams website and book).
>

This explains (some of) the confusing info I've seen along the way!

>
> >
> >Perhaps possible causes for slow motioned log switch: Inadequate
 disk
> >I/O, way too big redo buffer, unusually heavy
 redo-generating/commit
> >load, ... Could take some time to analyze, it seems.
>
> Having a too big redo buffer is more likely to lead to high
> values in v$session_wait for 'log sync' and 'log write'.
>

I was under the impression that log sync waiting is posted by COMMITing transactions only.

Regards
/Fad Received on Tue Jan 09 2001 - 19:02:16 CST

Original text of this message

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