How to Reduce DB File Sequential Read Wait

DB File Sequential Read wait event occurs when we are trying to access data using index and oracle is waiting
for the read of index block from disk to buffer cache to complete. A sequential read is a single-block read.Single
block I/Os are usually the result of using indexes. Rarely, full table scan calls could get truncated to a single block
call due to extent boundaries, or buffers already present in the buffer cache.Db file sequential read wait events
may also appear when undo blocks are read from disk in order to provide a consistent get(rarely).
To determine the actual object being waited can be checked by the p1, p2, p3 info in v$session_wait . A sequential
read is usually a single-block read, although it is possible to see sequential reads for more than one block (See P3).
This wait may also be seen for reads from datafile headers (P2 indicates a file header read) ,where p1,p2 and
p3 gives the the absolute file number ,the block being read ,and the number of blocks (i.e, P3 should be 1)
respectively.
Block reads are fairly inevitable so the aim should be to minimise un-necessary IO. This is best achieved by good
application design and efficient execution plans. Changes to execution plans can yield orders of magnitude changes
in performance.Hence to reduce this wait event follow the below points .
1.) Tune Oracle - tuning SQL statements to reduce unnecessary I/O request is the only guaranteed way to reduce
"db file sequential read" wait time.
2.) Tune Physical Devices - Distribute(stripe) the data on diferent disk to reduce the i/o . Logical distribution is
useless. "Physical" I/O performance is only governed by "independency of devices".
3.) Faster Disk - Buy the faster disk to reduce the unnecessary I/O request .
4.) Increase db_block_buffers - A larger buffer cache can (not will, "might") help .

Difference between DBFile Sequential and Scattered

Reads
Submitted by admin on Wed, 2003-04-23 08:46

RDBMS Server

Both "db file sequential read" and "db file scattered read" events signify time waited for I/O read requests to complete.
Time is reported in 100's of a second for Oracle 8i releases and below, and 1000's of a second for Oracle 9i and above.
Most people confuse these events with each other as they think of how data is read from disk. Instead they should think
of how data is read into the SGA buffer cache or user PGA memory.
db file sequential read:
A sequential read operation reads data into contiguous memory (usually a single-block read with p3=1, but can be
multiple blocks). Single block I/Os are usually the result of using indexes. This event is also used for rebuilding the
controlfile and reading datafile headers (P2=1). In general, this event is indicative of disk contention on index reads.
db file scattered read:
Similar to db file sequential reads, except that the session is reading multiple data blocks and scatters them into
different discontinuous buffers in the SGA. This statistic is NORMALLY indicating disk contention on full table scans.

Rarely, data from full table scans could be fitted into a contiguous buffer area, these waits would then show up as
sequential reads instead of scattered reads. However, scattered read will never read just one block (p3 is always >= 2).
The following query shows average wait time for sequential versus
scattered reads:

SQL> tti "AVERAGE WAIT TIME FOR READ REQUESTS"

SQL>
SQL> SELECT a.average_wait "SEQ READ", b.average_wait "SCAT READ"
2

FROM sys.v_$system_event a, sys.v_$system_event b

WHERE a.event = 'db file sequential read'

AND b.event = 'db file scattered read';

SEQ READ

SCAT READ

---------- ---------.74

1.6

Wait Events & DB FILE SEQUENTIAL READ

August

26, 2011
Posted by Arvind in Oracle Performance Tuning.
trackback

Whats a Wait Event ?

An event for which a process is waiting for.
Oracle process is BUSY when it utilises the cpu time and is NOT BUSY only when its waiting for
some thing to happen.
It waits for something. WAITS FOR WHAT ? This could be various reasons and every reason
has been given a specific name and is termed to be a ORACLE WAIT EVENT.
Eg: SQL*Net message from client is a typical Wait Event.
Typical Wait Events which we commonly see are
1.db file sequential read

2.db file scattered read

3.library cache pin
4.buffer busy waits
5.free buffer waits
6.latch free
7.direct path read
8.direct path write
9.Enqueue
and Many such others
DB File Sequential Read: Oracle logs this Event is when it waits for a single block I/O read
request to complete.This occurs when read requests are against indexes segments and table(when
tables are accessed via row-ids) segments.
The db file sequential read is thus named because it reads blocks into contiguous memory from
the segment involved.
Physical I/O requests for index blocks are perfectly normal and so the presence of the db file
sequential read waits do not necessarily mean that there is something wrong with the database or
the application. The issue is not index reads, rather it is the waits that are caused by excessive
and unwarranted index reads. The performance degradation is magnified by slow I/O subsystem
and/or poor datafiles layout. The DBA should be concerned with the average I/O time and SQL
statements that spend a lot of time on this wait event.
Related Queries:
select * from v$system_event where event = db file sequential read;
select * from
v$session_event where event = db file sequential read order by
time_waited;
The best cure for the db file sequential read waits is to find and tune the SQL statement that
clocked the most time on this event. The goal of tuning is to minimize the number of logical and
physical I/Os. To capture the SQL statement, the DBA may trace the identified session using
Oracle event 10046, a third party monitoring tool, a homegrown monitoring process, or
interactive monitoring. Regardless of the method, often the job must be rerun to properly identify
the root cause of the bottleneck.

The best cure for the db file sequential read waits is to find and tune the SQL statement that
clocked the most time on this event. The goal of tuning is to minimize the number of logical and
physical I/Os. To capture the SQL statement, the DBA may trace the identified session using
Oracle event 10046, a third party monitoring tool, a homegrown monitoring process, or
interactive monitoring. Regardless of the method, often the job must be rerun to properly identify
the root cause of the bottleneck.
Below are some examples for interactive monitoring. The V$SESSION_WAIT view is the
primary source for root cause analysis. Using the values from P1 and P2, the DBA can determine
the object being read. If it is an index, and the plan calls for table access by index rowid, then it
may be worthwhile to check the clustering factor. The clustering factor of an index defines how
ordered the rows are in the index, and affects the number of I/Os required for the whole
operation. If the DBA_INDEXES.CLUSTERING_FACTOR for the index approaches the
number of blocks in the table (this is desirable), the rows are ordered. If it approaches the
number of rows in the table, the rows are randomly ordered. In such a case, it is unlikely that
index entries in the same leaf block will point to rows in the same data blocks.
Interactive monitoring has serious limitations. It is a slow manual process and many important
events can potentially be missed between sampling. It is also not practical for the DBA to baby
sit a long-running job.
Use this query to find the name of the object:
select segment_name, partition_name, segment_type, tablespace_name
from dba_extents a, v$session_wait b
where b.p2 between a.block_id and (a.block_id + a.blocks 1)
and a.file_id = b.p1
and b.event = db file sequential read;
The SQL statement associated with this event can be obtained using this query:
select a.sid, a.serial#, a.username, a.osuser, b.sql_text
from
v$session a, v$sqltext b
where a.sql_hash_value = b.hash_value
and
a.sql_address = b.address
and
a.sid in (select sid
from
v$session_wait

where event = db file sequential read)

order by a.sid, b.hash_value, b.piece;
The session waits while a sequential read from the database is performed. This event is also used
for rebuilding the control file, dumping datafile headers, and getting the database file headers.