Lost time in trace file

Question

There is anonimous block:
begin
  execute immediate 'alter session set tracefile_identifier = ''TS'''; 
  dbms_monitor.session_trace_enable;
  some_proc(true);
end;Procedure some_proc consists following code
loop
  select val into i from a where par = 'Bar';
  if i = 'EXIT' then
    exit;
  end if;
  for cur in (select fld from t order by r) loop
    processing(cur);
  end loop;
end loop;Tables A and t is very small tables. So table t is empty.
As you can see, expected than will be works loop and select from very small table.
I have executed the block, and it works about 477 seconds.
   select value
  2      from v$sesstat s
  3   natural
  4      join v$statname n
  5     where sid = sys_context('USERENV', 'SID')
  6       and name = 'CPU used by this session';
     VALUE
         2
declare
  2    t date;
  3  begin
  4    execute immediate 'alter session set tracefile_identifier = ''TS''';
  5    dbms_monitor.session_trace_enable;
  6    come_proc(true);
  7  end;
  8  /
PL/SQL procedure successfully completed.
Elapsed: 00:07:57.63
   select value
  2      from v$sesstat s
  3   natural
  4      join v$statname n
  5     where sid = sys_context('USERENV', 'SID')
  6       and name = 'CPU used by this session';
     VALUE
     45175But there is some strange moments:
1. In tkprof report shows only 277.83 sec (whereas statistic "CPU usage" above is different and more appropriate, 451.75 sec.)
declare
  t date;
begin
  execute immediate 'alter session set tracefile_identifier = ''TS''';
  dbms_monitor.session_trace_enable;
  some_proc(true);
end;
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1    260.95     277.83          0         64          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        1    260.95     277.83          0         64          0           1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 10757 
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1       20.64         20.64
SELECT VAL
FROM
A WHERE PAR = 'BAR'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute 1782640     29.01      28.20          0          0          0           0
Fetch   1782640     32.78      31.77          0    5347922          0     1782640
total   3565281     61.80      59.97          0    5347922          0     1782640
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 43     (recursive depth: 1)
Rows     Row Source Operation
1782640  INDEX RANGE SCAN A_UI (cr=5347922 pr=0 pw=0 time=31762812 us)(object id 530778)
SELECT FLD
FROM
T ORDER BY R
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.01          0          0          0           0
Execute 1782639     33.21      31.91          0          0          0           0
Fetch   1782639     95.52      95.82          0   12478473          0           0
total   3565279    128.74     127.75          0   12478473          0           0
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 43     (recursive depth: 1)
Rows     Row Source Operation
      0  SORT ORDER BY (cr=12478473 pr=0 pw=0 time=103178656 us)
      0   PARTITION RANGE SINGLE PARTITION: 1 1 (cr=12478473 pr=0 pw=0 time=92028737 us)
      0    TABLE ACCESS FULL T PARTITION: 1 1 (cr=12478473 pr=0 pw=0 time=86376673 us)2. In raw trace very many rows with c=0. And somtimes there is rows with c=1000
EXEC #9:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912283
FETCH #9:c=0,e=42,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912345
EXEC #8:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912395
FETCH #8:c=0,e=13,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451912427
EXEC #9:c=0,e=14,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912475
FETCH #9:c=0,e=37,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912534
EXEC #8:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912580
FETCH #8:c=0,e=12,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451912612
EXEC #9:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912659
FETCH #9:c=0,e=39,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912718
EXEC #8:c=0,e=16,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912807
FETCH #8:c=0,e=14,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451912865
EXEC #9:c=0,e=14,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912916
FETCH #9:c=0,e=46,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451912982
EXEC #8:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913040
FETCH #8:c=0,e=13,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451913148
EXEC #9:c=0,e=14,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913197
FETCH #9:c=0,e=40,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913256
EXEC #8:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913302
FETCH #8:c=0,e=12,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451913334
EXEC #9:c=0,e=14,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913381
FETCH #9:c=0,e=39,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913440
EXEC #8:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913487
FETCH #8:c=0,e=19,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451913525
EXEC #9:c=0,e=18,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913590
FETCH #9:c=0,e=36,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913661
EXEC #8:c=10000,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913710
FETCH #8:c=0,e=13,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451913742
EXEC #9:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913790
FETCH #9:c=0,e=37,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913846
EXEC #8:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913893
FETCH #8:c=0,e=12,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451913924
EXEC #9:c=0,e=18,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451913996
FETCH #9:c=0,e=51,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451914077
EXEC #8:c=0,e=18,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451914149
FETCH #8:c=0,e=17,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=2,tim=5857451914207
EXEC #9:c=0,e=14,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451914284
FETCH #9:c=0,e=37,p=0,cr=7,cu=0,mis=0,r=0,dep=1,og=2,tim=5857451914347Questions:
1. How do you think, lost time is time spent
a. in PLSQL engine during context switch,
b. or lost time is time spent in SQL processing where CPU time is less than minimum accurancy (0.01s)
c. or time lost during write in trace file (trace overhead)?
2. Value c=10000 is accumulated value? I think no, may be I am wrong?
But if I right, and time of processing was smaller than 0.01s, CPU time in tkprof will equal to zero, right?
And from this point of view, strange that CPU time and elapsed time is near.
3. Write in trace file is included into "elapsed time" in tracefile steps, e.g. "execute" and "fetch"?
In other words I want more deeply understand process of SQL processing and trace.

Answer 1

What version of Oracle are you using?
Can you post the entire contents of the trace file?