SQL Tuning Advisor  Recommends New Explain Plan

Hi:
I have to believe this has been asked before but didn't see it in a forum search so I'll ask here. I had SQL Tuning Advisor look at a query and it is recommending a new plan for a 50+% improvement (hazah!). The trouble is, I don't want Oracle to re-write the plan to execute the query better, I want to know how I can re-write the query to generate that more optimal plan in the first place because I have similar systems in the field that I would like to also be optimized. What are my options?
Thanks.

Sorry Gaff I know where you are talking about but I don't have your answer, but it may be a good start going over the 19g reference guide for these dictionary views -
SQL> select view_name from dba_views where view_name like 'DBA%ADVISOR%' ;
VIEW_NAME
DBA_ADVISOR_DEFINITIONS
DBA_ADVISOR_COMMANDS
DBA_ADVISOR_OBJECT_TYPES
DBA_ADVISOR_USAGE
DBA_ADVISOR_TASKS
DBA_ADVISOR_TEMPLATES
DBA_ADVISOR_LOG
...Best regards.

Similar Messages

  • SQL Tuning - Not understanding the explain plan.

    Hi All,
    I am using 11g R2 and I have 2 questions about tuning a query.
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE    11.2.0.3.0      Production
    TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - ProductionMy parameters relevant to the optimizer are :
    NAME                                 TYPE        VALUE
    optimizer_capture_sql_plan_baselines boolean     FALSE
    optimizer_dynamic_sampling           integer     2
    optimizer_features_enable            string      11.2.0.3
    optimizer_index_caching              integer     0
    optimizer_index_cost_adj             integer     100
    optimizer_mode                       string      ALL_ROWS
    optimizer_secure_view_merging        boolean     TRUE
    optimizer_use_invisible_indexes      boolean     FALSE
    optimizer_use_pending_statistics     boolean     FALSE
    optimizer_use_sql_plan_baselines     boolean     TRUEThe query I would like to execute is pretty simple. It just returns some exceptions with a filter.
    SELECT ERO.DVC_EVT_ID,  E.DVC_EVT_DTTM
    FROM D1_DVC_EVT E,  D1_DVC_EVT_REL_OBJ ERO
    WHERE ERO.MAINT_OBJ_CD = 'D1-DEVICE'
    AND ERO.PK_VALUE1 = :H1
    AND ERO.DVC_EVT_ID = E.DVC_EVT_ID
    AND E.DVC_EVT_TYPE_CD IN ('END-GSMLOWLEVEL-EXCP-SEV-1', 'STR-GSMLOWLEVEL-EXCP-SEV-1')
    ORDER BY E.DVC_EVT_DTTM DESC;The execution plan is the following :
    Plan hash value: 3627978539
    | Id  | Operation                            | Name               | Starts | E-Rows |E-Bytes| Cost (%CPU)| Pstart| Pstop | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   0 | SELECT STATEMENT                     |                    |      1 |        |       |  7131 (100)|       |       |   1181 |00:00:17.17 | 8627 |   2978 |       |       |          |
    |   1 |  SORT ORDER BY                       |                    |      1 |   3137 |   275K|  7131   (1)|       |       |   1181 |00:00:17.17 | 8627 |   2978 | 80896 | 80896 |71680  (0)|
    |   2 |   NESTED LOOPS                       |                    |      1 |        |       |            |       |       |   1181 |00:00:17.16 | 8627 |   2978 |       |       |          |
    |   3 |    NESTED LOOPS                      |                    |      1 |   3137 |   275K|  7130   (1)|       |       |   2058 |00:00:08.09 | 6709 |   1376 |       |       |          |
    |   4 |     TABLE ACCESS BY INDEX ROWID      | D1_DVC_EVT_REL_OBJ |      1 |   3137 |   125K|   845   (1)|       |       |   2058 |00:00:04.37 |  820 |    799 |       |       |          |
    |*  5 |      INDEX RANGE SCAN                | D1T404S0           |      1 |   3137 |       |    42   (0)|       |       |   2058 |00:00:00.08 |   27 |     23 |       |       |          |
    |   6 |     PARTITION RANGE ITERATOR         |                    |   2058 |      1 |       |     1   (0)|   KEY |   KEY |   2058 |00:00:03.69 | 5889 |    577 |       |       |          |
    |*  7 |      INDEX UNIQUE SCAN               | D1T400P0           |   2058 |      1 |       |     1   (0)|   KEY |   KEY |   2058 |00:00:03.66 | 5889 |    577 |       |       |          |
    |*  8 |    TABLE ACCESS BY GLOBAL INDEX ROWID| D1_DVC_EVT         |   2058 |      1 |    49 |     2   (0)| ROWID | ROWID |   1181 |00:00:09.05 | 1918 |   1602 |       |       |          |
    Peeked Binds (identified by position):
       1 - (VARCHAR2(30), CSID=178): '271792300706'
    Predicate Information (identified by operation id):
       5 - access("ERO"."PK_VALUE1"=:H1 AND "ERO"."MAINT_OBJ_CD"='D1-DEVICE')
           filter("ERO"."MAINT_OBJ_CD"='D1-DEVICE')
       7 - access("ERO"."DVC_EVT_ID"="E"."DVC_EVT_ID")
       8 - filter(("E"."DVC_EVT_TYPE_CD"='END-GSMLOWLEVEL-EXCP-SEV-1' OR "E"."DVC_EVT_TYPE_CD"='STR-GSMLOWLEVEL-EXCP-SEV-1'))So as you can see, row 8, I have a TABLE ACCESS BY GLOBAL INDEX ROWID. But what I am failling to see is how Oracle display a TABLE ACCESS BY GLOBAL INDEX ROWID without using any index. As thought that Oracle always got a ROWID because of an index.
    I also have an index on the column DVC_EVT_TYPE_CD in my table (row 8 of the predicate information section)
    And finally what would be your suggestion to improve the runtime of this query...
    Many thanks.

    if I read the rowsource statistics information and the plan correctly then the table access in step 4 on D1_DVC_EVT_REL_OBJ needs 4.37 sec and accesses 820 buffers. If you had an index D1_DVC_EVT_REL_OBJ(MAINT_OBJ_CD, PK_VALUE1, DVC_EVT_ID) I assume that this table access could be avoided. To avoid the table access on D1_DVC_EVT an index on D1_DVC_EVT(DVC_EVT_ID, DVC_EVT_TYPE_CD, DVC_EVT_DTTM) should be sufficient.
    I think these indexes would improve the performance of the given query but of course they would have a negative impact on DML performance on the table and they could influence other queries on the table.

  • SQL Tuning Advisor (STA) recommends indexes that already exists?

    I have enabled the STA to run twice a week, while we are going live with a new application in a new database. I want to insure we have good performance as the load goes up. I was not involved in the original design, which there not not much of, I've discovered. Since we are licensed for it, it seemed like a safe thing to turn on.
    The STA ran last night and the report tells me it looked at 736 SQLs with findings, 143 without findings, and skipped 0.
    What puzzles me is that, in the "Statistics Finding Summary", it's reporting stale stats on some tables which I know are up to date, as I ran stats on them yesterday and there were no updates to them.
    Worse, in the "Index Finding Summary", it reports indexes needed that already do, in fact, exist.
    Is there some reason for this? Is there some way to get the STA to be aware of these and avoid the erroneous findings so that I can concentrate on real ones?
    Thanks in advance for any suggestions.
    PDP

    Hi Mark,
    Thanks for your interest, yes, the index is being used . Here is the evidence that you were asking about.
    It has existed for many weeks, now as the info below will show.
    Here is the STA run info, the run was from 2011-07-28 at 11 PM:
    ========================================
    Advisory Type Name Description User Status Start Time Duration (seconds) Expires In (days)
    SQL Tuning Advisor SYS_AUTO_SQL_TUNING_TASK Automatic SQL Tuning Task SYS COMPLETED Jul 28, 2011 11:00:03 PM 865 UNLIMITED
    Here is part of the Index Finding Summary
    =========================================
    Index Finding Summary
    Table Name Schema References Index Columns
    EINSTANCE_ARCH EINTAKE 74 GLOBAL_PATIENT_ID
    Drilling into that table, we see the following SQL_ID listed first, "g9uf2kmyvc66y" which is just one of many.
    Here is 1 if the sqls, which use the "global_patient_id" as a predicate
    (with the many columns that are actually selected not listed as they are not germain:
    =====================================================================================
    SELECT *
    FROM (SELECT '0' AS locked,
    (... a whole lot of columns selected)
    FROM einstance_arch a
    LEFT OUTER JOIN
    patient d
    ON a.global_patient_id = d.patient_id
    LEFT OUTER JOIN
    referral e
    ON a.instance_id = e.einstance_id,
    einstance_states_arch b
    WHERE a.current_state = b.inst_state_id
    AND a.current_state_id != 15
    AND ( a.global_patient_id = 496 )
    ORDER BY a.instance_id ASC)
    WHERE ROWNUM <= :1
    Here's an explain plan extracted from Toad, the index in question is identified by ==>:
    ======================================================
    Plan
    SELECT STATEMENT ALL_ROWS Cost: 19 Bytes: 4,528 Cardinality: 4
    1 INDEX UNIQUE SCAN INDEX (UNIQUE) EINTAKE.STATES_PK Cost: 0 Bytes: 14 Cardinality: 1
    3 SORT AGGREGATE Bytes: 6 Cardinality: 1
    2 INDEX RANGE SCAN INDEX EINTAKE.DOCUMENT_ATTR_LNK_INST_ID_IDX2 Cost: 1 Bytes: 6 Cardinality: 1
    18 COUNT STOPKEY
    17 VIEW EINTAKE. Cost: 19 Bytes: 4,528 Cardinality: 4
    16 SORT ORDER BY STOPKEY Cost: 19 Bytes: 1,544 Cardinality: 4
    15 NESTED LOOPS
    13 NESTED LOOPS Cost: 18 Bytes: 1,544 Cardinality: 4
    11 NESTED LOOPS OUTER Cost: 10 Bytes: 1,296 Cardinality: 4
    8 HASH JOIN OUTER Cost: 9 Bytes: 1,228 Cardinality: 4
    5 TABLE ACCESS BY INDEX ROWID TABLE EINTAKE.EINSTANCE_ARCH Cost: 6 Bytes: 1,152 Cardinality: 4
    ==> 4 INDEX RANGE SCAN INDEX EINTAKE.EINSTANCE_ARCH_GLBL_PT_ID_IDX3 Cost: 1 Cardinality: 5
    7 TABLE ACCESS BY INDEX ROWID TABLE EINTAKE.PATIENT Cost: 2 Bytes: 19 Cardinality: 1
    6 INDEX UNIQUE SCAN INDEX (UNIQUE) EINTAKE.PATIENT_PK Cost: 1 Cardinality: 1
    10 TABLE ACCESS BY INDEX ROWID TABLE EINTAKE.REFERRAL Cost: 1 Bytes: 17 Cardinality: 1
    9 INDEX RANGE SCAN INDEX EINTAKE.REFERRAL_EINSTANCE_ID Cost: 0 Cardinality: 1
    12 INDEX UNIQUE SCAN INDEX (UNIQUE) EINTAKE.EINSTANCE_STATES_ARCH_PK Cost: 1 Cardinality: 1
    14 TABLE ACCESS BY INDEX ROWID TABLE EINTAKE.EINSTANCE_STATES_ARCH Cost: 2 Bytes: 62 Cardinality: 1
    Here is the DDL info on the index in question:
    ============================
    select object_name, created, last_ddl_time from user_objects where object_name = 'EINSTANCE_ARCH_GLBL_PT_ID_IDX3';
    OBJECT_NAME CREATED LAST_DDL_TIME
    EINSTANCE_ARCH_GLBL_PT_ID_IDX3 2011 07 11 11:22:36 2011 07 11 11:22:36
    1 row selected.
    Regards,
    Paul

  • SQL Tuning Advisor evaluates statement using wrong plan_hash_value

    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

    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')
    ;

  • Need help to debug SQL Tuning Advisor Error Message

    Hi,
    I am getting an error message while try to get recommendations from the SQL Tuning Advisor.
    Environment:
    Oracle Version:  11.2.0.3.0
    O/S: AIX
    Following is my code:
    declare
    my_task_name  varchar2 (30);
    my_sqltext    clob;
    begin
    my_sqltext := 'SELECT DISTINCT MRKT_AREA AS DIVISION, PROMO_ID,
                    PROMO_CODE,
                    RBR_DTL_TYPE.PERF_DETL_TYP, 
                    RBR_DTL_TYPE.PERF_DETL_DESC,
                    RBR_DTL_TYPE.PERF_DETL_SUB_TYP,
                    RBR_DTL_TYPE.PERF_DETL_SUB_DESC,
                    BU_SYS_ITM_NUM,
                    RBR_CPN_LOC_ITEM_ARCHIVE.CLI_SYS_ITM_DESC,
                    PROMO_START_DATE,
                    PROMO_END_DATE,
                    PROMO_VALUE2,
                    PROMO_VALUE1,
                    EXEC_COMMENTS,
                    PAGE_NUM,
                    BLOCK_NUM,
                    AD_PLACEMENT,
                    BUYER_CODE,
                    RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STAT_TYP,
                    RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG
    FROM  (PROMO_REPT_OWNER.RBR_CPN_LOC_ITEM_ARCHIVE
    INNER JOIN PROMO_REPT_OWNER.RBR_MASTER_CAL_ARCHIVE
    ON (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PROMO_ID = PROMO_ID)
    AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PERF_DTL_ID = PERF_DETAIL_ID)
    AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STR_NBR = STORE_ZONE)
    AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_ITM_ID = ITM_ID))
    INNER JOIN PROMO_REPT_OWNER.RBR_DTL_TYPE
    ON (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_TYP = RBR_DTL_TYPE.PERF_DETL_TYP)
    AND (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_SUB_TYP = RBR_DTL_TYPE.PERF_DETL_SUB_TYP)
    WHERE ( ((MRKT_AREA)=40)
    AND ((RBR_DTL_TYPE.PERF_DETL_TYP)=1)
    AND ((RBR_DTL_TYPE.PERF_DETL_SUB_TYP)=1) )
    AND ((CLI_STAT_TYP)=1 Or (CLI_STAT_TYP)=6)
    AND ((RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG)=''A'')
    AND ( ((PROMO_START_DATE) >= to_date(''2011-10-20'', ''YYYY-MM-DD'')
    And (PROMO_END_DATE) <= to_date(''2011-10-26'', ''YYYY-MM-DD'')) )
    ORDER BY MRKT_AREA';
    my_task_name := dbms_sqltune.create_tuning_task
                                 (sql_text => my_sqltext,
                                  user_name => 'PROMO_REPT_OWNER',
                                  scope     => 'COMPREHENSIVE',
                                  time_limit => 3600,
                                  task_name  => 'Test_Query',
                                  description  => 'Test Query');
    end;
    begin
      dbms_sqltune.execute_tuning_task(task_name => 'Test_Query');
    end;
    set serveroutput on size unlimited;
    set pagesize 5000
    set linesize 130
    set long 50000
    set longchunksize 500000
    SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('Test_Query') FROM DUAL;
    Output:
    snippet .....
    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: 71.48%)
    - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    Error: Cannot fetch actions for recommendation: INDEX
    Error: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
    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.
    snippet
    Any ideas why I am getting ORA-06502 error?
    Thanks in advance
    Rogers

    Bug 14407401 - ORA-6502 from index recommendation section of DBMS_SQLTUNE output (Doc ID 14407401.8)
    Fixed:
    The fix for 14407401 is first included in
    12.1.0.1 (Base Release)

  • [OCP exam] doubt about Automatic SQL Tuning Advisor

    Hi,
    Sorry for my poor english.
    I am currently preparing for the OCP  11g exam.
    For that, I have bought some training tools  to help me prepare the exam.
    But, in the chapter related to the SQL tuning advisor, some explanation really confuse me .
    Extract :
    <<
    the SQL automatic tuning  job runs every night during the maintenance window.
    By default, the job makes SQL profile recommendations, tests them, and automatically implements them if they provide better performance improvement)
    >>
    I was persuaded it was the opposite.
    I check several databases/documentation, and it's seems to be always the opposite.
    By default,new sql profile are tested but not implemented automatically (you have to set a parameter ACCEPT_SQL_PROFILES TO TRUE to activate this option)
    But the exam is validated on oracle 11.2.0.1, and I only have 11.2.0.2/11.2.0.3 db available.
    So may be oracle changed the value of the default parameter in the new releases.
    Can someone confirm if I am right or not ?

    I would rather accept what is in the documentation:
    "If a SQL profile is recommended, the database tests the new profile by executing the SQL statement both with and without the profile. If the performance improvement improves at least threefold, then the database accepts the SQL profile, but only if the ACCEPT_SQL_PROFILES task parameter is set to TRUE. Otherwise, the automatic SQL tuning reports merely report the recommendation to create a SQL profile." Automatic SQL Tuning
    "If automatic implementation of SQL profiles is enabled (the default is disabled), then the database implements any SQL profiles that promise a great performance benefit. The implementation occurs at tuning time so that the database can immediately benefit from the new plan. You can enable or disable automatic implementation by using the SET_AUTO_TUNING_TASK_PARAMETER API to set the ACCEPT_SQL_PROFILES parameter." DBMS_AUTO_SQLTUNE

  • Sql Tuning advisor Misc message

    HI I am using SQL Tuning advisor to tune one of my queries.I am gettin following recommendation
    Miscellaneous     The optimizer could not merge the view at line ID 4 of the execution plan.
    I am attaching my execution plan .Please let me know what does that mean and what action i have to take
    Execution Plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Tim
    | 0 | SELECT STATEMENT | | | | 10130 (100)|
    | 1 | HASH GROUP BY | | 56 | 15848 | 10130 (1)| 00:
    | 2 | VIEW | | 56 | 15848 | 10129 (1)| 00:
    | 3 | WINDOW BUFFER | | 56 | 63280 | 10129 (1)| 00:
    | 4 | VIEW | | 56 | 63280 | 10129 (1)| 00:
    | 5 | WINDOW SORT | | 56 | 24752 | 10129 (1)| 00:
    | 6 | NESTED LOOPS | | 56 | 24752 | 10128 (1)| 00:
    | 7 | NESTED LOOPS | | 55 | 22165 | 10018 (1)| 00:
    | 8 | NESTED LOOPS | | 58 | 21866 | 9902 (1)| 00:
    | 9 | NESTED LOOPS | | 60 | 21060 | 9781 (1)| 00:
    | 10 | NESTED LOOPS | | 60 | 19020 | 9661 (1)| 00:
    | 11 | NESTED LOOPS | | 63 | 18333 | 9534 (1)| 00:
    | 12 | NESTED LOOPS | | 67 | 17755 | 9400 (1)| 00:
    | 13 | NESTED LOOPS | | 67 | 12931 | 9333 (1)| 00:
    | 14 | NESTED LOOPS | | 67 | 11725 | 9266 (1)| 00:
    | 15 | HASH JOIN | | 67 | 10854 | 9198 (1)| 00:
    | 16 | HASH JOIN | | 67 | 10117 | 9160 (1)| 00:
    | 17 | HASH JOIN | | 67 | 9581 | 9154 (1)| 00:
    | 18 | TABLE ACCESS BY INDEX ROWID | T_FACT_AGGR_TAX_RPTG | 1355 | 178K| 9149 (1)| 00:
    | 19 | NESTED LOOPS | | 67 | 9045 | 9149 (1)| 00:
    | 20 | MAT_VIEW ACCESS FULL | MV_T_DIM_INSTM | 1 | 43 | 53 (4)| 00:
    | 21 | BITMAP CONVERSION TO ROWIDS| | | | |
    | 22 | BITMAP INDEX SINGLE VALUE | XB_T_FACT_AGGR_TAX_RPTG_N5 | | | |
    | 23 | MAT_VIEW ACCESS FULL | MV_T_DIM_CURR | 457 | 3656 | 5 (0)| 00:
    | 24 | MAT_VIEW ACCESS FULL | MV_T_DIM_CURR | 457 | 3656 | 5 (0)| 00:
    | 25 | VIEW | index$_join$_007 | 3480 | 38280 | 38 (6)| 00:
    | 26 | HASH JOIN | | | | |
    | 27 | INDEX FAST FULL SCAN | XPK_MV_ORIG_T_DIM_MNGMT_ENT | 3480 | 38280 | 10 (0)| 00:
    | 28 | INDEX FAST FULL SCAN | X_MV_CUR_T_DIM_MNGMT_ENT_N1 | 3480 | 38280 | 27 (4)| 00:
    | 29 | TABLE ACCESS BY INDEX ROWID | T_DIM_DATE | 1 | 13 | 1 (0)| 00:
    | 30 | INDEX UNIQUE SCAN | XPK_T_DIM_DATE | 1 | | 0 (0)|
    | 31 | MAT_VIEW ACCESS BY INDEX ROWID | MV_T_DIM_EXTL_PARTY | 1 | 18 | 1 (0)| 00:
    | 32 | INDEX UNIQUE SCAN | XPK_MV_T_DIM_EXTL_PARTY | 1 | | 0 (0)|
    | 33 | MAT_VIEW ACCESS BY INDEX ROWID | MV_T_DIM_LGL_ENT_BR | 1 | 72 | 1 (0)| 00:
    | 34 | INDEX UNIQUE SCAN | XPK_MV_O_LGL_ENT_BR | 1 | | 0 (0)|
    | 35 | TABLE ACCESS BY INDEX ROWID | T_FACT_DAILY_RATE | 1 | 330 | 2 (0)| 00:
    | 36 | INDEX UNIQUE SCAN | XPK_T_FACT_DAILY_RATE | 1 | | 1 (0)| 00:
    | 37 | TABLE ACCESS BY INDEX ROWID | T_FACT_DAILY_RATE | 1 | 356 | 2 (0)| 00:
    | 38 | INDEX UNIQUE SCAN | XPK_T_FACT_DAILY_RATE | 1 | | 1 (0)| 00:
    | 39 | MAT_VIEW ACCESS BY INDEX ROWID | MV_T_DIM_TRD | 1 | 34 | 2 (0)| 00:
    | 40 | INDEX UNIQUE SCAN | XPK_MV_T_DIM_TRD | 1 | | 1 (0)| 00:
    | 41 | TABLE ACCESS BY INDEX ROWID | T_FACT_DAILY_RATE | 1 | 382 | 2 (0)| 00:
    | 42 | INDEX UNIQUE SCAN | XPK_T_FACT_DAILY_RATE | 1 | | 1 (0)| 00:
    | 43 | TABLE ACCESS BY INDEX ROWID | T_FACT_DAILY_RATE | 1 | 442 | 2 (0)| 00:
    | 44 | INDEX UNIQUE SCAN | XPK_T_FACT_DAILY_RATE | 1 | | 1 (0)| 00:
    | 45 | TABLE ACCESS BY INDEX ROWID | T_FACT_AGGR_WGT_AVG_RATE | 1 | 39 | 2 (0)| 00:
    | 46 | INDEX UNIQUE SCAN | XPK_T_FACT_AGGR_WGT_AVG_RATE | 1 | | 1 (0)| 00:
    Thanks
    Pramod Garre

    No version number? Why? And I am not interested in manually formatting your post to make it readable.
    In the FAQ which you should have read there is a clear explanation of how to use tags so that what you copy in retains its formatting.
    Please read the FAQ and correct what you posted as well as providing more information such as the type of application, the DML being executed, and why you are using the tuning advisor at all?
    There doesn't seem to be much here that couldn't be far more easily created with:
    explain plan for
    <your SQL statement>
    followed by:
    SELECT * FROM TABLE(dbms_xplan.display);                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • SQL Tuning Advisor against the session (is it poosible)

    My Company customer has observed that there is job that are running longer than expected running(5 days).
    They did not gave any information.they want me to run
    SQL Tuning Advisor against the session running this job.
    can you run sql tunning advisor against running session?
    if so how
    Please suggest me your valuable tips so that I approach this work properly.
    DB = 11g
    OS= Solaris 10

    >
    ...SQL Tuning Advisor against the session running this job.
    can you run sql tunning advisor against running session?
    >
    SQL Tuning Advisor is run on statements and not sessions. I don't do much with SQL Tuning Advisor, but I'd consider that current running sessions a lost cause until it completes or you kill it. You can see the "estimate" of how long that current running SQL is going to take in v$session_longops. You can use a script like Tanel's sw.sql
    http://blog.tanelpoder.com/2008/01/08/updated-session-wait-script/
    to see what the wait interface has to say.
    >
    Please suggest me your valuable tips so that I approach this work properly.
    >
    My approach for this would be to determine what the current explain plan is and compare it to one that ran (correctly) in the past and then try to determine why it changed. (bad stats, dropped index, parameter changes, etc).
    Cheers.

  • What is this SQL Tuning Advisor's Advice means

    HI ,
    I am Tuning a query wit hthe help of ORACLE 10 g 's SQL Tuning Advisor.I got the following recommendation .
    **Consider removing the disconnected table or view from this statement or add a join condition which refers to it.**
    I didn't understand what does this mean.
    Can anyone please help me
    Thanks,
    Pramod.
    Edited by: Pramod Garre on Jul 15, 2009 6:20 AM

    Simply saying if i apply that profile i will get Good plan.But I want to change the SQL itself rather than applying profile.in that case what can be done.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.
    If you want to change the SQL, You can re-write the SQL and evaluate the Performance recommendations SQL tuning Advisor.

  • Sql tuning advisor-10g

    Dear all,
    DB : 10.2.0.4.
    Solaris 5.10
    One of the monthly process had a problem and one of the select statements was taking a lot of time and when I ran sql tuning advisor, initially it advised me to accept the new sql profile. then since there is no improvements, I proceeded with running sql tuning advisor again which resulted in
    Optimizer statistics for index "USER"."CDR_BITMAP_IDX" are stale. Consider collecting optimizer statistics for this index. The optimizer requires up-to-date statistics for the index in order to select a good execution plan.
    Miscellaneous SQL Profile "SYS_SQLPROF_02492cc266e98000" exists for this statement and was ignored during the tuning process.
    select b.custno ,b.contrno ,b.rowid  ,a.subscr_type ,a.area ,a.subno ,
      nvl(a.imsi_no,:"SYS_B_00") ,a.extn ,a.b_subno ,a.chargetype ,a.tariffclass ,
      a.cdrcode ,to_char(a.transdate,'YYYYMMDD') ,to_char(nvl(a.transdate_to,
      a.transdate),'YYYYMMDD') ,nvl(a.no_of_calls,:"SYS_B_01") ,nvl(a.duration,
      :"SYS_B_02") ,nvl(a.act_duration,:"SYS_B_03") ,a. time  ,a.time_data ,
      a.act_time ,a.cdrtext ,a.ar_cdrtext ,a.cdramount ,a.cdramount_int ,
      a.gross_amount ,a.gross_amount_int ,nvl(adv_cdramount,:"SYS_B_04") ,
      nvl(adv_gross_amount,:"SYS_B_05") ,to_char(nvl(adv_transdate,transdate),
      'YYYYMMDD') ,to_char(nvl(adv_transdate_to,transdate_to),'YYYYMMDD') ,
      a.factor ,a.factor_int ,to_char(a.upddate,'YYYYMMDD') ,a.tax_class ,
      a.vol_group ,nvl(a.table_gen,:"SYS_B_06") ,a.call_type ,
      to_char(a.ltd,'YYYYMMDD') ,nvl(a.equipgroup,:"SYS_B_07") ,
      nvl(a.equipid,:"SYS_B_08") ,dest_code ,rate_type ,org_tariff_group ,
      tariff_group ,rate_pos ,nvl(a.tariff_profile,:"SYS_B_09") ,a.rowid  ,
      nvl(a.adv_cdred,:"SYS_B_10") ,a.SPLIT_TARIFFCLASS ,a.SPLIT_DURATION ,
      a.SPLIT_cdrAMOUNT ,a.SPLIT_cdrAMOUNT_INT
    from
    cdr_master a ,cdr_control b where (((((b.ltd=to_date(:b0,
      :"SYS_B_11") and a.contrno=b.contrno) and b.run_group=:b1) and b.cdr_flag=
      :"SYS_B_12") and nvl(a.cdred,:"SYS_B_13")<>:"SYS_B_14") and
      (((trunc(a.transdate)<=to_date(:b0,:"SYS_B_15") or ((trunc(a.upddate)<=
      to_date(:b0,:"SYS_B_16") and chargetype=:"SYS_B_17") and (((a.cdred is
      not null  and a.cdred=:"SYS_B_18") and nvl(adv_cdred,:"SYS_B_19")=
      :"SYS_B_20") or (((a.cdred is  not null  and a.cdred=:"SYS_B_21") and
      nvl(adv_cdred,:"SYS_B_22")=:"SYS_B_23") and adv_transdate_to<=to_date(:b0,
      :"SYS_B_24"))))) or ((a.cdred is  not null  and a.cdred=:"SYS_B_25") and
      nvl(adv_cdred,:"SYS_B_26")=:"SYS_B_27")) or (((a.cdred is  not null  and
      a.cdred=:"SYS_B_28") and nvl(adv_cdred,:"SYS_B_29")=:"SYS_B_30") and
      adv_transdate_to<=to_date(:b0,:"SYS_B_31")))) order by a.contrno,a.subno,
      a.subscr_type,a.area,nvl(a.equipgroup,:"SYS_B_32"),a.chargetype,a.cdrcode
      for update of a.cdred nowait
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      5    451.99    1997.19     596620   37306277    3351623           0
    Fetch      404      0.96       0.84          0          0          0       39900
    total      409    452.95    1998.04     596620   37306277    3351623       39900
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 185
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                     404        0.00          0.00
      SQL*Net more data to client                  3219        0.00          0.03
      SQL*Net message from client                   404        0.00          0.22
      gc current block 2-way                      34454        0.27         21.77
      gc cr multi block request                    2649        0.27          1.06
      db file sequential read                    596211        0.15       1561.81
      gc cr block busy                               16        0.00          0.02
      db file parallel read                          11        0.00          0.04
      db file scattered read                         50        0.01          0.10
      gc cr block 2-way                               2        0.00          0.00
      gc current grant 2-way                          6        0.00          0.00
      latch: cache buffers chains                     9        0.00          0.00
      gc current block congested                      6        0.00          0.02
      gc current grant busy                         257        0.00          0.17
      latch: object queue header operation            3        0.00          0.00
      log file switch completion                     22        0.82          2.52
      latch free                                     27        0.00          0.00
      log buffer space                                7        0.24          0.83
      log file switch (checkpoint incomplete)        10        0.98          1.47
      gc cr grant 2-way                               2        0.00          0.00Any idea what am missing ?
    Kai

    Hi,
    Try to Update the Stats of the Source tables and re-reun the Advisor, that might give or suggest different things further.
    Second thing, check that Referred SQL profile and I would suggest if it not used, then drop that and check.
    Surprised to see huge wait event on "db file sequential read"
    - Pavan Kumar N

  • Sql tuning advisor for concurrent requests

    Dear all,
    I am having one doubt in my mind from very long time.Can we use sql tuning advisor from 10G(EM) to tune concurrent requests and reports?
    Regards

    Hi Helios,
    I am just thinking wiht voice. If you have one code blog which is typed in sql-pl/sql for your concurrent request, its going and run on dbtier. So it has one SQL'ID and also can be check on AWR report. So i belive you can use sqltuning adviser for to can tune related sqlAFAIK, some Instances a single concurrent request may contain multiple SQLID's and in that scenario tuning approach is difficult. Any information how can we consolidate it. If tune one specific sql then the explain plan for other sql become more worst. I came across this situation so many time.
    Any information or inputs on this is really appreciated.
    thanks,
    X A H E E R

  • Stucked between SQL Tuning Advisor and and SQL statement

    Hi,
    There is an important query running on my system which consists
    MEMBER OF function.
    At first place let me explain why i used MEMBER OF,
    I am sending a string( eg : #123#124#125) to query and a function converts this string into a number array.
    After then I use this number array inside my sql.
    The reason I am using this structure, in order to generate a dynamic IN statement inside my sql. (IF you have any other solution that would be great)
    The most important point is; when I put this statement to SQL Tuning Advisor the response is only ORA-00932: inconsistent datatypes: expected UDT got CHAR
    Any answer will be greatly appreciated.
    Thanks

    Solomon Yakobson wrote:
    Object oriented stuff almost never provides better performance over relational. You should stay away from MEMBER OF if performance is a factor. Instead of:
    WHERE expr MEMBER OF nested-tableI'd test:
    WHERE expr IN (SELECT column_value FROM TABLE(nested-table))SY.
    expr IN (SELECT COLUMN_VALUE FROM TABLE (CAST (v_type_number_table AS type_number_table)))worked like a charm. i hope tuning advisor will like it as i do.
    thanks.

  • Oracle 10g SQL Tuning Advisor

    I am working as a junior DBA. I tried to tune a query using SQL Tuning Advisor that is with DBMS_SQLTUNE.I have created the tuning task successfully with DBMS_SQLTUNE.create_tuning_task.But when i execute the tuning task with EXEC DBMS_SQLTUNE.execute_tuning_task() i got an error like
    SQL> EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'rep_three');
    BEGIN DBMS_SQLTUNE.execute_tuning_task(task_name => 'rep_three'); END;
    ERROR at line 1:
    ORA-00081: address range [0x60000000000A7D70, 0x60000000000A7D74) is not
    readable
    ORA-00600: internal error code, arguments: [kesatmGetSqlStats:optCost], [], [],
    ORA-06512: at "SYS.PRVT_ADVISOR", line 1624
    ORA-06512: at "SYS.DBMS_ADVISOR", line 186
    ORA-06512: at "SYS.DBMS_SQLTUNE", line 1008
    ORA-06512: at line 1The oracle version is Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi. The OS is HP-UX. The version is HP-UX B.11.23 U ia64.
    I tried to execute DBMS_SQLTUNE as DWH user.I have granted the advisor,DROP ANY SQL PROFILE,ALTER ANY SQL PROFILE,CREATE ANY SQL PROFILE privileges and DBA roles to the DWH user. The way i ran DBMS_SQLTUNE is, first i logged in as DWH user and i tried to execute the query for getting the SQL_ID for the query. For getting the SQL_ID i selected the SQL_ID column value for the DWH user session from v$session.I kept that query executing and meanwhile i opened another session as DWH user and created the tuning task as follows
    DECLARE
      l_sql_tune_task_id  VARCHAR2(100);
    BEGIN
      l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
                              sql_id      => 'b65fj39dkkb9v',
                              scope       => DBMS_SQLTUNE.scope_limited,
                              time_limit  => 3600,
                              task_name   => 'rep_three',
                              description => 'Report Tuning');
      DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
    END;
    /The creation of tuning task was successful.And i executed the tuning task as follows
    EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'rep_three');The above mentioned errors came when i executed the tuning task.
    I am also adding the query which i have tried to tune
    select * from dwh.beneficiary_dim BEN_DIM,
                     (Select adr_dp_id,
                   adr_account_no,
                   ADR_ADDRESS_LINE_1 || ' ' ||
                   ADR_ADDRESS_LINE_2 || ' ' ||
                   ADR_ADDRESS_LINE_3 || ' ' ||
                   ADR_ADDRESS_LINE_4 as ADDRESS,
                   adr_pin_code,adr_phone_no,adr_fax_no
              from dwh.beneficiary_address_dim where adr_type_id = 1) PERMANENT_ADD_DIM,
           (Select adr_dp_id,
                   adr_account_no,
                   ADR_ADDRESS_LINE_1 || ' ' ||
                   ADR_ADDRESS_LINE_2 || ' ' ||
                   ADR_ADDRESS_LINE_3 || ' ' ||
                   ADR_ADDRESS_LINE_4 as ADDRESS,
                   adr_pin_code,adr_phone_no,adr_fax_no
              from dwh.beneficiary_address_dim where adr_type_id = 2) BANK_ADD_DIM,
           (Select adr_dp_id,
                   adr_account_no,
                   ADR_ADDRESS_LINE_1 || ' ' ||
                   ADR_ADDRESS_LINE_2 || ' ' ||
                   ADR_ADDRESS_LINE_3 || ' ' ||
                   ADR_ADDRESS_LINE_4 as ADDRESS,
                   adr_pin_code,adr_phone_no,adr_fax_no
              from dwh.beneficiary_address_dim where adr_type_id = 3) NOM_GUARDIAN_ADD_DIM,
           (Select adr_dp_id,
                   adr_account_no,
                   ADR_ADDRESS_LINE_1 || ' ' ||
                   ADR_ADDRESS_LINE_2 || ' ' ||
                   ADR_ADDRESS_LINE_3 || ' ' ||
                   ADR_ADDRESS_LINE_4 as ADDRESS,
                   adr_pin_code,adr_phone_no,adr_fax_no
              from dwh.beneficiary_address_dim where adr_type_id = 4) CORR_ADD_DIM,
           (Select adr_dp_id,
                   adr_account_no,
                   ADR_ADDRESS_LINE_1 || ' ' ||
                   ADR_ADDRESS_LINE_2 || ' ' ||
                   ADR_ADDRESS_LINE_3 || ' ' ||
                   ADR_ADDRESS_LINE_4 as ADDRESS,
                   adr_pin_code,adr_phone_no,adr_fax_no
              from dwh.beneficiary_address_dim where adr_type_id = 6) MINOR_ADDRESS,
                     (Select rp.requestid as requestid,
    decode(rp.value,'ALL','ALL','','ALL',decode(substr(rp.value,1,instr(rp.value,'|',1,1)-1),'','ALL',substr(rp.value,1,instr(rp.value,'|',1,1)-1))) as Name,
    decode(rp.value,'ALL','ALL','','ALL',decode(substr(rp.value,(instr(rp.value,'|',1,1)+1),((instr(rp.value,'|',1,2))-(instr(rp.value,'|',1,1)+1))),'','ALL',substr(rp.value,(instr(rp.value,'|',1,1)+1),((instr(rp.value,'|',1,2))-(instr(rp.value,'|',1,1)+1))))) as Address,
    decode(rp.value,'ALL','ALL','','ALL',decode(substr(rp.value,(instr(rp.value,'|',1,2)+1)),'','ALL',substr(rp.value,(instr(rp.value,'|',1,2)+1)))) as PAN
                      from disadmin.requestparameters rp, disadmin.requestparameters rps, disadmin.reportrequests rr
                     where rp.parameterid = 'CNAS_PARAM_VALUE'   
                       and rr.status = 'A'
                       and rp.requestid = rr.id
                       and rp.id = rps.id) P_PARAM_VALUE,
                     (Select rp.requestid as requestid, rp.value as Type
                        from disadmin.requestparameters rp, disadmin.reportrequests rr
                       where rp.parameterid = 'CNAS_NAME_TYPE'
                         and rr.status = 'A'
                         and rp.requestid = rr.id)  P_NAME_TYPE,
                     (Select rp.requestid as requestid, rp.value as Addtype
                        from disadmin.requestparameters rp, disadmin.reportrequests rr
                       where rp.parameterid = 'CNAS_ADDRESS_TYPE'
                         and rr.status = 'A'
                         and rp.requestid = rr.id) P_ADDRESS_TYPE    
       where ( 1= case when P_NAME_TYPE.Type = 'F' then
                   case when BEN_DIM.BDM_FIRST_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
                             or BEN_DIM.BDM_FIRST_HOLDER_SURNAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_SURNAME||'%','%'||P_PARAM_VALUE.Name||'%')
                        then 1
                   else null end
                 else            
                   case when P_NAME_TYPE.Type = 'ALL' then
                     case when (BEN_DIM.BDM_FIRST_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
                                or BEN_DIM.BDM_FIRST_HOLDER_SURNAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_SURNAME||'%','%'||P_PARAM_VALUE.Name||'%'))
                                and BEN_DIM.BDM_SECOND_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_SECOND_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
                                and BEN_DIM.BDM_THIRD_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_THIRD_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
                          then 1
                     else null end
                   else null end 
                 end )                    
         and BEN_DIM.BDM_IT_PAN like DECODE(P_PARAM_VALUE.PAN,'ALL','%'||BEN_DIM.BDM_IT_PAN||'%','%'||P_PARAM_VALUE.PAN||'%')
         and (1 = case when P_ADDRESS_TYPE.ADDTYPE = 1 then
                         case when instr(PERMANENT_ADD_DIM.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',PERMANENT_ADD_DIM.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0
                              then 1
                         else null end
                       when P_ADDRESS_TYPE.ADDTYPE = 3 then
                         case when instr(NOM_GUARDIAN_ADD_DIM.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',NOM_GUARDIAN_ADD_DIM.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0 
                           then 1
                         else null end 
                       when P_ADDRESS_TYPE.ADDTYPE = 4 then
                         case when instr(CORR_ADD_DIM.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',CORR_ADD_DIM.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0 
                           then 1
                         else null end
                       when P_ADDRESS_TYPE.ADDTYPE = 6 then
                         case when instr(MINOR_ADDRESS.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',MINOR_ADDRESS.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0 
                           then 1
                         else null end 
                  else null end );The above query also tries to access some tables from another user DISADMIN. Could you please help me in solving this problem while using SQL Tuning Advisor ? I am the only DBA here.

    will the rows really be updated just by using the package?Considering DMLs
    SQL> select * from test
      2  /
            NO
             1
             2
    SQL> ed
    Wrote file afiedt.buf
      1  DECLARE
      2   my_task_name VARCHAR2(30);
      3  my_sqltext   CLOB;
      4  BEGIN
      5  my_sqltext := 'insert into test values (3)';
      6  my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
      7   sql_text    => my_sqltext,
      8  task_name   => 'my_sql_tuning_task');
      9* end;
    SQL> /
    PL/SQL procedure successfully completed.
    SQL> BEGIN
      2  DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task' );
      3  END;
      4  /
    PL/SQL procedure successfully completed.
    SQL> select * from test
      2  /
            NO
             1
             2
    SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'my_sql_tuning_task')
      2    FROM DUAL;
    DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK')
    GENERAL INFORMATION SECTION
    Tuning Task Name   : my_sql_tuning_task
    Tuning Task Owner  : TEST
    Scope              : COMPREHENSIVE
    Time Limit(seconds): 1800
    Completion Status  : COMPLETED
    Started at         : 03/27/2008 05:16:14
    Completed at       : 03/27/2008 05:16:16
    DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK')
    Schema Name: TEST
    SQL ID     : gwkmgmyj9824t
    SQL Text   : insert into test values (3)
    There are no recommendations to improve the statement.
    -------------------------------------------------------------------------------Adith

  • Change automatic SQL Tuning Advisor time

    Hi All,
    can anyone help me in changing "automatic SQL Tuning Advisor" job timingsm because currently it is scheduled during peak hours , i want to change it to evening 6 pm daily.Because during peak hours it is taking more cpu and taking one hour.
    Wed May 08 08:00:10 2013
    Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
    Wed May 08 08:05:47 2013
    thanks
    Mapps

    Hello,
    Here's what you can do,
    Create a new window to the time you want it to run:
    EXEC dbms_scheduler.create_window(window_name => 'YOUR_WINDOW_NAME',
    duration => numtodsinterval(1, 'hour'),
    resource_plan => 'DEFAULT_MAINTENANCE_PLAN',
    repeat_interval => 'FREQ=DAILY;BYHOUR=18;BYMINUTE=0;BYSECOND=0');>
    The above window would be in effect from 6 pm to 7 pm.
    Then, disable automatic sql_tuning and then re-enable it to run on the window you just created:
    EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'sql tuning advisor',
    operation => NULL,
    window_name => NULL);>
    and now set it to run to your window:
    EXEC DBMS_AUTO_TASK_ADMIN.ENABLE(client_name => 'sql tuning advisor',
    operation => NULL,
    window_name => 'YOUR_WINDOW_NAME');

  • Enterprise Manager - sql tuning advisor , Access advisor for SQL Tuning

    Hi,
    NO I mean in oracle 10g you have the enterprise manager which can be used to tune sql statements using the SQL ADvisor and SQL access advisor.
    I believe in oracle 10g the process of SQL Tuning is slightly easier using the Enterprise Manager ...so if some one could explain me that process...
    Again thanking you in advance
    regds
    Manoj Gokhale

    Hi Manoj,
    tune sql statements using the SQL ADvisor and SQL access advisor.Do you have the OEM extra cost "performance pack"?
    The OEM screens are fairly self-explainatory, but here are some references on the 10 SQL tuning advisors:
    http://www.oracle-base.com/articles/10g/AutomaticSQLTuning10g.php
    http://www.remote-dba.net/oracle_10g_tuning/t_oracle_sql_tuning_advisor_session_example.htm

Maybe you are looking for