SQL execution plan - question

Under SQL result in development in a few seconds, but in production continues to run. Explain plan is also less.

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

CURSOR_SHARING is set to EXACT (production) and FORCE (development) - is this the reason?

select wonum from workorder where
worktype in ('EM','CM')
and siteid = 'DWS_DSS'
and historyflag = 0
and (exists (select null
             from dcw_ddotpermits b
             where workorder.wonum = b.wonum 
                and workorder.siteid = b.siteid
                and b.permittype in ('Construction Permit', 'Occupancy Permit')
                and b.permitenddate > sysdate
             group by b.wonum, b.permittype
             having count(wonum) > 1));

Explain the Plan of Production (which is slow)

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                    |     1 |    26 |   162K (17)| 00:32:30 |       |       |
|*  1 |  TABLE ACCESS BY GLOBAL INDEX ROWID| WORKORDER          |  1491 | 38766 |  4259   (1)| 00:00:52 |     1 |     1 |
|*  2 |   INDEX RANGE SCAN                 | WORKORDER_NDX20    |  2399 |       |   988   (1)| 00:00:12 |       |       |
|*  3 |    FILTER                          |                    |       |       |            |          |       |       |
|   4 |     HASH GROUP BY                  |                    |     1 |    35 |     6  (17)| 00:00:01 |       |       |
|*  5 |      TABLE ACCESS BY INDEX ROWID   | DCW_DDOTPERMITS    |     1 |    35 |     5   (0)| 00:00:01 |       |       |
|*  6 |       INDEX RANGE SCAN             | W_DDOTPERMITS_NDX2 |     3 |       |     2   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("WORKTYPE"='CM' OR "WORKTYPE"='EM')
   2 - access("SITEID"='DWS_DSS' AND "HISTORYFLAG"=0)
       filter( EXISTS (SELECT 0 FROM "MAXIMO"."DCW_DDOTPERMITS" "B" WHERE "B"."WONUM"=:B1 AND 
              ("B"."PERMITTYPE"='Construction Permit' OR "B"."PERMITTYPE"='Occupancy Permit') AND 
              "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B2 GROUP BY "B"."WONUM","B"."PERMITTYPE" HAVING COUNT(*)>1))
   3 - filter(COUNT(*)>1)
   5 - filter(("B"."PERMITTYPE"='Construction Permit' OR "B"."PERMITTYPE"='Occupancy Permit') AND 
              "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B1)
   6 - access("B"."WONUM"=:B1)

Explain the Plan of development (which is fast)

-----------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                    |     1 |    25 | 28247  (17)| 00:05:39 |
|*  1 |  FILTER                        |                    |       |       |            |          |
|*  2 |   VIEW                         | index$_join$_001   |  7991 |   195K|   985   (1)| 00:00:12 |
|*  3 |    HASH JOIN                   |                    |       |       |            |          |
|   4 |     INLIST ITERATOR            |                    |       |       |            |          |
|*  5 |      INDEX RANGE SCAN          | WWORKORDER_NDX32   |  7991 |   195K|   279   (2)| 00:00:04 |
|*  6 |     INDEX RANGE SCAN           | WORKORDER_NDX20    |  7991 |   195K|   973   (1)| 00:00:12 |
|*  7 |   FILTER                       |                    |       |       |            |          |
|   8 |    HASH GROUP BY               |                    |     1 |    39 |     6  (17)| 00:00:01 |
|*  9 |     TABLE ACCESS BY INDEX ROWID| DCW_DDOTPERMITS    |     1 |    39 |     5   (0)| 00:00:01 |
|* 10 |      INDEX RANGE SCAN          | W_DDOTPERMITS_NDX2 |     3 |       |     2   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( EXISTS (SELECT 0 FROM "MAXIMO"."DCW_DDOTPERMITS" "B" WHERE "B"."WONUM"=:B1 
              AND ("B"."PERMITTYPE"=:SYS_B_4 OR "B"."PERMITTYPE"=:SYS_B_5) AND 
              "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B2 GROUP BY "B"."WONUM","B"."PERMITTYPE" 
              HAVING COUNT(*)>:SYS_B_6))
   2 - filter("HISTORYFLAG"=:SYS_B_3 AND "SITEID"=:SYS_B_2 AND ("WORKTYPE"=:SYS_B_0 OR 
              "WORKTYPE"=:SYS_B_1))
   3 - access(ROWID=ROWID)
   5 - access("WORKTYPE"=:SYS_B_0 OR "WORKTYPE"=:SYS_B_1)
   6 - access("SITEID"=:SYS_B_2 AND "HISTORYFLAG"=:SYS_B_3)
   7 - filter(COUNT(*)>:SYS_B_6)
   9 - filter(("B"."PERMITTYPE"=:SYS_B_4 OR "B"."PERMITTYPE"=:SYS_B_5) AND 
              "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B1)
  10 - access("B"."WONUM"=:B1)

It looks more like a problem with the size of the data and related statistics.  (It may be simply the outdated statistics on dev).

In the production of a larger data NDX20 index on its own looks too expensive to the optimizer so it combines this with the index of ndx32 to avoid visiting the table.

The first step to study the problem would be to check if the estimated row counts are realistic for individual systems, and then to determine if the data cluster for the production system is much better than Oracle think it is - if yes, then (for newer versions) affecting the preference of table 'table made of blocks cached' a realistic value can help ( https://jonathanlewis.wordpress.com/2015/11/02/clustering_factor-4/ ). If all else fails and the dev is good then allusion and capture of a Plan SQL database may be required.

Concerning

Jonathan Lewis

Tags: Database

Similar Questions

  • Get the SQL execution plan that is currently running in 9i

    Hello

    Apologies for the magnitude of this issue, but I was wondering if someone could help me to the more accurate/efficient way to get a piece of running Oracle 9i SQL execution plan.

    in 10g and 11g of course dbms_xplan.display_cursor (sql_id) can be used.

    How can this be achieved in 9i, currently I am just get the SQL_TEXT and then executing a plan to explain ("EXPLAIN PLAN for.") - I think that this is not neccesserally the same plan to explain that will be used for the sql code that runs if

    Any help would be appreciated.

    Thank you

    The plan exists after analysis difficult.
    Statistics of actual execution will require a completed.
    That is why sql followed in real time is so great in 11g.
    In 9i, difficult.

  • Trace SQL execution plan

    Hello

    I need to get the execution plan for a particular SQL, but I don't have it. Application it issues for a second or two and then his party so I think that the definition of a trace on specific user. Is it possible to get the execution plan of the query like this? Thank you!

    Find the sql code, you are interested in v$ sql using the sql_text column and get the SQL_ID and CHILD_NUMBER. Entry of these two values for the query to get the execution below plan.

    Select * from table

    (dbms_xplan.display_cursor ('> ',>, 'ALLSTATS'));

  • package pl/sql execution plan

    Hi all

    How we can find the bottoleneks in the pl/sql package. I know we can use dbms_profiler. Gathersed data, but not having planned the details.

    Here's the query I use

    Select s.text,

    p.total_occur,

    p.TOTAL_TIME/1000000000 total_time,

    p.min_time / 1000000000 min_time,.

    p.max_time / 1000000000 max_time

    of plsql_profiler_data p, user_source s, plsql_profiler_runs r

    where p.line # = Check

    and p.runid = r.runid

    and r.run_comment = 'XXXX_YYY_INIT.XXX_TO_DDD(1,,360). '

    and s.name LIKE 'XXX % ';

    I see that dbms_profiler has gathered data. But it does give that which line is how long take.

    Please guide findout that.

    Thank you

    Col owner format a10

    Col name format a20

    row col 9999 format

    Col source format a40 word_wrap

    occurrences of col 9999999 format

    Col tot_time_s format 999,999,990.999

    Col run_comment format a40

    format of pct col 999

    Select runid, run_date, plsql_profiler_runs run_comment;

    Select OWNER u.unit_owner, u.unit_name NAME, d.line # LINE, (select the text from all_source where type in ('BODY of PACKAGE', 'FUNCTION', 'PROCEDURE', 'TRIGGER') and name = u.unit_name and = d.line line # and u.unit_owner and type = u.unit_type = owner) SOURCE, d.total_occur OCCURRENCES, (d.total_time/1000000000) TOT_TIME_S, d.total_time/r.run_total_time*100 "PCT".

    of plsql_profiler_runs r, plsql_profiler_units u, plsql_profiler_data d

    where are.runid = & runid

    and r.runid = u.runid

    and r.runid = d.runid

    and d.unit_number = u.unit_number

    and (d.total_time/1000000000) > 1 - more than 1 second

    order of tot_time_s

    /

    Kind regards

    Harman

  • PL/SQL execution error Question

    Hi Experts,
    It's the SQL procedure I remove a set number of order that are closed

    CREATE OR REPLACE PROCEDURE closed_test1 (varchar tabname, v_rowcount_int certain NUMBER)
    is
    v_sql varchar2 (4000);
    Start
    v_sql: =' delete ' | tabname |' College where exists (select order_nbr from the cl closed_order where fac.internal_order_id = cl.order_nbr)';
    immediately run v_sql;
    v_rowcount_int: = number of lines sql %;
    dbms_output.put_line (v_rowcount_int |) ("' deleted rows");
    commit;
    end;
    /

    I use an ETL tool to display the number of deleted rows, so I had to create an output parameter and awarded for the number of rows sql %

    When I run

    Declare
    number of v_rowndel;
    exec closed_test1 ('COST_TRANS_TABLE', v_rowndel);

    I get this error message
    ERROR at line 3:
    ORA-06550: line 3, column 57:
    PLS-00103: encountered the symbol "end-of-file" when awaits an of the
    Next:
    := ; not null default characters

    I don't understand what the problem is! Is it because I don't have an exit statement, but the sql statement is interlooped

    Any help is apprct in advance

    Thank you
    AJ

    It's the way you need to call the procedure.

    DECLARE
      v_rowndel   NUMBER;
    BEGIN
      closed_test1 ( 'COST_TRANS_TABLE', v_rowndel);
      DBMS_OUTPUT.PUT_LINE ('v_rowndel = ' || v_rowndel);
    END;
    

    If you use a tool, then turn on dbms_output.
    If execution of sqlplus and then SET SERVEROUPUT on.

    G.

  • Multiple execution plan.

    Hi all

    Can I get a query to see if there are several implementation plans for a query.
    I tried with v$ sql where CHILD_NUMBER can be 0 or 1 at a time.

    What interests me is any plans for a particular sql.

    Also I can get good technical quality for outln paper / and the profile of sql. I have some links but do not have enough to her.

    Thank you

    Rana.

    user582224 wrote:
    Can I get a query to see if there are several implementation plans for a query.
    I tried with v$ sql where CHILD_NUMBER can be 0 or 1 at a time.

    What interests me is any plans for a particular sql.

    Rana,

    If you are interested in what you have now in the pool that is shared, you can start with V$ SQL, V$ SQLAREA, SQLSTATS $ V and V$ SQL_PLAN.

    Note that different the same statement execution plans may already have aged out of the shared pool, that's why this information does not necessarily reflect the number of versions you may have had over time.

    If you are already on 10g or later, you can use the DBMS_XPLAN. Function DISPLAY_CURSOR. If you specify "NULL" for the second parameter ("cursor_child_no"), it will show you all the sliders of the specified SQL_ID child execution plans.

    If you have 10g or later and a CWA license, you can use DBA_HIST_SQL_PLAN and DBMS_XPLAN. DISPLAY_AWR to get stored for a particular SQL_ID. Note different execution plans that AWR cannot capture your particular statement, since it only samples consumers albums according to certain thresholds.

    If you do not have a license of AWR you will always get a similar historical view of your plans with using STATSPACK snapshot level > = 6 that captures SQL execution plans. Once your statement again could not enjoy according to the load and thresholds (STATSPACK documentation: "to collect plans for all statements in the shared pool, you can temporarily specify the threshold of executions (i_executions_th) to be zero (0) for these snapshots").

    Kind regards
    Randolf

    Oracle related blog stuff:
    http://Oracle-Randolf.blogspot.com/

    SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676 /.
    http://sourceforge.NET/projects/SQLT-pp/

  • Version 12: Same SQL, another scheme == > different execution plan?

    I'm testing a huge application with a database middleware sophisticated against the Oracle 12 database. So far, it works well with Pervasive SQL, MSSQL and Oracle 8 database... 11.

    There are many questions about execution plans changed from Version 11 to 12. Oracle will tell what all of the improvements are (or at least have to improvements), and I can't really denied him. It's not the subject.

    But I met some SQLs with horrible execution time, especially connected to Crystal Reports. Whenever I tried to check them, the queries have been executed quickly. As far as I can see, this has to do with the schema/user who executes the SQL statement in a first time. Here are the details:

    = ADMIN, DML = GUI DDL: all data are stored in a scheme of the ADMIN. The ADMIN user creates the tables, views and so on. It grants access to and creates synonyms for users, but it cannot modify the data using DML, given that triggers prevent him. End users, named 'GUI' users, are allowed to use the DML, but they have no privileges DDL.

    • Database of reports (on paper) are generally quite complex. They have only a limited data set (must fit on sheets of paper!), and the Oracle optimizer optimizes often against this goal. Because Crystal Reports generates no advice, most of the reports are based on a view ADMIN. < xyz > (with the necessary information) and are accessible via a GUI. < xyz > synonym of user GUI.

    • Crystal Reports running slowly (~ 5 minutes) connected as a GUI. I export it, get the SQL export, log in as an ADMINISTRATORand run the query, it works quickly (~ 2 seconds). Well, I've probably changed some white space, the line endings and others then copy / paste, I don't?

    • I tried many things, connecting both GUI and ADMIN, simplifying the application, execution and so on. Then I got confused version of who this query: when the ADMIN has added an additional space character it was fast, removed again and it was slow again. Whitespace have an influence on the execution plan? Probably not, and if yes, my vision of the world would collapse.

    • Later, I found out: in Version 12, depends on the user executing this query. Nail down us the source of the query for the synonym GUI. < xyz >. Let us make a new version of it (coded by white space - smile), and if run you it like GUI first, it's slow. Even if you re - log on as ADMINISTRATOR, the same version of this query is still slow. (This is a bug!)

    Question 1: When I prepend the SQL with 'EXPLAIN PLAN FOR', I seem to be changing. As GUI has no plan_table and no privilege to explain a plan, I can't spy on the implementation plan of 'bad '. I don't want to give too much GUI, and I fear it could alter the execution plan. Is there a trick to get the plan of execution of a SQL statement in v$ sql or v$ sqlarea? (Means: execute the query: GUI and explain it as an ADMINISTRATOR)

    Question 2: Is this on the privileges of the GUI? What you think, what direction will further investigate?

    Oracle database generates an execution plan based on SQL, the dictionary, the statistics, the privileges of the user of the analysis and database and session settings. One of the privileges is GRANT MERGE [ALL] DISPLAY, which was responsible for the difference in this particular example and in this particular version.

    When you log on as another user and run the same code in SQL, Oracle database verifies all required components before she reuses the old execution plan. This is a minor bug, but it is.

    In the example, the privilege GRANT MERGE ANY NOTICE was given implicitly by the DBA privilege. Because MERGE ANY VIEW disables security controls, the privilege of s/n, default, also disables security controls. This is not a desired behavior from the DBA privilege.

  • Same SQL different execution Plans in two different database instances.

    Hi all

    I run a different query on two instances of database. On one instance, the query takes 30 minutes and the other it takes 10 hours to complete. Data on the two instances are the same. When I generated the execution plan, on the two cases, it was different.

    OS: Redhat Linux 5
    Database version: 11.2.02 (on two instances)

    Plan on 1 Instance that takes 30 minutes.
    SELECT 
         X_REPLEN_RQST_INV_STG.BUSINESS_UNIT, 
         NVL(SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 
         INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)),'N/A') AS DOC_ID, 
         W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_ITEM, 
         W_PURCH_SCHEDULE_LINE_F.PURCH_SCHEDULE_NUM, 
         X_REPLEN_RQST_INV_STG.INV_ITEM_ID, 
         X_REPLEN_RQST_INV_STG.PROCESS_DATE AS REPLEN_PROCESS_DT, 
         X_REPLEN_RQST_INV_STG.EXPECTED_DATE AS REPLEN_EXPECTED_DT, 
         X_REPLEN_RQST_INV_STG.REORDER_QTY AS REPLEN_REORDER_QTY, 
         X_ITEM_ATTRIB_D.REPLENISH_CLASS AS REPLEN_CLASS, 
         X_REPLEN_RQST_INV_STG.REPLEN_STATUS, 
         X_REPLEN_RQST_INV_STG.REPLENISH_TYPE AS REPLEN_TYPE, 
         X_REPLEN_RQST_INV_STG.REQ_ID, 
         X_REPLEN_RQST_INV_STG.REQ_LINE_NBR, 
         X_REPLEN_RQST_INV_STG.REQ_SCHED_NBR, 
         X_REPLEN_RQST_INV_STG.REQ_DISTRIB_NBR, 
         P.FIRST_PO_DISP_DT, 
         W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID
    FROM 
         X_REPLEN_RQST_INV_STG LEFT OUTER JOIN W_RQSTN_LINE_COST_F 
                   ON X_REPLEN_RQST_INV_STG.RQSTN_LN_COST_INTG_ID = W_RQSTN_LINE_COST_F.INTEGRATION_ID 
                        AND X_REPLEN_RQST_INV_STG.DATASOURCE_NUM_ID = W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID 
         LEFT OUTER JOIN W_PURCH_COST_F 
                   ON W_RQSTN_LINE_COST_F.INTEGRATION_ID = W_PURCH_COST_F.REQ_DISTR_INTG_ID 
                        AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = W_PURCH_COST_F.DATASOURCE_NUM_ID 
         INNER join W_PURCH_SCHEDULE_LINE_F 
                   ON W_PURCH_COST_F.PURCH_SCHEDULE_INTG_ID = W_PURCH_SCHEDULE_LINE_F.INTEGRATION_ID 
                        AND W_PURCH_COST_F.DATASOURCE_NUM_ID = W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID 
         LEFT OUTER JOIN W_STATUS_D S1 
                   ON W_RQSTN_LINE_COST_F.APPROVAL_STATUS_WID = S1.ROW_WID 
                        AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = S1.DATASOURCE_NUM_ID 
                        AND 'PURCH_APPROVE' = S1.W_STATUS_CLASS 
         LEFT OUTER JOIN W_STATUS_D S2 
                   ON W_PURCH_COST_F.APPROVAL_STATUS_WID = S2.ROW_WID 
                        AND W_PURCH_COST_F.DATASOURCE_NUM_ID = S2.DATASOURCE_NUM_ID 
                        AND 'PURCH_APPROVE' = S2.W_STATUS_CLASS 
         LEFT OUTER JOIN (SELECT p1.BUSINESS_UNIT, p1.PO_ID, MIN(p1.DATETIME_DISP) AS FIRST_PO_DISP_DT
    FROM 
              X_PS_PO_DISPATCHED p1 GROUP BY p1.BUSINESS_UNIT, p1.PO_ID) P 
                   ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = P.BUSINESS_UNIT 
                        AND SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)) = 
    
    P.PO_ID      
         LEFT OUTER JOIN W_PRODUCT_D 
                   ON W_PURCH_SCHEDULE_LINE_F.PRODUCT_WID = W_PRODUCT_D.ROW_WID 
         LEFT OUTER JOIN X_ITEM_ATTRIB_D 
                   ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = X_ITEM_ATTRIB_D.BUSINESS_UNIT 
                        AND W_PRODUCT_D.PART_NUM = X_ITEM_ATTRIB_D.INV_ITEM_ID
    WHERE 
         TRIM(X_REPLEN_RQST_INV_STG.req_id) IS NOT NULL 
         AND X_REPLEN_RQST_INV_STG.replenish_type = '1' 
         AND X_REPLEN_RQST_INV_STG.replen_status = '4' 
         AND X_ITEM_ATTRIB_D.REPLENISH_CLASS = 'A' 
         AND S1.STATUS_CODE != 'X' 
         AND S2.STATUS_CODE != 'X' 
         AND P.FIRST_PO_DISP_DT IS NOT NULL
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 1674299164
    
    ----------------------------------------------------------------------------------------------------------------
    | Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
    ----------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                     |                         |     1 |   461 | 13942   (1)| 00:04:11 |
    |*  1 |  HASH JOIN                           |                         |     1 |   461 | 13942   (1)| 00:04:11 |
    |   2 |   NESTED LOOPS                       |                         |       |       |            |          |
    |   3 |    NESTED LOOPS                      |                         |     1 |   441 | 10409   (1)| 00:03:08 |
    |   4 |     NESTED LOOPS                     |                         |     1 |   421 | 10407   (1)| 00:03:08 |
    |   5 |      NESTED LOOPS                    |                         |     1 |   388 | 10406   (1)| 00:03:08 |
    |   6 |       NESTED LOOPS                   |                         |     1 |   319 | 10405   (1)| 00:03:08 |
    |   7 |        NESTED LOOPS                  |                         |     1 |   280 | 10404   (1)| 00:03:08 |
    |*  8 |         HASH JOIN                    |                         |     1 |   220 | 10401   (1)| 00:03:08 |
    |   9 |          NESTED LOOPS                |                         |       |       |            |          |
    |  10 |           NESTED LOOPS               |                         |    16 |  2896 | 10392   (1)| 00:03:08 |
    |* 11 |            TABLE ACCESS FULL         | X_REPLEN_RQST_INV_STG   |    16 |  2432 | 10375   (1)| 00:03:07 |
    |* 12 |            INDEX UNIQUE SCAN         | W_RQST_LN_CS_F_U1       |     1 |       |     1   (0)| 00:00:01 |
    |  13 |           TABLE ACCESS BY INDEX ROWID| W_RQSTN_LINE_COST_F     |     1 |    29 |     2   (0)| 00:00:01 |
    |* 14 |          TABLE ACCESS FULL           | W_STATUS_D              |     1 |    39 |     8   (0)| 00:00:01 |
    |  15 |         TABLE ACCESS BY INDEX ROWID  | W_PURCH_COST_F          |     1 |    60 |     3   (0)| 00:00:01 |
    |* 16 |          INDEX RANGE SCAN            | W_PURCH_COST_F_M1       |     1 |       |     2   (0)| 00:00:01 |
    |* 17 |        TABLE ACCESS BY INDEX ROWID   | W_STATUS_D              |     1 |    39 |     1   (0)| 00:00:01 |
    |* 18 |         INDEX UNIQUE SCAN            | W_STATUS_D_P1           |     1 |       |     0   (0)| 00:00:01 |
    |  19 |       TABLE ACCESS BY INDEX ROWID    | W_PURCH_SCHEDULE_LINE_F |     1 |    69 |     1   (0)| 00:00:01 |
    |* 20 |        INDEX UNIQUE SCAN             | W_PRCH_SC_LN_F_U1       |     1 |       |     1   (0)| 00:00:01 |
    |  21 |      TABLE ACCESS BY INDEX ROWID     | W_PRODUCT_D             |     1 |    33 |     1   (0)| 00:00:01 |
    |* 22 |       INDEX UNIQUE SCAN              | W_PRODUCT_D_P1          |     1 |       |     0   (0)| 00:00:01 |
    |* 23 |     INDEX RANGE SCAN                 | X_ITEM_ATTRIB_U01       |     1 |       |     1   (0)| 00:00:01 |
    |* 24 |    TABLE ACCESS BY INDEX ROWID       | X_ITEM_ATTRIB_D         |     1 |    20 |     2   (0)| 00:00:01 |
    |  25 |   VIEW                               |                         |  1428K|    27M|  3529   (2)| 00:01:04 |
    |* 26 |    FILTER                            |                         |       |       |            |          |
    |  27 |     HASH GROUP BY                    |                         |  1428K|    27M|  3529   (2)| 00:01:04 |
    |  28 |      TABLE ACCESS FULL               | X_PS_PO_DISPATCHED      |  1428K|    27M|  3493   (1)| 00:01:03 |
    ----------------------------------------------------------------------------------------------------------------
    On the Instance 2
    SELECT 
         X_REPLEN_RQST_INV_STG.BUSINESS_UNIT, 
         NVL(SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 
         INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)),'N/A') AS DOC_ID, 
         W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_ITEM, 
         W_PURCH_SCHEDULE_LINE_F.PURCH_SCHEDULE_NUM, 
         X_REPLEN_RQST_INV_STG.INV_ITEM_ID, 
         X_REPLEN_RQST_INV_STG.PROCESS_DATE AS REPLEN_PROCESS_DT, 
         X_REPLEN_RQST_INV_STG.EXPECTED_DATE AS REPLEN_EXPECTED_DT, 
         X_REPLEN_RQST_INV_STG.REORDER_QTY AS REPLEN_REORDER_QTY, 
         X_ITEM_ATTRIB_D.REPLENISH_CLASS AS REPLEN_CLASS, 
         X_REPLEN_RQST_INV_STG.REPLEN_STATUS, 
         X_REPLEN_RQST_INV_STG.REPLENISH_TYPE AS REPLEN_TYPE, 
         X_REPLEN_RQST_INV_STG.REQ_ID, 
         X_REPLEN_RQST_INV_STG.REQ_LINE_NBR, 
         X_REPLEN_RQST_INV_STG.REQ_SCHED_NBR, 
         X_REPLEN_RQST_INV_STG.REQ_DISTRIB_NBR, 
         P.FIRST_PO_DISP_DT, 
         W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID
    FROM 
         X_REPLEN_RQST_INV_STG LEFT OUTER JOIN W_RQSTN_LINE_COST_F 
                   ON X_REPLEN_RQST_INV_STG.RQSTN_LN_COST_INTG_ID = W_RQSTN_LINE_COST_F.INTEGRATION_ID 
                        AND X_REPLEN_RQST_INV_STG.DATASOURCE_NUM_ID = W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID 
         LEFT OUTER JOIN W_PURCH_COST_F 
                   ON W_RQSTN_LINE_COST_F.INTEGRATION_ID = W_PURCH_COST_F.REQ_DISTR_INTG_ID 
                        AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = W_PURCH_COST_F.DATASOURCE_NUM_ID 
         INNER join W_PURCH_SCHEDULE_LINE_F 
                   ON W_PURCH_COST_F.PURCH_SCHEDULE_INTG_ID = W_PURCH_SCHEDULE_LINE_F.INTEGRATION_ID 
                        AND W_PURCH_COST_F.DATASOURCE_NUM_ID = W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID 
         LEFT OUTER JOIN W_STATUS_D S1 
                   ON W_RQSTN_LINE_COST_F.APPROVAL_STATUS_WID = S1.ROW_WID 
                        AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = S1.DATASOURCE_NUM_ID 
                        AND 'PURCH_APPROVE' = S1.W_STATUS_CLASS 
         LEFT OUTER JOIN W_STATUS_D S2 
                   ON W_PURCH_COST_F.APPROVAL_STATUS_WID = S2.ROW_WID 
                        AND W_PURCH_COST_F.DATASOURCE_NUM_ID = S2.DATASOURCE_NUM_ID 
                        AND 'PURCH_APPROVE' = S2.W_STATUS_CLASS 
         LEFT OUTER JOIN (SELECT p1.BUSINESS_UNIT, p1.PO_ID, MIN(p1.DATETIME_DISP) AS FIRST_PO_DISP_DT
    FROM 
              X_PS_PO_DISPATCHED p1 GROUP BY p1.BUSINESS_UNIT, p1.PO_ID) P 
                   ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = P.BUSINESS_UNIT 
                        AND SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)) = 
    
    P.PO_ID      
         LEFT OUTER JOIN W_PRODUCT_D 
                   ON W_PURCH_SCHEDULE_LINE_F.PRODUCT_WID = W_PRODUCT_D.ROW_WID 
         LEFT OUTER JOIN X_ITEM_ATTRIB_D 
                   ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = X_ITEM_ATTRIB_D.BUSINESS_UNIT 
                        AND W_PRODUCT_D.PART_NUM = X_ITEM_ATTRIB_D.INV_ITEM_ID
    WHERE 
         TRIM(X_REPLEN_RQST_INV_STG.req_id) IS NOT NULL 
         AND X_REPLEN_RQST_INV_STG.replenish_type = '1' 
         AND X_REPLEN_RQST_INV_STG.replen_status = '4' 
         AND X_ITEM_ATTRIB_D.REPLENISH_CLASS = 'A' 
         AND S1.STATUS_CODE != 'X' 
         AND S2.STATUS_CODE != 'X' 
         AND P.FIRST_PO_DISP_DT IS NOT NULL
    
    
    ---------------------------------------------------------------------------------------------------------------
    | Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                    |                         |     1 |   420 | 19630   (1)| 00:04:35 |
    |   1 |  NESTED LOOPS                       |                         |       |       |            |       |
    |   2 |   NESTED LOOPS                      |                         |     1 |   420 | 19630   (1)| 00:04:35 |
    |   3 |    NESTED LOOPS                     |                         |     1 |   400 | 19627   (1)| 00:04:35 |
    |   4 |     NESTED LOOPS                    |                         |     1 |   386 | 19626   (1)| 00:04:35 |
    |   5 |      NESTED LOOPS                   |                         |     1 |   317 | 19625   (1)| 00:04:35 |
    |   6 |       NESTED LOOPS                  |                         |     1 |   289 | 19624   (1)| 00:04:35 |
    |   7 |        NESTED LOOPS                 |                         |     1 |   229 | 19621   (1)| 00:04:35 |
    |   8 |         NESTED LOOPS                |                         |     1 |   201 | 19620   (1)| 00:04:35 |
    |   9 |          MERGE JOIN CARTESIAN       |                         |     1 |   172 | 19619   (1)| 00:04:35 |
    |  10 |           VIEW                      |                         |     1 |    20 |  4942   (2)| 00:01:10 |
    |* 11 |            FILTER                   |                         |       |       |            |       |
    |  12 |             HASH GROUP BY           |                         |     1 |    20 |  4942   (2)| 00:01:10 |
    |  13 |              TABLE ACCESS FULL      | X_PS_PO_DISPATCHED      |  1428K|    27M|  4902   (1)| 00:01:09 |
    |  14 |           BUFFER SORT               |                         |     1 |   152 | 19619   (1)| 00:04:35 |
    |* 15 |            TABLE ACCESS FULL        | X_REPLEN_RQST_INV_STG   |     1 |   152 | 14676   (1)| 00:03:26 |
    |  16 |          TABLE ACCESS BY INDEX ROWID| W_RQSTN_LINE_COST_F     |     1 |    29 |     1   (0)| 00:00:01 |
    |* 17 |           INDEX UNIQUE SCAN         | W_RQST_LN_CS_F_U1       |     1 |       |     1   (0)| 00:00:01 |
    |* 18 |         TABLE ACCESS BY INDEX ROWID | W_STATUS_D              |     1 |    28 |     1   (0)| 00:00:01 |
    |* 19 |          INDEX UNIQUE SCAN          | W_STATUS_D_P1           |     1 |       |     0   (0)| 00:00:01 |
    |  20 |        TABLE ACCESS BY INDEX ROWID  | W_PURCH_COST_F          |     3 |   180 |     3   (0)| 00:00:01 |
    |* 21 |         INDEX RANGE SCAN            | W_PURCH_COST_F_M1       |     1 |       |     2   (0)| 00:00:01 |
    |* 22 |       TABLE ACCESS BY INDEX ROWID   | W_STATUS_D              |     1 |    28 |     1   (0)| 00:00:01 |
    |* 23 |        INDEX UNIQUE SCAN            | W_STATUS_D_P1           |     1 |       |     0   (0)| 00:00:01 |
    |* 24 |      TABLE ACCESS BY INDEX ROWID    | W_PURCH_SCHEDULE_LINE_F |     1 |    69 |     1   (0)| 00:00:01 |
    |* 25 |       INDEX UNIQUE SCAN             | W_PRCH_SC_LN_F_U1       |     1 |       |     1   (0)| 00:00:01 |
    |* 26 |     TABLE ACCESS BY INDEX ROWID     | W_PRODUCT_D             |     1 |    14 |     1   (0)| 00:00:01 |
    |* 27 |      INDEX UNIQUE SCAN              | W_PRODUCT_D_P1          |     1 |       |     0   (0)| 00:00:01 |
    |* 28 |    INDEX RANGE SCAN                 | X_ITEM_ATTRIB_U01       |     1 |       |     2   (0)| 00:00:01 |
    |* 29 |   TABLE ACCESS BY INDEX ROWID       | X_ITEM_ATTRIB_D         |     1 |    20 |     3   (0)| 00:00:01 |
    ---------------------------------------------------------------------------------------------------------------
    In the second execution plan, we can see that it uses a Cartesian product.

    Thank you.

    Oceaner wrote:
    Hi all

    I run a different query on two instances of database. On one instance, the query takes 30 minutes and the other it takes 10 hours to complete. Data on the two instances are the same. When I generated the execution plan, on the two cases, it was different.

    The most obvious difference is the subquery total inline:

    Quick plan:

    ----------------------------------------------------------------------------------------------------------------
    | Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
    ----------------------------------------------------------------------------------------------------------------
    |*  1 |  HASH JOIN                           |                         |     1 |   461 | 13942   (1)| 00:04:11 |
    |   2 |   NESTED LOOPS                       |                         |       |       |            |          |
    ...
    |  25 |   VIEW                               |                         |  1428K|    27M|  3529   (2)| 00:01:04 |
    |* 26 |    FILTER                            |                         |       |       |            |          |
    |  27 |     HASH GROUP BY                    |                         |  1428K|    27M|  3529   (2)| 00:01:04 |
    |  28 |      TABLE ACCESS FULL               | X_PS_PO_DISPATCHED      |  1428K|    27M|  3493   (1)| 00:01:03 |
    ----------------------------------------------------------------------------------------------------------------
    

    Plan of slow

    ---------------------------------------------------------------------------------------------------------------
    | Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------------------------------
    ...
    |   9 |          MERGE JOIN CARTESIAN       |                         |     1 |   172 | 19619   (1)| 00:04:35 |
    |  10 |           VIEW                      |                         |     1 |    20 |  4942   (2)| 00:01:10 |
    |* 11 |            FILTER                   |                         |       |       |            |          |
    |  12 |             HASH GROUP BY           |                         |     1 |    20 |  4942   (2)| 00:01:10 |
    |  13 |              TABLE ACCESS FULL      | X_PS_PO_DISPATCHED      |  1428K|    27M|  4902   (1)| 00:01:09 |
    |  14 |           BUFFER SORT               |                         |     1 |   152 | 19619   (1)| 00:04:35 |
    |* 15 |            TABLE ACCESS FULL        | X_REPLEN_RQST_INV_STG   |     1 |   152 | 14676   (1)| 00:03:26 |
    ...
    ---------------------------------------------------------------------------------------------------------------
    

    Note the value of lines given to the operation - VIEW


    One for the slow plan - that of why Oracle chose display online as a starting point for the query and used a Cartesian merge join to join to the table nearby.

    1.4Million for the fast plan - this is why Oracle has decided to visit the table set and use it as the table of the probe in a hash join.

    I think we can assume that the estimation of the single line is a big mistake. We can also assume that the two series of statistics (or possibly index definitions) on the tables two versions do not match.

    It would be useful, of course, see the comprehensive implementation plan, and preferably one from memory: (http://jonathanlewis.wordpress.com/2006/12/22/dbms_xplan-again/).

    You might notice that you outer joins are not relevant - maybe this SQL is a framework for a more general query - given that the plan shows that they have all been turned away.

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    Author: core Oracle

  • Plan shows SQL execution Hrs 999:59:59 Sec.

    Dear masters,

    My development team announced today that the query below takes more time. When I check the plan for my shok show Hrs 999:59:59 Sec.

    Kindly help me for this query setting.

    I use the oracle 10.2.0.3 version.
    SELECT  
     S_INVLOC.NAME , S_ORDER.ACCNT_ID , S_ORDER.APPR_BY_EMP_ID , S_ORDER.BL_CON_ID , S_ORDER.BL_OU_ID , S_ORDER.CARRIER_CD , S_ORDER.CONTACT_ID , S_ORDER.CURCY_CD , S_ORDER.TAX_EXEMPT_FLG ,
     S_ORDER.REQ_SHIP_DT , S_ORDER.SHIP_ADDR_ID , S_ORDER.SHIP_CON_ID , S_ORDER.SHIP_METH_CD , S_ORDER.SHIP_OU_ID , S_ORDER.STATUS_CD , S_ORDER.TAX_EXEMPT_NUM , S_ORDER.TAX_EXEMPT_REASON ,
     S_ORDER.OPTY_ID , S_ORDER.BU_ID PR_VIS_ORG_ID , S_ORDER.PROMO_ID , S_ORDER.PRI_LST_ID , S_ORDER.AGREE_ID AGREEMENT_ID , S_ORDER.ENTLMNT_ID ENTITLEMENT_ID , S_ORDER.SR_ID ,
     S_ORDER.BILLABLE_FLG , S_ORDER_ITEM.ROW_ID , S_ORDER_ITEM.ORDER_ID , S_ORDER_ITEM.LN_NUM , S_ORDER_ITEM.PROD_ID , S_ORDER_ITEM.ADJ_UNIT_PRI , S_ORDER_ITEM.BASE_UNIT_PRI ,
     S_ORDER_ITEM.CARRIER_CD CARRIER_CD1 , S_ORDER_ITEM.EXTD_QTY , S_ORDER_ITEM.QTY_SHIPPED , S_ORDER_ITEM.REQ_SHIP_DT REQ_SHIP_DT1 , S_ORDER_ITEM.SHIP_ADDR_ID SHIP_ADDR_ID1 ,
     S_ORDER_ITEM.SHIP_CON_ID SHIP_CON_ID1 , S_ORDER_ITEM.SHIP_METH_CD SHIP_METH_CD1 , S_ORDER_ITEM.STATUS_CD STATUS_CD1 , S_ORDER_ITEM.PROD_STATUS_CD , S_ORDER_ITEM.PROD_NAME ,
     S_ORDER_ITEM.LOANER_FLG , S_ORDER_ITEM.DISCNT_METH_CD , S_ORDER_ITEM.SHIP_OU_ID SHIP_OU_ID1 , S_ORDER_ITEM.STATUS_DT , S_ORDER_ITEM.MUST_DLVR_BY_DT , S_ORDER_ITEM.ACTION_CD ,
     S_ORDER_ITEM.ROLLUP_PRI , S_PROD_INT.NAME NAME1 , A.NAME NAME2 , B.NAME NAME3 , S_VOL_DISCNT.NAME NAME4 , ACCNT.PR_INDUST_ID , POSCRTDORG.OU_ID CREATED_BY_ORG_ID ,
     POSOWNERORG.OU_ID PR_OWNER_ORG_ID , PAROITEM.LN_NUM , PAROITEM.PROD_ID , SHIPOITEM.CITY , SHIPOITEM.COUNTRY , SHIPOITEM.ZIPCODE , SHIPO.CITY , SHIPO.COUNTRY , SHIPO.ZIPCODE ,
     BILL.CITY , BILL.COUNTRY , BILL.ZIPCODE , S_CAMP_CON.PR_CALL_LST_ID SEGMENT_ID , S_ORDER.DCP_ID OFFER_ID , APPRBYPOS.PR_HELD_POSTN_ID , POSOWNERORG.ROW_ID , POSOWNERORG.PR_EMP_ID ,
     S_ENTLMNT.PAR_AGREE_ID , ROOTOITEM.PROD_ID ROOT_LN_PROD_ID , ROOTOITEM.LN_NUM ROOT_LN_NUM , S_ORDER.PR_POSTN_ID , S_CAMP_CON.CAMP_LD_WAVE_ID , S_SRC.REGION_ID , OPRI.COST_PRI ,
     S_ORDER_ITEM.ORDER_ITM_CURCY_CD OITM_CURCY_CD , ROOTOITEM.ORDER_ITM_CURCY_CD ROOTOITM_CURCY_CD , S_ORDER_ITEM.ORDER_ITM_EXCH_DT OITM_AMT_DT , S_ORDER.ORDER_EXCH_DT ,
     S_ORDER_ITEM.CREATED , S_ORDER_ITEM.NET_PRI , S_ORDER_ITEM.CRSE_OFFR_ID , S_ORDER_ITEM.PRI_LST_ID OITM_PRI_LST_ID , ROOTOITEM.PRI_LST_ID ROOTOITM_PRI_LST_ID ,
     OWNORG.PRTNR_FLG , VISORG.PRTNR_FLG , S_CAMP_LD_WAVE.LAUNCHED_TS , QUOTE.CREATED , S_ORDER.ACTIVE_FLG , S_ORDER.APPROVED_FLG , PARPROD.PROD_TYPE_CD , ROOTPROD.PROD_TYPE_CD ,
     S_PROD_INT.PRICE_TYPE_CD , S_SRC.PROG_END_DT , S_SRC.PROG_START_DT , S_SRC.ROW_ID , S_ORDER.CREATED , OWNORG.ROW_ID , 0 AS X_CUSTOM , S_ORDER_ITEM. X_PHONE_NUMBER ,
     S_ORDER_ITEM.X_BACKEND_SERVICE_ID , S_ORDER_ITEM.SERVICE_NUM , S_ORDER_ITEM.BILL_ACCNT_ID , S_ORDER_X.ATTRIB_04 , S_ORDER_X.ATTRIB_30 , S_ORDER_X.ATTRIB_31
       FROM
     SIEBEL.V_ORDER_ITEM S_ORDER_ITEM, SIEBEL.S_ORDER_ITEM PAROITEM, SIEBEL.S_ORDER_ITEM ROOTOITEM, SIEBEL.S_ORDER, SIEBEL.S_VDISCNT_ITEM A, SIEBEL.S_VOL_DISCNT, SIEBEL.S_PROD_INT,
     SIEBEL.S_VDISCNT_ITEM B, SIEBEL.S_INVLOC, SIEBEL.S_ORG_EXT ACCNT, SIEBEL.S_POSTN POSOWNERORG, SIEBEL.S_CONTACT CRTD, SIEBEL.S_CONTACT APPRBYPOS, SIEBEL.S_POSTN POSCRTDORG,
     SIEBEL.S_ADDR_ORG SHIPOITEM, SIEBEL.S_ADDR_ORG SHIPO, SIEBEL.S_ADDR_ORG BILL, SIEBEL.S_CAMP_CON, SIEBEL.S_ENTLMNT, SIEBEL.S_SRC, SIEBEL.S_ORDER_ITM_PRI OPRI,
     SIEBEL.S_CAMP_LD_WAVE, SIEBEL.S_DOC_QUOTE QUOTE, SIEBEL.S_ORG_EXT OWNORG, SIEBEL.S_ORG_EXT OWNORG1, SIEBEL.S_ORG_EXT VISORG1, SIEBEL.S_ORG_EXT VISORG,
     SIEBEL.S_PROD_INT PARPROD, SIEBEL.S_PROD_INT ROOTPROD, SIEBEL.S_ORDER_X
     WHERE 
         S_ORDER_ITEM.ORDER_ID     = S_ORDER.ROW_ID
        AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID  = ROOTOITEM.ROW_ID
        AND S_ORDER_ITEM.PAR_ORDER_ITEM_ID   = PAROITEM.ROW_ID(+)
        AND S_ORDER_ITEM.PROD_ID      = S_PROD_INT.ROW_ID(+)
        AND S_ORDER_ITEM.SRC_INVLOC_ID       = S_INVLOC.ROW_ID(+)
        AND S_ORDER_ITEM.VOL_DISCNT_ITEM_ID  = A.ROW_ID(+)
        AND S_ORDER_ITEM.VOL_DISCNT_ID       = S_VOL_DISCNT.ROW_ID(+)
        AND S_ORDER_ITEM.VOL_UPSELL_ITEM_ID  = B.ROW_ID(+)
        AND S_ORDER_ITEM.SHIP_ADDR_ID = SHIPOITEM.ROW_ID(+)
        AND S_ORDER.PR_POSTN_ID       = POSOWNERORG.ROW_ID(+)
        AND S_ORDER_ITEM.CREATED_BY   = CRTD.ROW_ID(+)
        AND CRTD.PR_HELD_POSTN_ID     = POSCRTDORG.ROW_ID(+)
        AND S_ORDER.ACCNT_ID   = ACCNT.ROW_ID(+)
        AND S_ORDER.CAMP_CON_ID       = S_CAMP_CON.ROW_ID(+)
        AND S_ORDER.SHIP_ADDR_ID      = SHIPO.ROW_ID(+)
        AND S_ORDER.BL_ADDR_ID        = BILL.ROW_ID(+)
        AND S_ORDER.APPR_BY_EMP_ID    = APPRBYPOS.ROW_ID(+)
        AND S_ORDER.ENTLMNT_ID        = S_ENTLMNT.ROW_ID(+)
        AND S_ORDER.PROMO_ID   = S_SRC.ROW_ID(+)
        AND S_ORDER_ITEM.ROW_ID       = OPRI.PAR_ROW_ID(+)
        AND S_CAMP_CON.CAMP_LD_WAVE_ID       = S_CAMP_LD_WAVE.ROW_ID(+)
        AND S_ORDER.QUOTE_ID   = QUOTE.ROW_ID(+)
        AND POSOWNERORG.OU_ID  = OWNORG1.ROW_ID(+)
        AND OWNORG1.PAR_BU_ID  = OWNORG.ROW_ID(+)
        AND S_ORDER.BU_ID      = VISORG1.ROW_ID(+)
        AND VISORG1.PAR_BU_ID  = VISORG.ROW_ID(+)
        AND PAROITEM.PROD_ID   = PARPROD.ROW_ID(+)
        AND ROOTOITEM.PROD_ID  = ROOTPROD.ROW_ID(+)
        AND S_ORDER_ITEM.ORDER_ID     = S_ORDER_X.PAR_ROW_ID(+)
        AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID IS NOT NULL;
    Execution plan is: select * from table (dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    ------------------------------------------------------------------------------------------------------------------------------------------------------
    Plan hash value: 73463824
    
    ------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                                                | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                                         |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   1 |  NESTED LOOPS OUTER                                      |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   2 |   NESTED LOOPS OUTER                                     |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   3 |    NESTED LOOPS OUTER                                    |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   4 |     NESTED LOOPS OUTER                                   |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   5 |      NESTED LOOPS OUTER                                  |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   6 |       NESTED LOOPS                                       |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   7 |        NESTED LOOPS OUTER                                |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   8 |         NESTED LOOPS OUTER                               |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |   9 |          NESTED LOOPS OUTER                              |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |  10 |           NESTED LOOPS OUTER                             |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |  11 |            NESTED LOOPS OUTER                            |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |  12 |             NESTED LOOPS OUTER                           |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |  13 |              NESTED LOOPS OUTER                          |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |  14 |               NESTED LOOPS OUTER                         |                   |  3170K|    12G|  4100G  (4)|999:59:59 |
    |  15 |                NESTED LOOPS OUTER                        |                   |  3170K|    11G|  4100G  (4)|999:59:59 |
    |  16 |                 NESTED LOOPS OUTER                       |                   |  3170K|    11G|  4100G  (4)|999:59:59 |
    |  17 |                  NESTED LOOPS OUTER                      |                   |  3170K|    11G|  4100G  (4)|999:59:59 |
    |  18 |                   NESTED LOOPS OUTER                     |                   |  3170K|    10G|  4100G  (4)|999:59:59 |
    |  19 |                    NESTED LOOPS OUTER                    |                   |  3170K|    10G|  4100G  (4)|999:59:59 |
    |  20 |                     NESTED LOOPS OUTER                   |                   |  3170K|    10G|  4100G  (4)|999:59:59 |
    |  21 |                      NESTED LOOPS                        |                   |  3170K|  9911M|  4100G  (4)|999:59:59 |
    |  22 |                       NESTED LOOPS OUTER                 |                   |  3108K|  4927M|  2569K  (2)| 01:08:47 |
    |  23 |                        NESTED LOOPS OUTER                |                   |  3108K|  4835M|   115K (14)| 00:03:06 |
    |  24 |                         NESTED LOOPS OUTER               |                   |  3108K|  4782M|   115K (14)| 00:03:06 |
    |  25 |                          NESTED LOOPS OUTER              |                   |  3108K|  4660M|   112K (12)| 00:03:02 |
    |  26 |                           NESTED LOOPS OUTER             |                   |  3108K|  4417M|   112K (12)| 00:03:02 |
    |  27 |                            NESTED LOOPS OUTER            |                   |  3108K|  4227M|   112K (12)| 00:03:02 |
    |  28 |                             NESTED LOOPS OUTER           |                   |  3108K|  3943M|   112K (12)| 00:03:02 |
    |  29 |                              NESTED LOOPS OUTER          |                   |  3108K|  3178M|   111K (11)| 00:02:59 |
    |  30 |                               TABLE ACCESS FULL          | S_ORDER           |  3108K|  2413M|   109K  (9)| 00:02:56 |
    |  31 |                               TABLE ACCESS BY INDEX ROWID| S_ADDR_ORG        |     1 |   258 |     1   (0)| 00:00:01 |
    |* 32 |                                INDEX UNIQUE SCAN         | S_ADDR_ORG_P1     |     1 |       |     1   (0)| 00:00:01 |
    |  33 |                              TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG        |     1 |   258 |     1   (0)| 00:00:01 |
    |* 34 |                               INDEX UNIQUE SCAN          | S_ADDR_ORG_P1     |     1 |       |     1   (0)| 00:00:01 |
    |  35 |                             TABLE ACCESS BY INDEX ROWID  | S_CAMP_CON        |     1 |    96 |     1   (0)| 00:00:01 |
    |* 36 |                              INDEX UNIQUE SCAN           | S_CAMP_CON_P1     |     1 |       |     1   (0)| 00:00:01 |
    |  37 |                            TABLE ACCESS BY INDEX ROWID   | S_ENTLMNT         |     1 |    64 |     1   (0)| 00:00:01 |
    |* 38 |                             INDEX UNIQUE SCAN            | S_ENTLMNT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  39 |                           TABLE ACCESS BY INDEX ROWID    | S_SRC             |     1 |    82 |     1   (0)| 00:00:01 |
    |* 40 |                            INDEX UNIQUE SCAN             | S_SRC_P1          |     1 |       |     1   (0)| 00:00:01 |
    |  41 |                          TABLE ACCESS BY INDEX ROWID     | S_CAMP_LD_WAVE    |     1 |    41 |     1   (0)| 00:00:01 |
    |* 42 |                           INDEX UNIQUE SCAN              | S_CAMP_LD_WAVE_P1 |     1 |       |     1   (0)| 00:00:01 |
    |  43 |                         TABLE ACCESS BY INDEX ROWID      | S_DOC_QUOTE       |     1 |    18 |     1   (0)| 00:00:01 |
    |* 44 |                          INDEX UNIQUE SCAN               | S_DOC_QUOTE_P1    |     1 |       |     1   (0)| 00:00:01 |
    |  45 |                        TABLE ACCESS BY INDEX ROWID       | S_POSTN           |     1 |    31 |     1   (0)| 00:00:01 |
    |* 46 |                         INDEX UNIQUE SCAN                | S_POSTN_P1        |     1 |       |     1   (0)| 00:00:01 |
    |* 47 |                       VIEW                               | V_ORDER_ITEM      |     1 |  1616 |  1318K  (4)| 00:35:19 |
    |  48 |                        NESTED LOOPS                      |                   |  3128K|  1372M|  1318K  (4)| 00:35:19 |
    |  49 |                         INDEX FAST FULL SCAN             | S_ETL_I_IMG_25_M2 |  3128K|    32M|  2756  (11)| 00:00:05 |
    |* 50 |                         TABLE ACCESS BY INDEX ROWID      | S_ORDER_ITEM      |     1 |   449 |     2   (0)| 00:00:01 |
    |* 51 |                          INDEX UNIQUE SCAN               | S_ORDER_ITEM_P1   |     1 |       |     2   (0)| 00:00:01 |
    |  52 |                      TABLE ACCESS BY INDEX ROWID         | S_VDISCNT_ITEM    |     1 |   134 |     1   (0)| 00:00:01 |
    |* 53 |                       INDEX UNIQUE SCAN                  | S_VDISCNT_ITEM_P1 |     1 |       |     1   (0)| 00:00:01 |
    |  54 |                     TABLE ACCESS BY INDEX ROWID          | S_VOL_DISCNT      |     1 |   134 |     1   (0)| 00:00:01 |
    |* 55 |                      INDEX UNIQUE SCAN                   | S_VOL_DISCNT_P1   |     1 |       |     1   (0)| 00:00:01 |
    |  56 |                    TABLE ACCESS BY INDEX ROWID           | S_VDISCNT_ITEM    |     1 |   134 |     1   (0)| 00:00:01 |
    |* 57 |                     INDEX UNIQUE SCAN                    | S_VDISCNT_ITEM_P1 |     1 |       |     1   (0)| 00:00:01 |
    |  58 |                   TABLE ACCESS BY INDEX ROWID            | S_ADDR_ORG        |     1 |   258 |     1   (0)| 00:00:01 |
    |* 59 |                    INDEX UNIQUE SCAN                     | S_ADDR_ORG_P1     |     1 |       |     1   (0)| 00:00:01 |
    |* 60 |                  TABLE ACCESS FULL                       | S_ORDER_ITM_PRI   |     1 |    45 |     0   (0)| 00:00:01 |
    |  61 |                 TABLE ACCESS BY INDEX ROWID              | S_INVLOC          |     1 |    33 |     1   (0)| 00:00:01 |
    |* 62 |                  INDEX UNIQUE SCAN                       | S_INVLOC_P1       |     1 |       |     1   (0)| 00:00:01 |
    |  63 |                TABLE ACCESS BY INDEX ROWID               | S_PROD_INT        |     1 |    58 |     1   (0)| 00:00:01 |
    |* 64 |                 INDEX UNIQUE SCAN                        | S_PROD_INT_P1     |     1 |       |     1   (0)| 00:00:01 |
    |  65 |               TABLE ACCESS BY INDEX ROWID                | S_ORDER_X         |     1 |    36 |     2   (0)| 00:00:01 |
    |* 66 |                INDEX RANGE SCAN                          | S_ORDER_X_U1      |     1 |       |     2   (0)| 00:00:01 |
    |  67 |              TABLE ACCESS BY INDEX ROWID                 | S_CONTACT         |     1 |    14 |     2   (0)| 00:00:01 |
    |* 68 |               INDEX UNIQUE SCAN                          | S_CONTACT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  69 |             TABLE ACCESS BY INDEX ROWID                  | S_POSTN           |     1 |    20 |     1   (0)| 00:00:01 |
    |* 70 |              INDEX UNIQUE SCAN                           | S_POSTN_P1        |     1 |       |     1   (0)| 00:00:01 |
    |  71 |            TABLE ACCESS BY INDEX ROWID                   | S_CONTACT         |     1 |    14 |     1   (0)| 00:00:01 |
    |* 72 |             INDEX UNIQUE SCAN                            | S_CONTACT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  73 |           TABLE ACCESS BY INDEX ROWID                    | S_ORG_EXT         |     1 |    14 |     2   (0)| 00:00:01 |
    |* 74 |            INDEX UNIQUE SCAN                             | S_ORG_EXT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  75 |          TABLE ACCESS BY INDEX ROWID                     | S_ORG_EXT         |     1 |    14 |     2   (0)| 00:00:01 |
    |* 76 |           INDEX UNIQUE SCAN                              | S_ORG_EXT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  77 |         TABLE ACCESS BY INDEX ROWID                      | S_ORG_EXT         |     1 |    17 |     2   (0)| 00:00:01 |
    |* 78 |          INDEX UNIQUE SCAN                               | S_ORG_EXT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  79 |        TABLE ACCESS BY INDEX ROWID                       | S_ORDER_ITEM      |     1 |    60 |     2   (0)| 00:00:01 |
    |* 80 |         INDEX UNIQUE SCAN                                | S_ORDER_ITEM_P1   |     1 |       |     2   (0)| 00:00:01 |
    |  81 |       TABLE ACCESS BY INDEX ROWID                        | S_ORDER_ITEM      |     1 |    24 |     2   (0)| 00:00:01 |
    |* 82 |        INDEX UNIQUE SCAN                                 | S_ORDER_ITEM_P1   |     1 |       |     2   (0)| 00:00:01 |
    |  83 |      TABLE ACCESS BY INDEX ROWID                         | S_PROD_INT        |     1 |    16 |     1   (0)| 00:00:01 |
    |* 84 |       INDEX UNIQUE SCAN                                  | S_PROD_INT_P1     |     1 |       |     1   (0)| 00:00:01 |
    |  85 |     TABLE ACCESS BY INDEX ROWID                          | S_PROD_INT        |     1 |    16 |     1   (0)| 00:00:01 |
    |* 86 |      INDEX UNIQUE SCAN                                   | S_PROD_INT_P1     |     1 |       |     1   (0)| 00:00:01 |
    |  87 |    TABLE ACCESS BY INDEX ROWID                           | S_ORG_EXT         |     1 |    14 |     2   (0)| 00:00:01 |
    |* 88 |     INDEX UNIQUE SCAN                                    | S_ORG_EXT_P1      |     1 |       |     1   (0)| 00:00:01 |
    |  89 |   TABLE ACCESS BY INDEX ROWID                            | S_ORG_EXT         |     1 |    17 |     2   (0)| 00:00:01 |
    |* 90 |    INDEX UNIQUE SCAN                                     | S_ORG_EXT_P1      |     1 |       |     1   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
      32 - access("S_ORDER"."SHIP_ADDR_ID"="SHIPO"."ROW_ID"(+))
      34 - access("S_ORDER"."BL_ADDR_ID"="BILL"."ROW_ID"(+))
      36 - access("S_ORDER"."CAMP_CON_ID"="S_CAMP_CON"."ROW_ID"(+))
      38 - access("S_ORDER"."ENTLMNT_ID"="S_ENTLMNT"."ROW_ID"(+))
      40 - access("S_ORDER"."PROMO_ID"="S_SRC"."ROW_ID"(+))
      42 - access("S_CAMP_CON"."CAMP_LD_WAVE_ID"="S_CAMP_LD_WAVE"."ROW_ID"(+))
      44 - access("S_ORDER"."QUOTE_ID"="QUOTE"."ROW_ID"(+))
      46 - access("S_ORDER"."PR_POSTN_ID"="POSOWNERORG"."ROW_ID"(+))
      47 - filter("S_ORDER_ITEM"."ORDER_ID"="S_ORDER"."ROW_ID")
      50 - filter("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID" IS NOT NULL)
      51 - access("S_ORDER_ITEM"."ROW_ID"="S_ETL_I_IMG_25"."ROW_ID")
      53 - access("S_ORDER_ITEM"."VOL_DISCNT_ITEM_ID"="A"."ROW_ID"(+))
      55 - access("S_ORDER_ITEM"."VOL_DISCNT_ID"="S_VOL_DISCNT"."ROW_ID"(+))
      57 - access("S_ORDER_ITEM"."VOL_UPSELL_ITEM_ID"="B"."ROW_ID"(+))
      59 - access("S_ORDER_ITEM"."SHIP_ADDR_ID"="SHIPOITEM"."ROW_ID"(+))
      60 - filter("S_ORDER_ITEM"."ROW_ID"="OPRI"."PAR_ROW_ID"(+))
    
    PLAN_TABLE_OUTPUT
    ------------------------------------------------------------------------------------------------------------------------------------------------------
      62 - access("S_ORDER_ITEM"."SRC_INVLOC_ID"="S_INVLOC"."ROW_ID"(+))
      64 - access("S_ORDER_ITEM"."PROD_ID"="S_PROD_INT"."ROW_ID"(+))
      66 - access("S_ORDER_ITEM"."ORDER_ID"="S_ORDER_X"."PAR_ROW_ID"(+))
      68 - access("S_ORDER_ITEM"."CREATED_BY"="CRTD"."ROW_ID"(+))
      70 - access("CRTD"."PR_HELD_POSTN_ID"="POSCRTDORG"."ROW_ID"(+))
      72 - access("S_ORDER"."APPR_BY_EMP_ID"="APPRBYPOS"."ROW_ID"(+))
      74 - access("S_ORDER"."ACCNT_ID"="ACCNT"."ROW_ID"(+))
      76 - access("POSOWNERORG"."OU_ID"="OWNORG1"."ROW_ID"(+))
      78 - access("OWNORG1"."PAR_BU_ID"="OWNORG"."ROW_ID"(+))
      80 - access("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID"="ROOTOITEM"."ROW_ID")
      82 - access("S_ORDER_ITEM"."PAR_ORDER_ITEM_ID"="PAROITEM"."ROW_ID"(+))
      84 - access("PAROITEM"."PROD_ID"="PARPROD"."ROW_ID"(+))
      86 - access("ROOTOITEM"."PROD_ID"="ROOTPROD"."ROW_ID"(+))
      88 - access("S_ORDER"."BU_ID"="VISORG1"."ROW_ID"(+))
      90 - access("VISORG1"."PAR_BU_ID"="VISORG"."ROW_ID"(+))
    
    132 rows selected.
    Published by: KODS on 13 December 2012 14:11

    Hello

    what the plan for

    SELECT * FROM V_ORDER_ITEM WHERE ROW_ID = :ROW_ID
    

    ?

    If it's the same thing, this means that the optimizer cannot merge the view (in fact, he can't even lower the predicate). Nothing in the view looks like he could have done fusion (such as the use of rownum etc.), so is lack of privilege VIEW MERGE or a bug in the optimizer.

    GRANT MERGE VIEW ON V_ORDER_ITEM try or run the query under the account of the owner of the view and see what happens.

    Best regards
    Nikolai

  • OEM12c: in execution plans, no more links to tables (OEM10g has them)

    in the Plan for SQL, version details tab OEM 10g has hyperlinks to the objects mentioned in the implementation plan.

    OEM10g Plan has hyperlinks.jpg

    It seems not to be the case more in OEM12c:

    OEM12c no more hyperlink to table.jpg

    Does anyone know how to activate the ability to directly open the details page of the objects listed in the execution plans?

    Hello

    This feature has been valuable, but unfortunately has not been set up at EM12c.  If you want to access the Cloud control, once connected to the database, the best way is to click on the schema, database objects and then go to the correct data type to search for the object in question.  If you are looking for information on the object in the execution plan, then the best way to see it is via SQL Monitor if the process has not aged.  If it has, then use SQL statements search, (under the menu Performance/SQL for the database that you are connected) and then do a search for cache, CWA and other, you know you want to watch for the SQLID in question.

    I hope this helps!

    Kevin Pot' wine-Gorman

  • "Execution plan is not available" in OEM.

    Greetings. Try to watch my first Exec Plan here and make the message displayed above in OEM 11 g even executing simple statements like below. I googled this and see only one question without an answer identical to this.

    Thank you!

    explain plan for

    Select * from SCOTT. DEPT;

    Don't know why you're looking for a plan in OEM.

    * Connect to the base of data with the help of sqlplus and wwho and extract the map below;

    SQL > explain plan for select * from SCOTT. DEPT;

    SQL > SELECT * FROM TABLE (dbms_xplan.display);

    * Very easy, set autotrace on and run the query, you will get the plan and statistics;

    SQL > set autotrace

    Syntax: SET AUTOT [RACE] {OFF |} WE | TRACE [ONLY]} [EXP [LAIN]] [[C] STAT]

    SQL > set autotrace on

    SQL > select * from double;

    D

    -

    X

    Execution plan

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

    Hash value of plan: 272002086

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

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

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

    |   0 | SELECT STATEMENT |      |     1.     2.     2 (0) | 00:00:01 |

    |   1.  TABLE ACCESS FULL | DOUBLE |     1.     2.     2 (0) | 00:00:01 |

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

    Statistics

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

    1 recursive calls

    0 db block Gets

    Gets 2 compatible

    0 physical reads

    0 redo size

    522 bytes sent via SQL * Net to client

    523 bytes received via SQL * Net from client

    2 SQL * Net back and forth to and from the client

    0 sorts (memory)

    0 sorts (disk)

    1 rows processed

    HTH,

    Pradeep

  • Confused with SQL query plan numbers

    Hi all

    I'm on Oracle 11.2 "Standard Edition" under Windows.

    Here is a simple query plan and the predicate shown after the plan. I'm a little confused by the numbers indicated on the plan and not able to understand why the index is not used. The query is generated from Cognos front end, I captured using dbms_xplan.display_cursor (when the query was actually being run).

    SQL > select * from table (dbms_xplan.display_cursor ('& sqlid', 0));

    Enter the value of sqlid: 8yd0uu78jzqpg

    old 1: select * from table (dbms_xplan.display_cursor ('& sqlid', 0))

    new 1: select * from table (dbms_xplan.display_cursor('8yd0uu78jzqpg',0))

    PLAN_TABLE_OUTPUT

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

    SQL_ID, 8yd0uu78jzqpg, number of children 0

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

    Select distinct CASE WHEN (CASE WHEN ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" IS "

    NULL NULL) THEN ELSE ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" | " -") END IS NULL)"

    OR ("MY_TRANSACTION_TABLE3". ("' EMP_NM ' IS NULL) THEN NO OTHER (CASE

    WHEN ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" IS NULL), THEN ANOTHER NULL "

    ("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" | " -")

    END | "" MY_TRANSACTION_TABLE3 ". ("" EMP_NM END ")"Officer_Name. "

    'MY_TRANSACTION_TABLE3 '. ' ' NEW_OFFCR_CD ' 'Officer_Code' of

    'FDS_LDN_APLOWNER '. ' ' MY_TRANSACTION_TABLE ' 'MY_TRANSACTION_TABLE3' where

    'MY_TRANSACTION_TABLE3 '. » M » (« A », « E », « U », « F ») et

    'MY_TRANSACTION_TABLE3 '. ' BASE_DT ' =: PQ1 and.

    'MY_TRANSACTION_TABLE3 '. "" NEW_OFFCR_CD "as 'LO %' order by

    'Officer_Code' asc nulls last

    Hash value of plan: 1213358407

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

    | ID | Operation | Name                  | Lines | Bytes | Cost (% CPU). Time |

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

    |   0 | SELECT STATEMENT |                       |       |       | 42146 (100) |          |

    |   1.  UNIQUE FATE |                       |   230.  5750 | 42145 (1) | 00:08:26 |

    |*  2 |   TABLE ACCESS FULL | MY_TRANSACTION_TABLE |  4283.   104K | 42144 (1) | 00:08:26 |

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

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

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

    2 filter (("MY_TRANSACTION_TABLE3". "NEW_OFFCR_CD" AS "% LO %' AND

    'MY_TRANSACTION_TABLE3 '. ' BASE_DT ' =: PQ1 AND.

    INTERNAL_FUNCTION ("MY_TRANSACTION_TABLE3". "M") AND "

    'MY_TRANSACTION_TABLE3 '. (("' NEW_OFFCR_CD ' IS NOT NULL))

    MY_TRANSACTION_TABLE has 1.3 million records. There is an index made up of 4 columns, first column is BASE_DT and none of the other columns is used here in the predicate.

    Questions-

    (1) the number the ROWS column in the plan, I guess it's number of selected records in the query (and not the records read by the query). Fix?

    (2) there is an index on this table from BASE_DT (but other 3 columns in the index are not used). Each base_dt will select approximately 1.3 M. 80000 records why the index is not used?

    (3) the column of time in the plan. Step 1 made by 08:26 minutes and not 2A crossed 08:26 minutes? or steps 1 and 2 together have 08:26 mins?

    Thanks in advance

    1 LINES - shows the no. of rows estimated by the optimizer for this operation. This estimate is made using the table and column statistics (+ a few formulas can be)

    2. with the help of the index is decided by the optimizer based on profit he would get him. Internally, the database comes up with a lot of plan and selects a plan and at low cost. She stated that in light of current statistics rather than index, scanning, beneficial full table scan - so index have not been used.

    3. it is worth cumulative - CBO estimated a total 08:26 minutes - similar to the cost. But this chronology may not be necessarily the actual execution time.

    Read this link: http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf it has almost all the information about the execution plan.

  • 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

  • What is the correct procedure of DMBS_XPLAN for the query execution plan

    Hello.

    We are on Oracle 11.2.0.3 on Linux. I am dev. DBA and we have about 80 developers Java development team. They want to question the execution plan of queries to resolve the sqls. Generally, they use the GUI tools like the toad to see execution plan. I always use the procedure for the following query execution plan:

    
    

    Select * from
    Table (dbms_xplan.display_cursor (null, null, 'allstats + cost'));

    I should suggest that they use this too rather than rely on tools like the toad - because they can show estimated plan and not the actual plan. And to provide a sql, it is best to use the real plan to work with. Do not take account of 'allstats + cost' part in the command above, but my point is: should I ask them of still rely on sqlplus and not the GUI tools and use the command display_cursor package DBMS_XPLAN?

    I will be grateful for suggestions.

    OrauserN

    You must use the DBMS_XPLAN package and functionality.

    The tool used to run the package doesn't matter. A raw request to DISPLAY_CURSOR will run the same server code in any tool including Toad.

    If you rely on other GUI features (for example a "explain plan" button or similar) then you know what this feature of actuall application running under-the-covers.

    My suggestion would be to assess and consider using Oracle free sql developer version 4 because it is not only FREE but also uses the DBMS_XPLAN correctly.

    http://www.Oracle.com/technetwork/developer-tools/SQL-Developer/downloads/index.html?ssSourceSiteId=ocomen

  • What execution plan has been used?

    Hello

    I'm looking for what execution plan has been used for a SQL when it was run as part of batch in the night? 10gr 2 on ASM, 5.8 RHEL 64 bit.

    Best regards

    You use the Enterprise edition?  Are you a license to use the AWR?  If so, assuming that the query ran long enough to be captured in a snapshot of the CWA (which seems likely, if you are asked this question), DBA_HIST_SQL_PLAN will be the information in the plan and DBA_HIST_SQLSTAT will tell you the plan_hash_value (or values) that have been used for a particular SQL_ID in a particular SNAP_ID.  DBA_HIST_SNAPSHOT will tell you what SNAP_ID (or a set of snap_id) matches any time period you are interested in.

    Justin

Maybe you are looking for

  • Name of the motherboard

    Dear HP, HP 3135 MT Pro, I had and I need to know the name of the motherboard that is added to the basic computer. I need to know, because I want to change case. Thank you for your attention.

  • problems with reading card compact flash

    Hey, I recently bought a mac and I have a problem with she read my cards compact flash. I have a 64 GB scan disk card and a canon 5 d mark II camera. I get the error message that disk was bypassed and that the files could not be read. so I can't tran

  • Resolution of Pro - Windows 8.1 update 1 - Lenovo Yoga 2 is not clear

    Hi all Since the 1 Windows 8.1 update, the resolution of my Yoga isn't really clear. Some screenshots to show the problem: http://hpics.Li/d671deb http://hpics.Li/e500b70 Does anyone have the same problem or a solution? Thank you.

  • tab control event link

    I'm working on a program which requires me to bind two different tab controls.  I tried to implement a case of the event, but I don't know how to get it to link page 1 control 1 to page control 1 2, page 2 of control 1 control 2 2 page, etc...  Any h

  • Toshiba satellite m70 drivers audio xp

    lost sound in a clean, what drivers are compatible?