SQL Tuning Advisor evaluates statement using wrong plan_hash_value

Question

The execution plan for one of my SQL statements changed this morning. The statement is in a third-party package. The new plan runs worse than the old plan. I had the SQL tuning advisor evaluate the statement. I ran it three times. Each time it evaluated the original plan, not the new one. I can tell that because the plan_hash_value shown in the advisor's recommendations is the old plan's plan_hash_value. The old plan no longer appears in DBA_HIST_SQL_PLAN. I do not understand why the advisor is using the original plan, nor where it is getting it. It does not show up in Oracle Enterprise Manager either.
Has anyone see this before?
Do you have any suggestions how I can force the advisor to evaluate the new execution plan?
I am running Oracle Database Server 10gR2 Enterprise Edition.
Thanks,
Bill

Answer 1

Following advice given earlier, I ran the SQL Tuning Advisor by executing DBMS_SQLTUNE from within a SQL*Plus session instead of via Oracle Enterprise Manager. The problem I originally encountered in OEM also happened using DBMS_SQLTUNE. Using DBMS_SQLTUNE I specified plan_hash_value => '3657286666' but the results of running create_tuning_task shows that the utility used a different plan_hash_value. See below:
Based on this, I think the problem I originally blamed on OEM's creation of a SQL Tuning Advisor job was misdirected. I now believe that OEM supplied the proper information to the advisor, but the advisor did not correctly use what is was given.
Below is what I submitted when I ran create_tuning_task and execute_tuning_task. Note that the value assigned to plan_hash_value is 3657286666. Following the messages from execute_tuning_task, see the output produced by the execution of report_tuning_task. In EXPLAIN PLANS SECTION heading 1 - ORIGINAL, note that Plan Hash Value = 3541843898.
I submitted instructions to use plan_hash_value 3657286666 but instead it used 3541843898. Why did it do this??????
I have not found a published bug that describes this condition.
Thanks,
Bill
SQL> DECLARE
2 stmt_task VARCHAR2(64);
3 BEGIN
4 stmt_task:=dbms_sqltune.create_tuning_task(sql_id => 'ab30ujpshkur3', plan_hash_
value => '3657286666', time_limit => 3600, task_name => 'Tune_ab30ujpshkur3_3657286666'
, description => 'Task to tune sql_id ab30ujpshkur3 plan_hash_value 3657286666');
5 END;
6 /
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_sqltune.execute_tuning_task('Tune_ab30ujpshkur3_3657286666');
PL/SQL procedure successfully completed.
Here is the output produced by report_tuning_task:
SQL> SET linesize 200
SQL> SET LONG 999999999
SQL> SET pages 1000
SQL> SET longchunksize 20000
SQL> SELECT dbms_sqltune.report_tuning_task('Tune_ab30ujpshkur3_3657286666', 'TEXT', 'ALL') FROM dual;
SELECT dbms_sqltune.script_tuning_task('Tune_ab30ujpshkur3_3657286666', 'ALL')
FROM dual;
DBMS_SQLTUNE.REPORT_TUNING_TASK('TUNE_AB30UJPSHKUR3_3657286666','TEXT','ALL')
GENERAL INFORMATION SECTION
Tuning Task Name : Tune_ab30ujpshkur3_3657286666
Tuning Task Owner : EXPTEST
Tuning Task ID : 110190
Scope : COMPREHENSIVE
Time Limit(seconds) : 3600
Completion Status : COMPLETED
Started at : 08/03/2012 14:47:45
Completed at : 08/03/2012 14:48:54
Number of Index Findings : 1
Schema Name: EXPTEST
SQL ID : ab30ujpshkur3
SQL Text : SELECT ATTACHED_ACC_ID FROM SERVICE_EVENTS WHERE TSERV_ID = :B4
AND EQ_NBR = :B3 AND ASSOC_EQ_NBR = :B2 AND (PERFORMED <= :B1 +
1/1440 AND PERFORMED >= :B1 - 1/1440)
FINDINGS SECTION (1 finding)
1- Index Finding (see explain plans section below)
The execution plan of this statement can be improved by creating one or more
indices.
Recommendation (estimated benefit: 100%)
- Consider running the Access Advisor to improve the physical schema design
or creating the recommended index.
create index EXPTEST.IDX$$_1AE6E0001 on
EXPTEST.SERVICE_EVENTS('EQ_NBR','ASSOC_EQ_NBR');
Rationale
Creating the recommended indices significantly improves the execution plan
of this statement. However, it might be preferable to run "Access Advisor"
using a representative SQL workload as opposed to a single statement. This
will allow to get comprehensive index recommendations which takes into
account index maintenance overhead and additional space consumption.
EXPLAIN PLANS SECTION
1- Original
Plan hash value: 3541843898
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
Time |
| 0 | SELECT STATEMENT | | 1 | 32 | 4 (0)|
00:00:01 |
|* 1 | FILTER | | | | |
|
|* 2 | TABLE ACCESS BY INDEX ROWID| SERVICE_EVENTS | 1 | 32 | 4 (0)|
00:00:01 |
|* 3 | INDEX RANGE SCAN | SEVENTS_PERFORMED | 18 | | 2 (0)|
00:00:01 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
2 - SEL$1 / SERVICE_EVENTS@SEL$1
3 - SEL$1 / SERVICE_EVENTS@SEL$1
Predicate Information (identified by operation id):
1 - filter(:B1+.000694444444444444444444444444444444444444>=:B1-.0006944444444444444
444
44444444444444444444)
2 - filter("EQ_NBR"=:B3 AND "ASSOC_EQ_NBR"=:B2 AND "TSERV_ID"=:B4)
3 - access("PERFORMED">=:B1-.000694444444444444444444444444444444444444 AND
"PERFORMED"<=:B1+.000694444444444444444444444444444444444444)
Column Projection Information (identified by operation id):
1 - "ATTACHED_ACC_ID"[VARCHAR2,12]
2 - "ATTACHED_ACC_ID"[VARCHAR2,12]
3 - "SERVICE_EVENTS".ROWID[ROWID,10]
2- Using New Indices
Plan hash value: 2568062050
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| T
ime |
| 0 | SELECT STATEMENT | | 1 | 32 | 2 (0)| 0
0:00:01 |
|* 1 | FILTER | | | | |
|
|* 2 | TABLE ACCESS BY INDEX ROWID| SERVICE_EVENTS | 1 | 32 | 2 (0)| 0
0:00:01 |
|* 3 | INDEX RANGE SCAN | IDX$$_1AE6E0001 | 1 | | 2 (0)| 0
0:00:01 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
2 - SEL$1 / SERVICE_EVENTS@SEL$1
3 - SEL$1 / SERVICE_EVENTS@SEL$1
Predicate Information (identified by operation id):
1 - filter(:B1+.000694444444444444444444444444444444444444>=:B1-.0006944444444444444
4
4444444444444444444444)
2 - filter("TSERV_ID"=:B4 AND "PERFORMED">=:B1-.000694444444444444444444444444444444
4
44444 AND "PERFORMED"<=:B1+.000694444444444444444444444444444444444444)
3 - access("EQ_NBR"=:B3 AND "ASSOC_EQ_NBR"=:B2)
Column Projection Information (identified by operation id):
1 - "ATTACHED_ACC_ID"[VARCHAR2,12]
2 - "ATTACHED_ACC_ID"[VARCHAR2,12]
3 - "SERVICE_EVENTS".ROWID[ROWID,10]
SQL> 2
DBMS_SQLTUNE.SCRIPT_TUNING_TASK('TUNE_AB30UJPSHKUR3_3657286666','ALL')
-- Script generated by DBMS_SQLTUNE package, advisor framework --
-- Use this script to implement some of the recommendations --
-- made by the SQL tuning advisor. --
-- NOTE: this script may need to be edited for your system --
-- (index names, privileges, etc) before it is executed. --
create index EXPTEST.IDX$$_1AE6E0001 on EXPTEST.SERVICE_EVENTS('EQ_NBR','ASSOC_EQ_NBR')
;