Eyal Markovich

“db file sequential read” wait event

By Eyal Markovich
Bookmark/FavoritesFacebookDeliciousDiggGoogle+LinkedInTechnorati FavoritesStumbleUponTumblrTwitterShare

In a previous post, I have discussed steps and methods to calculate I/O wait from an Oracle AWR report. The key and sometimes challenge task is to identify wait events which are related to the storage. While many waits may be caused by I/O related performance issues, the following waits are the main ones on which Oracle foreground session will be waiting:

  • db file sequential read
  • db file scattered read
  • direct path read
  • direct path read temp
  • direct path write temp
  • free buffer wait
  • log file sync
  • read by other session

In the next few posts, I will explain these waits. This important information is taken from the Oracle performance white paper written by Bartal Vindzberg (availability of this white paper will be posted in a future blog article). 

I shall start with the wait event that is most associated with slow storage causing end-user delays, the Db file sequential read.  This event represents a wait for a physical read of a single Oracle block from the disk. It is usually caused by reading an index block or accessing a table via a rowid (after it was obtained from an index block). Although the name may suggest that sequential I/O access path is being used, actually this event indicates random I/O access pattern. The following SQL statement illustrates a table that is being accessed via an index resulting in reads of a single block (one to access the index and another one to access the table):

 

The following diagram illustrates an Oracle shadow process that reads one block from the disk and places it in the buffer cache in the SGA (System Global Area):

 

Db file sequential read is almost always associated with index access path that reads a single block into the buffer cache. If a query performs multiple reads of single blocks (which results in several Db file sequential read waits) , the blocks most likely will not be adjacent on disk, resulting in Random I/Os.

Db file sequential read is the common wait event associated with disk I/O.

A performance of application that suffers from high percentage of Db file sequential read will almost always improve its performance with  low latency storage.

Bookmark/FavoritesFacebookDeliciousDiggGoogle+LinkedInTechnorati FavoritesStumbleUponTumblrTwitterShare

Tags: , , , , , ,

This entry was posted on Wednesday, August 31st, 2011 at 8:44 pm and is filed under Oracle Database Performance. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

One Response to ““db file sequential read” wait event”

  1. Steve Howard says:

    It’s not always an I/O problem, which I have fought against for years. See below…

    We see that our average wait time produced by 10046 traces of our application is 66 milliseconds during a test. DBA’s quickly begin pointing the finger at the storage guys saying we need faster disks, or a faster SAN, or more HBA’s in the servers…

    CMHLDJDADB01:oracle:cmhdjda1:/u01/app/oracle/diag/rdbms/cmhdjda/cmhdjda1/trace>awk ‘$0 ~ “db file seq” {s+=$8;i++} END {print s/1000000,s/1000/i,i}’ cmhdjda1_ora*trc
    27085.4 66.2747 408683

    However, when we look at the server, it is absolutely buried. The state that is maintained for a process when it hands the I/O off to the OS and when it returns is just greatly elongated since it the OS scheduler is busier than a one legged riverdancer. The number is correct, it is just seeing a massive amount of OS queueing.

    CMHLDJDADB01:oracle:cmhdjda1:/u01/app/oracle/diag/rdbms/cmhdjda/cmhdjda1/trace>sar -u 1 5
    Linux 2.6.18-308.1.1.el5 (CMHLDJDADB01) 03/28/2012

    03:49:18 PM CPU %user %nice %system %iowait %steal %idle
    03:49:19 PM all 60.83 0.00 27.19 11.98 0.00 0.00
    03:49:21 PM all 62.75 0.00 30.88 6.37 0.00 0.00
    03:49:22 PM all 62.86 0.00 28.10 9.05 0.00 0.00
    03:49:23 PM all 60.93 0.00 26.51 12.56 0.00 0.00
    03:49:24 PM all 61.24 0.00 29.19 9.57 0.00 0.00
    Average: all 61.71 0.00 28.34 9.95 0.00 0.00
    CMHLDJDADB01:oracle:cmhdjda1:/u01/app/oracle/diag/rdbms/cmhdjda/cmhdjda1/trace>

    Maybe faster disks or whatever would help, but if your server is overutilized, you will also see high db file sequential read waits.

    If CPU is not highly utilized, yep, chances are it is an I/O issue.

Leave a Reply

*

*