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

Similar Messages

  • 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

  • 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 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

  • 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

  • Is there any way to change the document size from scene to scene?

    I'm building a portfolio site, but I need the document size to be different from each scene.  I'd rather not create a separate swf/html file for each page since that would disrupt the transition between scenes (not to mention all the wok I went through to get the dropdown menus working).
    For instance, the "home" scene is structured for 1200x670 px, but the portfolio scene labeled "published" needs to be at 1200x1500px.
    Is there any way to change the document size from scene to scene?  OR; If, for instance, I made the universal document size 1200x1500 for the entire flash file, is there a script that would restrict the "home" scene to only show the first 670 pixels?

    not in flash alone.
    you may be able to do what you want using javascript in your html document and using the externalinterface class to communicate between your actionscript the embedding html javascript.

  • Changing my page size from American A4 to UK A4 shifts everything on the page, if I want everything on the page to stick to the top left rather than shift around, what do I do?

    Changing my page size from American A4 to UK A4 shifts everything on the page, if I want everything on the page to stick to the top left rather than shift to the right and down, what do I do?
    Using Indesign CS6.

    @Gabrielle – if you change the size in your document setup, pages always crop from the center of your spread, if you are using facing pages:
    Uwe

  • 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 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.

  • Can I programmatically change printer paper size from ActionScript?

    Hi,
    I'm a newbie Flash/ActionSript developer and I have been searching for answers for a while with no luck. I wonder if I can get some pointers from this forum.
    I'm trying to programmatically print a movie clip to 8.5" x 11" plain paper regardless of the current paper size setting in the printer. e.g if the user's printer is currently set to use paper size A4, can I change the setting to Letter (8.5" x 11") from ActionScript at runtime? I use PrintJob class for printing the movieclip.
    According to the ActionScript online API spec ( http://www.adobe.com/livedocs/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context =LiveDocs_Parts&file=00002066.html), I can only READ the paper size setting after the call to PrintJob.start. I can't believe that we are not allowed to change the setting. Maybe I missed something here. Can somebody help me out?
    Thanks in advance!

    you can't change the paper size used in client side printer.

  • How to change the font size from tabs ???

    Hi
    I found a tip to change the CSS in the apache directory in the forum here.
    but i can´t find the directory on my hard disk/oracle directory
    i got this version installed:
    Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
    PL/SQL Release 10.2.0.1.0 - Production
    CORE 10.2.0.1.0 Production
    can i change the font size of tabs/regions etc in any other way??

    Hi,
    The font size is defined by the style class used for the tab cells (tabs are normally created as cells in a table).
    To do this, the simplest solution may be to edit the page template:
    1 - Go to Shared Components/Templates
    2 - Select the page template(s) that you are using (you will have to do this for each template that you've used that uses tabs)
    3 - Scroll down to "Standard Tab Attributes" - you'll see two sections: Current Tab and Non Current Standard Tab.
    In Current Tab, you'll have something like:
    <a href="#TAB_LINK#" class="t12standardtabcurrent">#TAB_LABEL#</a>
    In Non Current Standard Tab, you'll have something like:
    <a href="#TAB_LINK#" class="t12standardtabnoncurrent">#TAB_LABEL#</a>
    After the class="...." attribute add in style="font-size:12px" (use whatever px value you want)
    4 - You should repeat the process for Current Parent Tab and Non Current Parent Tab as these contain the same settings
    5 - Apply your changes
    Regards
    Andy

  • 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 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.

  • How do I change the photo sizes from cm to inches in the new iPhoto share/print?

    When I wish to print a picture from the share/print section of iphoto it lists the available print sizes in cm ie 10 x 15 instead of 4 x 6 inches. I can't seem to find anywhere to select the units that you want to use.  I am using the latest version of iPhoto.

    Terence,
    perhaps Dukeasooke is using mixed language settings like me.
    I found that changing "Measurements Units" did not suffice, if the region is still set to Germany. I had to actually set the region in the Language & Text preferences to a country that uses "US" units in addition to ensuring that the "US" units were selected. Also, with Mavericks it is essential  to restart the system before launching iPhoto again after changing "Language & Text" preferences, or they may not take.
    -- Léonie

  • How to change an image size from MB to KB

    Okay I am at a loss how to change an image from 6.8MB to 290KB or at least in the KB's so we can keep from getting the file is too large message from where we want it to go to. I am at a loss when I move the inches smaller the size is still too small. Daughter is trying to move a picture to a site called my space and she keeps getting a message that the file is too large...

    Susan,
    Please see my posting to
    http://www.adobeforums.com/cgi-bin/webx/.3bc17071/4
    Mark

Maybe you are looking for