Star_transformation not shoiwng in the execution plan

Hello

We have a data warehouse and processing star not no projection in the execution plan.

STAR_TRANSFORMATION_ENABLED at the database level.

With the help of 11.2.0.3 on AIX

The fact table has index bitmap and fks to keys on tables dimesnion dimesnion.

Example query
select *
from media m, retailer_transaction rt
, retailer r
where m.dimension_key = rt.plant_issue_id
and rt.outlet_id = r.dimension_key
and prod_num = 600
Anthing we are ' % s '?

Found how interrogate more selective cause said to use star_transformation

added and plis_handled_year = 2013
and out_num 123423

Why is this good?

Is there a rule such as only highly selective queries will use transformation star?

Thank you

Published by: user5716448 on February 15, 2013 04:10

Transformation of Star I it'sactually one expensive thing to do. So, the optimizer plans an ABC on this subject. This quote comes from a piece on the blog of optimizer Oracle [url https://blogs.oracle.com/optimizer/entry/star_transformation]:

"The transformation is performed based on cost - when the cost of the transformed plan is lower than that of the unprocessed plan. If dimension filters do not significantly reduce the amount of data to be extracted from the fact table, and then a full table scan is more effective. »

Cheers, APC

Tags: Database

Similar Questions

  • Cost of the execution plan is different in the two databases

    Hi gurus,

    I have two databases, which are 12 C.

    The execution plan cost is different in the two databases for the same query.

    is it possible to copy the execution to another plan.

    Thank you in advance

    Kind regards

    REDA

    Jr.Raj wrote:

    There are a few differences.

    The machine that has a high cost, has setup up, linux, 2-node RAC, more CPU.

    and

    other machine windows server less Setup and less cpus.

    Please explain, cost really makes a difference.

    Thank you & best regards

    REDA

    You simply can't compare costs like that. It does not work like that. Especially through two different systems.  Here is a very good read: column the COST of the PLAN to EXPLAIN. Oracle FAQ

  • Should I wait until the end of the execution time of the query for the execution plan?

    Hello Experts,

    I want to see the execution plan of the query below. However, it takes more than 3 hours. Should I wait all the time to see the execution plan?

    Note: EXPLAIN PLAN for does not work. (I mean that I do not see the actual line number, etc. with EXPLAIN the PLAN of market)

    You can see the output of the execution plan when I canceled the execution after 1 minute.

    My first question is: what should I do to see the execution plan for queries running out of time time?

    2nd question: when I cancel the query during execution in order to see the execution plan, will I see the specific plan of execution or erroneous values? Because the first execution plan seems inaccurate, what do you think?

    question 3: why EXPLAIN the PLAN for the clause does not work? Also, should I use EXPLAIN the PLAN of the clause to this scenerio? Can I see the result of running for long time without her queries?

    Thnaks for your help.

    Oracle Database 11 g Enterprise Edition Release 11.2.0.2.0 - 64 bit Production

    PL/SQL Release 11.2.0.2.0 - Production

    CORE Production 11.2.0.2.0

    AMT for Linux: Version 11.2.0.2.0 - Production

    NLSRTL Version 11.2.0.2.0 - Production

    Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price

    of custinvoicejour j join custinvoicetrans t on

    substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and

    substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)

    where

    substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457

    and substr (nls_lower (j.dataareaid), 1, 7) = '201' and

    J.INVOICEACCOUNT in

    (select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))

    and J.AVAWARDSALES > 190

    and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'

    "and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';

    SQL_ID, dznya6x7st0t8, number of children 0

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

    Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT,.

    J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price of

    CustInvoiceJour j join custinvoicetrans t on

    substr (nls_lower (j.DataAreaId), 1, 7) =

    substr (nls_lower (t.DataAreaId), 1, 7) and

    = substr (nls_lower (J.INVOICEID), 1: 25)

    substr (nls_lower (t.INVOICEID), 1: 25) where

    substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =

    29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and

    J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of

    drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and

    IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and

    substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and

    "J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.

    Hash value of plan: 2002317666

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

    | ID | Operation | Name                           | Begins | E - lines. A - lines.   A - time | Pads | Bed |  OMem |  1Mem | Used Mem.

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

    |   0 | SELECT STATEMENT |                                |      1.        |      0 | 00:00:00.01 |       0 |      0 |       |       |          |

    |*  1 |  HASH JOIN |                                |      1.   3956.      0 | 00:00:00.01 |       0 |      0 |  2254K |  1061K | 2190K (0) |

    |*  2 |   HASH JOIN |                                |      1.     87.  16676. 00:00:01.64 |     227K |   3552.  3109K |  1106K | 4111K (0) |

    |*  3 |    TABLE ACCESS BY INDEX ROWID | CUSTINVOICEJOUR |      1.   1155 |  31889 | 00:00:01.16 |     223KO |     15.       |       |          |

    |*  4 |     INDEX RANGE SCAN | I_062INVOICEDATEORDERTYPEIDX |      1.   4943 |    134K | 00:00:00.83 |   45440 |      0 |       |       |          |

    |   5.    SIMPLE LIST OF PARTITION.                                |      1.  82360 |    173K | 00:00:00.08 |    3809 |   3537 |       |       |          |

    |*  6 |     TABLE ACCESS FULL | AVTR_SEG_CUST_CAMPEND |      1.  82360 |    173K | 00:00:00.06 |    3809 |   3537 |       |       |          |

    |   7.   TABLE ACCESS BY INDEX ROWID | CUSTINVOICETRANS |      1.   4560 |      0 | 00:00:00.01 |       0 |      0 |       |       |          |

    |*  8 |    INDEX RANGE SCAN | I_064INVLINENUMCAMPAIGNOFPRICE |      1.   4560 |      0 | 00:00:00.01 |       0 |      0 |       |       |          |

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

    Information of predicates (identified by the operation identity card):

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

    1 - access("J".") "SYS_NC00299$"="T". "' SYS_NC00165$ ' AND SUBSTR (NLS_LOWER ('J'. "" "" REFFACTURE")(, 1, 25) = SUBSTR (NLS_LOWER ("T"." "" "REFFACTURE")(, 1, 25)).

    2 - access("J".") INVOICEACCOUNT '= SYS_OP_C2C ("EC". ". ACCOUNTNUM'))

    3 - filter("J".") AVAWARDSALES"> 190)

    4 - access("J".") SYS_NC00299$ "= U ' 201"AND "J". INVOICEDATE"> = TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND

    "J"." SYS_NC00307$ "= U ' 201406"AND "J". INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss')))

    filter ((' J'. "INVOICEDATE' > = 'J' AND TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') '." " SYS_NC00307$ "= U '201406' AND"

    "J"." INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss'))))

    6 filter (("CE". "SEGMENT_LEVEL" = A "OR"THIS"." SEGMENT_LEVEL "=" E"))

    8 - access("T".") SYS_NC00165$ "= U ' 201"AND "T". AVBROCHURELINENUM "= 29457)

    filter ("T". ("AVBROCHURELINENUM" = 29457)

    EXPLAIN PLAN FOR

    Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price

    of custinvoicejour j join custinvoicetrans t on

    substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and

    substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)

    where

    substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457

    and substr (nls_lower (j.dataareaid), 1, 7) = '201' and

    J.INVOICEACCOUNT in

    (select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))

    and J.AVAWARDSALES > 190

    and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'

    "and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';

    SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR);

    SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR ('7h1nbzqjgwsp7', 2));

    SQL_ID, 7h1nbzqjgwsp7, number of children 2

    EXPLAIN PLAN for select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * /.

    J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE,

    (T.LINEAMOUNT + T.LINEAMOUNTTAX) join price j custinvoicejour

    CustInvoiceTrans t on substr (nls_lower (j.dataareaid), 1, 7) =

    substr (nls_lower (t.DataAreaId), 1, 7) and

    = substr (nls_lower (J.INVOICEID), 1: 25)

    substr (nls_lower (t.INVOICEID), 1: 25) where

    substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =

    29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and

    J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of

    drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and

    IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and

    substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and

    "J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.

    NOTE: cannot fetch SQL_ID plan: 7h1nbzqjgwsp7, CHILD_NUMBER: 2

    Check the value of SQL_ID and CHILD_NUMBER;

    It could also be that the plan is no longer in the cursor cache (check v$ sql_plan)

    NightWing wrote:

    Randolf,

    I don't understand. What you hear from the above statement that you mean A-lines and E will be incorrect, but the ratio between them remain the same. Therefore, you can deduct the bad things by comparing the differences.

    Thus, A-lines always give a wrong result for cancellation of queries, isn't it?

    Charlie,

    I think that Martin gave a good explanation. Here's another example that hopefully makes more obvious things:

    17:56:55 SQL >-things go very wrong here with a small buffer cache

    17:56:55 SQL >-T2 lines are badly scattered when you access through T1. FK

    17:56:55 SQL >--

    17:56:55 SQL >-"Small job" approach would have been a good idea

    17:56:55 SQL >-if the estimate of 100 iterations of the loop was correct!

    17:56:55 SQL > select

    17:56:55 (t2.attr2) count 2

    17:56:55 3 of

    17:56:55 4 t1

    17:56:55 5, t2

    17:56:55 6 where

    17:56:55   7  /*------------------*/

    17:56:55 8 trunc (t1.attr1) = 1

    17:56:55 9 and trunc (t1.attr2) = 1

    17:56:55 10 / *-* /.

    17:56:55 11 and t1.fk = t2.id

    17:56:55 12.

    T1

    *

    ERROR on line 4:

    ORA-01013: user has requested the cancellation of the current operation

    Elapsed time: 00:04:58.30

    18:01:53 SQL >

    18:01:53 SQL > @xplan_extended_display_cursor ' ' ' ' 'ALLSTATS LAST + COST.

    18:01:53 SQL > set echo off verify off termout off

    SQL_ID, 353msax56jvvp, number of children 0

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

    SELECT count (t2.attr2) from t1, t2 where

    / / *-* trunc (t1.attr1) = 1 and

    trunc (T1.attr2) = 1 / *-* / and t1.fk = t2.id

    Hash value of plan: 2900488714

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

    | ID | The NEST | DSB | Operation | Name | Begins | E - lines. Cost (% CPU). A - lines.   A - time | Pads | Bed |

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

    |   0 |     |   7. SELECT STATEMENT |        |      1.        |  4999 (100) |      0 | 00:00:00.01 |       0 |      0 |

    |   1.   0 |   8 2 GLOBAL TRI |        |      1.      1.            |      0 | 00:00:00.01 |       0 |      0 |

    |   2.   1.   5.   NESTED LOOPS |        |      1.        |            |  57516 | 00:04:58.26 |     173K |  30770 |

    |   3.   2.   3.    NESTED LOOPS |        |      1.    100.  4999 (1) |  57516 | 00:00:21.06 |     116K |   3632.

    |*  4 |   3.   1.     TABLE ACCESS FULL | T1 |      1.    100.  4799 (1) |  57516 | 00:00:00.19 |    1008 |   1087 |

    |*  5 |   3.   2.     INDEX UNIQUE SCAN | T2_IDX |  57516 |      1.     1 (0) |  57516 | 00:00:20.82 |     115K |   2545 |

    |   8 2 2 |   4.    TABLE ACCESS BY INDEX ROWID | T2 |  57516 |      1.     2 (0) |  57516 | 00:04:37.14 |   57516 |  27138 |

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

    Information of predicates (identified by the operation identity card):

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

    4 filter ((TRUNC ('T1'. "ATTR1") = 1 AND TRUNC ('T1'. " ATTR2') = 1))

    5 - access("T1".") FK '= 'T2'.' (ID')

    You say here that I canceled a query after about 5 minutes, and looking at the statistics of content (RowSource) I can already say the following:

    1. the estimation of cardinality of T1 is far - the optimizer estimated 100 lines, but it actually generated more than 57000 lines when the query was cancelled. If this definitely seems like a candidate at the origin of the problems

    2. the query has spent most of the time in search of random table T2

    So while it is true that I don't know final A-lines of this cancelled query information, I can still say a lot of this and begin to deal with the problems identified so far.

    Randolf

  • An odd index in the execution plan name

    Hi all

    Today someone came to aks my help on setting a SQL. Follow-up is compositions of the entire plan. Although I resovled performance issue, I still don't understand why
    the index with the name "BIN$ ld5VAtb88PngQAB/AQF8hg == $0 ' similar appear in the plan."

    If I remember correctly, this kind of names mean the items in the Recycle Bin. But the index has been abandoned can be used in the execution plan?
    Someone sees potential problems involved with this kind of index name, index name, just please?

    Best regards
    Leon
    ---------------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                                             | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
    ----------------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                                      |                                |     1 |   231 |     5   (0)| 00:00:01 |
    |*  1 |  FILTER                                               |                                |       |       |            |          |
    |   2 |   TABLE ACCESS FULL                                   | TBL_SYS_USERS                  |   344 | 79464 |     5   (0)| 00:00:01 |
    |   3 |   NESTED LOOPS                                        |                                |     1 |    80 |    13   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL                                  | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |*  5 |    INDEX UNIQUE SCAN                                  | BIN$ld5VAtb88PngQAB/AQF8hg==$0 |     1 |    26 |     0   (0)| 00:00:01 |
    |   6 |     NESTED LOOPS                                      |                                |     1 |    80 |    13   (0)| 00:00:01 |
    |*  7 |      TABLE ACCESS FULL                                | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |*  8 |      INDEX UNIQUE SCAN                                | BIN$ld5VAtb88PngQAB/AQF8hg==$0 |     1 |    26 |     0   (0)| 00:00:01 |
    |   9 |       NESTED LOOPS                                    |                                |     1 |    80 |    13   (0)| 00:00:01 |
    |* 10 |        TABLE ACCESS FULL                              | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |* 11 |        INDEX UNIQUE SCAN                              | BIN$ld5VAtb88PngQAB/AQF8hg==$0 |     1 |    26 |     0   (0)| 00:00:01 |
    |* 12 |         TABLE ACCESS BY INDEX ROWID                   | TBL_SYS_EMPLOYEES              |     1 |    26 |     1   (0)| 00:00:01 |
    |* 13 |          INDEX UNIQUE SCAN                            | BIN$ld5VAtba8PngQAB/AQF8hg==$0 |     1 |       |     0   (0)| 00:00:01 |
    |* 14 |          TABLE ACCESS FULL                            | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |* 15 |           TABLE ACCESS FULL                           | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |* 16 |            TABLE ACCESS FULL                          | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |* 17 |             TABLE ACCESS BY INDEX ROWID               | TBL_SYS_EMPLOYEES              |     1 |    26 |     1   (0)| 00:00:01 |
    |* 18 |              INDEX UNIQUE SCAN                        | BIN$ld5VAtba8PngQAB/AQF8hg==$0 |     1 |       |     0   (0)| 00:00:01 |
    |  19 |              NESTED LOOPS                             |                                |     1 |    80 |    14   (0)| 00:00:01 |
    |  20 |               TABLE ACCESS BY INDEX ROWID             | TBL_SYS_EMPLOYEES              |     1 |    26 |     1   (0)| 00:00:01 |
    |* 21 |                INDEX UNIQUE SCAN                      | BIN$ld5VAtba8PngQAB/AQF8hg==$0 |     1 |       |     0   (0)| 00:00:01 |
    |* 22 |               TABLE ACCESS FULL                       | TBL_SYS_DATA_ACCESS_RULES      |     1 |    54 |    13   (0)| 00:00:01 |
    |  23 |                NESTED LOOPS                           |                                |     1 |    80 |    14   (0)| 00:00:01 |

    user12064076 wrote:
    Hi all

    Today someone came to aks my help on setting a SQL. Follow-up is compositions of the entire plan. Although I resovled performance issue, I still don't understand why
    the index with the name "BIN$ ld5VAtb88PngQAB/AQF8hg == $0 ' similar appear in the plan."

    If I remember correctly, this kind of names mean the items in the Recycle Bin. But the index has been abandoned can be used in the execution plan?
    Someone sees potential problems involved with this kind of index name, index name, just please?

    Best regards
    Leon

    The simple answer is that the table has been abandoned and flashed then back to before the fall. When this happens, the table name is restored to its original name, but the index names are not restored. A quick to demonstrate test case.

    First, create us a table and an index, and then collect statistics:

    DROP TABLE T1 PURGE;
    
    CREATE TABLE T1 AS
    SELECT
      ROWNUM C1,
      RPAD('A',255,'A') C2
    FROM
      DUAL
    CONNECT BY
      LEVEL<=10000;
    
    COMMIT;
    
    CREATE INDEX IND_T1_C1 ON T1(C1);
    
    EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',CASCADE=>TRUE)
    

    Then we will check that the index will be used with a sample SQL statement:

    
    SELECT
      C1,
      SUBSTR(C2,1,2)
    FROM
      T1
    WHERE
      C1<=5;
    
     C1 SU
    --- --
      1 AA
      2 AA
      3 AA
      4 AA
      5 AA
    
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    
    PLAN_TABLE_OUTPUT
    -----------------------------------------------------------------------------------------
    SQL_ID  g0kkvxqg3v145, child number 0
    -------------------------------------
    SELECT   C1,   SUBSTR(C2,1,2) FROM   T1 WHERE   C1<=5
    
    Plan hash value: 683303157
    
    -----------------------------------------------------------------------------------------
    | Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    -----------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |           |       |       |     3 (100)|          |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1        |     5 |  1300 |     3   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | IND_T1_C1 |     5 |       |     2   (0)| 00:00:01 |
    -----------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
       2 - access("C1"<=5)
    

    The index has been used.

    Then, we will empty the trash, delete the index and see if it can still be used in an execution plan:

    PURGE RECYCLEBIN;
    
    DROP INDEX IND_T1_C1;
    
    SELECT
      C1,
      SUBSTR(C2,1,2)
    FROM
      T1
    WHERE
      C1<=5;
    
     C1 SU
    --- --
      1 AA
      2 AA
      3 AA
      4 AA
      5 AA
    
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------
    SQL_ID  g0kkvxqg3v145, child number 0
    -------------------------------------
    SELECT   C1,   SUBSTR(C2,1,2) FROM   T1 WHERE   C1<=5
    
    Plan hash value: 3617692013
    
    --------------------------------------------------------------------------
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |      |       |       |   137 (100)|          |
    |*  1 |  TABLE ACCESS FULL| T1   |     5 |  1300 |   137   (5)| 00:00:01 |
    --------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
       1 - filter("C1"<=5)
    

    Note that in the foregoing that falling was not used.

    We'll re-create the index and gather statistics (when the index is created on Oracle Database 10.1 and higher, the index of statistics will be automatically collected, so it's actually an unnecessary step):

    CREATE INDEX IND_T1_C1 ON T1(C1);
    
    EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',CASCADE=>TRUE)
    

    We could verify that the index will be used again, but we can skip this step.

    Now we remove the table and pick up the trash. Then we run the simple query of the T1 table again and retrieve the execution plan:

    DROP TABLE T1;
    
    FLASHBACK TABLE T1 TO BEFORE DROP;
    
    SELECT
      C1,
      SUBSTR(C2,1,2)
    FROM
      T1
    WHERE
      C1<=5;
    
     C1 SU
    --- --
      1 AA
      2 AA
      3 AA
      4 AA
      5 AA
    
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------
    SQL_ID  g0kkvxqg3v145, child number 0
    -------------------------------------
    SELECT   C1,   SUBSTR(C2,1,2) FROM   T1 WHERE   C1<=5
    
    Plan hash value: 3441582395
    
    --------------------------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |                                |       |       |     3 (100)|       |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1                             |     5 |  1300 |     3   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | BIN$PESygWW5R0WhbOaDugxqwQ==$0 |     5 |       |     2   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
       2 - access("C1"<=5)
    

    In the above, you will notice that the index has been used, but now has a funny name.

    We will resolve the weird name and re - run the query:

    ALTER INDEX "BIN$PESygWW5R0WhbOaDugxqwQ==$0" RENAME TO IND_T1_C1;
    
    SELECT
      C1,
      SUBSTR(C2,1,2)
    FROM
      T1
    WHERE
      C1<=5;
    
     C1 SU
    --- --
      1 AA
      2 AA
      3 AA
      4 AA
      5 AA
    
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    
    PLAN_TABLE_OUTPUT
    -----------------------------------------------------------------------------------------
    SQL_ID  g0kkvxqg3v145, child number 0
    -------------------------------------
    SELECT   C1,   SUBSTR(C2,1,2) FROM   T1 WHERE   C1<=5
    
    Plan hash value: 683303157
    
    -----------------------------------------------------------------------------------------
    | Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    -----------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |           |       |       |     3 (100)|          |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1        |     5 |  1300 |     3   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | IND_T1_C1 |     5 |       |     2   (0)| 00:00:01 |
    -----------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
       2 - access("C1"<=5)
    

    The index is now back to normal.

    Charles Hooper
    http://hoopercharles.WordPress.com/
    IT Manager/Oracle DBA
    K & M-making Machine, Inc.

  • Sense of the GOAL: &lt; text &gt; in the execution plan

    Hello

    Could you please help me understand the following in the execution plan (Oracle10gR2)?
    ++++++++++++++
    GOAL: HINT
    OBJECTIVE: ANALYZE
    ++++++++++++++

    For example, the following plan:
    Rows     Execution Plan
    -------  ---------------------------------------------------
          0  SELECT STATEMENT   GOAL: HINT: FIRST_ROWS
        301   HASH JOIN
        200    TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'EP1'
        303    NESTED LOOPS
        304     TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF 'EP3'
        304      BITMAP CONVERSION (TO ROWIDS)
          2       BITMAP OR
          2        BITMAP INDEX (SINGLE VALUE) OF 'EP3_BI1'
          2        BITMAP INDEX (SINGLE VALUE) OF 'EP3_BI2'
        303     TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF 'EP2'
        606      INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF 'EP2_PK' (UNIQUE)
    My question is: what do I do ' GOAL: HINT ' and ' GOAL: ANALYSIS "means? Not specifically for the plan above, just a question about how they mean when they show up in the plan of execution like the one above.

    Thank you!

    Published by: shape on May 6, 2009 10:52

    Published by: shape on May 6, 2009 10:54

    Published by: shape on May 6, 2009 10:58

    New: your exit is whence?
    And I wonder too much about the word 'OBJECTIVE', the previous words and then the words are much more interest.

    GOAL: TIP: FIRST_ROWS<-- optimizer="" decided="" to="" use="" first_rows="">
    301 HASH JOIN
    TABLE 200 ACCESS OBJECTIVE: ANALYZED (FULL)<-- optimizer="" decided="" to="" go="" for="" a="" full="" table="" scan="" based="" on="" provided="" table="" stats="" ('analyzed'="" means:="" stats="" are="" available="" for="">
    303 NESTED LOOPS
    304 TABLE ACCESS OBJECTIVE: ANALYSIS (BY INDEX ROWID)<-- optimizer="" decides="" to="" go="" for="" an="" index="" scan="" here="" based="" on="" provided="" table="" stats="" ('analyzed'="" means:="" stats="" are="" available="" for="">

  • Creative cloud storage limit not sync with the management plan. 2 GB display on the application instead of 100 GB.

    Creative cloud storage limit not sync with the management plan. 2 GB display on the application instead of 100 GB.

    Hi Christian,

    Please check the help below document:

    Applications creative Cloud back in test mode after an update until 2015 for CC

    Kind regards

    Sheena

  • How to capture the execution plan for a query

    Hi all

    Can someone help me please to find the command to capture the execution plan for a query.

    Execution plan for select * from EMP where < condition >

    Is getting executed successfully, but I need to get the appropriate for the same execution plan.

    Thank you

    Read the Doc

  • difference between the execution plan and explain the plan?

    What is the difference between the execution plan & explain the plan?

    an execution plan is the actual steps that oracle will pass by when it executes a query.

    explain plan is a tool that is used to generate the steps of an execution plan for a query.

  • Find child cursors due to changes in the execution plan

    Hi all

    I have a situation to provide the list of execution of the plan for a particular SQL_ID. The particular SQL toggles between 2 paths (FTS and Index scan), but at this point in time, I can see that a single (current) plan_hash_value for instruction. That is to say - the previous cursor gets disabled (due to a statistical series application package which in turn disabled the previous cursor - this is my guess).

    I can get it from dba_hist_sqlstat for the specific SQL, but curious, it is only possible to get it from the dynamic views such as V$ SQL and V$ SQLAREA for a list of all the plan_hash_values for a particular SQL, where the child_number is 0.

    Any idea please?

    Note: I am interested to extract cursors of the child due to the execution of different cursors of the regime and not child created because different settings for the same plan (mode ex-optimizer etc...)

    > is it possible to capture the two dynamic views PHV even if the first cursor is invalidated

    Once it is invalid, it is out!  Is no longer present.

    Hemant K Collette

  • order of operations in the execution plan

    Hello

    I'm not sure if my order of the following execution plan is correct.

    So hopefully someone can confirm or refute my order of the plan.


    This is the query:

    SELECT DISTINCT 'A3. ' "' ISIN '.

    Of

    "WERTPAPIERE" "A3."

    "LOGTABLE" "A2."

    "WP_STATUS" "A1".

    WHERE

    "A2". "PK_ID"= "A3". "" IDENTITY CARD "AND

    "A2". "" REFERENCE "> TIMESTAMP' 2014-01-06 18:30 ' AND

    "A2". "" REFERENCE "< = TIMESTAMP' 2014-01-08 07:00 ' AND

    "A2". "" LOG_DATUM "> TIMESTAMP' 2014-01-07 18:30 ' AND

    "A2". "" LOG_DATUM "< = TIMESTAMP' 2014-01-08 07:00 ' AND

    "A2". "TABLE" = "WERTPAPIERE" AND "

    "A3". ' BATCH '= 'A1'. "" IDENTITY CARD "AND

    "A1". "" CODE "<>" * 33' AND "

    (THERE ARE

    (SELECT "BESTANDS_MERKM" 0 "A7"

    WHERE 'A7 '. "ID"= "A3". "' BESTANDS_MERKMAL_ID ' AND ('A7'. "CODE"= "1" OR "A7". "CODE"(= '2')) AND ("A3" ".") " USER name "= 'Ect' OR 'A3'." USER name "= 'pro' OR 'A3'". "" Username "(= 'prom') or does NOT EXIST"

    (SELECT 0

    OF 'BESTANDS_MERKM' "A6".

    WHERE "A6". «ID «= NVL ("A3".» ("' BESTANDS_MERKMAL_ID ', 0) AND ("A6". "CODE"= "1" OR "A6". "CODE"(= '2')) AND ("A3" ".") " Username "="Res"OR"A3"." Username "(= 'prom') AND ("A3"". ")" LOESCH_KZ_ID' IS NULL OR EXISTS

    (SELECT 0

    OF 'WERTPAPIER_LOESCH_KZ' "A5".

    WHERE "A5". "ID"= "A3". "' LOESCH_KZ_ID ' AND 'A5 '. (("CODE"="1")) AND THERE ARE

    (SELECT 'PRODUKTGRUPPE_SEGMENT' 0 'A4'

    WHERE "A4". "ID"= "A3". "' PRODUKTGRUPPE_SEGMENTIERUNG_ID ' AND ('A4'. "CODE"= "USE" OR "A4". "CODE"= "ZUUZ" OR "A4". "CODE"= "4000" OR "A4". "CODE"= "5000" OR "A4". "CODE"= "3000" OR "A4". "CODE"= "4444" OR "A4". "CODE"= "4445" OR "A4". "CODE"= "5544" OR "A4". "CODE"= "6544" OR "A4". «CODE ' = ' 6543 "OR"A4".» ((("CODE"="8765')))

    The plan has been acquired through dbms_xplan:

    Select * from table (dbms_xplan.display_cursor (format = > 'ALLSTATS LAST SCHEMA'));


    Here's the plan:


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

    | ID | Operation | Name                     | Begins | E - lines. A - lines.   A - time | Pads | Bed |  OMem |  1Mem | Used Mem.

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

    |   0 | SELECT STATEMENT |                          |      1.        |   1252 | 00:05:55.03 |      11 M |    594K |       |       |          |

    |   1.  UNIQUE HASH |                          |      1.  28517 |   1252 | 00:05:55.03 |      11 M |    594K |  1135K |  1135K | 2976K (0) |

    |*  2 |   FILTER                               |                          |      1.        |   2579 | 00:05:55.02 |      11 M |    594K |       |       |          |

    |*  3 |    HASH JOIN |                          |      1.    571K |   2219K | 00:05:53.49 |      11 M |    594K |  1306K |  1306K | 1 272 K (0) |

    |*  4 |     INDEX SCAN FULL | WP_STAT_UPI |      1.     57.     57. 00:00:00.01 |       1.      0 |       |       |          |

    |   5.     NESTED LOOPS |                          |      1.        |   2219K | 00:05:52.17 |      11 M |    594K |       |       |          |

    |   6.      NESTED LOOPS |                          |      1.    583K |   2219K | 00:00:18.62 |     726K |    436K |       |       |          |

    |   7.       RANGE OF SINGLE PARTITION |                          |      1.    583K |   2219K | 00:00:12.29 |     436K |    436K |       |       |          |

    |   8.        PARTITION LIST ALL |                          |      1.    583K |   2219K | 00:00:11.96 |     436K |    436K |       |       |          |

    |*  9 |         TABLE ACCESS FULL | LOGTABLE |      4.    583K |   2219K | 00:00:11.61 |     436K |    436K |       |       |          |

    | * 10 |       INDEX UNIQUE SCAN | WP_PK_I                  |   2219K |      1.   2219K | 00:00:05.34 |     289K |    491.       |       |          |

    |  11.      TABLE ACCESS BY INDEX ROWID | WERTPAPIERE |   2219K |      1.   2219K | 00:05:32.59 |      10 M |    157K |       |       |          |

    | * 12 |    TABLE ACCESS BY INDEX ROWID | BESTANDS_MERKM |      5.      1.      2. 00:00:00.01 |       8.      0 |       |       |          |

    | * 13 |     INDEX UNIQUE SCAN | BESTANDS_MERKM_PK_I |      5.      1.      4. 00:00:00.01 |       4.      0 |       |       |          |

    | * 14 |    TABLE ACCESS BY INDEX ROWID | BESTANDS_MERKM |      3.      1.      0 | 00:00:00.01 |       5.      0 |       |       |          |

    | * 15 |     INDEX UNIQUE SCAN | BESTANDS_MERKM_PK_I |      3.      1.      2. 00:00:00.01 |       3.      0 |       |       |          |

    | * 16.    TABLE ACCESS BY INDEX ROWID | PRODUKTGRUPPE_SEGMENT |      3.      1.      2. 00:00:00.01 |       6.      0 |       |       |          |

    | * 17.     INDEX UNIQUE SCAN | PRG_SEG_PK_I |      3.      1.      3. 00:00:00.01 |       3.      0 |       |       |          |

    | * 18.    INDEX UNIQUE SCAN | WERTPAPIER_LOESCH_KZ_UPI |      2.      1.      1. 00:00:00.01 |       2.      0 |       |       |          |

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

    Vector data

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

    /*+

    BEGIN_OUTLINE_DATA

    IGNORE_OPTIM_EMBEDDED_HINTS

    OPTIMIZER_FEATURES_ENABLE ('11.2.0.3')

    DB_VERSION ('11.2.0.3')

    ALL_ROWS

    OUTLINE_LEAF(@"SEL$2")

    OUTLINE_LEAF(@"SEL$3")

    OUTLINE_LEAF(@"SEL$4")

    OUTLINE_LEAF(@"BLOCK1")

    OUTLINE_LEAF(@"SEL$1")

    OUTLINE(@"BLOCK1")

    FULL (@"SALT$ 1" "A2"@"SEL$1")

    INDEX (@"SALT$ 1" "A3"@"SEL$1" ("WERTPAPIERE".) "ID")) "

    INDEX (@"SALT$ 1" "A1"@"SEL$1" ("WP_STATUS".) "CODE" "WP_STATUS" "." " ID'))

    LEADING (@"SALT$ 1" "A2"@"SEL$1" "A3"@"SEL$1" "A1"@"SEL$1")

    USE_NL (@"SALT$ 1" "A3"@"SEL$1")

    NLJ_BATCHING (@"SALT$ 1" "A3"@"SEL$1")

    USE_HASH (@"SALT$ 1" "A1"@"SEL$1")

    SWAP_JOIN_INPUTS (@"SALT$ 1" "A1"@"SEL$1")

    USE_HASH_AGGREGATION(@"SEL$1")

    INDEX_RS_ASC (@"BLOCK1" "A4"@"BLOCK1" ("PRODUKTGRUPPE_SEGMENT".) "ID")) "

    INDEX (@"SALT$ 4" "A5"@"SEL$4" ("WERTPAPIER_LOESCH_KZ".) "CODE" "WERTPAPIER_LOESCH_KZ" "." " ID'))

    INDEX_RS_ASC (@"SALT$ 3" "A6"@"SEL$3" ("BESTANDS_MERKM".) "ID")) "

    INDEX_RS_ASC (@"SALT$ 2" "A7"@"SEL$2" ("BESTANDS_MERKM".) "ID")) "

    END_OUTLINE_DATA

    */

    According to independent-combine- JOIN operation by HASH, I assumed the first operation's Id 4 because the "INDEX FULL SCAN' on 'WP_STAT_UPI' is the first child.

    So I guess the order of operations by Id is 4,9,10 and so on.

    I got my information from the official oracle documentation, the book of Troubleshooting Oracle Performance (APRESS) and some research on the internet.

    Unfortunately so far I have found a good documentation on the scheduling. Most of the tutorials and documentation talk a lot operations themselves, but very little about the opening sequence.

    According to the section ATTACK to State "LEADING(@"SEL$1""A2"@"SEL$1""A3"@"SEL$1""A1"@"SEL$1")", for the classification should be Id: 9,10 and so on.


    I also tried to find order information in the v$ sql_plan. The database version is 11.2.


    Any help welcome.


    Best regards

    Your interpretation is correct (even if you have obscured the lines 5-8, but they do not add significant value to what you're saying).

    The explanation of the difference between your interpretation and the indicator leading() is the indicator USE_HASH() is accompanied by a hint of swap_join_inputs(). Hash joins | Oracle scratchpad indicator tells you the order of join optimizer was examining, but the optimizer exchange the roles of man and hash tables when it comes to her 'now to join A1 (WP_STAT)' part of the analysis - and this is reflected in the implementation plan.

    Symbolically, the main indicator says

    You should join A2 and A3--> (A2, A3)

    Then you must join A1--> ((A2, A3), A1)

    But Exchange - join entries. (A1, (A2, A3))

    Concerning

    Jonathan Lewis

  • The execution plan changes for the same query.

    Hi all

    This issue was raised before also, but still not able to find the real cause of this.

    Thread1:
    Re: Research of fragmentation of the table in Oracle 8.1.6.3.0

    Thread2:
    CBC latch and buffer busy await you on the same table.

    It comes, sometimes hammers server 100% CPU utilization with free latch and buffer busy wait events.

    We found a single query consumes high CPU usage that is run by different sessions.

    This query have two types of execution plans, where one is accurate and is not (its primary key hit index index no appropriate means present on the table)

    Because its primary key index hit repeatedly at various sessions, some sessions are powerful db file sequential read and a few sessions waiting buffer busy waits for event. Also during this time a few sessions waiting for latch free event.

    My doubt is how to sql even with different literal values execution plan changes and causes a prob.
    select count(*),event from v$session_wait group by event;
      COUNT(*) EVENT
    ---------- ----------------------------------------------------------------
           165 SQL*Net message from client
             1 SQL*Net message to client
             3 buffer busy waits
             2 db file parallel read
            18 db file sequential read
            10 latch free
             5 log file sync
             1 pmon timer
             6 rdbms ipc message
             1 smon timer
    
    SQL> select sid from v$session_wait where event='db file sequential read';
           SID
    ----------
            26
            58
            82
           107
           116
           223
           212
           203
           192
           173
           161
           157
           150
           147
           254
           238
           229
           112
           101
            81
            68
    
    SQL> select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID;
    Enter value for sid: 161
    old   1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID
    new   1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=161
    
    SPID             SID    SERIAL# PROGRAM
    --------- ---------- ---------- ------------------------------------------------
    4231             161      49569 oracle@tfrdb3 (TNS V1-V3)
    
    
    SQL> select sql_text
    from v$process a,
         v$session b,  2    3
         v$sql c
    where a.addr = b.paddr and
         b.sql_hash_value = c.hash_value and
        a.spid = &PID;  4    5    6    7
    Enter value for pid: 4231
    old   7:     a.spid = &PID
    new   7:     a.spid = 4231
    
    SQL_TEXT
    --------------------------------------------------------------------------------
    SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM LOG WHERE ID = '09292AMR
    10B41FE' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'234225222' OR TYPE =
     18 AND LOG_SEQ='234225222') ORDER BY TIME_STAMP ASC
    
    SQL> set autotrace traceonly exp
    SQL> SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM amrwf1.LOG WHERE ID = '09292AMR10B41FE' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'234225222' OR TYPE =18 AND LOG_SEQ='234225222') ORDER BY TIME_STAMP ASC;
    
    Execution Plan
    ----------------------------------------------------------
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=2 Bytes=126)
       1    0   SORT (ORDER BY) (Cost=11 Card=2 Bytes=126)
       2    1     CONCATENATION
       3    2       TABLE ACCESS (BY INDEX ROWID) OF 'LOG' (Cost=4 Card=1
              Bytes=63)
    
       4    3         INDEX (UNIQUE SCAN) OF 'PK_LOG_LOG_SEQ' (UNIQUE) (Co
              st=3 Card=1)
    
       5    2       TABLE ACCESS (BY INDEX ROWID) OF 'LOG' (Cost=4 Card=1
              Bytes=63)
    
       6    5         INDEX (RANGE SCAN) OF 'PK_LOG_LOG_SEQ' (UNIQUE) (Cos
              t=3 Card=1)
    
    
    SQL> select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID;
    Enter value for sid: 147
    old   1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID
    new   1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=147
    
    SPID             SID    SERIAL# PROGRAM
    --------- ---------- ---------- ------------------------------------------------
    6255             147      38306 oracle@tfrdb3 (TNS V1-V3)
    
    SQL> select sql_text
    from v$process a,
         v$session b,
         v$sql c  2    3
    where a.addr = b.paddr and
         b.sql_hash_value = c.hash_value and
        a.spid = &PID;  4    5    6    7
    Enter value for pid: 6255
    old   7:     a.spid = &PID
    new   7:     a.spid = 6255
    
    SQL_TEXT
    --------------------------------------------------------------------------------
    SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM LOG WHERE ID = '09273AMR
    62B4894' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'223324996' OR TYPE =
     18 AND LOG_SEQ='223324996') ORDER BY TIME_STAMP ASC
    
    
    SQL> set autotrace traceonly exp
    SQL> SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM amrwf1.LOG WHERE ID = '09273AMR62B4894' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'223324996' OR TYPE =18 AND LOG_SEQ='223324996') ORDER BY TIME_STAMP ASC;
    
    Execution Plan
    ----------------------------------------------------------
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1538 Card=736 Bytes=
              46368)
    
       1    0   SORT (ORDER BY) (Cost=1538 Card=736 Bytes=46368)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'LOG' (Cost=1527 Card=7
              36 Bytes=46368)
    
       3    2       INDEX (RANGE SCAN) OF 'LOG_ID' (NON-UNIQUE) (Cost=32 C
              ard=736)
    
    
    
    SQL> select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID;
    Enter value for sid: 82
    old   1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID
    new   1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=82
    
    SPID             SID    SERIAL# PROGRAM
    --------- ---------- ---------- ------------------------------------------------
    6172              82      45378 oracle@tfrdb3 (TNS V1-V3)
    
    
    SQL> select sql_text
    from v$process a,
         v$session b,
         v$sql c
    where a.addr = b.paddr and
         b.sql_hash_value = c.hash_value and  2
      3      a.spid = &PID;  4    5    6    7
    Enter value for pid: 6172
    old   7:     a.spid = &PID
    new   7:     a.spid = 6172
    
    SQL_TEXT
    --------------------------------------------------------------------------------
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    
    SQL_TEXT
    --------------------------------------------------------------------------------
    
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    
    SQL_TEXT
    --------------------------------------------------------------------------------
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    
    INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F
    LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V
    002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
    How to avoid this... why its different execution plan using (I mean bad index PK)

    Is it possible to avoid this?

    If any details please check out some of my previous post on this specific URL (above)

    -Yasser

    My doubt is how to sql even with different literal values execution plan changes and causes a prob.

    Different literal values cause analysis difficult.
    Hard analysis includes the re-evaluation of the best path.
    Literal value is included in the assessment of the selectivity for the scan interval (log_seq >...)

    See
    http://www.centrexcc.com/A%20Look%20under%20The%20Hood%20Of%20CBO%20-%20The%2010053%20Event.ppt.PDF
    http://www.centrexcc.com/fallacies%20Of%20The%20Cost%20Based%20Optimizer.PDF
    more the book of Jonathan Lewis which other threads, I believe that you already have.

    You must lower your CPU.
    Previous discussions, if the situation is still the same, it sounded like hard analysis particularly with this SELECTION against the NEWSPAPER plays an important role in that.

    How to avoid this... why its different execution plan using (I mean bad index PK)

    The points raised in the previous discussion remain valid.
    -Do you have access to this SQL to change?
    for example using bind variable or trick it if necessary due to problems caused by data as discussed in the previous thread.
    - Or you could it repoint the view to a view and a hint?
    -If a particular user makes this sql, could affect you cursor_sharing just for this user. If not, you should consider implementing pan-Canadian database.

    Oracle 8.1.6 still?

  • I had a plan that allowed me to use Photoshop, Illustrator and InDesign, but I don't see that as an option, and I'm not interested in the other plans, how to make a comeback?

    I had a plan that was built to use about 5 total programs, mainly Photoshop, Illustrator and InDesign, but now I see not as an option and I'm a graphic artist, not a photographer, and I don't want to have to buy subscriptions to each individually... is possible to retrieve the map I had? (I had to cancel when I was unemployed for a while and couldn't afford to keep paying my membership)

    I don't know what you had, but you can buy now is the special plan of photography at a special price and individual programs can do for (I think) $20 each

    Go to Cloud Plans https://creative.adobe.com/plans and check price... you CAN do better with the overall plan cloud

  • Hence the optimizer is get the data for the execution Plan?

    Hi all

    11 GR 2 DB.

    It may be a fundamental ignorance.

    I had created a new table as DEPT_TEST in the sample HR schema provided by ORACLE.
    create table dept_test as select * from departments;
    No primary key. No index. Stats not garthered. Now my doubt is hence the optimizer is information for power plan?
    SQL> explain plan for
      2  select *
      3  from employees e,dept_test d
      4  where e.department_id = d.department_id
      5  and d.department_name in( 'Purchasing','IT Support','xx','yyy');
    
    Explained.
    
    SQL> select *
      2  from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    ----------------------------------------------------------------------------------------------------
    Plan hash value: 3561042801
    
    --------------------------------------------------------------------------------------------------
    | Id  | Operation                    | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT             |                   |    19 |  2375 |     4   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS                |                   |       |       |            |          |
    |   2 |   NESTED LOOPS               |                   |    19 |  2375 |     4   (0)| 00:00:01 |
    |*  3 |    TABLE ACCESS FULL         | DEPT_TEST         |     2 |   112 |     3   (0)| 00:00:01 |
    |*  4 |    INDEX RANGE SCAN          | EMP_DEPARTMENT_IX |    10 |       |     0   (0)| 00:00:01 |
    |   5 |   TABLE ACCESS BY INDEX ROWID| EMPLOYEES         |    10 |   690 |     1   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       3 - filter("D"."DEPARTMENT_NAME"='IT Support' OR "D"."DEPARTMENT_NAME"='Purchasing' OR
                  "D"."DEPARTMENT_NAME"='xx' OR "D"."DEPARTMENT_NAME"='yyy')
       4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
    
    Note
    -----
       - dynamic sampling used for this statement (level=2)
    
    23 rows selected.
    How does he know that the 3 FILTER will produce 2 rows? (That's okay!)

    How does know - outside the Department 4 data are names, only two (purchase and support). Yet once, no primary key is defined in TEST_DEPT.

    Again, if I change the query by adding a name of service valid, optimizer generates the correct plan. He correctly assumes, IN condition will be released 3 departments... !
    SQL> select *
      2  from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    ----------------------------------------------------------------------------------------------------
    Plan hash value: 3561042801
    
    --------------------------------------------------------------------------------------------------
    | Id  | Operation                    | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT             |                   |    29 |  3625 |     4   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS                |                   |       |       |            |          |
    |   2 |   NESTED LOOPS               |                   |    29 |  3625 |     4   (0)| 00:00:01 |
    |*  3 |    TABLE ACCESS FULL         | DEPT_TEST         |     3 |   168 |     3   (0)| 00:00:01 |
    |*  4 |    INDEX RANGE SCAN          | EMP_DEPARTMENT_IX |    10 |       |     0   (0)| 00:00:01 |
    |   5 |   TABLE ACCESS BY INDEX ROWID| EMPLOYEES         |    10 |   690 |     1   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       3 - filter("D"."DEPARTMENT_NAME"='Human Resources' OR "D"."DEPARTMENT_NAME"='IT
                  Support' OR "D"."DEPARTMENT_NAME"='Purchasing' OR "D"."DEPARTMENT_NAME"='xx' OR
                  "D"."DEPARTMENT_NAME"='yyy')
       4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
    
    Note
    -----
       - dynamic sampling used for this statement (level=2)
    
    24 rows selected.

    Now my doubt is hence the optimizer is information for power plan?

    It seems that the optimizer played just - leaving a Note

    Note
    -----
       - dynamic sampling used for this statement (level=2)
    

    Concerning

    Etbin

  • Quirk in the execution Plan

    I know that I am not posting the complete plan, but what is more curious, is that I have never seen it before. I don't know if any of you have seen this.
    SQL> select * from v$version;
    
    BANNER
    --------------------------------------------------------------------------------
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    PL/SQL Release 11.1.0.7.0 - Production
    CORE    11.1.0.7.0      Production
    TNS for Linux: Version 11.1.0.7.0 - Production
    NLSRTL Version 11.1.0.7.0 - Production
    
    
    select * from table(dbms_Xplan.display_cursor('sql_id', null, 'ALLSTATS LAST'));
    
    PLAN_TABLE_OUTPUT
    ----------------------------------------------------------------------------------------------------
    SQL_ID  cnskfxp99n1gp, child number 0
    -------------------------------------
    
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                                   | Name                           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                            |                                |      1 |        |      1 |00:02:23.34 |     463K|    322K|       |       |          |
    |   1 |  SORT AGGREGATE                             |                                |      1 |      1 |      1 |00:02:23.34 |     463K|    322K|       |       |          |
    |   2 |   VIEW                                      |                                |      1 |  47948 |  14734 |00:02:23.34 |     463K|    322K|       |       |          |
    |   3 |    HASH GROUP BY                            |                                |      1 |  47948 |  14734 |00:02:23.34 |     463K|    322K|  3463K|   973K| 4899K (0)|
    |   4 |     VIEW                                    |                                |      1 |  47948 |  25714 |00:00:00.70 |     463K|    322K|       |       |          |
    |   5 |      UNION-ALL                              |                                |      1 |        |  25714 |00:00:00.70 |     463K|    322K|       |       |          |
    |*  6 |       FILTER                                |                                |      1 |        |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |   7 |        NESTED LOOPS                         |                                |      1 |        |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |   8 |         NESTED LOOPS                        |                                |      1 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |   9 |          MERGE JOIN CARTESIAN               |                                |      1 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |  10 |           PARTITION RANGE SINGLE            |                                |      1 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |* 11 |            TABLE ACCESS BY LOCAL INDEX ROWID| aaaaa                          |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |* 12 |             INDEX RANGE SCAN                | aaaa_IDX                       |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |  13 |           BUFFER SORT                       |                                |      0 |    113K|      0 |00:00:00.01 |       0 |      0 |  3989K|   854K|          |
    |* 14 |            TABLE ACCESS FULL                | bbb                            |      0 |    113K|      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |* 15 |          INDEX RANGE SCAN                   | IX2_bbb                        |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |* 16 |         TABLE ACCESS BY INDEX ROWID         | bbb                            |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |  17 |       HASH GROUP BY                         |                                |      1 |  47946 |  14548 |00:00:00.70 |   24273 |      0 |  1592K|  1158K| 2908K (0)|
    |* 18 |        FILTER                               |                                |      1 |        |  45639 |00:00:03.05 |   24273 |      0 |       |       |          |
    |* 19 |         HASH JOIN                           |                                |      1 |  47946 |  45639 |00:00:03.05 |   24273 |      0 |  1018K|  1018K| 1402K (0)|
    |  20 |          PARTITION RANGE SINGLE             |                                |      1 |   5472 |   5041 |00:00:00.01 |     960 |      0 |       |       |          |
    |* 21 |           TABLE ACCESS FULL                 | ccc                            |      1 |   5472 |   5041 |00:00:00.01 |     960 |      0 |       |       |          |
    |* 22 |          HASH JOIN                          |                                |      1 |  44172 |  45640 |00:00:00.38 |   23313 |      0 |  2515K|  1437K| 5099K (0)|
    |  23 |           PARTITION RANGE SINGLE            |                                |      1 |  45644 |  45648 |00:00:00.01 |    1463 |      0 |       |       |          |
    |* 24 |            TABLE ACCESS FULL                | ddd                            |      1 |  45644 |  45648 |00:00:00.01 |    1463 |      0 |       |       |          |
    |* 25 |           HASH JOIN                         |                                |      1 |    113K|    118K|00:00:00.31 |   21850 |      0 |  6993K|  2487K| 9677K (0)|
    |* 26 |            TABLE ACCESS FULL                | bbb                            |      1 |    113K|    109K|00:00:00.01 |   10925 |      0 |       |       |          |
    |* 27 |            TABLE ACCESS FULL                | bbb                            |      1 |    126K|    126K|00:00:00.01 |   10925 |      0 |       |       |          |
    |* 28 |       FILTER                                |                                |      1 |        |  11166 |00:02:22.57 |     439K|    322K|       |       |          |
    |  29 |        SORT GROUP BY                        |                                |      1 |      1 |  11434 |00:02:22.57 |     439K|    322K|  3313K|   814K| 2944K (0)|
    |* 30 |         HASH JOIN                           |                                |      1 |      6 |  12124 |00:02:22.52 |     439K|    322K|  2157K|  1015K| 2914K (0)|
    |* 31 |          HASH JOIN                          |                                |      1 |      5 |  12124 |00:02:22.34 |     438K|    322K|  2265K|  1007K| 2938K (0)|
    |  32 |           NESTED LOOPS                      |                                |      1 |        |  17129 |00:10:16.99 |     427K|    322K|       |       |          |
    |  33 |            NESTED LOOPS                     |                                |      1 |      6 |  17333 |00:10:15.53 |     417K|    322K|       |       |          |
    |* 34 |             HASH JOIN                       |                                |      1 |      5 |  17129 |00:10:16.91 |     408K|    322K|   963K|   963K| 1248K (0)|
    |* 35 |              VIEW                           | index$_join$_010               |      1 |     75 |     75 |00:00:00.02 |      10 |      3 |       |       |          |
    |* 36 |               HASH JOIN                     |                                |      1 |        |     75 |00:00:00.02 |      10 |      3 |  1048K|  1048K| 1550K (0)|
    |  37 |                INLIST ITERATOR              |                                |      1 |        |     75 |00:00:00.02 |       3 |      0 |       |       |          |
    |* 38 |                 INDEX RANGE SCAN            | ddd_IDX2                       |      7 |     75 |     75 |00:00:00.02 |       3 |      0 |       |       |          |
    |  39 |                INDEX FAST FULL SCAN         | ddd_IDX1                       |      1 |     75 |    210 |00:00:00.01 |       7 |      3 |       |       |          |
    |  40 |              NESTED LOOPS                   |                                |      1 |        |  17172 |00:00:48.24 |     408K|    322K|       |       |          |
    |  41 |               NESTED LOOPS                  |                                |      1 |     54 |  17172 |00:10:16.62 |     391K|    322K|       |       |          |
    |  42 |                PARTITION RANGE ALL          |                                |      1 |     54 |  17172 |00:10:11.33 |     361K|    322K|       |       |          |
    |  43 |                 PARTITION LIST INLIST       |                                |    276 |     54 |  17172 |00:07:16.25 |     361K|    322K|       |       |          |
    |* 44 |                  TABLE ACCESS FULL          | eee                            |    552 |     54 |  17172 |00:02:24.35 |     361K|    322K|       |       |          |
    |* 45 |                INDEX UNIQUE SCAN            | fff_PK                         |  17172 |      1 |  17172 |00:00:00.63 |   29633 |      3 |       |       |          |
    |* 46 |               TABLE ACCESS BY INDEX ROWID   | fff                            |  17172 |      1 |  17172 |00:00:00.49 |   17177 |    175 |       |       |          |
    |* 47 |             INDEX RANGE SCAN                | IX2_bbb                        |  17129 |      1 |  17333 |00:00:00.20 |    9265 |     33 |       |       |          |
    |* 48 |            TABLE ACCESS BY INDEX ROWID      | bbb                            |  17333 |      1 |  17129 |00:00:00.06 |    9840 |      0 |       |       |          |
    |* 49 |           TABLE ACCESS FULL                 | bbb                            |      1 |    113K|    109K|00:00:00.01 |   10925 |      0 |       |       |          |
    |  50 |          PARTITION RANGE SINGLE             |                                |      1 |   5472 |   5041 |00:00:00.07 |     960 |      5 |       |       |          |
    |* 51 |           TABLE ACCESS FULL                 | ccc                            |      1 |   5472 |   5041 |00:00:00.07 |     960 |      5 |       |       |          |
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    I've hidden the name of the table for various reasons, but if you have alook at 34 and 31 stages they do not correspond to the top. I'm more curious to know why he thinks, he spent 10 minutes on the step 34 when he finished step 31 in 2 minutes and 22 seconds. And elapse time total of this request is 2 minutes and 23 seconds.

    Concerning

    REDA

    >
    I'm more curious to know why he thinks, he spent 10 minutes on the step 34 when he finished step 31 in 2 minutes and 22 seconds. And elapse time total of this request is 2 minutes and 23 seconds.
    >
    This can happen if you use the flag "gather_plan_statistics" instead of define statistics_level to 'all '.

    It is related to the sampling frequency used.

    Oracle ACE Director and author, Jonathan Lewis examines your specific question in this blog
    http://jonathanlewis.WordPress.com/2007/04/26/Heisenberg/
    >
    So how can garnish 2 report a time greater than line 1. How can top 6 report a time greater than line 5? Straight lines, and what lines are bad?

  • help to see the execution plan

    Hello.


    I need to see the table of a sentence of merger plan (a very large) to check if it is running in parallel or not.
    I launch sqlplus, but I could only see the plan table using a utility of TOAD, but I don't trust what I saw it because it says that 20 lines merged while the sqlplus it is say that only 18 lines were merged.

    I need help to see the plan execution via sqlplus, I tried two things:
    1. "set autotrace on" does not work, it returns an error ORA-12838 which seems to be related to the fact that fusion uses two indicators append and at the same time.
    2 Plan_table table exists for this scheme, but even if I get 'Explained' comments no new lines are inserted into plan_table. Why?

    Any kind of advice will be welcome.


    Thanks in advance.
    SQL> explain plan for
      2  merge into ...
      3  using...
    

    If the query is valid, it will say "explained."

    Then proceed as follows:

    SQL> select * from table(dbms_xplan.display());
    

Maybe you are looking for

  • I lost the software

    I lost some of the software on my macbook pro as page and keynote... I also I don't have iwork file

  • El Capitan 10.11.2 disconnects from the network of Canon printer macbook pro after each use but with the same OS version iMac remains connected

    How to prevent my Macbook Pro El Capitan 10.11.2 going to disconnect my network printer Canon?   My iMac running the same OS version don't unplug and behaves like any normal wireless connection.  I deleted the printer and added back, reset printing,

  • Y570 - sound disappears when using some applications

    Hello everyone, I don't understand what the problem with this laptop When using Skype, as soon as we establish contact video, sound disappears and Skype says there is a problem with my sound card I installed the drivers from the Web site, but that di

  • 4635: hp4635

    I have a hp4635 all in one printer. The paper feeder stuck and there are pieces of paper in the paper tray. How can I open up the paper feeder? Do not send me assistance because hp videos etc that I saw do not describe the 4635. They refer to the 460

  • NOTICE - Ethernet controller driver needed

    Device ID PCI\VEN_10DE & DEV_ 0066 & SUBSYS_80A71043 & REV_A1\3 & 267A 616 & 0 & 20 Device is unknown. No driver. Unable to connect to the internet to install in the usual way. Need the driver in a format that can be downloaded and put on the disk so