Tuning PL/SQL - tkprof shows much more work for RECURSIVE STATEMENTS

Question

Hi,
Firstly I'm not sure if this should be in "Database - General" or "SQL and PL/SQL". Since it's more of a performance tuning question than specifically about the PL/SQL, I'm going to put it here in "Database - General". I hope that doesn't offend anyone.
I've just started looking at a reported performance problem in our app. One of the developers set me up a procedure that replicates the issue, I ran it while tracing the session and then fed the trace file to tkprof. The results at the bottom of my tkprof output file look like this:
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.01       0.07         10         60          0           0
Execute      3      0.01       0.01          0          3          0           3
Fetch        0      0.00       0.00          0          0          0           0
total        6      0.03       0.08         10         63          0           3
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       5        0.00          0.00
  SQL*Net message from client                     4        1.68          1.70
  db file sequential read                        18        0.01          0.10
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse      416      0.00       0.01          0          0          2           0
Execute   1456      0.71       0.75         26       1739        425         590
Fetch     2932      0.12       2.21        337       6338          0        3061
total     4804      0.84       2.98        363       8077        427        3651
Misses in library cache during parse: 25
Misses in library cache during execute: 24
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                       343        0.08          2.09
  db file scattered read                          1        0.00          0.00
   47  user  SQL statements in session.
  888  internal SQL statements in session.
  935  SQL statements in session.
   31  statements EXPLAINed in this session.I'm looking in particular at that relatively high activity for RECURSIVE STATEMENTS, because to me, the NON-RECURSIVE (ie the actual submitted statements that form our code) looks pretty harmless. This is my first experience of trying to tune some complex looking PL/SQL and I've no idea what could be considered more "normal", but from what I think I know, and google searches, the results look quite odd to me.
Is this high activity for RECURSIVE STATEMENTS a problem, and if so, what should I start looking at to reduce that activity?
Regards,
Ados

Answer 1

If you have a PLSQL block or stored procedure running SQL statements, the SQL statements, too, will appear as RECURSIVE STATEMENTS in the trace file and tkprof.
It is a misconception that RECURSIVE STATEMENTS are only SYS statements doing data dictionary lookups / updates.
For example, I ran this :
SQL> create or replace procedure test_procedure as
  2  begin
  3  insert into my_emp_table select * from my_emp_table;
  4  dbms_output.put_line('Rows Inserted :  ' || sql%rowcount);
  5  insert into my_emp_table select * from my_emp_table where emplid=1;
  6  dbms_output.put_line('Rows Inserted :  ' || sql%rowcount);
  7  end;
  8  /
Procedure created.
SQL> alter session set events '10046 trace name context forever, level 8';
Session altered.
SQL> execute test_procedure;
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> select 'x' from dual;
x
SQL> exitThe tkprof shows ;
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          1           1
Fetch        2      0.00       0.00          0          0          0           1
total        8      0.00       0.00          0          0          1           2
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       5        0.00          0.00
  SQL*Net message from client                     5        5.31         11.97
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        4      0.00       0.00          0          2          0           0
Execute      4      0.00       0.00          2         16          7           5
Fetch        2      0.00       0.00          0         14          0           2
total       10      0.01       0.01          2         32          7           7
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                         2        0.00          0.00
    7  user  SQL statements in session.
    0  internal SQL statements in session.
    7  SQL statements in session.Which were the Non-Recursive statements ?
BEGIN test_procedure; END;
commit
select 'x' from  dualWhich were the RECURSIVE statements (which you can identify by the keywords : (recursive depth) ?
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
  NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
  NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
  NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("MY_EMP_TABLE") FULL("MY_EMP_TABLE")
  NO_PARALLEL_INDEX("MY_EMP_TABLE") */ :"SYS_B_2" AS C1, :"SYS_B_3" AS C2
  FROM "MY_EMP_TABLE" "MY_EMP_TABLE") SAMPLESUB
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          7          0           1
total        3      0.00       0.00          0          7          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 2)
INSERT INTO MY_EMP_TABLE SELECT * FROM MY_EMP_TABLE
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          1          0           0
Execute      1      0.00       0.00          2          8          4           3
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          2          9          4           3
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 1)
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
  NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
  NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
  NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("MY_EMP_TABLE")
  FULL("MY_EMP_TABLE") NO_PARALLEL_INDEX("MY_EMP_TABLE") */ :"SYS_B_2" AS C1,
  CASE WHEN "MY_EMP_TABLE"."EMPLID"=:"SYS_B_3" THEN :"SYS_B_4" ELSE
  :"SYS_B_5" END AS C2 FROM "MY_EMP_TABLE" "MY_EMP_TABLE") SAMPLESUB
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          7          0           1
total        3      0.00       0.00          0          7          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 2)
INSERT INTO MY_EMP_TABLE SELECT * FROM MY_EMP_TABLE WHERE EMPLID=1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          1          0           0
Execute      1      0.00       0.00          0          8          3           2
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          9          3           2
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 1)The INSERT statments are recursive depth 1 while the SELECTS they cause are recursive depth 2.
Note that neither of these are are actually SYS statements agaisnt the data dictionary !!
Edit :
IF you read the last few lines, it would become evident that some (in my case all) the RECURSIVE STATEMENTS are non-SYS statements, actually being my code, not Oracle's code.
       1  session in tracefile.
       7  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       7  SQL statements in trace file.
       7  unique SQL statements in trace file.
      87  lines in trace file.
       6  elapsed seconds in trace file.I have 3 non-recursive and 4 "RECURSIVE" statements. All 7 are correctly identified as "user SQL statements in trace file".
Hemant K Chitale
http://hemantoracledba.blogspot.com
Edited by: Hemant K Chitale on Jul 29, 2009 11:44 PM
Edited by: Hemant K Chitale on Jul 29, 2009 11:47 PM