|
Taral and Aditya, The two top wait events may well be related, but the suggested "resolution" to increase time between log switches (which is assuming that checkpoints do not happen more frequently than at log switch) is -- at best -- somewhat like suggesting that applying compression to a gushing arterial rupture is a resolution. It does not address the underlying problem. It appears that the base problem involves asynchronous write I/O from DBWR activity, wouldn't you say? What is the OS/platform and version? For datafiles, are you using "raw disk" partitions, Oracle ASM, or OS-filesystem? If OS file-system, what file-system type? What are your database parameter settings for DB_WRITER_PROCESSES, DISK_ASYNC_IO, FILESYSTEMIO_OPTIONS, and DBWR_IO_SLAVES, just for starters? Notice that you are seeing large waits on four (13) occurrences of "db file async I/O submit", averaging 4 secs per wait, but please also notice that "log file parallel write", which is write I/O from the LGWR process, seems to be operating much more normally with 1,452 occurrences averaging only 0.004 seconds per wait. Are the online redo logfiles located on different devices or disk-groups or file-system mount-points than the datafiles? Or, are they all located on the same devices, disk-groups, or file-system mount-points? Dumping FILE_NAME from DBA_DATA_FILES and MEMBER from V$LOGFILE might be useful... Hope this helps... Tim Gorman consultant -> Evergreen Database Technologies, Inc. postal => P.O. Box 630791, Highlands Ranch CO 80163-0791 website => http://www.EvDBT.com/ email => Tim@xxxxxxxxx mobile => +1-303-885-4526 fax => +1-303-484-3608 Lost Data? => http://www.ora600.be/ for info about DUDE... On 7/28/2010 1:10 PM, Taral Desai wrote: Well the real culprit would be log file switch (checkpoint incomplete)-- //www.freelists.org/webpage/oracle-l |
