Automatic SQL Tuning in Oracle Database 10g

• Overview
• SQL Tuning Advisor
• Managing SQL Profiles
• SQL Tuning Sets
• Useful Views

Overview

• Statistics Analysis - The optimizer recommends the gathering of statistics on objects with missing or stale statistics. Additional statistics for these objects are stored in an SQL profile.
  
  
• SQL Profiling - The optimizer may be able to improve performance by gathering additional statistics and altering session specific parameters such as the OPTIMIZER_MODE. If such improvements are possible the information is stored in an SQL profile. If accepted this information can then used by the optimizer when running in normal mode. Unlike a stored outline which fixes the execution plan, an SQL profile may still be of benefit when the contents of the table alter drastically. Even so, it's sensible to update profiles periodically. The SQL profiling is not performed when the tuining optimizer is run in limited mode.
  
  
• Access Path Analysis - The optimizer investigates the effect of new or modified indexes on the access path. It's index recommendations relate to a specific statement so where necessary it will also suggest the use of the SQL Access Advisor to check the impact of these indexes on a representative SQL workload.
  
  
• SQL Structure Analysis - The optimizer suggests alternatives for SQL statements that contain structures that may impact on performance. The implementation of these suggestions requires human intervention to check their validity.

SQL Tuning Advisor

CONN sys/password AS SYSDBA
GRANT ADVISOR TO scott;
CONN scott/tiger

SET SERVEROUTPUT ON

-- Tuning task created for specific a statement from the AWR.
DECLARE
  l_sql_tune_task_id  VARCHAR2(100);
BEGIN
  l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
                          begin_snap  => 764,
                          end_snap    => 938,
                          sql_id      => '19v5guvsgcd1v',
                          scope       => DBMS_SQLTUNE.scope_comprehensive,
                          time_limit  => 60,
                          task_name   => '19v5guvsgcd1v_AWR_tuning_task',
                          description => 'Tuning task for statement 19v5guvsgcd1v in AWR.');
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

-- Tuning task created for specific a statement from the cursor cache.
DECLARE
  l_sql_tune_task_id  VARCHAR2(100);
BEGIN
  l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
                          sql_id      => '19v5guvsgcd1v',
                          scope       => DBMS_SQLTUNE.scope_comprehensive,
                          time_limit  => 60,
                          task_name   => '19v5guvsgcd1v_tuning_task',
                          description => 'Tuning task for statement 19v5guvsgcd1v.');
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

-- Tuning task created from an SQL tuning set.
DECLARE
  l_sql_tune_task_id  VARCHAR2(100);
BEGIN
  l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
                          sqlset_name => 'test_sql_tuning_set',
                          scope       => DBMS_SQLTUNE.scope_comprehensive,
                          time_limit  => 60,
                          task_name   => 'sqlset_tuning_task',
                          description => 'Tuning task for an SQL tuning set.');
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

-- Tuning task created for a manually specified statement.
DECLARE
  l_sql               VARCHAR2(500);
  l_sql_tune_task_id  VARCHAR2(100);
BEGIN
  l_sql := 'SELECT e.*, d.* ' ||
           'FROM   emp e JOIN dept d ON e.deptno = d.deptno ' ||
           'WHERE  NVL(empno, ''0'') = :empno';

  l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
                          sql_text    => l_sql,
                          bind_list   => sql_binds(anydata.ConvertNumber(100)),
                          user_name   => 'scott',
                          scope       => DBMS_SQLTUNE.scope_comprehensive,
                          time_limit  => 60,
                          task_name   => 'emp_dept_tuning_task',
                          description => 'Tuning task for an EMP to DEPT join query.');
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

EXEC DBMS_STATS.delete_table_stats('SCOTT','EMP');

EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'emp_dept_tuning_task');

-- Interrupt and resume a tuning task.
EXEC DBMS_SQLTUNE.interrupt_tuning_task (task_name => 'emp_dept_tuning_task');
EXEC DBMS_SQLTUNE.resume_tuning_task (task_name => 'emp_dept_tuning_task');

-- Cancel a tuning task.
EXEC DBMS_SQLTUNE.cancel_tuning_task (task_name => 'emp_dept_tuning_task');

-- Reset a tuning task allowing it to be re-executed.
EXEC DBMS_SQLTUNE.reset_tuning_task (task_name => 'emp_dept_tuning_task');

