Re: Log file I/O throughput

mccmx_at_hotmail.com (Matt) wrote in message news:<cfee5bcf.0308130306.72bacefe_at_posting.google.com>...
> Thanks very much for your response.
>
> The fact that the wait count is so high but the OS I/O is not
> bottlenecked must mean that the commit rate is much too high.
>
> I will speak to the app provider about increasing the commit
> interval....
>
> Matt
>
> Stephan Bressler <agadir_at_web.de> wrote in message news:<3F378225.5000101_at_web.de>...
> > > By far the most significant waits occuring in the database are for
> > > 'log file sync' and 'log file parallel write'.
> ... snip
> > > The reason I am hesitating is that the Unix Sys Admin (HP-UX) has run
> > > some I/O diagnostics on the server (sar, glance, and iostat) and we
> > > can see that there
> > > is no bottleneck at the operating system level. However I know for
> > > sure that Oracle is generating at least 100 x 80Mb redo log files
> > > every day.
> .. snip
> > > Any ideas....?
> > Hi,
> >
> > your redo writing is fast? Still have waits?
> > That usually indicates that your session are doing many short
> > transactions. A session has to wait on every commit for the lgwr to
> > flush the redo log buffer. Even on very fast disks this take 5-10msec,
> > exspecially if you configure several log groups.
> > So go and check the number of user commits and the relation of "redo
> > writes" (=background writes) and "redo synch writes" (=forced writes).
> > I believe the only working solution in your case to lower the commit rate.
> >

Maybe shrink the log buffer size, so the write gets kicked off more often by filling rather than the commits?

See http://www.ixora.com.au/q+a/0009/22195745.htm

> > Regards
> > Stephan

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/tue/business/news_1b12micro.html