The DB File Sequential Read wait event generally indicates a single block read (an index read,
for example). A large number could indicate poor joining orders of tables or unselective indexing.
This number will certainly be large (normally) for a high-transaction, well-tuned system. You
should correlate this wait with other known issues within the STATSPACK report such as
inefficient SQL. Check to ensure index scans are necessary and check join orders for multiple
table joins. The DB_CACHE_SIZE will also be a determining factor in how often these waits show
up; hash-area joins causing problems should show up in the PGA memory but similarly are
memory hogs that can cause high wait numbers for sequential reads or can also show up as
direct path read/write waits. Range scans can read a lot of blocks if the data is spread in many
different blocks (density within blocks could cause issues with range scans, and reverse key
indexes could be problematic with range scans). Loading data in a sorted manner can help
range scans and reduce the number of blocks read. Partitioning can help, as it can eliminate
some blocks. Look for unselective indexes that are causing a lot of these. Locate the data on
disk systems that either have more disk caching and/or are buffered by OS file system cache.
Correlated to the waits are the values for P1,P2,P3=file, block, blocks.