Re: Log file I/O throughput

Was down this same road last year. The application was trying to do 200 commits per second. Causes terrible perf problems on an 8x8 SUN using a SAN. Had them commit once every 10 rows and problems cleared up. Being "over committed" is in general hard on the db. Also, if you have two redo logs in each group, unless you have some sort of async io package on the box, you're redo writes are possible sequencial.

Muiltplexing dosn't solve all problems, I multiplex the the control file but lost all three copies several times on a database due to a bad memory chip that crashed the box. Files showed up with an ls but could not be read in any way.

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.
> >
> > Regards
> > Stephan
Received on Fri Aug 15 2003 - 15:15:01 CDT