SELECT task_name, status FROM dba_advisor_log WHERE owner = 'SCOTT';

TASK_NAME                      STATUS
------------------------------ -----------
emp_dept_tuning_task           COMPLETED

1 row selected.

SET LONG 10000;
SET PAGESIZE 1000
SET LINESIZE 200
SELECT DBMS_SQLTUNE.report_tuning_task('emp_dept_tuning_task') AS recommendations FROM dual;
SET PAGESIZE 24

RECOMMENDATIONS
--------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name   : emp_dept_tuning_task
Scope              : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status  : COMPLETED
Started at         : 05/06/2004 09:29:13
Completed at       : 05/06/2004 09:29:15

-------------------------------------------------------------------------------
SQL ID  : 0wrmfv2yvswx1
SQL Text: SELECT e.*, d.* FROM   emp e JOIN dept d ON e.deptno = d.deptno
          WHERE  NVL(empno, '0') = :empno

-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- Statistics Finding
---------------------
  Table "SCOTT"."EMP" and its indices were not analyzed.

  Recommendation
  --------------
    Consider collecting optimizer statistics for this table and its indices.
    execute dbms_stats.gather_table_stats(ownname => 'SCOTT', tabname =>
            'EMP', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
            method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE)

  Rationale
  ---------
    The optimizer requires up-to-date statistics for the table and its indices
    in order to select a good execution plan.

2- Restructure SQL finding (see plan 1 in explain plans section)
----------------------------------------------------------------
  The predicate NVL("E"."EMPNO",0)=:B1 used at line ID 2 of the execution plan
  contains an expression on indexed column "EMPNO". This expression prevents
  the optimizer from selecting indices on table "SCOTT"."EMP".

  Recommendation
  --------------
    Rewrite the predicate into an equivalent form to take advantage of
    indices. Alternatively, create a function-based index on the expression.

  Rationale
  ---------
    The optimizer is unable to use an index if the predicate is an inequality
    condition or if there is an expression or an implicit data type conversion
    on the indexed column.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original
-----------
Plan hash value: 1863486531

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |   107 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |         |     1 |   107 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL          | EMP     |     1 |    87 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|   4 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement

-------------------------------------------------------------------------------


1 row selected.

BEGIN
  DBMS_SQLTUNE.drop_tuning_task (task_name => '19v5guvsgcd1v_AWR_tuning_task');
  DBMS_SQLTUNE.drop_tuning_task (task_name => '19v5guvsgcd1v_tuning_task');
  DBMS_SQLTUNE.drop_tuning_task (task_name => 'sqlset_tuning_task');
  DBMS_SQLTUNE.drop_tuning_task (task_name => 'emp_dept_tuning_task');
END;
/

Managing SQL Profiles

CONN sys/password AS SYSDBA
GRANT CREATE ANY SQL PROFILE TO scott;
GRANT DROP ANY SQL PROFILE TO scott;
GRANT ALTER ANY SQL PROFILE TO scott;
CONN scott/tiger

SET SERVEROUTPUT ON
DECLARE
  l_sql_tune_task_id  VARCHAR2(20);
BEGIN
  l_sql_tune_task_id := DBMS_SQLTUNE.accept_sql_profile (
                          task_name => 'emp_dept_tuning_task',
                          name      => 'emp_dept_profile');
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

BEGIN
  DBMS_SQLTUNE.alter_sql_profile (
    name            => 'emp_dept_profile',
    attribute_name  => 'STATUS',
    value           => 'DISABLED');
END;
/

BEGIN
  DBMS_SQLTUNE.drop_sql_profile (
    name   => 'emp_dept_profile',
    ignore => TRUE);
END;
/

SQL Tuning Sets

CONN sys/password AS SYSDBA
GRANT ADMINISTER ANY SQL TUNING SET TO scott;
CONN scott/tiger

BEGIN
  DBMS_SQLTUNE.create_sqlset (
    sqlset_name  => 'test_sql_tuning_set',
    description  => 'A test SQL tuning set.');
END;
/

• SELECT_WORKLOAD_REPOSITORY - Retrieves statements from the Automatic Workload Repository (AWR).
• SELECT_CURSOR_CACHE - Retrieves statements from the cursor cache.
• SELECT_SQLSET - Retrieves statements from another SQL tuning set.

