I use a script like this, it takes file# and block# as parameters:

select owner, segment_name, partition_name, tablespace_name, extent_id
from dba_extents
where file_id = &1
and &2 between block_id and block_id + blocks – 1;

Of course if the job/session is still slow then I would run snapper on the session and see whether its perhaps hard parsing a lot or doing lots of logical IOs. In first case the application code must be changed (or cursor_sharing=force parameter can be used as a dirty workaround), in second case the heavy logical IOs may be due an inappropriate nested loop joins looping through the inner rowsources way too many times (revisiting blocks a lot etc)

Of course there are many more reasons for high CPU usage but these two are the first common ones that come into my mind.

Also you mentioned. “Even though the CPU usage is in the top of the list, it has only used 21.63% of total response time, so the rest 78% of the IO time is the “problem” here.” — what are some suggestions if its the other way around ?? Lets say i have 78% of CPU usage..what can I do to get that down?? any suggestions ?

Of course you’ve got to watch out that you’re not sampling the wrong X$ tables ultrafrequently as some X$ table access requires latch gets in order to protect the memrory structure while reading it.

The good news is that latchprof / latchprofx help to show what’s the latching impact of an X$ query…

Mike

The real trick here is that I have deliberately set the join method to NESTED LOOPS and join order so that the X$ tables are inner rowsources. Thus the nested loop join mechanism is doing the sampling for me!

And yes, you’re right, for normal tables the read consistency applies, so you see a single snapshot of data during a query execution time, that’s read consistency. But X$ tables do not have read consistency built in, thus nested loop sampling becomes possible.