Can someone try and reproduce this possible bug with DBMS_JOB.run

Question

11.2.0.2 EE
OEL5
getting an IO dump from what looks like entire shared pool. A call to a procedure using dbms_job.run shows the dump in the plan.
Be interested to see if anyone is on 11.2.0.3 on OEL can reproduce. thanks.
sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Tue Jan 8 16:44:33 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning and Automatic Storage Management options
SQL>
SQL> ALTER Sesssion SET EVENTS '10046 trace name context forever, level 12';
System altered.
/* create a small proc that takes in a var and does nothing except set a variable */
SQL>  
SQL>   create procedure io_test ( v_in number)
  2  IS
  3     v_variable    varchar2(10);
  4    begin
  5     null;
  6  END;  
  7   
  8   
Procedure created.
/* flush the shared pool to simulate a start */
SQL> alter system flush shared_pool;
System altered.
/* set our tracefile id */
SQL> alter session set tracefile_identifier=err_test;    
Session altered.
/* call the proc from a dbms_job submission */
SQL>   declare
  2    v_job_no  number;
  3    begin
  4     Dbms_Job.SUBMIT ( job  => v_job_no
  5                    , what => 'sys.io_test('  || 1234 || ');');
  6       Dbms_Job.RUN (v_job_no);
  7     end;   
  8  /  
PL/SQL procedure successfully completed.
SQL> tkprof the trace file, go to non-recursive statements at the bottom and we see following
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.04       0.04 4294967293 4294963226 4294967122           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.04       0.04 4294967293 4294963226 4294967122           1
some behaviour notes.
1. If I call the proc directly, I dont see the huge IO, its only dbms_job.run that does it.
2. If I call the dbms_job.run a second time I dont see it, its only when I flush the shared pool which simulates the first time I could be calling the proc which is how I found it initially
3. If I call the dbms_job.run outside of a proc I do see it.
4. Watch your IO and CPU if you generate it. Huge spike to coincide with the figures in the trace.
5. 4294967293 is very close 2^32, is also the size of my shared pool so looks like entire pool is being dumped.
6. Have reproduced on 3 instances on 3 separate servers. all same version 11.2.0.2.0 and patch level which is 2012 Q2.
7. change the proc to have the variable commented out and we dont see the dump.
8. I have a call open with support a while now but havent been able to reproduce on their side. Interested to see if someone has OEL 5, 11.2.0.2 instance, can generate it and also an 11.2.0.3 instance and can show its not in that.
thanks.

Answer 1

961469 wrote:
rjamya wrote:
I am suspecting this is a tkprof issue, analyzing the same trace file via orasrp doesnt show this behavior. Also the high physical reads shown are missing in the raw trace file.Im not so sure, I can see it in the raw trace file.
do you see it in raw trace file? if so can you post the STAT line showing high disk read (pr=nnnnnnnn) values ? I dont see it in the trace file that i generated.
Raj