-- Load the SQL set from the Automatic Workload Repository (AWR).
DECLARE
  l_cursor  DBMS_SQLTUNE.sqlset_cursor;
BEGIN
  OPEN l_cursor FOR
    SELECT VALUE(p)
    FROM   TABLE (DBMS_SQLTUNE.select_workload_repository (
                    765,  -- begin_snap
                    766,  -- end_snap
                    NULL, -- basic_filter
                    NULL, -- object_filter
                    NULL, -- ranking_measure1
                    NULL, -- ranking_measure2
                    NULL, -- ranking_measure3
                    NULL, -- result_percentage
                    10)   -- result_limit
                  ) p;

  DBMS_SQLTUNE.load_sqlset (
    sqlset_name     => 'test_sql_tuning_set',
    populate_cursor => l_cursor);
END;
/

-- Load the SQL set from the cursor cache.
DECLARE
  l_cursor  DBMS_SQLTUNE.sqlset_cursor;
BEGIN
  OPEN l_cursor FOR
    SELECT VALUE(p)
    FROM   TABLE (DBMS_SQLTUNE.select_cursor_cache (
                    NULL, -- basic_filter
                    NULL, -- object_filter
                    NULL, -- ranking_measure1
                    NULL, -- ranking_measure2
                    NULL, -- ranking_measure3
                    NULL, -- result_percentage
                    1)    -- result_limit
                  ) p;

  DBMS_SQLTUNE.load_sqlset (
    sqlset_name     => 'test_sql_tuning_set',
    populate_cursor => l_cursor);
END;
/

-- Create a new set and load it from the existing one.
DECLARE
  l_cursor  DBMS_SQLTUNE.sqlset_cursor;
BEGIN
  DBMS_SQLTUNE.create_sqlset(
    sqlset_name  => 'test_sql_tuning_set_2',
    description  => 'Another test SQL tuning set.');

  OPEN l_cursor FOR
    SELECT VALUE(p)
    FROM   TABLE (DBMS_SQLTUNE.select_sqlset (
                    'test_sql_tuning_set', -- sqlset_name
                    NULL,                  -- basic_filter
                    NULL,                  -- object_filter
                    NULL,                  -- ranking_measure1
                    NULL,                  -- ranking_measure2
                    NULL,                  -- ranking_measure3
                    NULL,                  -- result_percentage
                    NULL)                  -- result_limit
                  ) p;

  DBMS_SQLTUNE.load_sqlset (
    sqlset_name     => 'test_sql_tuning_set_2',
    populate_cursor => l_cursor);
END;
/

SELECT *
FROM   TABLE(DBMS_SQLTUNE.select_sqlset ('test_sql_tuning_set'));

DECLARE
  l_ref_id  NUMBER;
BEGIN
  -- Add a reference to a set.
  l_ref_id := DBMS_SQLTUNE.add_sqlset_reference (
    sqlset_name => 'test_sql_tuning_set',
    reference   => 'Used for manual tuning by SQL*Plus.');

  -- Delete the reference.
  DBMS_SQLTUNE.remove_sqlset_reference (
    sqlset_name  => 'test_sql_tuning_set',
    reference_id => l_ref_id);
END;
/

BEGIN
  DBMS_SQLTUNE.update_sqlset (
    sqlset_name     => 'test_sql_tuning_set',
    sql_id          => '19v5guvsgcd1v',
    attribute_name  => 'ACTION',
    attribute_value => 'INSERT');
END;
/

BEGIN
  -- Delete statements with less than 50 executions.
  DBMS_SQLTUNE.delete_sqlset (
    sqlset_name  => 'test_sql_tuning_set',
    basic_filter => 'executions < 50');

  -- Delete all statements.
  DBMS_SQLTUNE.delete_sqlset (
    sqlset_name  => 'test_sql_tuning_set');
END;
/

BEGIN
  DBMS_SQLTUNE.drop_sqlset (sqlset_name => 'test_sql_tuning_set');
  DBMS_SQLTUNE.drop_sqlset (sqlset_name => 'test_sql_tuning_set_2');
END;
/

Useful Views

