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/

Tags: Database

Similar Questions

  • Plans of multiple executions for the same SQL statement

    Dear experts,

    awrsqrpt. SQL shows several plans for a single SQL statement executions. How is it possible that a single SQL statement will be several Plans of executions within the AWR report.

    Here is the output of the awrsqrpt for your reference.

    WORKLOAD REPOSITORY SQL Report
    
    Snapshot Period Summary
    
    DB Name         DB Id    Instance     Inst Num Release     RAC Host
    ------------ ----------- ------------ -------- ----------- --- ------------
    TESTDB          2157605839 TESTDB1               1 10.2.0.3.0  YES testhost1
    
                  Snap Id      Snap Time      Sessions Curs/Sess
                --------- ------------------- -------- ---------
    Begin Snap:     32541 11-Oct-08 21:00:13       248     141.1
      End Snap:     32542 11-Oct-08 21:15:06       245     143.4
       Elapsed:               14.88 (mins)
       DB Time:               12.18 (mins)
    
    SQL Summary                            DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    
                    Elapsed
       SQL Id      Time (ms)
    ------------- ----------
    51szt7b736bmg     25,131
    Module: SQL*Plus
    UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(ACCT_DR_BAL,
    0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND TEST_ACC_NB = ACCT_ACC_NB(+)) WHERE
     TEST_BATCH_DT = (:B1 )
    
              -------------------------------------------------------------
    
    SQL ID: 51szt7b736bmg                  DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    -> 1st Capture and Last Capture Snap IDs
       refer to Snapshot IDs witin the snapshot range
    -> UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(AC...
    
        Plan Hash           Total Elapsed                 1st Capture   Last Capture
    #   Value                    Time(ms)    Executions       Snap ID        Snap ID
    --- ---------------- ---------------- ------------- ------------- --------------
    1   2960830398                 25,131             1         32542          32542
    2   3834848140                      0             0         32542          32542
              -------------------------------------------------------------
    
    
    Plan 1(PHV: 2960830398)
    -----------------------
    
    Plan Statistics                        DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
    
    Stat Name                                Statement   Per Execution % Snap
    ---------------------------------------- ---------- -------------- -------
    Elapsed Time (ms)                            25,131       25,130.7     3.4
    CPU Time (ms)                                23,270       23,270.2     3.9
    Executions                                        1            N/A     N/A
    Buffer Gets                               2,626,166    2,626,166.0    14.6
    Disk Reads                                      305          305.0     0.3
    Parse Calls                                       1            1.0     0.0
    Rows                                        371,735      371,735.0     N/A
    User I/O Wait Time (ms)                         564            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                 26            N/A     N/A
              -------------------------------------------------------------
    
    Execution Plan
    ------------------------------------------------------------------------------------------------
    | Id  | Operation                    | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------------
    |   0 | UPDATE STATEMENT             |                 |       |       |  1110 (100)|          |
    |   1 |  UPDATE                      | TEST            |       |       |            |          |
    |   2 |   TABLE ACCESS FULL          | TEST            |   116K|  2740K|  1110   (2)| 00:00:14 |
    |   3 |   TABLE ACCESS BY INDEX ROWID| ACCT            |     1 |    26 |     5   (0)| 00:00:01 |
    |   4 |    INDEX RANGE SCAN          | ACCT_DT_ACC_IDX |     1 |       |     4   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------------
    
    
    
    
    Plan 2(PHV: 3834848140)
    -----------------------
    
    Plan Statistics                        DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
    
    Stat Name                                Statement   Per Execution % Snap
    ---------------------------------------- ---------- -------------- -------
    Elapsed Time (ms)                                 0            N/A     0.0
    CPU Time (ms)                                     0            N/A     0.0
    Executions                                        0            N/A     N/A
    Buffer Gets                                       0            N/A     0.0
    Disk Reads                                        0            N/A     0.0
    Parse Calls                                       0            N/A     0.0
    Rows                                              0            N/A     N/A
    User I/O Wait Time (ms)                           0            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                 26            N/A     N/A
              -------------------------------------------------------------
    
    Execution Plan
    ---------------------------------------------------------------------------------------------
    | Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------------
    |   0 | UPDATE STATEMENT             |              |       |       |     2 (100)|          |
    |   1 |  UPDATE                      | TEST         |       |       |            |          |
    |   2 |   TABLE ACCESS BY INDEX ROWID| TEST         |     1 |    28 |     2   (0)| 00:00:01 |
    |   3 |    INDEX RANGE SCAN          | TEST_DT_IND  |     1 |       |     1   (0)| 00:00:01 |
    |   4 |   TABLE ACCESS BY INDEX ROWID| ACCT         |     1 |    26 |     4   (0)| 00:00:01 |
    |   5 |    INDEX RANGE SCAN          | INDX_ACCT_DT |     1 |       |     3   (0)| 00:00:01 |
    ---------------------------------------------------------------------------------------------
    
    
    
    Full SQL Text
    
    SQL ID       SQL Text
    ------------ -----------------------------------------------------------------
    51szt7b736bm UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL, 0) +
                  NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND PB
                 RN_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 )
    Your contribution is very much appreciated.

    Thank you for taking your time to answer my question.


    Concerning

    Oracle Lover3 wrote:
    How will I know (from Plan 1 and Plan 2) whose execution plan chose for the current run?

    Since you're already on 10.2, you can identify the actual execution plan by checking in V$ SESSION SQL_ID and SQL_CHILD_NUMBER column. This can be used to identify the plan in V$ SQL_PLAN (columns SQL_ID and CHILD_NUMBER) and in 10g, you can use the convenient DBMS_XPLAN. Function DISPLAY_CURSOR for the information of the real plan using these two parameters.

    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/

  • NPL of multiple execution for the awr sql_id

    Hi Experts,

    NPL of multiple execution for the AWR sql_id,

    I followed questions

    1. What plan using opimizer tcurrently?
    2. make sure optimizer to choose good plans


    SQL > select * from table (dbms_xplan.display_awr ('fb0p0xv370vmb'));

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    SQL_ID fb0p0xv370vmb
    --------------------

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Hash value of plan: 417907468

    ---------------------------------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time |
    ---------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 63353 (100) |
    | 1. UPDATE |
    | 2. SORT ORDER BY | 17133. 2978K | 3136K | 63353 (1) | 00:14:47 |
    | 3. HASH JOIN RIGHT SEMI | 17133. 2978K | 62933 (1) | 00:14:42 |
    | 4. COLLECTION ITERATOR PICKLER FETCH | |
    | 5. HASH JOIN RIGHT SEMI | 68530 | 11 M | 62897 (1) | 00:14:41 |

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    | 6. VIEW | VW_NSO_1 | 5000 | 35000 | 33087 (1) | 00:07:44 |
    | 7. COUNTY STOPKEY |
    | 8. VIEW | 127K | 868K | 33087 (1) | 00:07:44 |
    | 9. GROUP SORT BY STOPKEY | 127K | 2233K | 46 M | 33087 (1) | 00:07:44 |
    | 10. TABLE ACCESS FULL | ASYNCH_REQUEST | 1741K | 29 M | 29795 (1) | 00:06:58 |
    | 11. TABLE ACCESS FULL | ASYNCH_REQUEST | 1741K | 280 M | 29801 (1) | 00:06:58 |
    ---------------------------------------------------------------------------------------------------------------

    SQL_ID fb0p0xv370vmb
    --------------------
    SELECT ASYNCH_REQUEST_ID, REQUEST_STATUS, REQUEST_TYPE, REQUEST_DATA, PRIORITY, SUBMIT_BY, SUBMIT_DATE.

    Hash value of plan: 2912273206

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

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    --------------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 45078 (100) |
    | 1. UPDATE |
    | 2. SORT ORDER BY | 1323. 257K | 45078 (1) | 00:10:32 |
    | 3. TABLE ACCESS BY INDEX ROWID | ASYNCH_REQUEST | 1. 190. 3 (0) | 00:00:01 |
    | 4. NESTED LOOPS | 1323. 257K | 45077 (1) | 00:10:32 |
    | 5. THE CARTESIAN MERGE JOIN. 5000 | 45000 | 30069 (1) | 00:07:01 |
    | 6. UNIQUE FATE |
    | 7. COLLECTION ITERATOR PICKLER FETCH | |
    | 8. KIND OF BUFFER. 5000 | 35000 | 30034 (1) | 00:07:01 |
    | 9. VIEW | VW_NSO_1 | 5000 | 35000 | 30033 (1) | 00:07:01 |

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    | 10. UNIQUE FATE | 5000 | 35000 |
    | 11. COUNTY STOPKEY |
    | 12. VIEW | 81330 | 555K | 30033 (1) | 00:07:01 |
    | 13. GROUP SORT BY STOPKEY | 81330 | 1 429 K | 2384K | 30033 (1) | 00:07:01 |
    | 14. TABLE ACCESS FULL | ASYNCH_REQUEST | 86092 | 1513K | 29731 (1) | 00:06:57 |
    | 15. INDEX RANGE SCAN | ASYNCH_REQUEST_SUB_IDX | 1 | | | 1 (0) | 00:00:01 |
    --------------------------------------------------------------------------------------------------------------------------

    Hash value of plan: 3618200564

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

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    --------------------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 59630 (100) |
    | 1. UPDATE |
    | 2. SORT ORDER BY | 4474 | 777K | 59630 (1) | 00:13:55 |
    | 3. HASH JOIN RIGHT SEMI | 4474 | 777K | 59629 (1) | 00:13:55 |
    | 4. VIEW | VW_NSO_1 | 5000 | 35000 | 30450 (1) | 00:07:07 |
    | 5. COUNTY STOPKEY |
    | 6. VIEW | 79526 | 543K | 30450 (1) | 00:07:07 |
    | 7. GROUP SORT BY STOPKEY | 79526 | 1397K | 7824K | 30450 (1) | 00:07:07 |
    | 8. TABLE ACCESS FULL | ASYNCH_REQUEST | 284K | 5003K | 29804 (1) | 00:06:58 |
    | 9. TABLE ACCESS BY INDEX ROWID | ASYNCH_REQUEST | 71156 | 11 M | 29141 (1) | 00:06:48 |

    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    | 10. NESTED LOOPS | 71156 | 11 M | 29177 (1) | 00:06:49 |
    | 11. UNIQUE FATE |
    | 12. COLLECTION ITERATOR PICKLER FETCH | |
    | 13. INDEX RANGE SCAN | ASYNCH_REQUEST_EFFECTIVE_IDX | 327K | | 392 (1) | 00:00:06 |
    --------------------------------------------------------------------------------------------------------------------------------

    Thank you
    -Raj

    Published by: tt0008 on August 22, 2012 20:34

    Hello

    (1) you can see what plan has been used lately by running this query:

    select begin_interval_time, plan_hash_value
    from dba_hist_sqlstat st,
            dba_hist_snapshot sn
    where st.snap_id = sn.snap_id
    and sql_id = 'fb0p0xv370vmb'
    order by begin_interval_time desc;
    

    However, there is no guarantee that the next time you run this query, the latest plan will be chosen.
    Periodically, the plan is regenerated (for example when new statistics are collected, is the structure of a table referenced in)
    the query is changed etc.), and you can get 4 plans, or even a new function of many factors
    (statistics, bind variable values, the optimizer, NLS etc settings settings.)

    (2) this question is too large for the answer to fit into a thread, there are books written on the subject. The short answer is:
    If you know which of the 4 plans is right for you, then you can use a stored outline to lock in (it seems that you are not on 11g so SQL Profiler are not an option for you).
    Or you can try to find out why the optimizer generates different plans and address the underlying issue (the most common reason is to bind peeking - but to say
    course, we need to know more, starting with the text of your query).

    Best regards
    Nikolai

  • Execution plan will change if I use the variable binding instead of the literal value?

    Hi guys,.

    Suppose I have a select "... Of... WHERE ID = 2 and... "if I go to use the variable binding instead of the literal value 2," SELECT... " Of... WHERE ID =: p_id and... ", the execution plan change?
    I test multiple statements, the plan does not change, but I don't know if it would even as well as in some other cases.
    Someone at - it ideas?

    Thank you very much.

    Anneso wrote:
    Hi, sorry for the unclear post, it's 11 GR 2.

    As Sybrand already mentioned, there are a lot of change that came in the implementation of the bind variable in some versions of Oracle db. Since you're on 112, it is still true with the introduction of Adaptive Cursor Sharing . Please have a read on it since the post below written by the development of Oracle optimizer group.
    http://blogs.Oracle.com/optimizer/entry/why_are_there_more_cursors_in_11g_for_my_query_containing_bind_variables_1

    Aman...

  • Change of particular execution plan

    Hi all

    Oracle Version: 10.2.0.4

    Below mentioned query runs fine when only a single value is passed for the paragraph, but chooses to full table scan whenever multiple values is passed to IN would adopt.


    Could someone help me please know why the execution plan changes just passing multiple values IN the clause...

    Published by: Yasu on March 18, 2011 12:07
    and c.orgid(+)=o.orgid
    and o.orgid > 4
    

    OuterJoin on ORGID is not sensible if you apply a filter of ORGID greaterthan 4 also.
    The OuterJoin returns that value the NULL and NULL for ORGID would fail the filter.

    Hemant K Collette

  • 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

  • 12 c parallel execution Plans

    Hello world

    I have a little a problem of performance on 12 c that gives me a little trouble at the head. I moved from 11 to 12 databases and no amendment of the application have been made. Our requests are generated somewhat dynamically, so that they are the same thing every time.

    Let's start with the execution plan I get:

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


    PLAN_TABLE_OUTPUT

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

    Hash value of plan: 3567104424

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

    | ID | Operation                                            | Name                  | Lines | Bytes | Cost (% CPU). Time |    TQ | IN-OUT | PQ Distrib.

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

    |   0 | SELECT STATEMENT |                       |    55.  7095 |  3764 (1) | 00:00:01 |        |      |            |

    |   1.  COORDINATOR OF PX |                       |       |       |            |          |        |      |            |

    |   2.   PX SEND QC (ORDER). : TQ10006 |    55.  7095 |  3764 (1) | 00:00:01 |  Q1, 06 | P > S | QC (ORDER).

    |   3.    SORT ORDER BY |                       |    55.  7095 |  3764 (1) | 00:00:01 |  Q1, 06 | SVCP |            |

    |   4.     PX RECEIVE                                       |                       |    55.  7095 |  3763 (1) | 00:00:01 |  Q1, 06 | SVCP |            |

    |   5.      RANGE OF SEND PX | : TQ10005 |    55.  7095 |  3763 (1) | 00:00:01 |  Q1, 05 | P > P | RANGE |

    |   6.       UNIQUE FATE |                       |    55.  7095 |  3763 (1) | 00:00:01 |  Q1, 05 | SVCP |            |

    |*  7 |        HASH JOIN                                     |                       |    55.  7095 |  3762 (1) | 00:00:01 |  Q1, 05 | SVCP |            |

    |   8.         PX RECEIVE                                   |                       |   801 | 50463 |  3696 (1) | 00:00:01 |  Q1, 05 | SVCP |            |

    |   9.          PX SEND HASH | : TQ10003 |   801 | 50463 |  3696 (1) | 00:00:01 |  Q1, 03 | P > P | HASH |

    | * 10 |           HASH JOIN                                  |                       |   801 | 50463 |  3696 (1) | 00:00:01 |  Q1, 03 | SVCP |            |

    |  11.            RECEIVE PX |                       |   801 | 40851 |  2333 (1) | 00:00:01 |  Q1, 03 | SVCP |            |

    |  12.             PX SEND BROADCAST | : TQ10002 |   801 | 40851 |  2333 (1) | 00:00:01 |  Q1, 02 | P > P | BROADCAST |

    |  13.              NESTED LOOPS |                       |   801 | 40851 |  2333 (1) | 00:00:01 |  Q1, 02 | SVCP |            |

    |  14.               KIND OF BUFFER.                       |       |       |            |          |  Q1, 02 | ISSUE |            |

    |  15.                RECEIVE PX |                       |       |       |            |          |  Q1, 02 | SVCP |            |

    |  16.                 PX SEND HASH | : TQ10000 |       |       |            |          |        | S > P | HASH |

    |  17.                  NESTED LOOPS |                       |   823. 31274 |  1509 (1) | 00:00:01 |        |      |            |

    | * 18.                   TABLE ACCESS BY ROWID INDEX BATCH | PAGED_LOOKUP_PKS |   500 |  9500 |     3 (0) | 00:00:01 |        |      |            |

    | * 19.                    INDEX RANGE SCAN | PAGED_LOOKUP_PKS_IDX2 |     1.       |     2 (0) | 00:00:01 |        |      |            |

    |  20.                   TABLE ACCESS BY ROWID INDEX BATCH | BILL_ITEM |     2.    38.     4 (0) | 00:00:01 |        |      |            |

    | * 21.                    INDEX RANGE SCAN | BILL_ITEM_FK2 |     4.       |     2 (0) | 00:00:01 |        |      |            |

    | * 22.               INDEX UNIQUE SCAN | PK_INSERTION |     1.    13.     1 (0) | 00:00:01 |  Q1, 02 | SVCP |            |

    |  23.            ITERATOR BLOCK PX |                       |  1548K |    17 M |  1353 (2) | 00:00:01 |  Q1, 03 | ISSUE |            |

    |  24.             FULL RESTRICTED INDEX SCAN FAST | BOOKING_ACCOUNT_1 |  1548K |    17 M |  1353 (2) | 00:00:01 |  Q1, 03 | SVCP |            |

    |  25.         PX RECEIVE                                   |                       | 22037 |  1420K |    65 (2) | 00:00:01 |  Q1, 05 | SVCP |            |

    |  26.          PX SEND HASH | : TQ10004 | 22037 |  1420K |    65 (2) | 00:00:01 |  Q1, 04 | S > P | HASH |

    |  27.           SELECTOR PX |                       |       |       |            |          |  Q1, 04 | SCWC |            |

    |  28.            TABLE ACCESS FULL | CONTACT | 22037 |  1420K |    65 (2) | 00:00:01 |  Q1, 04 | SCWP |            |

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

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

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

    7 - access ("ACCOUNT_ID" ="ACCOUNT_ID")

    10 - access ("BOOKING" ="BOOKING")

    18 - filter("T1".") SEQUENCE_NO' < 501 AND "T1". ("' SEQUENCE_NO" > = 1).

    19 - access("T1".") SESSION_ID '= 123456 AND 'T1'.' SEARCH_ID "= 25)

    21 - access("T1".") N1 "=" BILL_ID")

    22 - access ("BOOKING" = "BOOKING" AND "INSERTION_SET" = "INSERTION_SET" AND "INSERT"="INSERT")

    Note

    -----

    -the dynamic statistics used: dynamic sampling (level = 2)

    -This is an adaptation plan

    -2 directives Plan Sql used for this statement

    51 selected lines.

    Elapsed time: 00:00:00.15

    SQL > spool off

    OK, now let's go through the problem:

    1. It's a development running on a virtual server, and which hosts a few other databases, so the parallel execution is not a good thing. parallel_degree_policy is set to MANUAL, parallel_max_servers and all other parallel_ limits are set to 1 and tables have been changed with the settings of NOPARALLEL. So why is the execution plan always generated with all stages of parallel execution? I don't seem to get rid of in 12 c
    2. Next mystery is that the said plan of the explain command is an adaptation plan, and yet I put the true optimizer_adaptive_reproting_only
    3. Now to the problem of effective enforcement, so I'm playing around with all these settings. The query runs for 3-4 seconds, returning around about 500 cases. However, in some cases this same query with the same input variable races for hours and if I can believe the AWR and ASH reports, read a good 180 GB of data. The main wait event is direct path read temp temp and writing.


    This is not isolated to that one query. I have a few queries now that all display the same behavior, one of them running overnight. I don't seem to get to a standard nested loop execution plans.


    The entire base is a database plug-in and I don't know I just missed something in the new features Guide.

    Would appreciate some ideas.

    Thank you

    If you want to disable parallel execution, you must set parallel_max_servers to zero.  Maybe the optimizer thinks he can use a parallel plan because parallel_max_servers is non-zero (even though the number of slaves available means that it will be serialized to a parallel plan).

    Note that you have a ticket saying dynamic stats have been used.  Maybe you have a 11 for optimizer_dynamic_sampling setting, and allowing Oracle to be very inventive with collection of samples and parallelism.

    You have also 2 SQL instructions in game. These are the things that get associated with objects rather than the instructions, then perhaps someone has been playing with parallelism and managed to associate the parallelism with one of the tables in your query (I am not sure 100% that it is possible, just throw a suggestion).  Take a look at the SQL used for education guidelines.

    To give us a little more information, you can:

    Shoot memory execution plan dbms_xplan.display_cursor ({sql_id}, {number of children}, 'ALL'));

    We show all the parallel settings (see setting the parallel)

    Pull on the parameters of the optimizer for query memory (select name, value of V$ sql_optimizer_env where sql_id = {your sql identifier} and child_number = {your child number})

    Concerning

    Jonathan Lewis

  • Execution Plan change

    Hello world

    I have this recommendation in Enterprise Manager, I would like to implement the first recommendation where there is a best execution plan that comes with the benefit of 99.7%. Its easy to implement using Enterprise manager by clicking just. But I would like to know how I can change execution plan using sqlplus. And if I want to return to the original plan, how can I do? Thank you in advance for your precious time really appreciate it.

    recommendation.png

    Yes, you can restore it-here, you will...

    http://docs.Oracle.com/CD/B28359_01/server.111/b28274/sql_tune.htm#CHDIDBBG

  • 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

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

  • Why I have two different execution plans for the same query on two different servers

    Hello everyone.

    I need your help to solve the problem quickly.

    In a nutshell, we have two servers that have the same version of Oracle RDBMS (11.2.0.4 EE). One of them for purposes of development and another is a production one.

    We have therefore two different execution plans for the same query executed on both servers. The only case of execution is OK and another is too slow.

    So I have to slow down the work of query using the same scheme to explain that young.

    Fence wire.

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

  • Version 12: Same SQL, another scheme == &gt; 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.

  • Newbie. SELECT with Clause: bad execution plan.

    Hello

    1)

    SQL> WITH CTATEL AS
      2  (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO
      3  FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C
      4  WHERE B.CTA_FACTURAC=A.CTA_FACTURAC
      5  AND C.NUM_TELEFONO=A.NUM_TELEFONO)
      6  SELECT 71, A.CTA_FACTURAC, B.NUM_TELEFONO, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E'
      7  FROM SOL_FICHERO a, CTATEL b
      8  WHERE ID_SOLICITUD=71
      9  AND A.CTA_FACTURAC=B.CTA_FACTURAC
     10  AND (A.NUM_TELEFONO IS NULL OR (A.NUM_TELEFONO <> '0' AND B.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO=B.NUM_TELEFONO))
     11  AND A.COD_CONFACTU IS NOT NULL AND  EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU);
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 711563975
    
    ---------------------------------------------------------------------------------------------------
    | Id  | Operation                       | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                |                 |     1 |    64 |     6   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS                   |                 |     1 |    64 |     6   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS                  |                 |     1 |    54 |     5   (0)| 00:00:01 |
    |   3 |    NESTED LOOPS                 |                 |     1 |    45 |     4   (0)| 00:00:01 |
    |   4 |     NESTED LOOPS SEMI           |                 |     1 |    26 |     2   (0)| 00:00:01 |
    |*  5 |      TABLE ACCESS BY INDEX ROWID| SOL_FICHERO     |     2 |    44 |     2   (0)| 00:00:01 |
    |*  6 |       INDEX RANGE SCAN          | SOL_FICHERO_I01 |     6 |       |     1   (0)| 00:00:01 |
    |*  7 |      INDEX UNIQUE SCAN          | PK_CONFACTU     |  5820 | 23280 |     0   (0)| 00:00:01 |
    |*  8 |     INDEX RANGE SCAN            | PK_CONTABON     |     1 |    19 |     2   (0)| 00:00:01 |
    |*  9 |    INDEX UNIQUE SCAN            | PK_CTAFACTU     |     1 |     9 |     1   (0)| 00:00:01 |
    |* 10 |   INDEX UNIQUE SCAN             | PK_ABONOS       |     1 |    10 |     1   (0)| 00:00:01 |
    ---------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       5 - filter("A"."COD_CONFACTU" IS NOT NULL)
       6 - access("ID_SOLICITUD"=71)
       7 - access("COD_CONFACTU"="A"."COD_CONFACTU")
       8 - access("A"."CTA_FACTURAC"="A"."CTA_FACTURAC")
           filter("A"."NUM_TELEFONO" IS NULL OR "A"."NUM_TELEFONO"="A"."NUM_TELEFONO" AND
                  "A"."NUM_TELEFONO"<>'0')
       9 - access("B"."CTA_FACTURAC"="A"."CTA_FACTURAC")
      10 - access("C"."NUM_TELEFONO"="A"."NUM_TELEFONO")
    
    
    

    2)

    SQL> WITH CTATEL AS
      2  (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO
      3  FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C
      4  WHERE B.CTA_FACTURAC=A.CTA_FACTURAC
      5  AND C.NUM_TELEFONO=A.NUM_TELEFONO)
      6  SELECT 71, A.CTA_FACTURAC, NULL, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E'
      7  FROM SOL_FICHERO a
      8  WHERE ID_SOLICITUD=71
      9  AND A.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO='0'
     10  AND EXISTS (SELECT 1 FROM CTATEL b WHERE A.CTA_FACTURAC=B.CTA_FACTURAC)
     11  AND A.COD_CONFACTU IS NOT NULL AND  EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU);
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 3992598922
    
    -------------------------------------------------------------------------------------------------
    | Id  | Operation                     | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
    -------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT              |                 |     1 |    26 |     7   (0)| 00:00:01 |
    |*  1 |  FILTER                       |                 |       |       |            |          |
    |   2 |   NESTED LOOPS SEMI           |                 |     1 |    26 |     2   (0)| 00:00:01 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID| SOL_FICHERO     |     1 |    22 |     2   (0)| 00:00:01 |
    |*  4 |     INDEX RANGE SCAN          | SOL_FICHERO_I01 |     6 |       |     1   (0)| 00:00:01 |
    |*  5 |    INDEX UNIQUE SCAN          | PK_CONFACTU     |  5820 | 23280 |     0   (0)| 00:00:01 |
    |   6 |   NESTED LOOPS                |                 |     1 |    38 |     5   (0)| 00:00:01 |
    |   7 |    NESTED LOOPS               |                 |     1 |    28 |     4   (0)| 00:00:01 |
    |*  8 |     INDEX UNIQUE SCAN         | PK_CTAFACTU     |     1 |     9 |     2   (0)| 00:00:01 |
    |*  9 |     INDEX RANGE SCAN          | PK_CONTABON     |     1 |    19 |     2   (0)| 00:00:01 |
    |* 10 |    INDEX UNIQUE SCAN          | PK_ABONOS       |     1 |    10 |     1   (0)| 00:00:01 |
    -------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       1 - filter( EXISTS (SELECT /*+ */ 0 FROM "FACTMS"."PGA_ABONOS_1"
                  "C","FACTMS"."PGA_CTAFACTU" "B","FACTMS"."PFA_CONTABON_1" "A" WHERE
                  "B"."CTA_FACTURAC"="A"."CTA_FACTURAC" AND "A"."CTA_FACTURAC"=:B1 AND
                  "B"."CTA_FACTURAC"=:B2 AND "C"."NUM_TELEFONO"="A"."NUM_TELEFONO"))
       3 - filter("A"."COD_CONFACTU" IS NOT NULL AND "A"."NUM_TELEFONO" IS NOT NULL AND
                  "A"."NUM_TELEFONO"='0')
       4 - access("ID_SOLICITUD"=71)
       5 - access("COD_CONFACTU"="A"."COD_CONFACTU")
       8 - access("B"."CTA_FACTURAC"=:B1)
       9 - access("B"."CTA_FACTURAC"="A"."CTA_FACTURAC")
           filter("A"."CTA_FACTURAC"=:B1)
      10 - access("C"."NUM_TELEFONO"="A"."NUM_TELEFONO")
    

    3)

      1  WITH CTATEL AS
      2  (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO
      3  FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C
      4  WHERE B.CTA_FACTURAC=A.CTA_FACTURAC
      5  AND C.NUM_TELEFONO=A.NUM_TELEFONO)
      6  SELECT 71, A.CTA_FACTURAC, B.NUM_TELEFONO, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E'
      7  FROM SOL_FICHERO a, CTATEL b
      8  WHERE ID_SOLICITUD=71
      9  AND A.CTA_FACTURAC=B.CTA_FACTURAC
     10  AND (A.NUM_TELEFONO IS NULL OR (A.NUM_TELEFONO <> '0' AND B.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO=B.NUM_TELEFONO))
     11  AND A.COD_CONFACTU IS NOT NULL AND  EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU)
     12  UNION ALL
     13  SELECT 71, A.CTA_FACTURAC, NULL, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E'
     14  FROM SOL_FICHERO a
     15  WHERE ID_SOLICITUD=71
     16  AND A.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO='0'
     17  AND EXISTS (SELECT 1 FROM CTATEL b WHERE A.CTA_FACTURAC=B.CTA_FACTURAC)
     18* AND A.COD_CONFACTU IS NOT NULL AND  EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU)
    
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 3945970136
    
    -----------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                       | Name                        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    -----------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                |                             |  3351 |   127K|       |   776  (53)| 00:00:10 |
    |   1 |  TEMP TABLE TRANSFORMATION      |                             |       |       |       |            |          |
    |   2 |   LOAD AS SELECT                |                             |       |       |       |            |          |
    |*  3 |    HASH JOIN                    |                             |   323K|    11M|    12M| 66832   (4)| 00:13:22 |
    |*  4 |     HASH JOIN                   |                             |   338K|  9254K|  4176K| 39353   (3)| 00:07:53 |
    |   5 |      INDEX FAST FULL SCAN       | PK_CTAFACTU                 |   203K|  1788K|       |   190   (4)| 00:00:03 |
    |   6 |      INDEX FAST FULL SCAN       | PK_CONTABON                 |    16M|   300M|       | 13975   (4)| 00:02:48 |
    |   7 |     INDEX FAST FULL SCAN        | PK_ABONOS                   |    15M|   150M|       |  9766   (5)| 00:01:58 |
    |   8 |   UNION-ALL                     |                             |       |       |       |            |          |
    |*  9 |    HASH JOIN                    |                             |  3350 |   127K|       |   388   (5)| 00:00:05 |
    |  10 |     NESTED LOOPS SEMI           |                             |     1 |    26 |       |     2   (0)| 00:00:01 |
    |* 11 |      TABLE ACCESS BY INDEX ROWID| SOL_FICHERO                 |     2 |    44 |       |     2   (0)| 00:00:01 |
    |* 12 |       INDEX RANGE SCAN          | SOL_FICHERO_I01             |     6 |       |       |     1   (0)| 00:00:01 |
    |* 13 |      INDEX UNIQUE SCAN          | PK_CONFACTU                 |  5820 | 23280 |       |     0   (0)| 00:00:01 |
    |  14 |     VIEW                        |                             |   323K|  4112K|       |   379   (4)| 00:00:05 |
    |  15 |      TABLE ACCESS FULL          | SYS_TEMP_0FD9D6621_1BE166BB |   323K|  6009K|       |   379   (4)| 00:00:05 |
    |* 16 |    HASH JOIN SEMI               |                             |     1 |    33 |       |   388   (5)| 00:00:05 |
    |  17 |     NESTED LOOPS SEMI           |                             |     1 |    26 |       |     2   (0)| 00:00:01 |
    |* 18 |      TABLE ACCESS BY INDEX ROWID| SOL_FICHERO                 |     1 |    22 |       |     2   (0)| 00:00:01 |
    |* 19 |       INDEX RANGE SCAN          | SOL_FICHERO_I01             |     6 |       |       |     1   (0)| 00:00:01 |
    |* 20 |      INDEX UNIQUE SCAN          | PK_CONFACTU                 |  5820 | 23280 |       |     0   (0)| 00:00:01 |
    |  21 |     VIEW                        |                             |   323K|  2214K|       |   379   (4)| 00:00:05 |
    |  22 |      TABLE ACCESS FULL          | SYS_TEMP_0FD9D6621_1BE166BB |   323K|  6009K|       |   379   (4)| 00:00:05 |
    -----------------------------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       3 - access("C"."NUM_TELEFONO"="A"."NUM_TELEFONO")
       4 - access("B"."CTA_FACTURAC"="A"."CTA_FACTURAC")
       9 - access("A"."CTA_FACTURAC"="B"."CTA_FACTURAC")
           filter("A"."NUM_TELEFONO" IS NULL OR "A"."NUM_TELEFONO"="B"."NUM_TELEFONO" AND "A"."NUM_TELEFONO"<>'0')
      11 - filter("A"."COD_CONFACTU" IS NOT NULL)
      12 - access("ID_SOLICITUD"=71)
      13 - access("COD_CONFACTU"="A"."COD_CONFACTU")
      16 - access("A"."CTA_FACTURAC"="B"."CTA_FACTURAC")
      18 - filter("A"."COD_CONFACTU" IS NOT NULL AND "A"."NUM_TELEFONO" IS NOT NULL AND "A"."NUM_TELEFONO"='0')
      19 - access("ID_SOLICITUD"=71)
      20 - access("COD_CONFACTU"="A"."COD_CONFACTU")
    

    I use this WITH clausule in the query above:

    operating system

    WITH CTATEL AS 
    (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO 
    FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C 
    WHERE B.CTA_FACTURAC=A.CTA_FACTURAC 
    AND C.NUM_TELEFONO=A.NUM_TELEFONO) 
    

    Why 3) plan is so bad? (In any case, it's like "UNION ALL" of 1) and 2).

    Thanks in advance,

    Jose Luis

    We do not know if one of them is 'bad' plans.

    In fact, there is no such thing as a bad plan, one or several inaccurate estimates.

    To determine whether a plan is 'bad', you really see who believes are inaccurate - and which means the time of execution of the execution plans and runtime enforcement measures.

    Please take a look at the notice in the following thread:

    HOW to: Validate a query of SQL statement tuning - model showing

    What happens in the third SQL, is that because you referenced the subquery WITH twice, Oracle decides to materialise it in a temporary table for the reason that it is cheaper that to do the same thing one subquery normally twice - a reasonable approach.

    It is probably more likely that the third query estimates are more accurate than the other two.

  • How to pass multiple work plans in illustrator?

    Looks like a pretty common thing and obvious a user to do, select and move multiple work plans, again for the life of me I don't see a way to do it.

    Am I missing something?

    Thank you!

    I don't think so. I agree, it is a no-brainer, but I does not offer this feature.

    You can read here workarounds:

    How can I move easily several plans of work in Illustrator? -Graphic design change battery

    In essence, creating rectangles then ' convert to ' plans work in mode 'Work Plan' may be the best option. Then, you can simply delete your original artboard (s).

Maybe you are looking for

  • How do you get the most recent backup that always has this app on it?

    My 2 years has removed an application in the course of the past week. He regularly plays with my phone, so I have no idea when he managed to do so. I do iCloud backups every night and have this updated app to make backups as well. Is there a way to c

  • Upgrade SSD in Portege Z930 - 14 c

    Hello I think upgradidng my ssd 128 GB stocks to a larger 250 GB model. I'm not sure of the type of ssd used in the machine that want to get the right size etc so can clone my disk and doa replacement right. Nobody knows the type of disc and how simp

  • Inspiron 14 3443 a40 can't pair Bluetooth earpiece/headset

    Hello I have a portable I14-3443-a40 with bluetooth (Dell Wireless 1705) and I'm trying to link my Sony BTN200 headset, but windows doesn't show any device bluetooth devices. The headset works fine, I can pair it with my android phone and the ipad. I

  • use the windows key 8 to activate windows 7

    As I bought a windows original 8 and I do not use it, is it possible to use the windows button 8 to activate windows 7? How can I do?

  • Lightroom on PC - Photoshop in the clouds

    Because I travel in remote areas where internet access is unavailable or very expensive, I like to keep my licensed copy of Lightroom 6 on my PC.  I would also like to add Photoshop to my photo editing by purchasing the CC option.  Can I keep my Ligh