'db file parallel read' occurs during recovery. The datablocks that need to be changed are read from various datafiles and are placed in non-contiguous buffer blocks. The server process waits till all the blocks are read in to the buffer.
Tuning options - same as db file sequential read.
'db file parallel write' occurs when database writer (DBWr) is performing parallel write to files and blocks. Check the average_wait in V$SYSTEM_EVENT, if it is greater than 10 milliseconds then it signals a slow IO throughput.
Tuning options - The main blocker for this wait event is the OS I/O sub systems. Hence use OS monitoring tools (sar -d, iostat) to check the write performance. To improve the average_wait time you can consider the following,
If the data files reside on raw devices use asynchronous writes. However if the data files reside on cooked file systems use synchronous writes with direct IO.
Note: If the average_wait time for db file parallel write is high then you may see that the system waits on free buffer waits event.
Thanks
Monday, August 17, 2009
Subscribe to:
Post Comments (Atom)
1 comment:
Funnily enough, I came here because I got this wait event and I'm not doing recovery. It seems Oracle keeps track of x$kcbkpfs statistics, to figure out if putting together a bunch of single blocks reads to prefetch multiple blocks is doing better or worse than not putting them together. In my case, it seems to come to the wrong decision because the normal operations are different than the mass read a program is doing right now. So I have massive waits on this, users are asking how long until it finishes, since they don't remember it taking this long last year, and 'taint nuthin' I can do about it, apparently. I, and I'm sure others who have been asking for years, would be open to other suggestions.
word: trownsio
Post a Comment