• DBA_ADVISOR_TASKS
• DBA_ADVISOR_FINDINGS
• DBA_ADVISOR_RECOMMENDATIONS
• DBA_ADVISOR_RATIONALE
• DBA_SQLTUNE_STATISTICS
• DBA_SQLTUNE_BINDS
• DBA_SQLTUNE_PLANS
• DBA_SQLSET
• DBA_SQLSET_BINDS
• DBA_SQLSET_STATEMENTS
• DBA_SQLSET_REFERENCES
• DBA_SQL_PROFILES
• V$SQL
• V$SQLAREA
• V$ACTIVE_SESSION_HISTORY

• Automatic SQL Tuning
• DBMS_SQLTUNE

SQL Profiles (10g)

When the Tuning Advisor suggests that you accept a SQL Profile, what is it offering you. If you want to find out, the following SQL seems to be the appropriate query to run before you accept the profile:

select
	rat.attr1
from
	wri$_adv_tasks		tsk,
	wri$_adv_rationale	rat
where
	tsk.name = {sql tuning task name}
and	rat.task_id   = tsk.id
;

The {sql tuning task name} will be the task name generated and printed at the top of the Enterprisie Manager screen where you can see the recommendations. The output might list a few lines like the following:

OPT_ESTIMATE(@"SEL$1",INDEX_SCAN, "REQUESTS"@"SEL$1",REQ_UK,SCALE_ROWS=5.786002118 )
OPT_ESTIMATE(@"SEL$1", TABLE, "REQUESTS"@"SEL$1",SCALE_ROWS=0.0004355485551)

These are actually hints - they will be accepted if you include them in the usual fashion in your SQL (although that wouldn't be a good idea at present as they are undocumented, unsupported, and liable to change in their implementation).

Like Stored Outlines, the SQL Profile consists of a stored SQL statement, and a set of hints that will be brought into play when that SQL has to be optimised. Unlike Stored Outlines, the hints for SQL Profiles do not attempt to dictate execution mechanisms directly. Instead they supply arithmetical correction factors to the optimizer as it does its arithemetic as, even with a 100% sample size, it is still possible for the optimizer to misinterpret your statistics and produce an unsuitable execution path.

In principle, if the data distributions do not change, then a stored profile will ensure that the optimizer "understands" your data and does the right thing - even when the data volume changes.

SQL Profiles - 2

Following yesterday's note on SQL Profiles, someone asked how I detect that an opt_estimate hint had been used - with specific reference to the "index_scan" option. The reason for this particular choice is that other opt_estimate hints have a highly visible impact in the 10053 trace files, but this one doesn't.

Here are a few extracts from the Single Table Access section of the trace:

a) Following: opt_estimate(@sel$1, table, t1@sel$1, scale_rows=10) (multiply row count by 10)

   Table: T1  Alias: T1
    Card: Original: 4000    >> Single Tab Card adjusted from: 10.00  to: 100.00
  Rounded: 100  Computed: 100.00  Non Adjusted: 10.00      

b) Following: opt_estimate(@sel$1, join, (t2@sel$1, t1@sel$1), scale_rows=225) (multiply join cardinality by 225)

>> Join Card adjusted from 0.00  to: 1.00, prelen=2
Adjusted Join Cards: adjRatio=2666.67 cardHjSmj=1.00 cardHjSmjNPF=1.00
cardNlj=1.00 cardNSQ=1.00 cardNSQ_na=0.00

As you can see, the impact of the opt_estimate() shows up very clearly in these two cases, but when we try: opt_estimate(@sel$1, index_scan, t1@sel$1, t1_i1, scale_rows=0.05) (divide index selectivity by 20), we have to check the before and after trace files:
Before:

   Access Path: index (AllEqRange)
    Index: T1_I1
    resc_io: 168.00  resc_cpu: 1278402
    ix_sel: 0.05  ix_sel_with_filters: 0.05
    Cost: 168.19  Resp: 168.19  Degree: 1
  Best:: AccessPath: IndexRange  Index: T1_I1
         Cost: 168.19  Degree: 1  Resp: 168.19  Card: 10.00  Bytes: 0     

After:

   Access Path: index (AllEqRange)
    Index: T1_I1
    resc_io: 12.00  resc_cpu: 89967
    ix_sel: 0.0025  ix_sel_with_filters: 0.0025
    Cost: 12.01  Resp: 12.01  Degree: 1
  Best:: AccessPath: IndexRange  Index: T1_I1
         Cost: 12.01  Degree: 1  Resp: 12.01  Card: 10.00  Bytes: 0     

