Professional Documents
Culture Documents
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 .
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:
SEQ READ
SCAT READ
---------- ---------.74
1.6
August
26, 2011
Posted by Arvind in Oracle Performance Tuning.
trackback
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