Re: log file sync vs log file parallel write probably not bug 2669566

On Nov 6, 10:51 am, HansP <hans-peter.sl..._at_atosorigin.com> wrote:
> > This is a wild guess, based on the 10g docs, which may or may not
> > apply or work the same:
>
> > The log file parallel write includes the I/O time only.  The log file
> > sync includes the time the log writer has to wait for the db writer
> > to
> > tell the log writer the redo is done (all those "private strand flush
> > incomplete" notifications in the 10g alert log), as well as all the
> > other
> > overhead of the interprocess communication.
>
> >http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitev...
>
> > jg
> > --
> > @home.com is bogus.
> > Ya win some, ya lose some.
>
> Yes the includes waiting for the log file parallel write by the log
> writer and some overhead (signalling each other etc)
> Therefore I would expect the for the log file sync be a little more
> than the time for the log file parallel write but not 10 to 20 time
> the
> time for the log file parallel write.
>
> regards Hans-Peter

This includes the time spent by the process waiting for signal that log file sync is complete and then time spent in the OS run queue waiting for the CPU, plus the time occasionally spent by the LGWR in the run queue. Kevin Closson covered this issue in great detail in his blog here:
http://kevinclosson.wordpress.com/2007/07/21/manly-men-only-use-solid-state-disk-for-redo-logging-lgwr-io-is-simple-but-not-lgwr-processing/. One of the suggestions in that post is to renice the LGWR to the highest priority possible so that it always gets CPU time when it needs before anything else does, and is not preempted by less important processes. Another post that might be helpful is here: http://www.pythian.com/blogs/1098/tuning-log-file-sync-event-waits.

Hth,

   Vladimir M. Zakharychev
   N-Networks, makers of Dynamic PSP(tm)    http://www.dynamicpsp.com Received on Thu Nov 06 2008 - 04:24:22 CST