In this case, we don't get any indication of "adjusted values" - we actually have to check the before and after to see what has changed - and infer from the drop in cost that we have used a reduced cardinality. This can be particularly awkward to interpret in cases where the targetted index is not a suitable candidate for a single table access path, but becomes available as an access path later in the join evolution.

Checked for relevance on 12-May-2008.

Clarification/Explanation
==========================

The query optimizer can sometimes produce inaccurate estimates about 
an attribute of a statement due to lack of information,leading to poor
execution plans.  Traditionally, users have corrected  this problem by
manually adding hints to the application code to guide the optimizer 
into making correct decisions. For packaged applications, changing 
application code is not an option and the only alternative available 
is to log a bug with the application vendor and wait for a fix.

Automatic SQL Tuning deals with this problem with its SQL Profiling 
capability. The Automatic Tuning Optimizer creates a profile of the 
SQL statement called a SQL Profile, consisting of auxiliary statistics 
specific to that statement. The query optimizer under normal mode makes 
estimates about cardinality, selectivity, and cost that can sometimes be 
off by a significant amount resulting in poor execution plans. SQL Profile 
addresses this problem by collecting additional information using
sampling and partial execution techniques to verify and, if necessary, 
adjust these estimates.

During SQL Profiling, the Automatic Tuning Optimizer also uses execution
history information of the SQL statement to appropriately set optimizer 
parameter settings, such as changing the OPTIMIZER_MODE initialization 
parameter setting from ALL_ROWS to FIRST_ROWS for that SQL statement.

The output of this type of analysis is a recommendation to accept the 
SQL Profile. A SQL Profile, once accepted, is stored persistently in 
the data dictionary. Note that the SQL Profile is specific to a 
particular query. If accepted, the optimizer under normal mode uses the 
information in the SQL Profile in conjunction with regular
database statistics when generating an execution plan. 
The availability of the additional information makes it possible
to produce well-tuned plans for corresponding SQL statement without
requiring any change to the application code.

The scope of a SQL Profile can be controlled by the CATEGORY profile attribute. 
This attribute determines which user sessions can apply the profile. 
You can view the CATEGORY attribute for a SQL Profile in CATEGORY column 
of the DBA_SQL_PROFILES view. By default, all profiles are created in the 
DEFAULT category. This means that all user sessions where the SQLTUNE_CATEGORY 
initialization parameter is set to DEFAULT can use the profile.

By altering the category of a SQL profile, you can determine which sessions are 
affected by the creation of a profile. For example, by setting the category 
of a SQL Profile to DEV, only those users sessions where the SQLTUNE_CATEGORY 
initialization parameter is set to DEV can use the profile. All other sessions 
do not have access to the SQL Profile and execution plans for SQL statements 
are not impacted by the SQL profile. This technique enables you to test 
a SQL Profile in a restricted environment before making it available to other 
user sessions.

It is important to note that the SQL Profile does not freeze the execution plan
of a SQL statement, as done by stored outlines. As tables grow or indexes 
are created or dropped, the execution plan can change with the same SQL Profile. 
The information stored in it continues to be relevant even as the data 
distribution or access path of the corresponding statement change. 
However, over a long period of time, its content can become outdated and 
would have to be regenerated. This can be done by running Automatic 
SQL Tuning again on the same statement to regenerate the SQL Profile.

SQL Profiles apply to the following statement types:

     SELECT statements 
     UPDATE statements 
     INSERT statements (only with a SELECT clause) 
     DELETE statements 
     CREATE TABLE statements (only with the AS SELECT clause) 
     MERGE statements (the update or insert operations)

Managing SQL Profiles
=====================

While SQL Profiles are usually handled by Oracle Enterprise Manager as part 
of the Automatic SQL Tuning process, SQL Profiles can be managed through the
DBMS_SQLTUNE package. To use the SQL Profiles APIs, you need the 
CREATE ANY SQL_PROFILE, DROP ANY SQL_PROFILE, and ALTER ANY SQL_PROFILE
system privileges.

Accepting a SQL Profile
=======================

You can use the DBMS_SQLTUNE.ACCEPT_SQL_PROFILE procedure to accept a 
SQL Profile recommended by the SQL Tuning Advisor. This creates and stores a
SQL Profile in the database. For example:

DECLARE
 my_sqlprofile_name VARCHAR2(30);
