SQL_TRACE a package

Question

In my EM SQL_MONITOR, Every 2-3 days Im seeing a package getting called which is generating 8.5gb of IO. It runs in 3-4 seconds. This is putting a large load on my CPU which is causing a delay for an app which needs to be tuned for same as it can timeout during this period CPU load. I can get to that later. this question is about the trace on the pkg.
In the SQL monitor, Im just seeing the package call, not any subsequent SQL calls which would generate any IO. So Im thinking I should trace the pkg. Its a prod system so a bit sensitive to putting a global trace on, so I set events for the sql_id in the hope it will catch that sql alone.
alter system set events 'sql_trace [sql:<sql_id of pkg taken from v$sqlarea>] wait=true, bind=true, plan_stat=all_executions, level=12';
Ive used this method previously to catch select traces, and works great but havent ran for a proc or pkg.
If the package has nested proc calls with their own selects, will they generate their own sql_ids that will be missed by the above trace or should that trace catch all sub queries as well?
On the IO itself, its a strange one to look at, its 8590m of IO every time, the developer who last done some work on it is adamant it shouldnt be doing anything like that which is why I gotta trace. But something doesnt look right to me.

Answer 1

hi, more on this, thanks for suggestions. I left the trace I entered above to see would that catch it. had an occurrence of it this morning, ran tkprof on the output and for the recursive statements I dont see anything heavy, a lot of small calls, but at the end of the trace file I see the pkg call as a non-recursive statement, and thats whats generating the heavy IO. check this out....
note, no clobs.
BEGIN
  app_user.package_call(:bind1);     -- pkg name changed,
END;
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute    418      8.30      24.67 4294967145 4294370939 4294918743         408
Fetch        0      0.00       0.00          0          0          0           0
total      418      8.30      24.67 4294967145 4294370939 4294918743         408
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 646
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  library cache pin                             677        0.31          0.87
  SQL*Net message to client                     418        0.00          0.00
  log file sync                                1142        0.78         12.31
  SQL*Net message to dblink                     762        0.00          0.00
  SQL*Net message from dblink                   762        0.11          1.31
  rdbms ipc reply                               736        0.02          0.12
  SQL*Net message from client                   391        0.01          0.18
  KJC: Wait for msg sends to complete            77        0.00          0.00
  SQL*Net break/reset to client                  20        0.00          0.00
  enq: JQ - contention                          331        0.08          0.30
  latch free                                      1        0.02          0.02
  gc current grant busy                           2        0.01          0.01
  library cache lock                              2        0.00          0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute    418      8.30      24.67 4294967145 4294370939 4294918743         408
Fetch        0      0.00       0.00          0          0          0           0
total      418      8.30      24.67 4294967145 4294370939 4294918743         408
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  library cache pin                             716        0.31          0.88
  library cache lock                             69        0.00          0.03
  SQL*Net message to client                     418        0.00          0.00
  gc current grant busy                           2        0.01          0.01
  single-task message                             1        0.03          0.03
  SQL*Net message from dblink                   885        0.11          1.41
  SQL*Net message to dblink                     884        0.00          0.00
  rdbms ipc reply                               738        0.02          0.12
  SQL*Net more data from dblink                 381        0.00          0.13
  log file sync                                1142        0.78         12.31
  SQL*Net message from client                   391        0.01          0.18
  KJC: Wait for msg sends to complete            82        0.00          0.00
  SQL*Net break/reset to client                  20        0.00          0.00
  enq: JQ - contention                          331        0.08          0.30
  latch: row cache objects                        1        0.00          0.00
  latch free                                      3        0.02          0.02
  latch: shared pool                              1        0.00          0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse    75579      4.11       7.17          0          0         12           0
Execute  78995     22.41     130.83       1593      45835     225754       20408
Fetch    52898     30.39      56.71        950    1712730         45       46680
total   207472     56.93     194.73       2543    1758565     225811       67088So now I have a good trace but still cant see whats causing that IO. In SQL monitor I can see the exact minute that pkg was called, I ran an ASH report which took in a ten minute period either side of it but its not showing up that pkg call or anythign that could be causing that IO. this is strange for me. Do non-recursive statements show up in an ASH report?