Explain plan changing after partition exchange

I currently have a data warehouse where I use partition exchange to refresh the data. I'm finding that after a partition exchange of exactly the same data. explain plan changes.
database 11.2.0.2
To demonstrate what I'm doing I simplified the steps.
first I gather stats on the table that will be exchanged and run explain plan
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
Select
FROM IDW_TARGET.ITD_MONTHLY_SUMMARY_FACT A,
IDW_TARGET.GL_PERIOD_DIM B,
IDW_TARGET.PROGRAM_DIM C,
IDW_TARGET.RPT_ENTITY_DIM D
WHERE ASST_SEC_CONCISE_NAME = 'abc'
AND A.GL_PERIOD_KEY = B.KEY
AND A.PROGRAM_KEY = C.KEY
AND A.RPT_ENTITY_KEY = D.KEY
AND B.PERIOD_YEAR >= 2006;
** uses FTS on fact table and runs in 20 seconds. **
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 25M| 71G| 47105 (1)| 00:09:26 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 25M| 61G| 46999 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 15 | HASH JOIN | | 25M| 57G| 46992 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | 4085 | 6829K| 1334 (1)| 00:00:17 | | | Q1,03 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10002 | 4085 | 6829K| 1334 (1)| 00:00:17 | | | | S->P | BROADCAST |
| 19 | PARTITION RANGE SINGLE| | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
|* 20 | TABLE ACCESS FULL | PROGRAM_DIM | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
| 21 | PX BLOCK ITERATOR | | 71M| 45G| 45650 (1)| 00:09:08 | 1 | LAST | Q1,03 | PCWC | |
| 22 | TABLE ACCESS FULL | ITD_MONTHLY_SUMMARY_FACT | 71M| 45G| 45650 (1)| 00:09:08 | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
15 - access("A"."PROGRAM_KEY"="C"."KEY")
20 - filter("ASST_SEC_CONCISE_NAME"='abc'')
drop table PELPROGRAMDIMALLDATA; -- Start fresh here and drop the partition that will be exchanged
create table PELPROGRAMDIMALLDATA as select * from PROGRAM_DIM; -- going to use exact same data for partition exchange (only one parition)
alter table PELPROGRAMDIMALLDATA add constraint CON_342 unique ("VALUE" ) using index ;
alter table PELPROGRAMDIMALLDATA add constraint CON_343 primary key ("KEY" ) using index ;
exec dbms_stats.gather_table_stats(ownname=>'IDW_TARGET', tabname=>'PELPROGRAMDIMALLDATA');
alter table PROGRAM_DIM exchange partition ALL_DATA with table PELPROGRAMDIMALLDATA excluding indexes;
** rebuild indexes **
** explain plan for same statement uses nested loop**
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 2637K| 6511M| 33324 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
| 15 | NESTED LOOPS | | 2642K| 6035M| 33318 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 18 | PX SEND ROUND-ROBIN | :TQ10002 | | | | | | | | S->P | RND-ROBIN |
| 19 | PARTITION RANGE SINGLE | | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
| 20 | TABLE ACCESS BY LOCAL INDEX ROWID| PROGRAM_DIM | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
|* 21 | INDEX RANGE SCAN | PROGRAM_DIM_IX20 | 420 | | 3 (0)| 00:00:01 | 1 | 1 | | | |
| 22 | PARTITION RANGE ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 9 | Q1,03 | PCWP | |
| 23 | PARTITION LIST ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | LAST | Q1,03 | PCWP | |
| 24 | TABLE ACCESS BY LOCAL INDEX ROWID | ITD_MONTHLY_SUMMARY_FACT | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 141 | Q1,03 | PCWP | |
| 25 | BITMAP CONVERSION TO ROWIDS | | | | | | | | Q1,03 | PCWP | |
|* 26 | BITMAP INDEX SINGLE VALUE | ITD_MONTHLY_SUMMARY_SK09 | | | | | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
21 - access("ASST_SEC_CONCISE_NAME"='abc')
26 - access("A"."PROGRAM_KEY"="C"."KEY")
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
** explain plan for same statement uses full table scan**
see first explain plan
Since the stats were not gathered after the partition exchange I would imagine that they would still be used.
Edited by: user12198207 on Feb 7, 2012 8:13 AM
Edited by: user12198207 on Feb 7, 2012 9:47 AM

Locking stats did not make any difference. Also, I deleted the stats at the global level leaving just partition stats and it continued to use the nested loop which takes 15+ minutes instead of 20 seconds with the FTS.
In my original situation it listed the stats at the global level as stale after the partition exchange. But after I removed many of the steps and use just what's described in this posts.
select * from dba_tab_statistics
where table_name='PROGRAM_DIM';
shows stale stats=no for both global and partition. Kind of unexpected. Further digging in shows that is just determined by a case statement.
from dba_tab_statistics view ddl
case
when t.analyzetime is null then null
when ((m.inserts + m.deletes + m.updates) >
t.rowcnt *
to_number(DBMS_STATS.GET_PREFS('STALE_PERCENT',
u.name, o.name))/100 or
bitand(m.flags,1) = 1) then 'YES'
else 'NO'
end

Similar Messages

  • Explain plan change after partitioning - Bitmap conversion to rowid

    hi gurus,
    before partitioning the table using range paritioning,
    for the query,
    SELECT MEDIUMID
              FROM MEDIUM_TB
              WHERE CMREFERENCEID =8
               AND CONTENTTYPEID = 8
               AND CMSTATUSID = 5
               AND SUBTYPEID = 99
    A. before partitioning
    SELECT STATEMENT, GOAL = ALL_ROWS          2452     882     16758
    SORT ORDER BY               2452     882     16758
      TABLE ACCESS BY INDEX ROWID     DBA1     MEDIUM_TB     2451     882     16758
       BITMAP CONVERSION TO ROWIDS                         
        BITMAP AND                         
         BITMAP CONVERSION FROM ROWIDS                         
          INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX07     242     94423     
         BITMAP CONVERSION FROM ROWIDS                         
          INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX02     1973     94423     
    B. after partitioning
    the explain plan changed to
    SELECT STATEMENT, GOAL = ALL_ROWS          33601     796     15124
    TABLE ACCESS BY GLOBAL INDEX ROWID     DBA1     MEDIUM_TB     33601     796     15124
      INDEX RANGE SCAN     DBA1     MEDIUM_TB_IX07     300     116570     as you can see in the plan, the paln cost is very high after partitioning and the query is taking more time.
    index MEDIUM_TB_IX02 is not used in the second plan and also the plan method BITMAP CONVERSION.
    fyi, there is all the indexes are b-tree based and global indexes.
    what could be reason for the plan change?
    please help
    thanks,
    charles

    user570138 wrote:
    SELECT STATEMENT, GOAL = ALL_ROWS          2452     882     16758
    SORT ORDER BY               2452     882     16758
    TABLE ACCESS BY INDEX ROWID     DBA1     MEDIUM_TB     2451     882     16758
    BITMAP CONVERSION TO ROWIDS                         
    BITMAP AND                         
    BITMAP CONVERSION FROM ROWIDS                         
    INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX07     242     94423     
    BITMAP CONVERSION FROM ROWIDS                         
    INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX02     1973     94423     
    If you supplied proper execution plans we might be able to offer some advice.
    Use dbms_xplan.
    A list of the index definitions might also help
    Regards
    Jonathan Lewis

  • Performance problem: Query explain plan changes in pl/sql vs. literal args

    I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between 123 and 456;
    Its performance was excellent with literal arguments (1 sec per execution).
    But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
    Ex:
    CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
    CURSOR LT_CURSOR IS
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between param1 AND param2;
    BEGIN
    FOR aRecord IN LT_CURSOR
    LOOP
    (print timestamp...)
    END LOOP;
    END runQuery;
    Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
    Solution:
    Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
    Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
    Downside: Query not cached for future use. Perfectly fine for this query's purpose.
    Other suggestions are welcome.

    AmandaSoosai wrote:
    I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between 123 and 456;
    Its performance was excellent with literal arguments (1 sec per execution).
    But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
    Ex:
    CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
    CURSOR LT_CURSOR IS
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between param1 AND param2;
    BEGIN
    FOR aRecord IN LT_CURSOR
    LOOP
    (print timestamp...)
    END LOOP;
    END runQuery;
    Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
    Solution:
    Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
    Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
    Downside: Query not cached for future use. Perfectly fine for this query's purpose.
    Other suggestions are welcome.Best wild guess based on what you've posted is a bind variable mismatch (your column is declared as a NUMBER data type and your bind variable is declared as a VARCHAR for example). Unless you have histograms on the columns in question ... which, if you're using bind variables is usually a really bad idea.
    A basic illustration of my guess
    http://blogs.oracle.com/optimizer/entry/how_do_i_get_sql_executed_from_an_application_to_uses_the_same_execution_plan_i_get_from_sqlplus

  • Explain plan change

    9.2.0.8 on solaris 10
    What are the scenarios that an explain plan will change when using RBO as optimizer_mode
    we have a query like :
    select * emp where empno=101;
    For this query , the explain plan uses the index in the column empno where as the query :
    select * emp where empno=501;
    doesn't use a index . the time taken for retreival is the same . but why does the explain plan change ?.
    Do we have to collect stats when using RBO ?
    I tried tracing the above sessions, but couldn't find any diff (just to let you know that I tried )
    Edited by: user12046873 on Feb 28, 2010 10:43 PM

    It appears you are not using RBO, because using RBO would have resulted in the same execution plans. PERIOD.
    Nor should you use RBO, as CBO provides way better execution plans.
    You don't post these execution plans, nor how you retrieved them, so no comments are possible.
    They need to be the live execution plan from a trace file,+not using explain=+ as that will have tkprof calculate the explain plan.
    Sybrand Bakker
    Senior Oracle DBA

  • Explain plan changing for the same sql

    Hi All,
    In a E Business suite application, we have the 10.2.0.4 Database.
    One of the program is running a select stmt which is using different explain plan one in a month which is causing issue in the program running for longer time.
    Ex : When it uses the index A, it is running fine. When it uses the index B, it is running for longer time.
    Can you please advice on the possible reasons for the same sql to choose index B instead of index A some times.
    Thanks,
    Rakesh

    It could be that the SQL is question got aged out of the shared pool and when it came to be reparsed - the values in the bind variables were such that access via index b was more attractive than access via index a.
    Could you please send the query and the good and bad plans and all other information that might help diagnose the problem..
    Note: we had a similiar case where plans suddenly changed for no apperant reason (on 10.2.0.2) - we found that under certain circumstances the optimizer would not peek into the bind varaibles to derive the execution path.

  • Explain plan changes by result size from contains clause

    I use 10.2.0.3 Std Edition and have a query like this
    select t1.id from table1 t1
    where t1.col99 = 123
    and t1.id in (select ttxt.id from fulltexttable ttxt where contains (ttxt.thetext, 'word1 & word2'));
    (note: for each row in table1 exists at least one corresponding row in fulltexttable)
    Now I came across a surprising change in execution plans depending on the values of word1 and word2:
    - if the number of result rows from the subquery is low compared to all rows the full text index is used (table access by rowid/domain index)
    - if the number of result rows is high explain plan does not indicate any use of the domain index (full text index) but only a full text table scan. And the slow execution proves this plan.
    But: if I create explain plan for the subquery only there is no difference whether the number of result rows is high or low: the full text index is always used.
    Any clue for this change in execution strategy?
    Michael

    hi michael,
    this is expected behaviour. because you have a query incorporating more than just a text-index, and furthermore, multiple tables, the optimizer may choose different access paths according to the cardinality of your where clause terms. in fact, anything you see is actually vanilla behaviour.
    however, as i suppose, you probably have not yet heard about the "post filter" characteristic of a context index. see the tuning chapter of the text dev guide for more info. also note that the optimizer has no other way than accessing the context index directly iff you execute the subquery on its own (the "post filter" characteristic is not applicable here, because a post filter always needs some input to be filtered). and finally, be aware that oracle may unnest your subquery by its own decision, that is, do not try to force a direct context index access by a subquery, it will not work (a compiler hint is the only thing that works relyably).
    the only thing i can not follow is the fts for your second example. dont you have join indexes on table1.id and fulltexttable.id, respectively?
    p

  • Explain plan changing between 9i and 11g

    Hi
    Recently we migrated the database from 9i to 11g.In 11g environment one query was running for long time and when we comapre the explain plan between 9i and 11g, we found one of the table is going through "INDEX RANGE SCAN NON UNIQUE" in 9i but in 11g it is accessing through "INDEX RANGE SCAN INDEX".
    Is there any hint to add so that it will access table through "INDEX RANGE SCAN NON UNIQUE"  in 11g?
    Please Help.

    I agree with Paul.
    Why are you assuming that the optimizer in 11g, which has had bug fixes and vast improvements since 9i, is optimizing the query badly just because you think the query is running slowly.
    Before making assumptions, you need to find the cause of the issue, not just look for differences in two non-comparible explain plans and assume that's the cause.  Adding hints to force indexes and suchlike is not the answer (even though some idiots may suggest it is).
    As it says in the documentation in relation to hints:
    Comments
    Hints were introduced in Oracle7, when users had little recourse if the optimizer generated suboptimal plans. Now Oracle provides a number of tools, including the SQL Tuning Advisor, SQL plan management, and SQL Performance Analyzer, to help you address performance problems that are not solved by the optimizer. Oracle strongly recommends that you use those tools rather than hints. The tools are far superior to hints, because when used on an ongoing basis, they provide fresh solutions as your data and database environment change.

  • Explain Plan changed using "IN"

    Hi ,
    I am using one of the query as below
    select a.x, b.y, c.z from a,b,c
    where
    a.x in ( select x from temp where col=b.y)
    i checked explain plan this query is going to access full table x
    i have index on x for temp table.
    i need to check b.y in subquery as parameter and that subquery result i have to use as first main query's where criteria.
    using function i can get only one record at time.
    if anyone have any idea how to solve.
    TIA

    when i use = instead of "IN" below is the explain plan from TOAD
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Optimizer Mode=RULE                                        
    SORT UNIQUE                                        
    CONCATENATION                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES                                   
    INDEX UNIQUE SCAN     PK_JOT                                   
    TABLE ACCESS BY INDEX ROWID     BULK_BOL                                   
    INDEX RANGE SCAN     BULK_BOL_N1                                   
    TABLE ACCESS BY INDEX ROWID     BULK_SKID                                   
    INDEX RANGE SCAN     BULK_SKID_N1                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON                                   
    INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY                                   
    INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK                                   
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES                                   
    INDEX UNIQUE SCAN     PK_JOT                                   
    TABLE ACCESS BY INDEX ROWID     BULK_BOL                                   
    INDEX RANGE SCAN     BULK_BOL_N1                                   
    TABLE ACCESS BY INDEX ROWID     BULK_SKID                                   
    INDEX RANGE SCAN     BULK_SKID_N1                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON                                   
    INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY                                   
    INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK                                   
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES                                   
    INDEX UNIQUE SCAN     PK_JOT                                   
    TABLE ACCESS BY INDEX ROWID     BULK_BOL                                   
    INDEX RANGE SCAN     BULK_BOL_N1                                   
    TABLE ACCESS BY INDEX ROWID     BULK_SKID                                   
    INDEX RANGE SCAN     BULK_SKID_N1                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON                                   
    INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY                                   
    INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK                                   
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    TABLE ACCESS BY INDEX ROWID     BULK_BOL                                   
    INDEX RANGE SCAN     BULK_BOL_N1                                   
    TABLE ACCESS BY INDEX ROWID     BULK_SKID                                   
    INDEX RANGE SCAN     BULK_SKID_N1                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON                                   
    INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY                                   
    INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK                                   
    TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES                                   
    INDEX UNIQUE SCAN     PK_JOT                                   
    when i use "IN" below is the explain plan from TOAD
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Optimizer Mode=RULE                                        
    SORT UNIQUE                                        
    FILTER                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    NESTED LOOPS                                        
    TABLE ACCESS FULL     JOB_DETAIL_LINES                                   
    TABLE ACCESS BY INDEX ROWID     BULK_BOL                                   
    INDEX RANGE SCAN     BULK_BOL_N1                                   
    TABLE ACCESS BY INDEX ROWID     BULK_SKID                                   
    INDEX RANGE SCAN     BULK_SKID_N1                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON                                   
    INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2                                   
    TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY                                   
    INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK                                   
    INDEX UNIQUE SCAN     PK_JOT

  • Explain plan changed

    Hi All,
    I have a performance issues in one of my database when i checked found that the plan has been changed.
    The previous plan was good and the new plan causing the slowness in query level.
    There is no code level change, No data volume increasing/ Nothing got changed in that query.
    i want to reset the old plan for this query, how can we proceed with that.
    is there any way to reset the old plan for the current query!!!
    please help me
    I dont have the query and plan details with me now, but curious to know how do we set it back with old(good) plan.
    RDBMS version: Version 11.2.0.3
    Edition: Enterprise Edition
    OS: Linux 5.6
    Thanks

    What is the cause of the plan change?
    On 11.2.0.3, it might be cardinality feedback.
    but curious to know how do we set it back with old(good) plan.Assuming you have the old, good plan in either the cursor cache or in AWR, then you have at least two options - one to load the plan into a sql plan baseline or to use a sql profile.
    Assuming that the old plan is not in the cursor cache but is still in AWR, then the steps are along the lines of:
    1. Create a SQL tuning set using DBMS_SQLTUNE.CREATE_SQLSET
    2. Load in your specific plan from AWR into a SQLSET using DBMS_SQLSET.LOAD_SQLSET and DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY
    3. Load plan into a baseline using DBMS_SPM.LOAD_PLANS_FROM_SQLSET.
    Alternatively, to use a sql profile to lock in a specific plan using outline hints, see COE_XFR_SQL_PROFILE script via Oracle Support doc id 215187.1
    The latter is certainly easier but baselines are marketed as sql plan management 2.0.

  • BI-IP To track the planning changes after Data Locking

    Hi All,
    Need your help to design solution for one critical user requirement in IP.
    We all know that in CC Planning, every month after certain date we lock the planning tool and freeze the data. But on exceptional basis, we might require to unlock planning tool to allow users to do some changes in planning data.
    User wants to track these changes and report it out. Is there any standard functionality that SAP-IP has provided to track these kind of changes? If not what is the best way to achieve this?
    Appreciate any input regarding this ! Thanks a lot!
    Som

    Hi,
    You need to have additional characteristics for User & Date in your RTP to record who changed when and what plan record.
    Then you can create a characteristic relationship of type 'Exit Class' to derive User Id(last changed by) and the date(last modified).
    Itu2019s not necessary to include User-ID and Date in any of the aggregation levels, but the Source Characteristic(Company code may be in your case) based on which the values are derived for User-ID & Date, must be present in each aggregation level.
    Then create a custom class say ZCL_LOC_CR_LINE_ITEM by taking class CL_RSPLS_CR_EXIT_BASE  as super class and then redefine the method DERIVE of interface IF_RSPLS_CR_METHODS in your class.
    You can write following code in your method DERIVE:
    CLEAR e_t_mesg.
    FIELD-SYMBOLS: <l_chavl> TYPE ANY.
    ASSIGN COMPONENT '/BIC/ZUSERID' OF STRUCTURE c_s_chas TO <l_chavl>.
      <l_chavl> = sy-uname.
    ASSIGN COMPONENT '0DATE' OF STRUCTURE c_s_chas TO <l_chavl>.
      <l_chavl> = sy-datlo.
    This will solve your purpose.
    Regards,
    Deepti

  • Help needed in EXPLAIN PLAN for a partitioned table

    Oracle Version 9i
    (Paste execution plan in a spreadsheet to make sense out of it)
    I am trying to tune this query -
    select * from comm c ,dates d
    where
    d.active_period = 'Y'
    and c.period = d.period;
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Optimizer Mode=CHOOSE          5 M          278887                     
    HASH JOIN          5 M     5G     278887                     
    TABLE ACCESS FULL     SCHEMA.DATES     24      1 K     8                     
    PARTITION LIST ALL                                   1     8
    TABLE ACCESS FULL     SCHEMA.COMM     6 M     5G     277624                1     8
    However, I know that the dates table will return only one record. So, if I add another condition to the above query, I get this execution plan. The comm table is huge but it is partitioned on period.
    select * from comm c ,dates d
    where
    d.active_period = 'Y'
    and c.period = qd.period
    and c.period = 'OCT-07'
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Optimizer Mode=CHOOSE          1           8                     
    MERGE JOIN CARTESIAN          1      9 K     8                     
    TABLE ACCESS FULL     SCHEMA.DATES     1      69      8                     
    BUFFER SORT          1      9 K                         
    TABLE ACCESS BY LOCAL INDEX ROWID     SCHEMA.COMM     1      9 K                    7     7
    INDEX RANGE SCAN     SCHEMA.COMM_NP9     1                          7     7
    How can I make the query such that the comm table does not have to traverse all of its partitions? The partitioning is based on quarters so it will get its data in one partition only (in the above example - partition no. 7)
    Thanks in advance for writing in your replies :)

    You need to specify period = 'OCT-07', otherwise there is no way the optimizer can know it needs to access only one partition.
    Alternatively, partition the DATES table in exactly the same way on "period", and partition-wise joins should kick in, and effectively accessing only the active partition.

  • Different explain plan between 10.2.0.3 and 10.2.0.4

    Had a problem with an explain plan changing after upgrade from 10.2.0.3 to 10.2.0.4. Managed to simplify as much as possible for now:
    Query is :
    SELECT * FROM m_promo_chk_str
    WHERE (m_promo_chk_str.cust_cd) IN (
    SELECT cust_cd
    FROM s_usergrp_pda
    GROUP BY cust_cd)
    On 10.2.0.3 explain plan is:
    | 0 | SELECT STATEMENT | | 1 | 1227 | 26 (16)| 00:00:01 |
    |* 1 | HASH JOIN SEMI | | 1 | 1227 | 26 (16)| 00:00:01 |
    | 2 | TABLE ACCESS FULL | M_PROMO_CHK_STR | 1 | 1185 | 14 (0)| 00:00:01 |
    | 3 | VIEW | VW_NSO_1 | 137 | 5754 | 11 (28)| 00:00:01 |
    | 4 | HASH GROUP BY | | 137 | 548 | 11 (28)| 00:00:01 |
    | 5 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 9 (12)| 00:00:01 |
    On 10.2.0.4 with same data is:
    | 0 | SELECT STATEMENT | | 1 | 1201 | 46 (5)| 00:00:01 |
    | 1 | HASH GROUP BY | | 1 | 1201 | 46 (5)| 00:00:01 |
    |* 2 | HASH JOIN | | 1 | 1201 | 45 (3)| 00:00:01 |
    | 3 | TABLE ACCESS FULL| M_PROMO_CHK_STR | 1 | 1197 | 29 (0)| 00:00:01 |
    | 4 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 15 (0)| 00:00:01 |
    Explain plan is reasonable for when M_PROMO_CHK_STR is empty, however we have the case where stats are gathered when table is empty, but table is then populated and the query runs slowly. I understand that this is not a problem with the database exactly, but want to try to understand why the different behaviour.
    Will look into CBO trace tommorrow, but for now anyone want to share any thoughts?

    PatHK wrote:
    Here is further simplification to reproduce the different behaviour - I think about as simple as I can get it!
    SELECT * FROM dual WHERE (dummy) IN (SELECT dummy FROM dual GROUP BY dummy);
    On 10.2.0.3
    |   0 | SELECT STATEMENT     |          |     1 |     4 |     5  (20)| 00:00:01 |
    |   1 |  NESTED LOOPS SEMI   |          |     1 |     4 |     5  (20)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL  | DUAL     |     1 |     2 |     2   (0)| 00:00:01 |
    |*  3 |   VIEW               | VW_NSO_1 |     1 |     2 |     3  (34)| 00:00:01 |
    |   4 |    SORT GROUP BY     |          |     1 |     2 |     3  (34)| 00:00:01 |
    |   5 |     TABLE ACCESS FULL| DUAL     |     1 |     2 |     2   (0)| 00:00:01 |On 10.2.0.4
    |   0 | SELECT STATEMENT     |      |     1 |     4 |     4   (0)| 00:00:01 |
    |   1 |  SORT GROUP BY NOSORT|      |     1 |     4 |     4   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS       |      |     1 |     4 |     4   (0)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    Timur's suggestion to look at a 10053 trace file is a good idea. It might be the case that someone disabled complex view merging in the 10.2.0.3 database instance. See the following:
    _complex_view_merging
    http://jonathanlewis.wordpress.com/2007/03/08/transformation-and-optimisation/
    Here is a test you might try on both database versions:
    ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=TRUE;
    ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST1';
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
    ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=FALSE;
    ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST2';
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';The first plan output:
    | Id  | Operation            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |      |       |       |     8 (100)|          |
    |   1 |  SORT GROUP BY NOSORT|      |     1 |     4 |     8   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS       |      |     1 |     4 |     8   (0)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     4   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     4   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - filter("DUMMY"="DUMMY")The second plan output:
    | Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |          |       |       |     9 (100)|          |
    |   1 |  NESTED LOOPS SEMI   |          |     1 |     4 |     9  (12)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL  | DUAL     |     1 |     2 |     4   (0)| 00:00:01 |
    |*  3 |   VIEW               | VW_NSO_1 |     1 |     2 |     5  (20)| 00:00:01 |
    |   4 |    SORT GROUP BY     |          |     1 |     2 |     5  (20)| 00:00:01 |
    |   5 |     TABLE ACCESS FULL| DUAL     |     1 |     2 |     4   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - filter("DUMMY"="$nso_col_1")From the first 10053 trace file:
    PARAMETERS USED BY THE OPTIMIZER
      PARAMETERS WITH ALTERED VALUES
      _pga_max_size                       = 368640 KB
    pgamax_size is the only parameter non-default value which could affect the optimizer.
    From the second 10053 trace file:
    PARAMETERS USED BY THE OPTIMIZER
      PARAMETERS WITH ALTERED VALUES
      _pga_max_size                       = 368640 KB
      _complex_view_merging               = false
      *********************************This section in the first 10053 trace seems to show the complex view merging:
    SU: Considering interleaved complex view merging
    SU:   Transform an ANY subquery to semi-join or distinct.
    CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
    CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
    CVM: CBQT Marking query block SEL$683B0107 (#2)as valid for CVM.
    CVM:   Merging complex view SEL$683B0107 (#2) into SEL$5DA710D3 (#1).
    qbcp:******* UNPARSED QUERY IS *******
    SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM  (SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY") "VW_NSO_2","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    vqbcp:******* UNPARSED QUERY IS *******
    SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY"
    CVM: result SEL$5DA710D3 (#1).
    ******* UNPARSED QUERY IS *******
    SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM "SYS"."DUAL" "DUAL","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="DUAL"."DUMMY" GROUP BY "DUAL"."DUMMY","DUAL".ROWID,"DUAL"."DUMMY"
    Registered qb: SEL$C9C6826C 0x155e2020 (VIEW MERGE SEL$5DA710D3; SEL$683B0107)
      signature (): qb_name=SEL$C9C6826C nbfros=2 flg=0
        fro(0): flg=0 objn=258 hint_alias="DUAL"@"SEL$1"
        fro(1): flg=0 objn=258 hint_alias="DUAL"@"SEL$2"
    FPD: Considering simple filter push in SEL$C9C6826C (#1)
    FPD:   Current where clause predicates in SEL$C9C6826C (#1) :
             "DUAL"."DUMMY"="DUAL"."DUMMY"
    kkogcp: try to generate transitive predicate from check constraints for SEL$C9C6826C (#1)
    predicates with check contraints: "DUAL"."DUMMY"="DUAL"."DUMMY"
    after transitive predicate generation: "DUAL"."DUMMY"="DUAL"."DUMMY"
    finally: "DUAL"."DUMMY"="DUAL"."DUMMY"
    CVM: Costing transformed query.
    kkoqbc-start
                : call(in-use=25864, alloc=65448), compile(in-use=115280, alloc=118736)
    kkoqbc-subheap (create addr=000000001556CD70)This is the same section from the second 10053 trace:
    SU: Considering interleaved complex view merging
    SU:   Transform an ANY subquery to semi-join or distinct.
    CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
    CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
    FPD: Considering simple filter push in SEL$5DA710D3 (#1)
    FPD:   Current where clause predicates in SEL$5DA710D3 (#1) :
             "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
    predicates with check contraints: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    after transitive predicate generation: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    finally: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    FPD: Considering simple filter push in SEL$683B0107 (#2)
    FPD:   Current where clause predicates in SEL$683B0107 (#2) :
             CVM: Costing transformed query.
    kkoqbc-start
                : call(in-use=25656, alloc=65448), compile(in-use=113992, alloc=114592)
    kkoqbc-subheap (create addr=00000000157E9078)Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Query regarding Partition table Explain plan

    Hello,
    We are amidst a tuning activity, wherein a large table has been partitioned for better administration. During testing, I was analyzing the explain plans for long running sql's and found a piece that I was unable to understand. The PSTART and PSTOP columns show ROWID as its value, which in normal partition pruning scenario be the Partition number or the KEY. I tried to look around for this issue but did not get enough information. Can anybody help me of what it means? Also, if there is a good explanation of the same, it will be extremely helpful.
    The snippet from explain plan looks like:
    | Id  | Operation                                | Name                          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    7 |        TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXXXXXXXX             | 43874 |  9083K|       |  1386   (1)| 00:00:17 | ROWID | ROWID |
    On another similar query it looks like:
    | Id  | Operation                             | Name                         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXX               | 22455 |  4648K|       |   456   (1)| 00:00:06 |     9 |     9 |
    I have another query with regards to the Partition tables. Does it, require/benefit if, the Indexes to be in partitioned mode? I tried to read about it but did not get a conclusive evidence. I am trying to test it and post here the outcome, but if anybody has experience of working with it, it would be great to have some advice.
    Oracle Version:- 10.2.0.4
    Regards,
    Purvesh.

    Hi Purvesh.
    Great explanation and example on this this topic...
    Ask Tom &amp;quot;explain plan on range-partitioned table&amp;quot;
    Hope this help.

  • Why the explain plan incorrent?

    I have a sql in oracle10.2.03:
    select *
    from (select a.*
    from t_user a, t_message b
    where b.user_id = a.row_id and a.user_type = 1
    order by b.happen_time desc)
    where rownum <= 5
    there are indexes on column a.user_type,b.user_id,b.happen_time, and has been analyzed. a.user_type=1 only have 1/1000 records
    the explain plan is below:
    cost Cardinary Bytes
    SELECT STATEMENT, GOAL = ALL_ROWS 30 5 3790
    COUNT STOPKEY
    VIEW BMTEST 30 6 4548
    NESTED LOOPS 30 6 1158
    TABLE ACCESS BY INDEX ROWID BMTEST T_MESSAGE 13 1524118 24385888
    INDEX FULL SCAN DESCENDING BMTEST IDX_MESSAGE_2 1 168
    TABLE ACCESS BY INDEX ROWID BMTEST T_USER 1 1 177
    INDEX UNIQUE SCAN BMTEST PK_USER 1 1
    Oracle use the index full scan descending on the happen_time. the cost only has 30.
    After I add hint on the sql on the user_id of t_message
    select *
    from (select /*+index (b idx_message_1)*/  a.*
    from t_user a, t_message b
    where b.user_id = a.row_id and a.user_type = 1
    order by b.happen_time desc)
    where rownum <= 5
    the explain plan change to:
    cost Cardinary Bytes
    SELECT STATEMENT, GOAL = ALL_ROWS 5020 5 3790
    COUNT STOPKEY
    VIEW BMTEST 5020 54707 41467906
    SORT ORDER BY STOPKEY 5020 54707 10558451
    TABLE ACCESS BY INDEX ROWID BMTEST T_MESSAGE 26 515 8240
    NESTED LOOPS 2707 54707 10558451
    TABLE ACCESS BY INDEX ROWID BMTEST T_USER 1 106 18762
    INDEX RANGE SCAN BMTEST IDX_USER_2 1 106
    INDEX RANGE SCAN BMTEST IDX_MESSAGE_1 1 515
    INDEX UNIQUE SCAN BMTEST PK_USER 1 1
    The cost is 5020, but the execute usage time only is 100ms, and the first SQL does not add hint usage 20s.
    Why the lower cost waste more time, if the cost caculate is incorrect?
    Edited by: [email protected] on Sep 11, 2008 9:14 PM

    [email protected] wrote:
    But i am afraid i use a misunderstand title for this post,my doubt is why oracle get a large cost with the sql execute few time but get a small cost with the sql execute long time.The cost of a query isn't a particularly good proxy for runtime. It is perfectly reasonable for a query with a cost of 1000 to run more quickly than a query with a cost of 100. The cost of queries is only directly comparable between different plans in the same 10053 trace file.
    [email protected] wrote:
    All the indexed columns are both analyzed by the command or by DBMS_STATS package and the cpu costing is enabled.But what order are the commands being run? And why is the ANALYZE command being used to gather optimizer stats.
    In the first plan:
    INDEX FULL SCAN DESCENDING BMTEST IDX_MESSAGE_2 1 168
    Why this index full scan cost only 1? how did oracle get this number? Is there formula to caculate the cost of index full scan? I have read the article named "Cost Based Oracle Fundamentals" and there is no introduce how to caculate it.
    I think this abnormality cost makes the cost of next step "NESTED LOOPS" very smal and finally lead this abnormality result.1) Which article are you talking about? Are you talking about Jonathan Lewis's book "Cost Based Oracle Fundamentals"? Or are you referring to a different article somewhere?
    2) Can you post the query plans formatted via DBMS_XPLAN.DISPLAY (including the predicate information and enclose the output in the \[pre\] and \[pre\] tags to preserve white space?
    Justin
    Justin

  • Understanding CBO decisions, explain plan instability

    Hi,
    I have a situation where the explain plan for a SELECT statement changes
    and performance takes a turn for the worse. The statement in question
    executes well and has the desired explain plan but after an insertion
    having a new eventtype ID the explain plan changes (doing lots of IO)
    and remains bad until the SGA is flushed.
    I would really like to know how to figure out how the CBO makes its
    decisions and why it changes its mind over a 2min period. Any pointers
    to get me started would be greatly appreciated.
    Table has columns C_ID, R_ID, EVENTTYPE, ...
    Regular indexes on (R_ID,C_ID) and EVENTTYPE.
    The SELECT runs well as long as the compound index is used first
    and runs poorly once a new EVENTTYPE is introduced (there are
    approx 10 event types and a new one is being introduced) and its
    index consulted first.
    Thansk,
    Darren

    Delayed block cleanout really confused me. I don't see how
    the details of block updates, SCNs and what is on disk relates
    to explain plans and a SQL statement that changes from
    performing well using the intended index to poorly using an index
    on a column having low cardinality.
    The SQL is actually quite trivial and a merely a lookup on this
    single table.
    SELECT * FROM table
    WHERE c_id = :1 and r_id = :2 and eventtype = :3
    Most of the time Oracle uses the intended index (r_id, c_id) and
    performs well. As long as both columns are used in the condition
    I don't think that ordering of them is an issue.
    If the CBO uses stats which get updated nightly after sufficient
    changes to the table then how can a statement change its execution
    plans (for the same user) following a addition of a row having a
    new EVENTTYPE value over a 2min period.
    That is the reason that I want to see/understand what the CBO
    is doing.
    It turns out that adding a new index (C_ID, R_ID, EVENTTYPE) was
    the bandaid needed to fix the problem but I'd like to get rid of
    it if its not needed.
    I'll look at these posts and try to get the differing plans back.
    At this point I'll need to drop the new index and break the app
    again and might receive some resistance to that.
    Thanks for your input,
    Darren

Maybe you are looking for

  • Mail not opening, "Home directory is full" ???

    I am unable to open my mail application. I'm getting the following error message: "Mail cannot update your mailboxes because your home directory is full. You must free up space in your home folder before using Mail. Delete unneeded documents or move

  • Using iPhotoToGoogleEarth with manually created gps data

    I use iPhotoToGoogleEarth 2.0 to export photos from iPhoto (version 8.1.2) with automatically created gps-information to GoogleEarth. This works well. If I create the gps location in iPhoto manually, the correct gps data are shown within the informat

  • Untread Text Frames without losing text in the second frame

    I probably not gonna use the right terms to express my question because I don't have an english version of ID. I'm sorry for that. If you, for example, import a text document into your column-based layout, you are able to automate the text flow and i

  • What is te max. file size for lightroom

    i have some very big files. lightroom says that the are to big to catalog. but what is the max. file size ?

  • IPhone thinks Bluetooth is still active

    My wife and I have identical iPhone 4s' with iOS 5.1, but... She has her iPhone paired to the bluetooth in a Subaru Forester and the connection is fine, mp3s play thru the speakers, etc...the problem is that when she turns off the vehicle and goes in