BEGIN
 my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE ( 
    task_name => 'my_sql_tuning_task',
    name      => 'my_sql_profile');
END;


Where my_sql_tuning_task is the name of the SQL tuning task.
You can view information about a SQL Profile in the DBA_SQL_PROFILES view.

Altering a SQL Profile
======================

You can alter the STATUS, NAME, DESCRIPTION, and CATEGORY attributes of 
an existing  SQL Profile with the ALTER_SQL_PROFILE procedure. For example:

BEGIN
  DBMS_SQLTUNE.ALTER_SQL_PROFILE(
     name            => 'my_sql_profile', 
     attribute_name  => 'STATUS', 
     value           => 'DISABLED');
END;
/


In this example, my_sql_profile is the name of the SQL Profile that you want to alter. 
The status attribute is changed to disabled which means the SQL Profile is
not used during SQL compilation.

Dropping a SQL Profile
======================
You can drop a SQL Profile with the DROP_SQL_PROFILE procedure. For example:

BEGIN
  DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'my_sql_profile');
END;
/


In this example, my_sql_profile is the name of the SQL Profile you want to drop. 
You can also specify whether to ignore errors raised if the name does not exist.
For this example, the default value of FALSE is accepted.

Example
=======

SESSION 1 -- SCOTT
=========

SQL> create table test (n number );

Table created.

declare
begin
for i in 1 .. 10000
loop
insert into test values(i);
commit;
end loop;
end;

PL/SQL procedure successfully completed.


create index test_idx on test(n);

Index created.


analyze table test estimate statistics (OR use dbms_stats)

Table analyzed.


select /*+ no_index(test test_idx) */ * from test where n=1

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=1 Bytes=13)
   1    0   TABLE ACCESS (FULL) OF 'TEST' (TABLE) (Cost=6 Card=1 Bytes
          =13)



SESSION 2  -- SYS
=========

  1  DECLARE
  2   my_task_name VARCHAR2(30);
  3   my_sqltext   CLOB;
  4  BEGIN
  5   my_sqltext := 'select /*+ no_index(test test_idx) */ * from test where n=
1';
  6   my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
  7           sql_text    => my_sqltext,
  8           user_name   => 'SCOTT',
  9           scope       => 'COMPREHENSIVE',
 10           time_limit  => 60,
 11           task_name   => 'my_sql_tuning_task_2',
 12           description => 'Task to tune a query on a specified table');
 13* END;
 14  /

PL/SQL procedure successfully completed.


  1  BEGIN
  2    DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task_2');
  3* end;
SQL> /

PL/SQL procedure successfully completed.


  1  SET LONG 1000
  2  SET LONGCHUNKSIZE 1000
  3  SET LINESIZE 100
  4* SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'my_sql_tuning_task_2') from DUAL;



DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK_2')
--------------------------------------------------------------------------------
--------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name   : my_sql_tuning_task_2
Scope              : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status  : COMPLETED
Started at         : 05/04/2004 17:36:05
Completed at       : 05/04/2004 17:36:05

-------------------------------------------------------------------------------
SQL ID  : d4wgpc5g0s0vu

DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK_2')
--------------------------------------------------------------------------------
--------------------
SQL Text: select /*+ no_index(test test_idx) */ * from test where n=1

-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
  A potentially better execution plan was found for this statement.

  Recommendation (estimated benefit: 83.84%)

DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK_2')
--------------------------------------------------------------------------------
--------------------
  ------------------------------------------
    Consider accepting the recommended


  1  DECLARE
  2   my_sqlprofile_name VARCHAR2(30);
  3  BEGIN
  4   my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
  5      task_name => 'my_sql_tuning_task_2',
  6      name      => 'my_sql_profile');
  7* END;
  8  /

PL/SQL procedure successfully completed.


SQL> select to_char(sql_text) from           dba_sql_profiles;

TO_CHAR(SQL_TEXT)
------------------------------------------------------------------------
select /*+ no_index(test test_idx) */ * from test where n=1


SESSION 1 --- SCOTT


SQL> select /*+ no_index(test test_idx) */ * from test where n=1;

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1 Card=1 Bytes=13)
   1    0   INDEX (RANGE SCAN) OF 'TEST_IDX' (INDEX) (Cost=1 Card=1 By
          tes=13


From http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:61313086268493