Explain the explain plan

decide to move to optimization soon. Book says join faster that the subquery in this example because the analyses involved. The "cost" to the subquery appears lower than the cost for the join. So it is confusing to me - aka How should I be interpreting this.

Plan of subquery:

image2.png.jpg

join plan

image2.png.jpg

as you can see that the plan for the subquery has less than a cost. Could someone explain these outputs as to which application is more effective. I need to start somewhere.

Thank you!

The BEST way to get help when you ask questions is:

1 ask questions on SPECIFIC things

2. tell us EXACTLY what term, value, etc. ask abaout

Book says join faster that the subquery in this example because the analyses involved. The "cost" to the subquery appears lower than the cost for the join. So it is confusing to me - aka How should I be interpreting this.

OK - what BOOK are you talking about? There is not much interest to mention a book if you're not going to tell us which book it and provide a link to it and even a page number. This gives us the SCOPE of your question.

This "cost for the subquery" are you talking about? Be specifc. It is in one of the plans that you posted? What plan? Whose cost is it? For example, you could say:

I have a question for the foreground below. Why is the cost to the xx line lower than the cost of the second plan on line AA?

This question refers CLEARLY to the info we're talking. The way in which you stating the question, we try to guess what plan and the lines you want to say.

subquery plan:


join plan


as you can see the subquery plan has less of a cost. Could someone explain from these outputs as to which query is more efficient. I need to start from somewhere.

Are you talking about line #1 in each of these plans?

Please edit your post and tell us EXACTLY what you ask in the topic and refer to values and SPECIFIC lines. Also post a link to the book and a reference to a page number you got the information from.

The optimizer generally chooses the REAL implementation with the lowest cost plan. It is not clear whether the plans that you have posted are ACTUAL spending plans that Oracle really determined and used or just explain plans.for what Oracle thought it might use.

If the statistics are not up-to-date these plans do not yet reflect the reality of the data.

And if the amount of data is a small number of blocks or other of these plans can run better than the other in reality.

You can find this Oracle white paper "Explain the Plan explaining" useful

http://www.Oracle.com/technetwork/database/bi-Datawarehousing/TWP-explain-the-explain-plan-052011-393674.PDF

Tags: Database

