I got the trace... why do I need that?

Question

Hi Techs
Question might seems to be little stupid but I got a concern in the middle of night.
I know how to generate at 10046 level trace. I do that using below:
execute sys.dbms_system.set_ev(SID,SERIAL, 10046, LEVEL, '');
I know there are other alternates to this as well like oradebug.
I know all level of tracec 4, 8 and 12... and also I know how to generate tkprof of particular trace file and what to look into it.
What I dont know is:
1) Ok. So my 10046 trace is showing block by block read of table scan with wait event... usually I see db sequential read.
Now I would like to know why should I generate this report as I do not know how many number of blocks It was supposed to read and how much blocks it has read in actual. eg:
suppose I have a 10GB table for which a query reads almost 1GB data in it.
I assume my query will retrieve this 1GB data by reading 10000 blocks. (I am assuming here. I dont know if there is any method using which I can determine that)
But when I generate a 10046 level trace I see that query has read 20000 blocks.
So, I have a difference of 10000 blocks. What I am trying to point out is that how would I know that number of blocks my query has read was supposed to be read.
How can I be sure that my query is reading actual data related to my query and not wasting time by reading some unwanted blocks.
Hope I am a bit clear with my confusion. I just wanted to understand like why do we generate 10046 level trace then If we dont know If trace has happened at perfect level without reading any junk or unwanted blocks. There might be a situation when my stats are invalid(old) and query is performing search on unused blocks.... just to see if data is there..
Please suggest.
Thanks
Amrit

Answer 1

the trace file can & should be processed using the "tkrpof" utility
bcm@bcm-laptop:~$ tkprof
Usage: tkprof tracefile outputfile [explain= ] [table= ]
              [print= ] [insert= ] [sys= ] [sort= ]
  table=schema.tablename   Use 'schema.tablename' with 'explain=' option.
  explain=user/password    Connect to ORACLE and issue EXPLAIN PLAN.
  print=integer    List only the first 'integer' SQL statements.
  aggregate=yes|no
  insert=filename  List SQL statements and data inside INSERT statements.
  sys=no           TKPROF does not list SQL statements run as user SYS.
  record=filename  Record non-recursive statements found in the trace file.
  waits=yes|no     Record summary for any wait events found in the trace file.
  sort=option      Set of zero or more of the following sort options:
    prscnt  number of times parse was called
    prscpu  cpu time parsing
    prsela  elapsed time parsing
    prsdsk  number of disk reads during parse
    prsqry  number of buffers for consistent read during parse
    prscu   number of buffers for current read during parse
    prsmis  number of misses in library cache during parse
    execnt  number of execute was called
    execpu  cpu time spent executing
    exeela  elapsed time executing
    exedsk  number of disk reads during execute
    exeqry  number of buffers for consistent read during execute
    execu   number of buffers for current read during execute
    exerow  number of rows processed during execute
    exemis  number of library cache misses during execute
    fchcnt  number of times fetch was called
    fchcpu  cpu time spent fetching
    fchela  elapsed time fetching
    fchdsk  number of disk reads during fetch
    fchqry  number of buffers for consistent read during fetch
    fchcu   number of buffers for current read during fetch
    fchrow  number of rows fetched
    userid  userid of user that parsed the cursor