Ryan, I have found that this type of query against dba_extents performs horribly. My solution has been to create a GTT, load relevant data from dba_extents, slap an index on file_id and block_id and query the GTT. Even in some of the larger dbs I've done this on, the overall time was much less than the original query. You are on the right track, you just need to get off the congested freeway and take a back road. Daniel Fink ryan.gaffuri@xxxxxxxxxxx wrote: > I am getting excessive 'db file sequential reads' in an array insert. It is > not from the select part, since those are all table scans with 'db file > scattered reads'. This part runs pretty fast(I ran a select count(*) on it). > I am reading my 10046 trace and from v$event_name I know that p2 for db file > sequential read is the 'block#'. > Where do I find the segment that this is a part of? I look for the block in > dba_extents and it never returns? I try a variety of different block#s that I > get back and it never comes back. I think I may not get this if its part of > the 'undo' tablespace since its not static. However, I know that it is part > of a data tablespace since I checked the 'p1' value in dba_data_files? > So which view should I use to nail down where the wait is coming from? I > turned off my foreign key constraint before I started, so at this point, I > want to nail down exactly what segment is being hit with a db file sequential > read, but I cannot find it in dba_extents? ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------