You can't eliminate the waits unless you never do any writes - sounds
like fairly normal activity for DBWR as thats all its does and its
main wait event is 'db file parallel write'. The only time to be
concerned about the speed of sbwr is if you see a 'free buffer waits'
which indicate that DBWR is not keeping the cache clena enough. Async
IO times are a little hard to tell from Oracle since the writes are
async and do you record the time for completions of the first write in
the batch or the last ? - but the stats from the IO susbsystems should
tell you that.
"Ethan Post" <Blah_at_Blah.com> wrote in message news:<XWoe7.161530$%a.7113965_at_news1.rdc1.sdca.home.com>...
> I have captured a bunch of session stats from V$SESSION_WAIT regarding event
> "db file parallel write". The docs state the following.
>
> Parameters:
> files
> This indicates the number of files to which the session is writing.
> blocks
> This indicates the total number of blocks to be written.
> requests
> This indicates the total number of I/O requests, which will be the same as
> blocks.
>
>
> However, p1, data file is returning values like 204. There are not 204
> datafiles in this database so where is this figure coming from? Also blocks
> shows 0 and requests shows 0. Why is a wait occuring for no blocks and no
> requests. This is the same for status = waiting and status=waited known
> time.
>
> DB_WRITERS=1. AIX 4.3.3 with the patch for async io. Oralce 8.1.6.3.
> Should I increase DB_WRITERS in this case to eliminate these waits. The
> waits are only occuring during a very intense batch processing job which we
> are trying to speed up. DBWR is not the biggest bottleneck at this point,
> LGWR is.
>
> Thanks,
> Ethan
> http://www.geocities.com/epost1
> http://www.freeocp.com
Received on Wed Aug 15 2001 - 12:00:07 CDT