Similar Questions

  • explain the in9i plan

    Hello

    on 9.2.0.4 under Unix.

    is it possible to import a plan for a query to explain from a (9.2.0.2) database to another (9.2.0.4)?

    Thank you.

    Difference is that the statistics of optimizer based on CSSTidy based on costs are different.

    Objects with the same data can be different segment size, then the execution plan may differ in function.

  • SQL not using indexes at runtime, but by using the index in "explain plan".

    Hi all

    I am facing a problem here that I don't get to think.

    I have a SQL that makes a FULL ACCESS of TABLE into two tables and its costs are very high, but it occurs only when I run it in my program (I saw it in the session trace). If I do a "explain plan" sqlplus (SQL Navigator or PLSQL Developer) it shows that he use indexes and have a low cost. I already checked the statistics from both tables, and they are up to date.

    Did someone never facing a similar problem or knows something I can do to find my problem?

    Thank you all very much.

    Hello

    As far as I KNOW, optimizer Oracle never guarantees that an Index scan in query explain plan will be necessarily used during query execution.

    ORACLE-BASE - DBMS_XPLAN: Oracle display execution Plans

    Could you please read the above, run the query, as described and check the execution using DBMS_XPLAN plan. The cursor cache DISPLAY_CURSOR and not PLAN_TABLEs.

  • How to keep the formatting explain plan made on this forum

    Can you please tell me as a way to preserve the formatting of explain plan made on this forum. I tried to use the '-' tag, but failed.

    \

    PLAN_TABLE_OUTPUT

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

    Hash value of plan: 615168685

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

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

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

    |   0 | SELECT STATEMENT |      |    23.  1242.     7 (15) | 00:00:01 |

    |*  1 |  HASH JOIN |      |    23.  1242.     7 (15) | 00:00:01 |

    |   2.   TABLE ACCESS FULL | DEPT |    13.   234.     3 (0) | 00:00:01 |

    |   3.   TABLE ACCESS FULL | EMP |    23.   828 |     3 (0) | 00:00:01 |

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

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

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

    1 - access("E".") DEPTNO "=" D ". ("' DEPTNO ')

    15 selected lines.

    \

    Go to advanced editor and change the font to a fixed-width font e.g. Courier New

    PLAN_TABLE_OUTPUT

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

    Hash value of plan: 615168685

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

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

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

    |   0 | SELECT STATEMENT |      |    23.  1242.     7 (15) | 00:00:01 |

    |*  1 |  HASH JOIN |      |    23.  1242.     7 (15) | 00:00:01 |

    |   2.   TABLE ACCESS FULL | DEPT |    13.   234.     3 (0) | 00:00:01 |

    |   3.   TABLE ACCESS FULL | EMP |    23.   828 |     3 (0) | 00:00:01 |

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

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

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

    1 - access("E".") DEPTNO "=" D ". ("' DEPTNO ')

    15 selected lines.

  • Interpret the Explain Plan command

    Hi guys,.

    I traced the command explain for a query plan and the plan is as below.

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

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

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

    |   0 | SELECT STATEMENT |                      |     1.  1482 |    12 (17) | 00:00:01 |

    |   1.  SORT ORDER BY |                      |     1.  1482 |    12 (17) | 00:00:01 |

    |   2.   UNIQUE HASH |                      |     1.  1482 |    11 (10) | 00:00:01 |

    |   3.    NESTED EXTERNAL LOOPS |                      |    44. 65208 |    10 (0) | 00:00:01 |

    |   4.     NESTED EXTERNAL LOOPS |                      |     2.  2952 |     8 (0) | 00:00:01 |

    |   5.      NESTED EXTERNAL LOOPS |                      |     2.  2940.     7 (0) | 00:00:01 |

    |   6.       NESTED EXTERNAL LOOPS |                      |     1.  1458 |     6 (0). 00:00:01 |

    |   8 S        NESTED EXTERNAL LOOPS |                      |     1.  1419.     5 (0) | 00:00:01 |

    |   8.         NESTED EXTERNAL LOOPS |                      |     1.  1331.     4 (0) | 00:00:01 |

    |   9.          NESTED EXTERNAL LOOPS |                      |     1.  1266.     3 (0) | 00:00:01 |

    |  10.           NESTED EXTERNAL LOOPS |                      |     1.  1250 |     2 (0) | 00:00:01 |

    | * 11 |            TABLE ACCESS BY INDEX ROWID | PERSPECTIVE |     1.  1236.     1 (0) | 00:00:01 |

    | * 12 |             INDEX RANGE SCAN | I08_PROSPECT |     1.       |     1 (0) | 00:00:01 |

    |  13.            TABLE ACCESS BY INDEX ROWID | REGION |     1.    14.     1 (0) | 00:00:01 |

    | * 14 |             INDEX RANGE SCAN | PK_REGION |     1.       |     1 (0) | 00:00:01 |

    |  15.           TABLE ACCESS BY INDEX ROWID | BANK                 |     1.    16.     1 (0) | 00:00:01 |

    | * 16.            INDEX UNIQUE SCAN | PK_BANK |     1.       |     1 (0) | 00:00:01 |

    |  17.          TABLE ACCESS BY INDEX ROWID | USERS |     1.    65.     1 (0) | 00:00:01 |

    | * 18.           INDEX UNIQUE SCAN | PK_USERS |     1.       |     1 (0) | 00:00:01 |

    |  19.         TABLE ACCESS BY INDEX ROWID | PROSPECT_ADDRESS |     1.    88.     1 (0) | 00:00:01 |

    | * 20.          INDEX RANGE SCAN | I02_PROSPECT_ADDRESS |     1.       |     1 (0) | 00:00:01 |

    | * 21.        TABLE ACCESS BY INDEX ROWID | SUBSCRIPTION_TYPE |     1.    39.     1 (0) | 00:00:01 |

    | * 22.         INDEX UNIQUE SCAN | PK_ADDRESS_TYPE |     1.       |     1 (0) | 00:00:01 |

    |  23.       TABLE ACCESS BY INDEX ROWID | REFERENCE |     2.    24.     1 (0) | 00:00:01 |

    | * 24.        INDEX RANGE SCAN | U01_REFERRAL |     2.       |     1 (0) | 00:00:01 |

    | * 25.      INDEX UNIQUE SCAN | PK_LOCATION_CODES |     1.     6.     1 (0) | 00:00:01 |

    | * 26.     INDEX SCAN FULL | U01_USER_LOCATION |    23.   138.     1 (0) | 00:00:01 |

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

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

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

    11 - filter("TPPRO1".") IS_DELETED' IS NULL OR "TPPRO1". "IS_DELETED"= U 'N')

    12 - access("TPPRO1".") CUSTOMER_ID "= U '000900000000000000000000122202')

    14 - access("TPREG1".") REGION_ID' (+) = "TPPRO1". ("' REGION_ID")

    16 - access("TPBA1".") BANK_ID' (+) = "TPPRO1". ("' BANK_ID")

    18 - access("TPUS21".") USER_ID' (+) = "TPPRO1". ("' CREATED_BY ')

    20 - access("TPPRO1".") PROSPECT_ID "= 'TPPRAD1'." PROSPECT_ID "(+))"

    21 - filter("TPADTY1".") ADDR_TYPE_NAME "(+) = U 'Primary')

    22 - access("TPPRAD1".") ADDR_TYPE_ID "= 'TPADTY1'." ADDR_TYPE_ID "(+))"

    24 - access("TPRE1".") PROSPECT_ID' (+) = "TPPRO1". ("' PROSPECT_ID")

    25 - access("TPLOCO1".") LOCATION_CODE_ID' (+) = "TPRE1". ("' LOCATION_LIMIT")

    26 - access("TPLOCO1".") LOCATION_CODE_ID "= 'TPUSLO1'." LOCATION_CODE_ID "(+))"

    filter ("TPLOCO1". "LOCATION_CODE_ID"= 'TPUSLO1'." LOCATION_CODE_ID "(+))"

    So while interpreting, I can understand the first step is 12 and the second stage is 14, but there is no relationship between step 12 and 14.

    Here's the sql code

    SELECT

    SEPARATE

    TPPRO1. PROSPECT_ID,

    TPPRO1. PROS_NAME,

    TPPRO1.NET_ADDRESS,

    TPPRO1. DAY_PHONE,

    TPPRO1. NIGHT_PHONE,

    TPPRO1. CONTACT_LOW,

    TPPRO1. CONTACT_HIGH,

    TPPRO1. CREATED_BY,

    TPPRO1. CUSTOMER_ID,

    TPPRO1. CUSTOMER_TYPE,

    TPPRO1. ACCOUNT_NUMBER,

    TPPRO1. MCIF_NUMBER,

    TPPRO1.IS_CUSTOMER,

    TPPRO1. BEST_DAY_TO_CALL,

    TPPRO1. DEFAULT_PRIORITY,

    TPPRO1. PROSPECT_STATUS,

    TPPRO1. FAX_NUMBER,

    TPPRO1.IS_BUSINESS,

    TPPRO1. BANK_ID,

    TPPRO1. REGION_ID,

    TPPRO1. BIRTH_DATE,

    TPPRO1. PRIMARY_LANGUAGE,

    TPPRO1. IDENTIFICATION_NUMBER,

    TPPRO1. EMPLOYER_NAME,

    TPPRO1. FUNCTION,

    TPPRO1. DATE_EMPLOYED,

    TPPRO1. EMPLOYEE_COUNT,

    TPPRO1. NUMBER_OF_LOCATIONS,

    TPPRO1. ESTABLISHED_DATE,

    TPPRO1. INDUSTRY_TYPE,

    TPPRO1. PRIMARY_CONTACT,

    TPPRO1. TIN,

    TPPRO1. FOREIGN_TAX_ID,

    TPPRO1. DATE_CHANGED,

    TPPRO1. RELATIONSHIP_MGR,

    TPPRO1. RELATIONSHIP_MGR_NAME RELATIONSHIP_MGR_USER_NAME,

    TPPRO1. LAST_NA_DONE,

    TPPRO1. TTL_ASSETS,

    TPPRO1. TTL_LIABILITIES,

    TPPRO1. PROFITABILITY_IND,

    TPPRO1. MARITAL_STATUS,

    TPPRO1. GREETING,

    TPPRO1. SIC_CODE,

    TPPRO1. STOCK_SYMBOL,

    TPPRO1. STOCK_EXCHANGE,

    TPPRO1. CURRENCY_TYPE,

    TPPRO1. PHRASE_TYPE,

    TPPRO1. PHRASE_VALUE,

    TPPRO1. EMPLOYEE_TYPE,

    TPPRO1. BUSINESS_TYPE,

    TPPRO1. CERTIFICATION,

    TPPRO1. GENDER,

    TPPRO1. ANNUAL_INCOME,

    TPPRO1.ID_TYPE,

    TPPRO1.ID_LOCATION,

    TPPRO1. PRIMARY_RESIDENCE,

    TPPRO1. RESIDENCE_DATE,

    TPPRO1. CUSTOMER_SINCE,

    TPPRO1. PRIMARY_BRANCH,

    TPPRO1. SERVICE_LEVEL_ID,

    TPPRO1. SERVICE_LEVEL_DESCRIPTION,

    TPPRO1. DO_NOT_SHARE,

    TPUS21. USER_NAME,

    TPUS21. FIRST NAME,

    TPUS21. MIDDLE_INITIAL,

    TPUS21. LAST_NAME,

    TPBA1. BANK_CODE,

    TPREG1. REGION_CODE,

    TPPRO1.IS_QUALIFIED,

    TPPRO1. QUALIFIED_TRACKING_NBR,

    TPPRO1. QUALIFIED_DEBIT_LIMIT,

    TPPRO1. QUALIFIED_LOC_LIMIT,

    TPPRO1. QUALIFIED_CARD,

    TPPRO1. QUALIFIED_DATE,

    TPPRO1. QUALIFIED_BY,

    TPPRO1. QUALIFIED_BY_NAME,

    TPPRO1. DAILY_LIMIT,

    TPPRO1. LINE_OF_CREDIT,

    TPPRO1. HOUSEHOLD_ID,

    TPPRO1. MARKET_SEGMENT,

    TPPRO1. CREDIT_TOLERANCE,

    TPPRO1. RISK_TOLERANCE,

    TPPRO1. CREDIT_RATING,

    TPPRO1. CREDIT_RATING_DATE,

    TPPRO1. WEBSITE_ADDRESS,

    TPPRO1. HOME_VALUE,

    TPPRO1. CENSUS_TRACT,

    TPPRO1. HOUSEHOLD_COUNT,

    TPPRO1. DUNS_NUMBER,

    TPPRO1. QUALIFIED_LENDING_DATE,

    TPPRO1. HOUSEHOLD_POSITION,

    TPPRO1. FS_REVIEW_DATE,

    TPPRO1. FISCAL_YEAR_END,

    TPPRO1. FS_DATE,

    TPPRO1. GRADE_DESCRIPTION,

    TPPRO1. HOME_OWNER_FLAG,

    TPPRO1.COMMERCIAL_RATING,

    TPPRO1. NAIC_RATING,

    TPPRO1. LTD_RATING_MOODY,

    TPPRO1. LTD_RATING_DUN,

    TPPRO1. LTD_RATING_SP,

    TPPRO1. INC_STATE,

    TPPRO1. POSITIVE_CREDIT_RPT,

    TPPRO1. ULTIMATE_DUNS,

    TPPRO1. PARENT_DUNS,

    TPPRO1. SECOND_SIC_CODE,

    TPPRO1. THIRD_SIC_CODE,

    TPPRO1. CUSTOMER_SEGMENT,

    TPPRO1. RELATIONSHIP_MGR_NAME2,

    TPPRO1. DEBT_WORTH_RATIO,

    TPPRO1. CASH_FLOW,

    TPPRO1. DEBT_SERVICE,

    TPPRO1. DEBT_INCOME_RATIO,

    TPPRO1.NET_WORTH,

    TPPRO1. FS_RPT_FREQUENCY,

    TPPRO1. SHAREHOLDERS_QUANTITY,

    TPPRO1. FS_LAG_TIME,

    TPPRO1. ULT_RELATIONSHIP_MGR,

    TPPRO1. CORP_TAX_RATE,

    TPPRO1. RISK_GRADE,

    TPPRO1. ULT_PROSPECT_ID,

    TPPRO1. PARENT_PROSPECT_ID,

    TPPRO1. EARNINGS_CREDIT_RATE,

    TPPRO1. First name assignedUserFirstName,

    TPPRO1. AssignedUserLastName last_name,

    TPPRO1. MIDDLE_NAME assignedMiddleUser,

    TPPRO1. SUFFIX,

    TPPRO1. PREFIX,

    TPPRO1. ULT_RELATIONSHIP_MGR_NAME,

    TPPRO1. ANNUAL_INCOME_CCODE,

    TPPRO1. CASH_FLOW_CCODE,

    TPPRO1.NET_WORTH_CCODE,

    TPPRO1. TTL_ASSETS_CCODE,

    TPPRO1. TTL_LIABILITIES_CCODE,

    TPPRO1. QUALIFIED_DEBIT_LIMIT_CCODE,

    TPPRO1. QUALIFIED_LOC_LIMIT_CCODE,

    TPPRO1. DAILY_LIMIT_CCODE,

    TPPRO1. LINE_OF_CREDIT_CCODE,

    TPPRO1. HOME_VALUE_CCODE,

    TPPRO1. ACCT_TYPE,

    TPPRO1. BUSINESS_STATE,

    TPPRO1. BUSINESS_COUNTY,

    TPPRO1.IS_FAX_ACCEPTED,

    TPPRO1.IS_OWNER,

    TPPRO1.IS_OFFICER,

    TPPRO1. LAST_CONTACT_DATE,

    TPPRO1. CITIZENSHIP_COUNTRY,

    TPPRO1. OCCUPATION,

    TPPRO1. LEGAL_DESIGNATION,

    TPPRO1. BUSINESS_NATURE,

    TPPRO1. INDUSTRY_TYPE_CODE,

    TPPRO1. INDUSTRY_TYPE_CODE_DESC,

    TPPRO1. PRIMARY_DATE_ISSUED,

    TPPRO1. PRIMARY_DATE_EXPIRED,

    TPPRO1. PRIMARY_ID_OTHER_INFO,

    TPPRO1. SEC_ID_OTHER_INFO,

    TPPRO1. QUALIFIED_LOC_LIMIT_CCODE,

    TPPRO1. SEC_ID_TYPE,

    TPPRO1. SEC_ID_LOCATION,

    TPPRO1. SEC_ID_NUMBER,

    TPPRO1. SEC_DATE_ISSUED,

    TPPRO1. SEC_DATE_EXPIRED,

    TPPRO1. THD_ID_TYPE,

    TPPRO1. THD_ID_LOCATION,

    TPPRO1. THD_ID_NUMBER,

    TPPRO1. THD_DATE_EXPIRED,

    TPPRO1. THD_DATE_ISSUED,

    TPPRO1. TIN_TYPE,

    TPPRO1.IS_VERIFIED,

    TPPRO1. VERIFIED_BY,

    TPPRO1. VERIFIED_BY_NAME,

    TPPRO1. VERIFIED_DATE,

    TPPRO1. QUALIFY_STRATEGY_TYPE,

    TPPRO1. INC_COUNTRY,

    TPPRO1. COUNTRY_OF_PRINCI_OFF,

    TPPRO1. OED_INSTITUTION,

    TPPRO1. VERIFY_FAILED_REASON,

    TPPRO1. QUALIFY_TYPE,

    TPPRAD1. CITY,

    TPPRAD1. ADDRESS_LINE1,

    TPPRAD1. ADDRESS_LINE2,

    TPPRAD1. ADDRESS_LINE3,

    TPPRAD1. ADDRESS_LINE4,

    TPPRAD1. STATE_PROVINCE,

    TPPRAD1. ZIP_CODE,

    TPPRAD1. COUNTRIES,

    TPPRAD1.IS_DOMESTIC,

    TPADTY1. ADDR_TYPE_ID,

    TPADTY1. ADDR_TYPE_NAME,

    TPADTY1. ADDR_TYPE_DESC,

    TPPRO1. VERIFY_FAILED_REASON,

    TPPRO1. QUALIFY_TYPE

    Of

    PERSPECTIVE TPPRO1

    LEFT OUTER JOIN

    PROSPECT_ADDRESS TPPRAD1

    ON TPPRO1. PROSPECT_ID = TPPRAD1. PROSPECT_ID

    LEFT OUTER JOIN

    SUBSCRIPTION_TYPE TPADTY1

    WE

    (Tpprad1.Addr_Type_Id = Tpadty1.Addr_Type_Id) And

    (TPADTY1. ADDR_TYPE_NAME = "Primary")

    LEFT OUTER JOIN

    USERS TPUS21

    ON TPUS21. USER_ID = TPPRO1. CREATED_BY

    LEFT OUTER JOIN

    REFERENCE TPRE1

    ON TPRE1. PROSPECT_ID = TPPRO1. PROSPECT_ID

    LEFT OUTER JOIN

    LOCATION_CODES TPLOCO1

    ON TPLOCO1. LOCATION_CODE_ID = TPRE1. LOCATION_LIMIT

    LEFT OUTER JOIN

    USER_LOCATION TPUSLO1

    ON TPLOCO1. LOCATION_CODE_ID = TPUSLO1. LOCATION_CODE_ID

    LEFT OUTER JOIN

    BANK TPBA1

    ON TPBA1. BANK_ID = TPPRO1. BANK_ID

    LEFT OUTER JOIN

    TPREG1 REGION

    ON TPREG1. REGION_ID = TPPRO1. REGION_ID

    Where

    ((TPPRO1.IS_DELETED = ' N ') OR)

    (((Tppro1.Is_Deleted) is nothing)) And

    AND (TPPRO1. CUSTOMER_ID = '000900000000000000000000122202')

    ORDER OF TPPRO1. PROSPECT_ID;

    Can someone explain to me the steps of the execution plan.

    Please share thoughts and ideas.

    Kind regards

    Ranjan

    Hello Rodriguez

    There is no problem with this execution plan:

    The order of execution is as follows - grouped by NL for you that you can see how it is run.

    NL (1): 12, 11, 10, 13, 14

    NL (2): 16, 15, 9

    NL (3): 18, 17: 8

    NL (4): 20, 19: 7

    NL (5): 22, 21: 6

    NL (6): 24, 23, 5

    NL (7): 25, 4

    NL (8): 26, 3

    2, 1, 0

    Unique hash = to SEPARATE sorting algorithm (it's a performanter we of the (Unique) fate)

    I hope that helps!

  • good performance in the long plan Explain.

    Hello

    on 11.2.0.3 for a query, I have more explain plan that sounds great, but when it is executed by an application it does not end.

    She's waiting on db file scattered read. Thanks for your ideas.


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

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

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

    |   0 | INSERT STATEMENT.                   |     1.   427.     2 (0) | 00:00:01 |

    |   1.  LOAD TABLE CLASSIC | PS_PC_RT_RUN_TA24 |       |       |            |          |

    |*  2 |   FILTER |                   |       |       |            |          |

    |   3.    TABLE ACCESS BY INDEX ROWID | PS_PRT_PRICE4 |     1.   427.     0 (0) | 00:00:01 |

    |*  4 |     INDEX RANGE SCAN | PSAPRT_PRICE4 |     1.       |     0 (0) | 00:00:01 |

    |*  5 |    TABLE ACCESS FULL | PS_PC_RT_RUN_TA24 |     1.    57.     2 (0) | 00:00:01 |

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

    Name of the query block / Alias object (identified by the operation identity card):

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

    1 SALT$ 1

    3 SALT$ 1 / PRT@SEL$1

    4 SALT$ 1 / PRT@SEL$1

    5 SALT$ 2 / A@SEL$2

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

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

    2 filter (NOT EXISTS (SELECT 0 'A' where 'PS_PC_RT_RUN_TA24'))

    "A"." BUSINESS_UNIT ' =: B1 AND 'A'. '. PROJECT "=: B2 AND 'A'". "" ACTIVITY_ID "=: B3 AND.

    "A"." RESOURCE_ID "=: B4 AND 'A'". "" PROCESS_INSTANCE "(=2690469))"

    4 - access("PRT".") PROCESS_INSTANCE "= 2690469).

    5 - filter("A".") BUSINESS_UNIT ' =: B1 AND 'A'. '. PROJECT "=: B2 AND 'A'". "" ACTIVITY_ID "=: B3.

    AND 'A '. "RESOURCE_ID" =: B4 AND 'A' "." " PROCESS_INSTANCE "= 2690469).

    SQL > show parameter optimizer

    VALUE OF TYPE NAME

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

    OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES boolean FALSE

    optimizer_dynamic_sampling integer 2

    optimizer_features_enable string 11.2.0.3

    optimizer_index_caching integer 0

    OPTIMIZER_INDEX_COST_ADJ integer 100

    the string ALL_ROWS optimizer_mode

    optimizer_secure_view_merging Boolean TRUE

    optimizer_use_invisible_indexes boolean FALSE

    optimizer_use_pending_statistics boolean FALSE

    optimizer_use_sql_plan_baselines boolean TRUE

    OK and what about the other issues? Are the stats accurate? In addition, application version/bundle you are on? Have you had a glance on My Oracle Support, apparently, there are a lot of perf. question on EI.

    I'm not really expert FSCM, maybe these tables is completed only when the AE run, otherwise empty (is PS_PC_RT_RUN_TA24 not a temp table?). And Oracle could collect its stats when it was empty. So it could be totally bad positioning.

    You can add a step before that a guilty just to gather statistics on the tables involved in this insert statement (probably not with 100% rating, but start with 10).

    I remember of a workaround on a similar behavior on the Payroll when we needed to lock the stats on the tables (with more accurate values actually) avoiding to be replaced by 0 outside EI run.

    Nicolas.

  • explain plan for the same query diff

    Hi experts,

    Please, help me understand explain the plan.  I have tow Server (server and two server). The server are same table, even the type of database, even version Oracle (gr 11 (2), same operating system (linux Redhat 5.5) and same table and index.

    but when I explain the plan for the same query on the two server. I got diff--diff to explain the plan. reason it has different, according to my understanding, it should be same. explain please, I share the explain plan and lower indices for the two server.

    Server a

    SQL > col COLUMN_NAME format a20

    SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.

    INDEX_NAME COLUMN_NAME POSITION_COLONNE

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

    DATE_IND1_S LOANDATETIME 1

    IND_MSI_LN_LNS1_S MSISDN 1

    IND_MSI_LN_LNS1_S LOANDATETIME 2

    IND_MSI_LN_LNS1_S LOANSTATUS 3

    LAST_INDEX L_INDX_MSISDN_S 1

    MSISDN L_INDX_MSISDN_S 2

    SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status

    2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.

    3 union

    4. Select 'Local' ind_type, index_name, nom_partition, status

    5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')

    6 order of 1,2,3;

    IND_TYPE INDEX_NAME NOM_PARTITION STATUS

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

    Global DATE_IND1_S VALID

    Global IND_MSI_LN_LNS1_S VALID

    Global L_INDX_MSISDN_S VALID

    SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;

    He explained.

    SQL > SQL > set line 200

    @?/rdbms/admin/utlxpls.sql

    SQL >

    PLAN_TABLE_OUTPUT

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

    Hash value of plan: 3659874059

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

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

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

    |   0 | SELECT STATEMENT |                            |  1448K |    58 M | 21973 (2) | 00:04:24 |       |       |

    |*  1 |  FILTER |                            |       |       |            |          |       |       |

    |   2.   PARTITION LIST ALL |                            |  1448K |    58 M | 21973 (2) | 00:04:24 |     1.    11.

    |*  3 |    TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH |  1448K |    58 M | 21973 (2) | 00:04:24 |     1.    11.

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

    PLAN_TABLE_OUTPUT

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

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

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

    1 - filter(SYSDATE@!-2>SYSDATE@!-15)

    3 - filter("LOANTYPE"=1 AND "LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)

    16 selected lines.

    Second server

    SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.

    INDEX_NAME COLUMN_NAME POSITION_COLONNE

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

    DATE_IND1_S LOANDATETIME 1

    IND_MSI_LN_LNS1_S MSISDN 1

    IND_MSI_LN_LNS1_S LOANDATETIME 2

    IND_MSI_LN_LNS1_S LOANSTATUS 3

    LAST_INDEX L_INDX_MSISDN_S 1

    MSISDN L_INDX_MSISDN_S 2

    SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status

    2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.

    Union

    3 4 Select 'Local' ind_type, index_name, nom_partition, status

    5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')

    6 order of 1,2,3;

    IND_TYPE INDEX_NAME NOM_PARTITION STATUS

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

    Global DATE_IND1_S VALID

    Global IND_MSI_LN_LNS1_S VALID

    Global L_INDX_MSISDN_S VALID

    SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;

    SQL > set line 200

    @?/rdbms/admin/utlxpls.sql

    SQL >

    PLAN_TABLE_OUTPUT

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

    Hash value of plan: 1161680601

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

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

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

    |   0 | SELECT STATEMENT |                            |     2.    84.     5 (0) | 00:00:01 |       |       |

    |*  1 |  FILTER                             |                            |       |       |            |          |       |       |

    |*  2 |   TABLE ACCESS BY INDEX ROWID | LOAN_RUNNING_DETAILS_SOUTH |     2.    84.     5 (0) | 00:00:01 | ROWID | ROWID |

    |*  3 |    INDEX RANGE SCAN | DATE_IND1_S |     2.       |     3 (0) | 00:00:01 |       |       |

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

    PLAN_TABLE_OUTPUT

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

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

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

    1 - filter(SYSDATE@!-2>SYSDATE@!-15)

    2 - filter ("LOANTYPE" = 1)

    3 - access("LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)

    17 selected lines.

    Reg,

    Hard

    Hi , HemantKChitale,

    I also update statistics manual as you say, but not see 'TABLE ACCESS FULL' good result

    What should I do? my need of production tuning, but I cannot able tune this...

    SQL > exec dbms_stats.gather_table_stats (-online 'ttt' ownname, tabname => 'LOAN_RUNNING_DETAILS_SOUTH', cascade => TRUE, estimate_percent => NULL, method_opt => 'for all columns size 254', => of degree 4);

    PL/SQL procedure successfully completed.

    SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME<=sysdate-2 and="" loandatetime="">sysdate-15 and LOANTYPE = 1;

    He explained.

    SQL > set line 200

    @?/rdbms/admin/utlxpls.sql

    SQL >

    PLAN_TABLE_OUTPUT

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

    Hash value of plan: 3659874059

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

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

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

    |   0 | SELECT STATEMENT |                            |  1874K |    75 M | 19626 (2) | 00:03:56 |       |       |

    |*  1 |  FILTER |                            |       |       |            |          |       |       |

    |   2.   PARTITION LIST ALL |                            |  1874K |    75 M | 19626 (2) | 00:03:56 |     1.    11.

    |*  3 |    TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH |  1874K |    75 M | 19626 (2) | 00:03:56 |     1.    11.

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

    PLAN_TABLE_OUTPUT

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

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

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

    1 - filter(SYSDATE@!-2>SYSDATE@!-15)

    3 - filter("LOANDATETIME">SYSDATE@!-15 AND "LOANTYPE"=1 AND "LOANDATETIME")<>

    16 selected lines.

  • Explain the different Plans

    Hello

    in 11.2.0.3 the same query on two different DBs (on the same server) have different explain Plans (differnet number of rows returned 9690K vs M 14):

    DBDEV:

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

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

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

    |   0 | INSERT STATEMENT.                  |  9690K |  4482M |   344K (1) | 01:08:49 |

    |   1.  LOAD TABLE CLASSIC | PS_PROJ_RES_TA14 |       |       |            |          |

    |*  2 |   TABLE ACCESS FULL | PS_PROJ_RESOURCE |  9690K |  4482M |   344K (1) | 01:08:49 |

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

    DBTST

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

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

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

    |   0 | INSERT STATEMENT.                  |    14 M |  6534M |   344K (1) | 01:08:50 |

    |   1.  LOAD TABLE CLASSIC | PS_PROJ_RES_TA14 |       |       |            |          |

    |*  2 |   TABLE ACCESS FULL | PS_PROJ_RESOURCE |    14 M |  6534M |   344K (1) | 01:08:50 |

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

    The optimizer settings are the same:

    VALUE OF TYPE NAME

    optimizer_capture_sql_plan_baselines boolean FALSE

    optimizer_dynamic_sampling integer 2

    optimizer_features_enable string 11.2.0.3

    optimizer_index_caching integer 0

    OPTIMIZER_INDEX_COST_ADJ integer 100

    the string ALL_ROWS optimizer_mode

    optimizer_secure_view_merging boolean TRUE

    optimizer_use_invisible_indexes boolean FALSE

    optimizer_use_pending_statistics boolean FALSE

    Boolean optimizer_use_sql_plan_baselines TRUE

    And the number of lines:

    In DBTST

    Select Count (*) from ps_proj_resource

    COUNT(*)

    --------

    18072893

    In DBDEV

    COUNT(*)

    --------

    18070581

    Thanks for the explanation and ideas.

    Hello

    Yes will not change the plan to explain it, but the number of rows must / may change in the case otherwise we must understand why the number of rows returned is so different (14 M against 9M) with almost the same number of rows in the PS_PROJ_RESOURCE table.

    Thank you and best regards.

  • difference between the execution plan and explain the plan?

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

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

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

  • To the topic to explain the query Plan

    Hello

    I have a question about the explain plan command. While gather us statistics and optimize, then choose the best possible plan out the plans explain command available. If we collect statistics on a table for a long time while the system choose:

    Whether it will continue to use the same plan, since it uses at startup when statistics have been collected, or will change the plan as soon as dml activities and statistics grow old.

    Thank you
    GK

    Gulshan says:
    Hello

    I have a question about the explain plan command. While gather us statistics and optimize, then choose the best possible plan out the plans explain command available. If we collect statistics on a table for a long time while the system choose:

    The same plan he chose to start with previous statistics. The plan will not change automatically as long as you update the statistics.

    Whether it will continue to use the same plan, since it uses at startup when statistics have been collected, or will change the plan as soon as dml activities and statistics grow old.

    The DML will not be able to change the statistics stored in the data dictionary views themselves. There must be a statistic explicit collection that has come to reflect the change in the data dictionary. 10 g from, there is automatically a task (a special 11 g automatic) is there who can detect the change in the ongoing dml on the table and can trigger the table for update statistics.

    Aman...

  • I have the following plan to explain, but I don't know how interperent it

    Hello all;

    I have the explain plan following below obtained pl/sql developer, but I don't know how to interperent or use it for my performance problem
    PLAN_TABLE_OUTPUT          
               
    ----------------------------------------------------------------------------------------          
    | Id  | Operation                       |  Name                | Rows  | Bytes | Cost  |          
    ----------------------------------------------------------------------------------------          
    |   0 | SELECT STATEMENT                |                      |     1 |   108 |   932 |          
    |   1 |  SORT GROUP BY                  |                      |     1 |   108 |   932 |          
    |*  2 |   TABLE ACCESS BY INDEX ROWID   | OPERATION            |     1 |    34 |    12 |          
    |   3 |    NESTED LOOPS                 |                      |     1 |   108 |   929 |          
    |   4 |     NESTED LOOPS                |                      |     1 |    74 |   917 |          
    |*  5 |      HASH JOIN                  |                      |     1 |    60 |   916 |          
    |*  6 |       TABLE ACCESS FULL         | WORK_ORDER           |  1302 | 46872 |   787 |          
    |*  7 |       TABLE ACCESS FULL         | SERIALIZATION_TRACE  |   129K|  3044K|   123 |          
    |*  8 |      TABLE ACCESS BY INDEX ROWID| PART                 |     1 |    14 |     1 |          
    |*  9 |       INDEX UNIQUE SCAN         | SYS_C004302          |     1 |       |       |          
    |* 10 |     INDEX RANGE SCAN            | RCLX_OPERATION_3     |     1 |       |    11 |          
    ----------------------------------------------------------------------------------------          
               
    Predicate Information (identified by operation id):          
    ---------------------------------------------------          
               
       2 - filter("O"."RESOURCE_ID" LIKE 'TEST%')          
       5 - access("W"."BASE_ID"="PT"."WORKORDER_BASE_ID" AND           
                  "W"."LOT_ID"="PT"."WORKORDER_LOT_ID" AND "W"."SPLIT_ID"="PT"."WORKORDER_SPLIT_ID" AND 
                  "W"."SUB_ID"="PT"."WORKORDER_SUB_ID")          
       6 - filter("W"."TYPE"='W' AND "W"."PART_ID" IS NOT NULL AND "W"."PART_ID"<>'RMA' AND           
                  "W"."PART_ID"<>'REWORK' AND "W"."CLOSE_DATE">=TO_DATE('2010-01-01 00:00:00',           
                  'yyyy-mm-dd hh24:mi:ss') AND "W"."CLOSE_DATE"<=TO_DATE('2010-12-31 00:00:00',           
                  'yyyy-mm-dd hh24:mi:ss'))          
       7 - filter("PT"."SERIAL_NUMBER"<>'N/A')          
       8 - filter("P"."PLANNER_USER_ID"='CCA')          
       9 - access("W"."PART_ID"="P"."ID")          
           filter("P"."ID"<>'RMA' AND "P"."ID"<>'REWORK')          
      10 - access("W"."SUB_ID"="O"."WORKORDER_SUB_ID" AND           
                  "W"."BASE_ID"="O"."WORKORDER_BASE_ID" AND "W"."LOT_ID"="O"."WORKORDER_LOT_ID" AND 
                  "W"."SPLIT_ID"="O"."WORKORDER_SPLIT_ID")          
           filter("W"."BASE_ID"="O"."WORKORDER_BASE_ID" AND           
                  "W"."LOT_ID"="O"."WORKORDER_LOT_ID" AND "W"."SPLIT_ID"="O"."WORKORDER_SPLIT_ID")     
               
    Note: cpu costing is off          
              

    Here are a few slides that I use when I present to you how to read explain plans:
    http://www.morganslibrary.org/Pres/lad/cloug_1_xplan.PDF

    |*  6 |        TABLE ACCESS FULL         | WORK_ORDER           |  1302 | 46872 |   787 |
    |*  7 |       TABLE ACCESS FULL         | SERIALIZATION_TRACE  |   129K|  3044K|   123 |
    

    Essentially, your question is here. you read a lot of lines to return alone. Do you need them all? To get them you do full table scan on the two tables? An index would help?

    and yes I am voluntarily is not giving you the answers but rather to point you in the right direction to find it yourself.

    On the one hand, I don't know your version, your SQL, or what indexes exist.

  • DECODE is changing the explain plan

    I have a statement with a decoding function in the where clause like this:
    AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

    Below plans to explain and tkprofs to 1 (no decode) and 2 (decode).

    * explain 1 *.
    {code}
    SQL statement that produced these data:
    Select * from table (dbms_xplan.display)

    PLAN_TABLE_OUTPUT

    ---------------------------------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU).
    ---------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 7080 | 2413K | 43611 (2) |
    | 1. SORT ORDER BY | 7080 | 2413K | 5224K | 43611 (2) |
    |* 2 | FILTER |
    |* 3 | HASH JOIN | 7156. 2 438 K | 43075 (2) |
    | 4. TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745. 363KO | 83 (0) |
    |* 5 | OUTER HASH JOIN | 7156. 2292K | 42991 (2) |
    |* 6 | HASH JOIN | 7156. 1355K | 42907 (2) |
    |* 7 | HASH JOIN | 6987. 1187K | 19170 (2) |
    |* 8 | HASH JOIN | 6947 | 963K | 10376 (1) |
    |* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3. 144. 3 (0) |
    | 10. NESTED LOOPS | 6907. 897K | 8577 (1) |
    | * 11 | HASH JOIN | 2264 | 187K | 1782 (2) |
    | 12. TABLE ACCESS BY INDEX ROWID | SAMPLE | 190. 4370. 17 (0) |
    | 13. NESTED LOOPS | 2264 | 152K | 107 (1) |
    | 14. NESTED LOOPS | 12. 552. 25 (0) |
    | * 15 | TABLE ACCESS FULL | SDG_USER | 12. 288. 13 (0) |
    | 16. TABLE ACCESS BY INDEX ROWID | SDG | 1. 22. 1 (0) |
    | * 17. INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0) |
    | * 18. INDEX RANGE SCAN | FK_SAMPLE_SDG | 597. 2 (0) |
    | 19. TABLE ACCESS FULL | SAMPLE_USER | 1078K | 16 M | 1669 (1) |
    | * 20. INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0) |
    | 21. TABLE ACCESS FULL | ALIQUOT_USER | 3403K | 29 M | 1781 (3) |
    | 22. TABLE ACCESS FULL | TEST | 3423K | 104 M | 8775 (2) |
    | * 23. TABLE ACCESS FULL | RESULT | 3435K | 65 M | 23718 (2) |
    | 24. VIEW | PLATE | 21787 | 2851K | 84 (2).
    | * 25. FILTER |
    | 26. TABLE ACCESS FULL | PLATE | 21787 | 574K | 84 (2).
    | * 27. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 28. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 29. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 31. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    ---------------------------------------------------------------------------------------------------------------

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

    2. ((«GROUP_ID» EST NULL ou EXISTE (SELECT / * + * / 0 DE "AGIL".) filter)) "OPERATOR_GROUP"
    "OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B1)) AND ('GROUP_ID' IS NULL) "'". "
    OR EXISTS (SELECT / * + * / 0 "LIMS".) ' ' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE
    "OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B2)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * +)) "" "."
    * / 0 "LIMS". "' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "."
    (('GROUP_ID' =: B3)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * + * / 0 "LIMS".)) "" OPERATOR_GROUP ".
    'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B4)))".
    3 - access ("U_ABS_DETERMINATION" ="DETERMINATION_ASSIGNMENT")
    5 - access("PLT".") PLATE_ID"(+) ="PLATE_ID")
    6 - access ("TEST_ID" ="TEST_ID")
    7 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
    8 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
    9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
    11 - access ("SAMPLE_ID" ="SAMPLE_ID")
    15 - filter ("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE" = 'QC' AND
    "U_WEEK_OF_PROCESSING"= TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY' = TO_NUMBER (:YEAR)).
    17 - access ("SDG_ID" ="SDG_ID")
    18 - access ("SDG_ID" ="SDG_ID")
    20 - access ("SAMPLE_ID" ="SAMPLE_ID")
    23 - filter ('NAME' = 'End result')
    25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS".")) OPERATOR_GROUP ".
    'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B1))".
    27 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    28 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    29 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    30 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    31 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())

    Note
    -----
    -"PLAN_TABLE' is old version
    {code}


    * tkprof 1 *.
    {code}

    TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009

    Copyright (c) 1982, 2005, Oracle. All rights reserved.

    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
    Sorting options: by default

    ********************************************************************************
    Count = number of times OIC procedure has been executed
    CPU = time in seconds cpu execution
    elapsed = elapsed time in seconds the execution
    disc = number of physical reads from disk buffers
    Query = number of buffers for a consistent reading
    current = number of buffers in current mode (usually for the update)
    rows = number of rows processed by extracting or execute the call
    ********************************************************************************

    SELECT sdu.u_crop_group,
    SD. Name as sdg_name,
    ad.variety_name,
    ad.batch_number,
    B.SID as aliquot_name,
    Sau.u_box_code as box_code,
    Sau.u_box_position as box_position,
    t.Nom as test_name,
    r.original_result,
    PLT. Name as plate_name,
    Concat (chr (a.plate_row + 64), a.plate_column) as plate_position,
    au.u_replicate_number as replicate_number
    OF lims_sys.sdg sd,.
    lims_sys.sdg_user STO,
    lims_sys. Sample his.
    lims_sys.sample_user sau,
    lims_sys.aliquot has,
    to the lims_sys.aliquot_user,.
    lims_sys.test t,
    lims_sys. Result r,
    PLT lims_sys.plate,
    Ad lims_sys.abs_determination
    WHERE sd.sdg_id = sdu.sdg_id
    AND sd.sdg_id = sa.sdg_id
    AND sa.sample_id = sau.sample_id
    AND sau.sample_id = a.sample_id
    AND a.aliquot_id = au.aliquot_id
    AND au.aliquot_id = t.aliquot_id
    AND t.test_id = r.test_id
    AND plt.plate_id (+) = a.plate_id
    AND sdu.u_abs_determination = ad.determination_assignment
    AND a.status IN ('V', 'P', 'C')
    AND r.name = 'result '.
    AND sdu.u_client_type = "QC".
    AND sdu.u_year_of_sample_delivery = (: year)
    AND sdu.u_week_of_processing = (: week)
    - AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    ORDER BY box_code, box_position, replicate_number

    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 1 0.00 0.00 0 0 0 0
    Run 1 1.15 1.16 0 0 0 0
    Fetch 1 8.53 16.10 227649 241266 0 500
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 3 9.68 17,27 227649 241266 0 500

    Chess in the library during parsing cache: 1
    Lack in the library during execution cache: 1
    Optimizer mode: ALL_ROWS
    The analysis of the user id: 97

    Rows Row Source operation
    ------- ---------------------------------------------------
    SORT ORDER BY 500 (cr = 241266 pr = 227649 pw = time 0 = 16104631 en)
    FILTER 21311 (cr = 241266 pr = 227649 pw = time 0 = 16246749 en)
    21311 HASH JOIN (cr = 241266 pr = 227649 pw = time 0 = 16225434 en)
    17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr = 374 pr = 0 pw = time 0 = 69 fr)
    21311 HASH JOIN RIGHT OUTER (cr = 240892 pr = 227649 pw = time 0 = 16170607 en)
    21895 VIEW PLATE (cr = 316 pr = 0 pw = time 0 = 43825 US)
    21895 FILTER (cr = 316 pr = 0 pw = time 0 = 43823 US)
    21895 TRAY FULL ACCESS (cr = 316 pr = 0 pw = time 0 = 31 US)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    21311 HASH JOIN (cr = 240576 pr = 227649 pw = time 0 = 16106174 en)
    21311 HASH JOIN (cr = 133559 pr 121596 pw = time = 0 = 9594130 en)
    21311 HASH JOIN (cr = 94323 pr = 83281 pw = time 0 = 6917067 en)
    21311 HASH JOIN (cr = 86383 pr 75547 pw = time = 0 = 5509672 en)
    JOIN by HASH 7776 (cr = 8134 pr = 0 pw = time 0 = 285364 en)
    TABLE ACCESS BY INDEX ROWID SAMPLE 7776 (cr = 572 pr = 0 pw = time 0 = 27152 US)
    7876 NESTED LOOPS (cr = 377 pr = 0 pw = time 0 = 488287 en)
    JOIN by HASH 99 (cr = 160 pr = 0 pw = time 0 = US 4168)
    99 TABLE ACCESS FULL SDG_USER (cr = 53 pr = 0 pw = time 0 = US 1209)
    5719 TABLE ACCESS FULL SDG (cr = 107 pr = 0 pw = time 0 = 17 US)
    7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr = 217 pr = 0 pw = time 0 = 623 en)(object id 45990)
    1079741 TABLE ACCESS FULL SAMPLE_USER (cr = 7562 pr = 0 pw = time 0 = 24 US)
    3307948 TABLE ALIQUOT FULL ACCESS (cr = 78249 pr = pw 75547 time = 0 = 3331129 en)
    3406836 TABLE ACCESS FULL ALIQUOT_USER (cr = 7940 pr 7734 pw = time = 0 = 556 en)
    3406832 TABLE TEST FULL ACCESS (cr = 39236 pr 38315 pw = time = 0 = 3413192 en)
    3406832 TABLE ACCESS FULL RESULTS (cr = 107017 pr = 106053 pw = time 0 = 6848487 en)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)

    ********************************************************************************

    Select 'x '.
    Of
    Double


    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 1 0.00 0.00 0 0 0 0
    Run 1 0.00 0.00 0 0 0 0
    Fetch 1 0.00 0.00 0 0 0 1
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 3 0.00 0.00 0 0 0 1

    Chess in the library during parsing cache: 0
    Optimizer mode: ALL_ROWS
    The analysis of the user id: 97

    Rows Row Source operation
    ------- ---------------------------------------------------
    1 DOUBLE QUICK (cr = 0 pr = 0 pw = time 0 = 3 US)

    ********************************************************************************

    Start: id: = sys.dbms_transaction.local_transaction_id; end;


    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 1 0.00 0.00 0 0 0 0
    Run 1 0.00 0.00 0 0 0 1
    Fetch 0 0.00 0.00 0 0 0 0
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 2 0.00 0.00 0 0 0 1

    Chess in the library during parsing cache: 0
    Optimizer mode: ALL_ROWS
    The analysis of the user id: 97



    ********************************************************************************

    TOTALS FOR ALL NON RECURSIVE INSTRUCTIONS

    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 3 0.00 0.00 0 0 0 0
    Run 3 1.15 1.16 0 0 0 1
    Pick 2 8.53 16.10 227649 241266 0 501
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 8 9.68 17,27 227649 241266 0 502

    Chess in the library during parsing cache: 1
    Lack in the library during execution cache: 1


    TOTALS FOR ALL RECURSIVE INSTRUCTIONS

    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 30 0.00 0.00 0 0 0 0
    Run 30 0.00 0.00 0 0 0 0
    Get 30 0.00 0.00 0 40 0 10
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 90 0.00 0.00 0 40 0 10

    Chess in the library during parsing cache: 0

    3 the session user SQL statements.
    30 internal to SQL statements in session.
    33 SQL statements in session.
    ********************************************************************************
    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
    Compatibility of trace files: 10.01.00
    Sorting options: by default

    8 sessions in the trace file.
    3 SQL statements of the user in the trace file.
    30 internal SQL instructions in the trace file.
    33 SQL statements in the trace file.
    6 unique SQL statements in the trace file.
    633 lines in the trace file.
    23 seconds in the trace file.
    {code}

    ZI wrote:
    I have a statement with a decoding function in the where clause like this:

    AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    

    When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

    I would interpret the results displayed differently.

    Execution which took 17 s according to the 241 266 coherent block played tkprof output gets but in order to do so he read 227 649 the disk blocks. Note that most of the table addressed by this query blocks were read through scanning of complete table that can take advantage of multiple blocks readings, for example if you unset the db_file_multiblock_read_count 10.2 (recommended) it usually try to read 1 MB with a read request, which are 128 blocks in case of standard block size 8 k. Due to several reasons not always the full size can be requested with each read request, lets say about 200 000 blocks could have been read by about 2,000 blocks multiple readings. Each read request would turn into a physical read, could you get an estimate approximate 25 MS per read times 2,000 applications-online 50 seconds (your system is running obviously better that the average assumed by ost g 10 base optimizer without collected statistics system workload, can be that some additional file caching system is involved).

    On the other hand, the execution plan that finished within 2 seconds completed 221 420 coherent block gets but did No physical reads at all. Note that most of the table blocks should be processed using one-piece random searches (ACCESS BY ROWID of the TABLE), according to the grouping of the indices factor, it could have been as many blocks that the lines have been returned to the range index scans. So you could have done with lets say more than 60,000 randomly accessed table blocks => until 60 000 monobloc required reading. So in the worst case, this may take 60 000 requests time 10ms by read-online 600 seconds, even if in reality at least some of the blocks will be stored in the buffer cache, so it should be less.

    It would be interesting to know how these two declarations with a cold buffer cache, so that both had to physical reads. I suppose the first is actually faster. Of course, if the second corresponds more to your typical situation that most of the blocks is in the buffer anyway, then it could be faster, because the blocks read by random access are more likely to stay in memory blocks read by complete sweep of the table, but in a true perspective of I/O the first is expected to be higher.

    Moreover, the change in the plan is probably caused by the fact that the additional predicate (DECODING) lowers the cardinality of the table of SDG_USER conduct so that LOOP IMBRIQUEE approach seems to be cheaper to the optimizer that the hash join/full scan table approach. Apparently the estimate is way off (by two orders of magnitude, in fact 100 instead of 1), then the plan is not really cheap, because it seems like the optimizer.

    By the way: two actual execution plans displayed in the output from tkprof are actually different from the displayed output of EXPLAIN the PLAN, so the statement has executed a little differently provided the facility to EXPLAIN the PLAN.

    Your PLAN_TABLE is old, since you are on 10g you should drop any PLAN_TABLEs that are in non - SYS diagrams, since 10 g already provides a global temporary Table as part of the default dictionary (SYS. Plan_table$ presentations via public synonym PLAN_TABLE).

    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/

  • Need to explain Plan output in HTML format

    Hello

    I have details slider sqlid and child. And I'm able to generate explain plan SQL running as below

    SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR('xxxxxxxxxxxxxx',0,'ALLSTATS'));

    I need send the output of this customer. and the problem is the customer wants in HTML format. Advice to reel in HTML format

    concerning

    Pravin

    You can always query the PLAN_TABLE directly, and use SQL * more to empty in HTML.

    Another option is to do this with SQL Developer. Paste the SQL statement into the worksheet, and then press the explain Plan. When you see the plan, right-click on it and choose export as HTML.

    See you soon,.
    Brian

  • Need help with understanding explain plan

    Hi all

    I'm trying to understand the subject of the explain Plan, and while I was reading a document and from there I found one of the query that is below:

    Query

    SELECT A.customer_name,

    Count (distinct b.invoice_id) 'open invoices. "

    Count (c.invoice_id) "open invoice".

    Clients has,

    b invoices,

    c invoices_items

    WHERE b.invoice_status = 'OPEN'

    AND A.customer_id = b.customer_id

    AND c.invoice_id (+) = b.invoice_id

    A.customer_name GROUP

    Explain Plan

    See attached file...

    explain_plan.JPG

    I appreciate if someone explain this attached plan really explain in detail for my purpose of learning. Thanks in advance

    Concerning

    Muzz

    I'm trying to understand the subject of the explain Plan

    Excellent!

    I suggest you just started reading the book of Maria Colgan white "Explain the explain Plan".

    http://www.Oracle.com/technetwork/database/bi-Datawarehousing/TWP-explain-the-explain-plan-052011-393674.PDF

    This white paper examines the different lines, you will see in a plan and what they mean.

  • Explain plan for select distinct

    I got 1 of the online test and there the question has been asked. I have already answered but curious to cross-check my response with your advice...

    Question

    Explain what information plan if the show room in SQL indicates that a separate select statement is made in the SQL.


    The choices are:

    Sort by a join

    b sort by

    c single fate

    d sort aggregate

    group e - sort by

    My answer

    I gave aggregates of SORT but it seems that his unique kind, because when I run explain plan then I see (unique) hash. Please guide


    SEPARATE will identify unique rows. So in the given choice it would be KIND of UNIQUE. But oracle could go other plans as UNIQUE HASH or same INDEX FULL SCAN.

    Look at the oracle does not SORT.

    SQL> select distinct ename from emp;
    ENAME
    ------
    SMITH
    BLAKE
    CLARK
    KING
    ADAMS
    TURNER
    ALLEN
    SCOTT
    JONES
    MARTIN
    WARD
    11 rows selected.
    SQL> select * from table(dbms_xplan.display_cursor);
    PLAN_TABLE_OUTPUT
    ---------------------------------------------------------------------------------
    SQL_ID  6b32yqumjmp9b, child number 0
    -------------------------------------
    select distinct ename from emp
    Plan hash value: 984151148
    ---------------------------------------------------------------------------
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------
    |   0 | SELECT STATEMENT   |      |       |       |     3 (100)|          |
    |   1 |  HASH UNIQUE       |      |    11 |    66 |     3  (34)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| EMP  |    11 |    66 |     2   (0)| 00:00:01 |
    ---------------------------------------------------------------------------
    
    14 rows selected.
    

    Let me make an explicit ORDER BY for her to performa SORT.

    SQL> select distinct ename from emp order by 1;
    ENAME
    ------
    ADAMS
    ALLEN
    BLAKE
    CLARK
    JONES
    KING
    MARTIN
    SCOTT
    SMITH
    TURNER
    WARD
    11 rows selected.
    SQL> select * from table(dbms_xplan.display_cursor);
    PLAN_TABLE_OUTPUT
    -------------------------------------------------------------------------------
    SQL_ID  f72vjx5rmm0z4, child number 0
    -------------------------------------
    select distinct ename from emp order by 1
    Plan hash value: 725351111
    ---------------------------------------------------------------------------
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------
    |   0 | SELECT STATEMENT   |      |       |       |     4 (100)|          |
    |   1 |  SORT UNIQUE       |      |    11 |    66 |     3  (34)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| EMP  |    11 |    66 |     2   (0)| 00:00:01 |
    ---------------------------------------------------------------------------
    
    14 rows selected.
    SQL>
    

    Version - 10.2.0.5.0

Maybe you are looking for