PL/SQL speed issues when using a variable

Question

I have a very strange issue that is causing problems.
I am running Golden connecting to a 11g database.
I created a procedure to insert records into a table based on a query. The source query includes variables that I have populated prior to the insert statement. The problem is that if I use the variable for one very specific where statement, the statement goes from running in less than 1 second, to running in 15 minutes. It gets even more strange though. Not only does a 2nd variable not cause any problems, the exact same variable in the same statement works fine.
This procedure takes 15 minutes to run.
declare
    v_start_period date;
    v_end_period date;
begin
    select add_months(trunc(sysdate,'mm'), -1), trunc(sysdate,'mm')
    into v_start_period, v_end_period
    from dual;
    insert into RESULTS_TABLE
            (first_audit_date, last_audit_date,
            data_column1, data_column2, data_column3)
        select
            a.first_audit_date, a.last_audit_date,
            b.data_column1, b.data_column2, b.data_column3
        from
            SOURCE_TABLE_1 b,
            (select marker_id, min(action_time) as first_audit_date, max(action_time) as last_audit_date
                from SOURCE_TABLE_2
                where action_time >= v_start_period and action_time < v_end_period
                group by marker_id) a
        where b.marker_id = a.marker_id
            and exists (select 1 from SOURCE_TABLE_2
                where marker_id = b.marker_id
                and action_time >= v_start_period and action_time < v_end_period
                and action_type = 'XYZ');
    commit;
end;This procedure runs in less than 1 second, yet returns the exact same results.
declare
    v_start_period date;
    v_end_period date;
begin
    select add_months(trunc(sysdate,'mm'), -1), trunc(sysdate,'mm')
    into v_start_period, v_end_period
    from dual;
    insert into RESULTS_TABLE
            (first_audit_date, last_audit_date,
            data_column1, data_column2, data_column3)
        select
            a.first_audit_date, a.last_audit_date,
            b.data_column1, b.data_column2, b.data_column3
        from
            SOURCE_TABLE_1 b,
            (select marker_id, min(action_time) as first_audit_date, max(action_time) as last_audit_date
                from SOURCE_TABLE_2
                where action_time >= v_start_period and action_time < trunc(sysdate,'mm')
                group by marker_id) a
        where b.marker_id = a.marker_id
            and exists (select 1 from SOURCE_TABLE_2
                where marker_id = b.marker_id
                and action_time >= v_start_period and action_time < v_end_period
                and action_type = 'XYZ');
    commit;
end;The only difference between the two is where I replace the first v_end_period variable with trunc(sysdate,'mm').
I've been googling for possible solutions and keep running into something called "parameter sniffing". It appears to be a SQL Server issue though, as I cannot find solutions for Oracle. I tried nesting the insert statement inside it's own procedure with new variables populated by the old variables, but nothing changed.
Edited by: user_7000017 on Jan 8, 2013 9:45 AM
Edited by: user_7000017 on Jan 8, 2013 9:52 AM Put the code in code tags.

Answer 1

You are not describing procedures. You are listing anonymous PL/SQL blocks.
As for the code - this approach to assigning PL/SQL variables are highly questionable. As the functions are native PL/SQL functions too, there is no need to parse and execute a SQL cursor, do context switching, in order to assign values to PL/SQL variables.
This is wrong:
select
    add_months(trunc(sysdate,'mm'), -1), trunc(sysdate,'mm')
    into v_start_period, v_end_period
from dual;This is correct:
v_start_period := add_months(trunc(sysdate,'mm'), -1);
v_end_period := trunc(sysdate,'mm');Just as you would not use +"select 1 into plVariable from dual;+", instead of a standard variable assignment statement like +"plVariable := 1;"+.
As for the performance/execution difference. Does not make sense. I suggest simplifying the code in order to isolate the problem. For example, take that in-line SQL (aliased as a in the main SQL) and create a testcase where it uses the function, versus a PL/SQL bind variable with the same data type and value as that returned by the function. Examine and compare the execution plans.
Increase complexity (if no error) and repeat. Until the error is isolated.
The 1st step in any troubleshooting, is IDENTIFYING the problem. Without knowing what the problem is, how can one fix it?