Execution Time & Explain Plan Variations

I have a scenario here. I have 2 schemas; schema1 & schema2. I executed a lengthy SELECT statement of 5 TABLE JOIN in these 2 schemas. I am getting totally different execution time (one runs at 0.3 seconds & the other at 4 seconds) and a different Explain Plan. I assume that, since its the same SELECT statement in these schema, I should get the same Explain Plan. What could be the reason for these dissimilarities? Oracle Version: 9.2.0.8.0. I am ready to share the Explain Plan of these 2 schemas. But they are of length around 300 lines.
Thank you.

There are many factors come in to play here.
1.) Size of all tables involved are same
2.) structures are also same
3.) Also indexes are same
4.) Also stats are up to date on both
5.) Constraints and other factors are also same.
regards
PravinAnd a few more.
6) session environments are the same
7) bind variable values are the same - or were at first execution
I'd change 4 to read Optimizer statistics are the same. (not up to date which is a bit vague).
In short if you are using the CBO and feed in the exact same inputs you will get the exact same plan, however typically you won't get the exact same inputs and so may get a different plan. If your query has a time element and the two queries are hard parsed at different times it may actually be impossible to get the same input - for example the percentage of a table that is returned by a predicate like
timestamp_col > sysdate - 1 will be estimated differently depending on the time of parsing for the same data.
That all said looking at the plans might reveal some obvious differences, though perhaps it might be better to point at a URL that holds the plans given the length you say they are.
Niall Litchfield
http://www.orawin.info/
null

Similar Messages

  • Efficient way to read through big explain plan and genterate html explain plan for sql id's executed in past

    Hi,
    I have a sql which is recently having a performance problems in Production. I have generated a explain plan for it trying to find out what it is doing but plan itself is close to 1000 lines. I want to check if there is any efficient way to go through big plan like this one and quickly find the damaging areas..
    2) I also wanted to know if there is way to generate explain plans in HTML format which executed in past and have entry in dba_hist_sqltext.
    3) I also have two sql_monitor reports which I want to compare. is there any efficient way to do it as well?
    Please share your thoughts!
    Thanks in advance!
    Regards,
    Suman-

    Hi,
    I suggest you can try running sql advisor on the query maybe something fruitful comes up
    http://www.oracle-base.com/articles/11g/sql-access-advisor-11gr1.php
    I am not sure about the explain plan being printed in html format but
    You may also want to try the sqlhistory.sql query from below page
    http://evdbt.com/scripts/
    I have used it many times to check on executions and explain plans which may have changed over the period
    I have faced it many times , the query picks up a bad explain plan and performs poorly

  • Explain plan : need advice in improving performance

    Hi,
    DB : 10.2.0.4
    platform: Solaris
    SGA: 8 G
    one of my query is taking too much time, explain plan gives below output.
    kindly advise what i can do to improve the performance
    PLAN_TABLE_OUTPUT
    Plan hash value: 430877948
    | Id  | Operation                    | Name                          | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |                               |  8143 | 1081K| 31130   (1)| 00:06:14 |
    |*  1 | FILTER | |       |       |            |          |
    |*  2 | TABLE ACCESS BY INDEX ROWID| ID_TICKET_DETAILS             |  8143 | 1081K|   494   (0)| 00:00:06 |
    |*  3 | INDEX SKIP SCAN           | TKT_IDX_21                    |     1 | |   493   (0)| 00:00:06 |
    |*  4 | TABLE ACCESS BY INDEX ROWID| ID_DELIVERY_DEBIT_SLIP_DETAIL |     1 | 34 |     3   (0)| 00:00:01 |
    |   5 | NESTED LOOPS              |                               |     2 | 124 |     7   (0)| 00:00:01 |
    |*  6 | TABLE ACCESS FULL        | ID_DELIVERY_DEBIT_SLIP_HEADER | 32243 | 881K|     2   (0)| 00:00:01 |
    |*  7 | INDEX RANGE SCAN         | DSD_DELIVERY_DEBIT_UKEY       |     1 | |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "ID_DELIVERY_DEBIT_SLIP_HEADER"
    "ID_DELIVERY_DEBIT_SLIP_HEADER","ID_DELIVERY_DEBIT_SLIP_DETAIL" "ID_DELIVERY_DEBIT_SLIP_DETAIL" WHERE
    "DSH_DOCUMENT_NUMBER"="DSD_DOCUMENT_NUMBER" AND "DSH_DOCUMENT_TYPE"="DSD_DOCUMENT_TYPE" AND
    "DSH_COMPANY"="DSD_COMPANY" AND "DSD_TICKET_NUMBER" IS NOT NULL AND
    LNNVL(:B1||:B2<>"DSD_AIRLINE"||"DSD_TICKET_NUMBER") AND "DSH_DELIVERY_DEBIT"='DEBIT'))
       2 - filter((:1 IS NULL OR "TICKET_AIRLINE"=:2) AND "TICKET_REFERENCE_2" IS NULL AND
    "TICKET_RECEIPT_NUMBER" IS NULL AND "TICKET_CARD_RECEIPT_NUMBER" IS NULL AND
    "TICKET_SYSTEM_DOC_NUMBER" IS NULL)
       3 - access("TICKET_REFERENCE_1" IS NULL)
           filter("TICKET_REFERENCE_1" IS NULL AND TO_NUMBER("TICKET_COMPANY")=1)
       4 - filter("DSD_TICKET_NUMBER" IS NOT NULL AND LNNVL(:B1||:B2<>"DSD_AIRLINE"||"DSD_TICKET_NUMBER"))
       6 - filter("DSH_DELIVERY_DEBIT"='DEBIT')
       7 - access("DSH_COMPANY"="DSD_COMPANY" AND "DSH_DOCUMENT_TYPE"="DSD_DOCUMENT_TYPE" AND
    "DSH_DOCUMENT_NUMBER"="DSD_DOCUMENT_NUMBER")
    Note
       - SQL profile "SYS_SQLPROF_014f902e2ea4c002" used for this statement

    some comments:
    it would be more simple to read the plan with indentatitions: you could use a fixed-width font
    it's hard to tell much about the plan without seeing the corresponding query (though in this case the predicate section gives some information on the query - especially step 1)
    the plan shows the use of a sql profile: so the CBO uses additional statistics to generate the plan
    in step 3 there is an index skip scan: that's only a good idea if there are few distinct values for the leading column of the index and the selectivity of "TICKET_REFERENCE_1" IS NULL is good
    in step 6 there is a Full Table Scan for the driving table of a nested loops join: the cost value for the scan is very small and so is the cost for the complete NL join - and that could be misleading
    I would use the gather_plan_statistics hint to get a plan with rowsource statistics to check if the cardinalities the CBO works with are correct. If they are not you could try to disable the profile (or create a new profile; of course after checking who created the profile and for what reasons). With an accurate sql profile the CBO should have enough information to create an accurate plan in most cases.
    Regards
    Martin

  • Strange explain plan

    I wrote a SQL in Oracle EBS, please see the following:
    SELECT msi.segment1 item_num, mmt.revision revision,
    msi.description description_en,
    msi_tl.long_description description_cn,
    mmt.transfer_organization_id mfg_org_id,
    xxuts_inv_trh_pkg.get_organization_name(mmt.transfer_organization_id),
    mmt.subinventory_code subinv, mmt.locator_id,
    mtln.lot_number lot_num, mmt.transaction_id txn_id,
    mmt.transfer_subinventory co_subinv, mmt.transfer_locator_id,
    mmt.transaction_date txn_date, fn.user_name user_name,
    mts.transaction_source_type_name txn_source_type,
    wie.wip_entity_name order_num,
    xxuts_inv_trh_pkg.get_qty_before (mmt.organization_id,
    mmt.inventory_item_id,
    mmt.revision,
    mmt.subinventory_code,
    mmt.transaction_id,
    mmt.transaction_date
    DECODE (msi.lot_control_code,
    2, mtln.transaction_quantity,
    mmt.transaction_quantity
    ) txn_qty,
    mtt.transaction_type_name txn_type, mmt.actual_cost item_cost,
    DECODE (msi.lot_control_code,
    2, mtln.transaction_quantity,
    mmt.transaction_quantity
    * mmt.actual_cost amount,
    mtln.primary_quantity primary_qty,
    NVL
    (mtr.reason_name,
    (SELECT mtrh.attribute1 || mtrh.attribute2 || mtrh.attribute3
    FROM mtl_txn_request_headers mtrh
    WHERE EXISTS (
    SELECT 'X'
    FROM mtl_txn_request_lines mtrl
    WHERE mtrh.header_id = mtrl.header_id
    AND mtrl.transaction_header_id =
    mmt.transaction_set_id
    AND mtrl.txn_source_id = mmt.transaction_source_id
    AND mtrl.line_id = mmt.source_line_id))
    ) reason,
    mmt.transaction_reference REFERENCE
    FROM mtl_system_items_b msi --250,
    mtl_system_items_tl msi_tl --500,
    mtl_transaction_lot_numbers mtln -210,
    mtl_material_transactions mmt -333,
    mtl_transaction_types mtt,
    mtl_txn_source_types mts,
    mtl_item_categories mic -800,
    mtl_transaction_reasons mtr,
    fnd_user fn,
    wip_entities wie --5
    WHERE msi.inventory_item_id = mmt.inventory_item_id
    AND msi.inventory_item_id = msi_tl.inventory_item_id
    AND msi.organization_id = msi_tl.organization_id
    AND mtr.reason_id(+) = mmt.reason_id
    AND msi_tl.LANGUAGE = USERENV ('LANG')
    AND mmt.transaction_id = mtln.transaction_id(+)
    AND mic.inventory_item_id = mmt.inventory_item_id
    AND mic.organization_id = mmt.organization_id
    AND mic.category_set_id = :b15
    AND mmt.transaction_type_id = mtt.transaction_type_id
    AND mmt.transaction_source_type_id = mts.transaction_source_type_id
    AND msi.organization_id = mmt.organization_id
    AND mmt.transaction_source_id = wie.wip_entity_id
    AND mmt.transaction_source_type_id IN (5)
    AND fn.user_id = mmt.created_by
    AND mmt.organization_id = :b14
    AND msi.segment1 >= NVL (:b13, msi.segment1)
    AND msi.segment1 <= NVL (:b12, msi.segment1)
    AND NVL (mmt.revision, '-99') = NVL (NVL (:b11, mmt.revision), '-99')
    AND mmt.subinventory_code >= NVL (:b10, mmt.subinventory_code)
    AND mmt.subinventory_code <= NVL (:b9, mmt.subinventory_code)
    AND mmt.transaction_date BETWEEN :b8 AND :b7
    AND mmt.creation_date BETWEEN :b6 AND :b5
    AND mmt.transaction_type_id = NVL (:b4, mmt.transaction_type_id)
    AND mmt.transaction_source_type_id = NVL (:b3, mmt.transaction_source_type_id)
    AND mmt.transaction_id = NVL (:b2, mmt.transaction_id)
    AND fn.user_id = NVL (:b1, fn.user_id)
    It's explain plan is:
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | INSERT STATEMENT | | | | 33 (100)| |
    | 1 | CONCATENATION | | | | | |
    |* 2 | FILTER | | | | | |
    | 3 | NESTED LOOPS | | 1 | 312 | 17 (0)| 00:00:01 |
    | 4 | NESTED LOOPS | | 1 | 297 | 15 (0)| 00:00:01 |
    | 5 | NESTED LOOPS OUTER | | 1 | 282 | 13 (0)| 00:00:01 |
    | 6 | NESTED LOOPS | | 1 | 257 | 10 (0)| 00:00:01 |
    | 7 | NESTED LOOPS | | 1 | 188 | 8 (0)| 00:00:01 |
    | 8 | NESTED LOOPS | | 1 | 174 | 7 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 1 | 148 | 6 (0)| 00:00:01 |
    | 10 | NESTED LOOPS OUTER | | 1 | 128 | 5 (0)| 00:00:01 |
    | 11 | NESTED LOOPS | | 1 | 108 | 4 (0)| 00:00:01 |
    | 12 | TABLE ACCESS BY INDEX ROWID| MTL_TXN_SOURCE_TYPES | 1 | 18 | 1 (0)| 00:00:01 |
    |* 13 | INDEX UNIQUE SCAN | MTL_TXN_SOURCE_TYPES_U1 | 1 | | 0 (0)| |
    |* 14 | TABLE ACCESS BY INDEX ROWID| MTL_MATERIAL_TRANSACTIONS | 1 | 90 | 3 (0)| 00:00:01 |
    |* 15 | INDEX RANGE SCAN | MTL_MATERIAL_TRANSACTIONS_N8 | 1 | | 2 (0)| 00:00:01 |
    | 16 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_REASONS | 1 | 20 | 1 (0)| 00:00:01 |
    |* 17 | INDEX UNIQUE SCAN | MTL_TRANSACTION_REASONS_U1 | 1 | | 0 (0)| |
    | 18 | TABLE ACCESS BY INDEX ROWID | WIP_ENTITIES | 1 | 20 | 1 (0)| 00:00:01 |
    |* 19 | INDEX UNIQUE SCAN | WIP_ENTITIES_U1 | 1 | | 0 (0)| |
    | 20 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_TYPES | 1 | 26 | 1 (0)| 00:00:01 |
    |* 21 | INDEX UNIQUE SCAN | MTL_TRANSACTION_TYPES_U1 | 1 | | 0 (0)| |
    | 22 | TABLE ACCESS BY INDEX ROWID | FND_USER | 1 | 14 | 1 (0)| 00:00:01 |
    |* 23 | INDEX UNIQUE SCAN | FND_USER_U1 | 1 | | 0 (0)| |
    |* 24 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 1 | 69 | 2 (0)| 00:00:01 |
    |* 25 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_B_U1 | 1 | | 1 (0)| 00:00:01 |
    | 26 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_LOT_NUMBERS | 1 | 25 | 3 (0)| 00:00:01 |
    |* 27 | INDEX RANGE SCAN | MTL_TRANSACTION_LOT_NUMBERS_N1 | 1 | | 2 (0)| 00:00:01 |
    |* 28 | INDEX RANGE SCAN | MTL_ITEM_CATEGORIES_U1 | 1 | 15 | 2 (0)| 00:00:01 |
    | 29 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_TL | 1 | 15 | 2 (0)| 00:00:01 |
    |* 30 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_TL_U1 | 1 | | 1 (0)| 00:00:01 |
    |* 31 | FILTER | | | | | |
    | 32 | NESTED LOOPS OUTER | | 1 | 312 | 16 (0)| 00:00:01 |
    | 33 | NESTED LOOPS | | 1 | 287 | 13 (0)| 00:00:01 |
    | 34 | NESTED LOOPS | | 1 | 272 | 11 (0)| 00:00:01 |
    | 35 | NESTED LOOPS | | 1 | 257 | 9 (0)| 00:00:01 |
    | 36 | NESTED LOOPS | | 1 | 188 | 7 (0)| 00:00:01 |
    | 37 | NESTED LOOPS OUTER | | 1 | 162 | 6 (0)| 00:00:01 |
    | 38 | NESTED LOOPS | | 1 | 142 | 5 (0)| 00:00:01 |
    | 39 | NESTED LOOPS | | 1 | 128 | 4 (0)| 00:00:01 |
    | 40 | NESTED LOOPS | | 1 | 108 | 3 (0)| 00:00:01 |
    | 41 | TABLE ACCESS BY INDEX ROWID| MTL_TXN_SOURCE_TYPES | 1 | 18 | 1 (0)| 00:00:01 |
    |* 42 | INDEX UNIQUE SCAN | MTL_TXN_SOURCE_TYPES_U1 | 1 | | 0 (0)| |
    |* 43 | TABLE ACCESS BY INDEX ROWID| MTL_MATERIAL_TRANSACTIONS | 1 | 90 | 2 (0)| 00:00:01 |
    |* 44 | INDEX UNIQUE SCAN | MTL_MATERIAL_TRANSACTIONS_U1 | 1 | | 1 (0)| 00:00:01 |
    | 45 | TABLE ACCESS BY INDEX ROWID | WIP_ENTITIES | 48143 | 940K| 1 (0)| 00:00:01 |
    |* 46 | INDEX UNIQUE SCAN | WIP_ENTITIES_U1 | 1 | | 0 (0)| |
    | 47 | TABLE ACCESS BY INDEX ROWID | FND_USER | 1 | 14 | 1 (0)| 00:00:01 |
    |* 48 | INDEX UNIQUE SCAN | FND_USER_U1 | 1 | | 0 (0)| |
    | 49 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_REASONS | 36 | 720 | 1 (0)| 00:00:01 |
    |* 50 | INDEX UNIQUE SCAN | MTL_TRANSACTION_REASONS_U1 | 1 | | 0 (0)| |
    | 51 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_TYPES | 98 | 2548 | 1 (0)| 00:00:01 |
    |* 52 | INDEX UNIQUE SCAN | MTL_TRANSACTION_TYPES_U1 | 1 | | 0 (0)| |
    |* 53 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 297 | 20493 | 2 (0)| 00:00:01 |
    |* 54 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_B_U1 | 1 | | 1 (0)| 00:00:01 |
    | 55 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_TL | 96026 | 1406K| 2 (0)| 00:00:01 |
    |* 56 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_TL_U1 | 1 | | 1 (0)| 00:00:01 |
    |* 57 | INDEX RANGE SCAN | MTL_ITEM_CATEGORIES_U1 | 1 | 15 | 2 (0)| 00:00:01 |
    | 58 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_LOT_NUMBERS | 1 | 25 | 3 (0)| 00:00:01 |
    |* 59 | INDEX RANGE SCAN | MTL_TRANSACTION_LOT_NUMBERS_N1 | 1 | | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - filter((:B6<=:B5 AND :B8<=:B7 AND :B2 IS NULL))
    13 - access("MTS"."TRANSACTION_SOURCE_TYPE_ID"=5)
    14 - filter(("MMT"."TRANSACTION_SOURCE_ID" IS NOT NULL AND
    "MMT"."TRANSACTION_TYPE_ID"=NVL(:B4,"MMT"."TRANSACTION_TYPE_ID") AND
    "MMT"."SUBINVENTORY_CODE">=NVL(:B10,"MMT"."SUBINVENTORY_CODE") AND
    "MMT"."SUBINVENTORY_CODE"<=NVL(:B9,"MMT"."SUBINVENTORY_CODE") AND
    NVL("MMT"."REVISION",'-99')=NVL(NVL(:B11,"MMT"."REVISION"),'-99') AND "MMT"."TRANSACTION_ID" IS NOT NULL AND
    "MMT"."CREATION_DATE">=:B6 AND "MMT"."CREATION_DATE"<=:B5))
    15 - access("MMT"."TRANSACTION_SOURCE_TYPE_ID"=5 AND "MMT"."ORGANIZATION_ID"=:B14 AND
    "MMT"."TRANSACTION_DATE">=:B8 AND "MMT"."TRANSACTION_DATE"<=:B7)
    filter(NVL(:B3,"MMT"."TRANSACTION_SOURCE_TYPE_ID")=5)
    17 - access("MTR"."REASON_ID"="MMT"."REASON_ID")
    19 - access("MMT"."TRANSACTION_SOURCE_ID"="WIE"."WIP_ENTITY_ID")
    21 - access("MMT"."TRANSACTION_TYPE_ID"="MTT"."TRANSACTION_TYPE_ID")
    23 - access("FN"."USER_ID"="MMT"."CREATED_BY")
    filter("FN"."USER_ID"=NVL(:B1,"FN"."USER_ID"))
    24 - filter(("MSI"."SEGMENT1">=NVL(:B13,"MSI"."SEGMENT1") AND "MSI"."SEGMENT1"<=NVL(:B12,"MSI"."SEGMENT1")))
    25 - access("MSI"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND "MSI"."ORGANIZATION_ID"=:B14)
    27 - access("MMT"."TRANSACTION_ID"="MTLN"."TRANSACTION_ID")
    28 - access("MIC"."ORGANIZATION_ID"=:B14 AND "MIC"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND
    "MIC"."CATEGORY_SET_ID"=:B15)
    30 - access("MSI"."INVENTORY_ITEM_ID"="MSI_TL"."INVENTORY_ITEM_ID" AND "MSI_TL"."ORGANIZATION_ID"=:B14 AND
    "MSI_TL"."LANGUAGE"=USERENV('LANG'))
    31 - filter((:B6<=:B5 AND :B8<=:B7 AND :B2 IS NOT NULL))
    42 - access("MTS"."TRANSACTION_SOURCE_TYPE_ID"=5)
    43 - filter(("MMT"."TRANSACTION_SOURCE_ID" IS NOT NULL AND "MMT"."TRANSACTION_DATE">=:B8 AND
    "MMT"."ORGANIZATION_ID"=:B14 AND "MMT"."TRANSACTION_SOURCE_TYPE_ID"=5 AND
    NVL(:B3,"MMT"."TRANSACTION_SOURCE_TYPE_ID")=5 AND "MMT"."TRANSACTION_TYPE_ID"=NVL(:B4,"MMT"."TRANSACTION_TYPE_ID"
    ) AND "MMT"."SUBINVENTORY_CODE">=NVL(:B10,"MMT"."SUBINVENTORY_CODE") AND
    "MMT"."SUBINVENTORY_CODE"<=NVL(:B9,"MMT"."SUBINVENTORY_CODE") AND
    NVL("MMT"."REVISION",'-99')=NVL(NVL(:B11,"MMT"."REVISION"),'-99') AND "MMT"."TRANSACTION_DATE"<=:B7 AND
    "MMT"."CREATION_DATE">=:B6 AND "MMT"."CREATION_DATE"<=:B5))
    44 - access("MMT"."TRANSACTION_ID"=:B2)
    46 - access("MMT"."TRANSACTION_SOURCE_ID"="WIE"."WIP_ENTITY_ID")
    48 - access("FN"."USER_ID"="MMT"."CREATED_BY")
    filter("FN"."USER_ID"=NVL(:B1,"FN"."USER_ID"))
    50 - access("MTR"."REASON_ID"="MMT"."REASON_ID")
    52 - access("MMT"."TRANSACTION_TYPE_ID"="MTT"."TRANSACTION_TYPE_ID")
    53 - filter(("MSI"."SEGMENT1">=NVL(:B13,"MSI"."SEGMENT1") AND "MSI"."SEGMENT1"<=NVL(:B12,"MSI"."SEGMENT1")))
    54 - access("MSI"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND "MSI"."ORGANIZATION_ID"=:B14)
    56 - access("MSI"."INVENTORY_ITEM_ID"="MSI_TL"."INVENTORY_ITEM_ID" AND "MSI_TL"."ORGANIZATION_ID"=:B14 AND
    "MSI_TL"."LANGUAGE"=USERENV('LANG'))
    57 - access("MIC"."ORGANIZATION_ID"=:B14 AND "MIC"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND
    "MIC"."CATEGORY_SET_ID"=:B15)
    59 - access("MMT"."TRANSACTION_ID"="MTLN"."TRANSACTION_ID")
    I am doubt why to perform two times explain plan(Predicate -2 and 31).
    Thanks

    Tom.lai wrote:
    I wrote a SQL in Oracle EBS, please see the following:
    AND msi.segment1 >= NVL (:b13, msi.segment1)
    AND msi.segment1 <= NVL (:b12, msi.segment1)
    AND NVL (mmt.revision, '-99') = NVL (NVL (:b11, mmt.revision), '-99')
    AND mmt.subinventory_code >= NVL (:b10, mmt.subinventory_code)
    AND mmt.subinventory_code <= NVL (:b9, mmt.subinventory_code)
    AND mmt.transaction_date BETWEEN :b8 AND :b7
    AND mmt.creation_date BETWEEN :b6 AND :b5
    AND mmt.transaction_type_id = NVL (:b4, mmt.transaction_type_id)
    AND mmt.transaction_source_type_id = NVL (:b3, mmt.transaction_source_type_id)
    AND mmt.transaction_id = NVL (:b2, mmt.transaction_id)
    AND fn.user_id = NVL (:b1, fn.user_id)I am doubt why to perform two times explain plan(Predicate -2 and 31).Using your NVL expressions above you've hit a special implementation for this particular construct in the Oracle optimizer, for more information, see here:
    http://jonathanlewis.wordpress.com/2007/01/09/conditional-sql/
    http://jonathanlewis.wordpress.com/2007/02/14/conditional-sql-2/
    This splits your plan into two plans for the two cases possible, and depending on if the value passed is NULL or not only one of the branches will actually get executed.
    Regards,
    Randolf
    Oracle related stuff blog:
    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/

  • Execution time from explain plan

    Hi
    How can i get the execution time of a query from explain plan (not tkprof). I don't see the execution time in the plan table output.
    Thanks

    Explain plan won't give execution time of a query because:
    - it does not execute the query
    - it only evaluates the execution plan and gives estimated costs
    I dont't know if it is possible to deduce execution time from estimated cost.
    Message was edited by:
    Pierre Forstmann

  • Tuning : Inconsistent result between Explain plan VS Execution Time

    Dear Experts,
    Need your suggestions belongs to contrary result between Explain plan VS Execution Time
    Environment :_
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
    PL/SQL Release 10.2.0.4.0 - Production
    CORE     10.2.0.4.0     Production
    TNS for Linux: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    Red Hat Enterprise Linux 5.4
    There's same query but : 1st query access Loan_Account, 2nd query access Loan_Account_Han
    *1st.*
    Query Access Via : Loan_account (Partition Type : Hash (5) with column Contract_Number)
    Explain Plan : cost: 4,432, bytes: 716, cardinality: 2
    Execution Time : 13 seconds
    *2nd.*
    Query Access Via : Loan_Account_Han (Partition Type : List(5) with column Loan_Status)
    Explain Plan : cost:188,447 bytes: 1,661,088, cardinality: 4,719
    Execution Time : 10 seconds
    Note :_
    all tables and all indexes belong to the table which included in query has been analyzed.
    my question :
    1. why it could become like this ? I even confusing with Jonathan Lewis Theory : Cost-Based Fundamental Book.
    with this result, I even not believed with the result from Explain Plan anymore.
    2. If analyze tables and indexes to update statistics which help CBO to choose the best path as part of Daily Performance Tuning,
    is there a way that could do in enviroment 24x7 ?
    Note : if original query is needed, I'll posting it here.
    Any help is very appreciated and thanks very much.
    Regards,
    Sigcle

    The DBMS_XPLAN.DISPLAY_CURSOR output
    Query no 1
    PLAN_TABLE_OUTPUT
    SQL_ID  bq7avs72xvmkv, child number 0
    SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id,        la.contract_number, mc.customer_name,       
    dco.os_principal_on_schedule AS os_principal_on_schedule,        f_get_param_value (la.financing_type,                           'FinancingType'                  
           ) AS financing_type,        CASE la.financing_type           WHEN 11                    -- Asset Purchase              THEN NVL (tp.os_principal_cust,     
                      la.os_principal_cust                       )           WHEN 12                                            -- JF Channelling              THEN
    NVL (tp.os_principal_mf, la.os_principal)        END AS os_principal_actual,        CASE           WHEN dco.bi_collectibility_with_gp >= 3              THEN 0    
          ELSE CASE           WHEN la.financing_type = '12'              THEN   NVL (ia.accrue_interest_pl, 0)                   + NVL (ia.accrue_interest_npl, 0)    
          ELSE   NVL (ia.accrue_
    Plan hash value: 4011856754
    | Id  | Operation                                  | Name                           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   1 |  TABLE ACCESS BY INDEX ROWID               | COLLECTIBILITY_CODE            |      3 |      1 |      3 |00:00:00.01 |       9 |      2 |       |       |          |
    |*  2 |   INDEX SKIP SCAN                          | UNQ_COLLECTIBILITY_CODE        |      3 |      1 |      3 |00:00:00.01 |       6 |      1 |       |       |          |
    |   3 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    501 |      1 |    501 |00:00:00.03 |    2004 |    796 |       |       |          |
    |*  4 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    501 |      1 |    501 |00:00:00.02 |    1503 |    377 |       |       |          |
    |   5 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.10 |    3220 |   1074 |       |       |          |
    |*  6 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.09 |    2887 |   1074 |       |       |          |
    |   7 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.05 |    1464 |    495 |       |       |          |
    |*  8 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.05 |    1297 |    495 |       |       |          |
    |   9 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 10 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  11 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 12 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |  13 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 14 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  15 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 16 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |  17 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 18 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  19 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 20 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |* 21 |  TABLE ACCESS FULL                         | COLLECTIBILITY_CODE            |      3 |      1 |      3 |00:00:00.01 |      12 |      1 |       |       |          |
    |  22 |  NESTED LOOPS OUTER                        |                                |      1 |      2 |    501 |00:00:01.02 |   96112 |  20091 |       |       |          |
    |  23 |   NESTED LOOPS                             |                                |      1 |      2 |    501 |00:00:00.28 |   13445 |   5358 |       |       |          |
    |  24 |    NESTED LOOPS                            |                                |      1 |      2 |    501 |00:00:00.26 |   11441 |   5071 |       |       |          |
    |  25 |     NESTED LOOPS OUTER                     |                                |      1 |      2 |    501 |00:00:00.24 |    9433 |   5014 |       |       |          |
    |* 26 |      HASH JOIN                             |                                |      1 |      2 |    501 |00:00:00.03 |     329 |    325 |  1206K|  1206K|  341K (0)|
    |* 27 |       TABLE ACCESS FULL                    | CURRENCY                       |      1 |      1 |      1 |00:00:00.01 |       3 |      2 |       |       |          |
    |* 28 |       HASH JOIN                            |                                |      1 |     61 |    501 |00:00:00.02 |     326 |    323 |   868K|   868K|  947K (0)|
    |* 29 |        HASH JOIN                           |                                |      1 |     10 |     13 |00:00:00.01 |       7 |      6 |   947K|   947K| 1030K (0)|
    |  30 |         TABLE ACCESS BY INDEX ROWID        | MULTIFINANCE                   |      1 |      5 |      9 |00:00:00.01 |       2 |      2 |       |       |          |
    |* 31 |          INDEX RANGE SCAN                  | IDX_STATUS_MF                  |      1 |      5 |      9 |00:00:00.01 |       1 |      1 |       |       |          |
    |* 32 |         TABLE ACCESS FULL                  | AGREEMENT                      |      1 |     18 |     13 |00:00:00.01 |       5 |      4 |       |       |          |
    |  33 |        VIEW                                |                                |      1 |    110 |    501 |00:00:00.02 |     319 |    317 |       |       |          |
    |* 34 |         HASH JOIN RIGHT OUTER              |                                |      1 |    110 |    501 |00:00:00.02 |     319 |    317 |  1011K|  1011K|  317K (0)|
    |  35 |          TABLE ACCESS BY INDEX ROWID       | TENANT_PARAMETER               |      1 |      1 |      1 |00:00:00.01 |       2 |      2 |       |       |          |
    |* 36 |           INDEX UNIQUE SCAN                | PK_TENANT_PARAMETER            |      1 |      1 |      1 |00:00:00.01 |       1 |      1 |       |       |          |
    |* 37 |          TABLE ACCESS BY GLOBAL INDEX ROWID| LOAN_ACCOUNT                   |      1 |    110 |    501 |00:00:00.02 |     317 |    315 |       |       |          |
    |* 38 |           INDEX RANGE SCAN                 | IDX_STATUS_LA1                 |      1 |   4394 |   3025 |00:00:00.01 |      15 |     14 |       |       |          |
    |* 39 |      TABLE ACCESS BY INDEX ROWID           | TX_PAYMENT                     |    501 |      1 |      0 |00:00:00.16 |    9104 |   4689 |       |       |          |
    |* 40 |       INDEX RANGE SCAN                     | FK_TX_PAY_LOAN_ACCT            |    501 |     12 |   8799 |00:00:00.02 |    1038 |    207 |       |       |          |
    |  41 |     TABLE ACCESS BY INDEX ROWID            | DL_CL_OUTSTANDING              |    501 |      1 |    501 |00:00:00.02 |    2008 |     57 |       |       |          |
    |* 42 |      INDEX RANGE SCAN                      | IDXLO_CNUM                     |    501 |      1 |    501 |00:00:00.01 |    1507 |     37 |       |       |          |
    |* 43 |    TABLE ACCESS BY INDEX ROWID             | MF_CUSTOMER                    |    501 |      1 |    501 |00:00:00.02 |    2004 |    287 |       |       |          |
    |* 44 |     INDEX UNIQUE SCAN                      | MF_CUSTOMER_PK                 |    501 |      1 |    501 |00:00:00.01 |    1503 |     24 |       |       |          |
    |* 45 |   TABLE ACCESS BY INDEX ROWID              | TX_INTEREST_ACCRUE             |    501 |      1 |      0 |00:00:00.73 |   82667 |  14733 |       |       |          |
    |* 46 |    INDEX RANGE SCAN                        | FK_TX_INTEREST_ACCRUE_LOAN_ACC |    501 |     67 |  40581 |00:00:00.14 |   42084 |    451 |       |       |          |
    Predicate Information (identified by operation id):
       2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
           filter("XX"."COLLECTIBILITY_CODE"=:B1)
       4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
       6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
       8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
      26 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
      27 - filter(UPPER("CURR"."STATUS")='A')
      28 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
      29 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
      31 - access("MF"."SYS_NC00052$"='A')
      32 - filter(UPPER("A"."STATUS")='A')
      34 - access("LA"."TENANT_ID"="TENANT_ID")
      36 - access("TENANT_PARAMETER_ID"=23)
      37 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR ("LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  UPPER("LA"."LOAN_STATUS")='CN')))
      38 - access("LA"."SYS_NC00118$"='A')
      39 - filter(("TP"."APPROVAL_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"=152 AND UPPER("TP"."APPROVAL_STATUS")='A'))
      40 - access("TP"."LOAN_ACCOUNT_ID"="from$_subquery$_016"."LOAN_ACCOUNT_ID")
      42 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
      43 - filter(UPPER("MC"."STATUS")='A')
      44 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")
      45 - filter("IA"."ACCRUE_DATE"="XX"."PREV_DATE")
      46 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID")
    The DBMS_XPLAN.DISPLAY_CURSOR output after : alter system flush buffer_cache; alter system flush shared_pool;
    Query no 2
    PLAN_TABLE_OUTPUT
    SQL_ID  cxmg4jfvr9pz0, child number 0
    SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id,        la.contract_number, mc.customer_name,       
    dco.os_principal_on_schedule AS os_principal_on_schedule,        f_get_param_value (la.financing_type,                           'FinancingType'                  
           ) AS financing_type,        CASE la.financing_type           WHEN 11                    -- Asset Purchase              THEN NVL (tp.os_principal_cust,     
                      la.os_principal_cust                       )           WHEN 12                                            -- JF Channelling              THEN
    NVL (tp.os_principal_mf, la.os_principal)        END AS os_principal_actual,        CASE           WHEN dco.bi_collectibility_with_gp >= 3              THEN 0    
          ELSE CASE           WHEN la.financing_type = '12'              THEN   NVL (ia.accrue_interest_pl, 0)                   + NVL (ia.accrue_interest_npl, 0)    
          ELSE   NVL (ia.accrue_
    Plan hash value: 2072372033
    | Id  | Operation                            | Name                           | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                     |                                |  4719 |  1622K|   188K (32)| 00:37:42 |       |       |
    |   1 |  TABLE ACCESS BY INDEX ROWID         | COLLECTIBILITY_CODE            |     1 |    12 |     3   (0)| 00:00:01 |       |       |
    |*  2 |   INDEX SKIP SCAN                    | UNQ_COLLECTIBILITY_CODE        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   3 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  4 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   5 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  6 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   7 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  8 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   9 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 10 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  11 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 12 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  13 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 14 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  15 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 16 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  17 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 18 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  19 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 20 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |* 21 |  TABLE ACCESS FULL                   | COLLECTIBILITY_CODE            |     1 |    12 |     3   (0)| 00:00:01 |       |       |
    |  22 |  NESTED LOOPS                        |                                |  4719 |  1622K|   188K (32)| 00:37:42 |       |       |
    |  23 |   NESTED LOOPS                       |                                |  4719 |  1460K|   183K (33)| 00:36:45 |       |       |
    |  24 |    NESTED LOOPS OUTER                |                                |  4719 |  1354K|   180K (33)| 00:36:07 |       |       |
    |  25 |     NESTED LOOPS OUTER               |                                |  4719 |  1225K|   130K (46)| 00:26:01 |       |       |
    |* 26 |      HASH JOIN                       |                                |  4719 |  1106K| 23591   (2)| 00:04:44 |       |       |
    |  27 |       TABLE ACCESS BY INDEX ROWID    | MULTIFINANCE                   |     5 |   130 |     2   (0)| 00:00:01 |       |       |
    |* 28 |        INDEX RANGE SCAN              | IDX_STATUS_MF                  |     5 |       |     1   (0)| 00:00:01 |       |       |
    |* 29 |       HASH JOIN                      |                                |  8494 |  1775K| 23589   (2)| 00:04:44 |       |       |
    |* 30 |        TABLE ACCESS FULL             | AGREEMENT                      |    18 |   360 |     3   (0)| 00:00:01 |       |       |
    |* 31 |        HASH JOIN                     |                                |  8494 |  1609K| 23585   (2)| 00:04:44 |       |       |
    |* 32 |         TABLE ACCESS FULL            | CURRENCY                       |     1 |     4 |     3   (0)| 00:00:01 |       |       |
    |  33 |         VIEW                         |                                |   212K|    38M| 23579   (2)| 00:04:43 |       |       |
    |* 34 |          HASH JOIN RIGHT OUTER       |                                |   212K|    32M| 23579   (2)| 00:04:43 |       |       |
    |  35 |           TABLE ACCESS BY INDEX ROWID| TENANT_PARAMETER               |     1 |    74 |     1   (0)| 00:00:01 |       |       |
    |* 36 |            INDEX UNIQUE SCAN         | PK_TENANT_PARAMETER            |     1 |       |     0   (0)| 00:00:01 |       |       |
    |  37 |           PARTITION LIST ALL         |                                |   212K|    17M| 23575   (2)| 00:04:43 |     1 |     5 |
    |* 38 |            TABLE ACCESS FULL         | LOAN_ACCOUNT_HAN               |   212K|    17M| 23575   (2)| 00:04:43 |     1 |     5 |
    |  39 |      TABLE ACCESS BY INDEX ROWID     | TX_INTEREST_ACCRUE             |     1 |    26 |   130K (46)| 00:26:01 |       |       |
    |  40 |       BITMAP CONVERSION TO ROWIDS    |                                |       |       |            |          |       |       |
    |  41 |        BITMAP AND                    |                                |       |       |            |          |       |       |
    |  42 |         BITMAP CONVERSION FROM ROWIDS|                                |       |       |            |          |       |       |
    |* 43 |          INDEX RANGE SCAN            | FK_TX_INTEREST_ACCRUE_LOAN_ACC |    67 |       |     0   (0)| 00:00:01 |       |       |
    |  44 |         BITMAP CONVERSION FROM ROWIDS|                                |       |       |            |          |       |       |
    |* 45 |          INDEX RANGE SCAN            | IDX_TX_INTEREST_ACCRUE         |    67 |       |    12 (100)| 00:00:01 |       |       |
    |* 46 |     TABLE ACCESS BY INDEX ROWID      | TX_PAYMENT                     |     1 |    28 |    11   (0)| 00:00:01 |       |       |
    |* 47 |      INDEX RANGE SCAN                | FK_TX_PAY_LOAN_ACCT            |    12 |       |     0   (0)| 00:00:01 |       |       |
    |  48 |    TABLE ACCESS BY INDEX ROWID       | DL_CL_OUTSTANDING              |     1 |    23 |     1   (0)| 00:00:01 |       |       |
    |* 49 |     INDEX RANGE SCAN                 | IDXLO_CNUM                     |     1 |       |     0   (0)| 00:00:01 |       |       |
    |* 50 |   TABLE ACCESS BY INDEX ROWID        | MF_CUSTOMER                    |     1 |    35 |     1   (0)| 00:00:01 |       |       |
    |* 51 |    INDEX UNIQUE SCAN                 | MF_CUSTOMER_PK                 |     1 |       |     0   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
       2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
           filter("XX"."COLLECTIBILITY_CODE"=:B1)
       4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
       6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
       8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
      26 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
      28 - access(UPPER("STATUS")='A')
      29 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
      30 - filter(UPPER("A"."STATUS")='A')
      31 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
      32 - filter(UPPER("CURR"."STATUS")='A')
      34 - access("LA"."TENANT_ID"="TENANT_ID"(+))
      36 - access("TENANT_PARAMETER_ID"(+)=23)
      38 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR "LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                  AND UPPER("LA"."LOAN_STATUS")='CN') AND UPPER("LA"."STATUS")='A')
      43 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID"(+))
      45 - access("IA"."ACCRUE_DATE"(+)="XX"."PREV_DATE")
      46 - filter("TP"."APPROVAL_DATE"(+)=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"(+)=152
                  AND UPPER("TP"."APPROVAL_STATUS"(+))='A')
      47 - access("TP"."LOAN_ACCOUNT_ID"(+)="from$_subquery$_016"."LOAN_ACCOUNT_ID")
      49 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
      50 - filter(UPPER("MC"."STATUS")='A')
      51 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")Typically both query running on 10-12 seconds (or same execution time).
    And I can't provide autotrace and tkprof output cause I cannot access via sqlplus.
    Thanks very much for the link HOW TO: Post a SQL statement tuning request - template posting
    Regards,
    Sigcle
    Edited by: SigCle on Feb 25, 2013 4:22 AM

  • Time column of an explain plan

    Hi,
    I'm using Oracle version 10.2.0.3.0. I have 2 tables with 10 million records each. The DDL is as follows.
    create table bigtable(col1 varchar2(20), col2 varchar2(20))
    create table bigtablechild(col1 varchar2(20), col2 varchar(20))
    bigtablechild.col1 is a foreign key to bigtable.col1. Below is the query and explain plan. Over several executions, the query runs for about 20 seconds before returning results. Could anyone please explain what the time column represents? It doesn't match the time it took to return results.
    SQL> set autotrace on
    SQL>
    SQL> select b.col2
      2  from bigtable a, bigtablechild b
      3  where a.col1 = b.col1
      4  and a.col1 = 'ABC6554';
    COL2
    XYZ6554
    XYZ6554
    XYZ6554
    XYZ6554
    XYZ6554
    Execution Plan
    Plan hash value: 4210396901
    | Id  | Operation          | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |               |     5 |   150 | 21538   (4)| 00:04:19 |
    |*  1 |  HASH JOIN         |               |     5 |   150 | 21538   (4)| 00:04:19 |
    |*  2 |   TABLE ACCESS FULL| BIGTABLE      |     1 |    10 | 13124   (4)| 00:02:38 |
    |*  3 |   TABLE ACCESS FULL| BIGTABLECHILD |     5 |   100 |  8413   (5)| 00:01:41 |
    Predicate Information (identified by operation id):
       1 - access("A"."COL1"="B"."COL1")
       2 - filter("A"."COL1"='ABC6554')
       3 - filter("B"."COL1"='ABC6554')
    Statistics
              0  recursive calls
              0  db block gets
          93672  consistent gets
          91845  physical reads
              0  redo size
            463  bytes sent via SQL*Net to client
            396  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              5  rows processed

    Hi,
    the values in the TIME column are calculated from cost using system I/O statistics. If dbms_stats.gather_system_stats has never been run, then these stats have default values which may be very far from the truth. In your case, the optimizer expects a single-block I/O read to take about 12 ms, while in reality it is closer to 1 ms, thus the discrepancy between the prediction and actual results.
    In general, TIME column is not very helpful not just because of potentially incorrect I/O time estimates, but also because it is hard to predict how much data will be found in cash, so I would recommend not to pay too much attention to it (note, however, that A-time column, on the other hand, is extremely useful, but it's only available if rowsource statistics for the plan have been populated).
    Best regards,
    Nikolay

  • Cost in explain plan vs elapsed time

    hi gurus,
    i have two tables with identical data volume(same database/schema/tablespace) and the only difference between these two is, one partitioned on a date filed.
    statistics are up to date.
    same query is executed against both tables, no partition pruning involved.
    select ....... from non-partitioned
    execution plan cost=92
    elapsed time=117612
    select ... from partitioned
    execution plan cost=3606
    elapsed time=19559
    though plan cost of query against non-partitioned is quite less than partitioned, elapsed time in v$sqlarea is higher than partitioned.
    what could be the reason please?
    thanks,
    charles
    Edited by: user570138 on May 6, 2010 6:54 AM

    user570138 wrote:
    if elapsed time value is very volatile(with the difference in explain plan cost) , then how can i compare the performance of the query?Note that the same query with same execution plan and same data can provide different execution times - and due to a number of factors. The primary one being that the first time the query is executed, it performs physical I/O and loads the data into the buffer cache - where the same subsequent query finds this data via cheaper and faster logical I/O in the cache.
    in my case i want to compare the performance change before and after table partitioning.Then look at the actual utilisation cost of the query and not (variant) elapsed execution time. The most expensive operation on a db platform is typically I/O. The more I/O, the slower the execution time.
    I/O can be decreased in a number of ways. The usual approach in the database environment is to provide better or alternative data structures, in order to create more optimal I/O paths.
    So instead of using a hash table and separate PK b+tree index, using an index organised table. Instead of a single large table with indexes, a partitioned table with local indexes. Instead of joining plain tables, joining tables that have been clustered. Etc.
    In most cases, when done correctly, these physical data structure changes do not even impact the application layer. The SQL and code in this layer should be blissfully unaware of the physical structure changes done to improve performance.
    Likewise, changes in the logical layer (data model changes) can also improve performance. This of course does impact the application layer - and requires a proper design and implementation in the physical layer. Often proper data modeling is overlooked and flaws in it is attempted to be fixed by hacking the physical layer.
    my aim is to measure the query performance improvements, if any, by partitioning an existing tableWhy not measure current I/O before an operation, and then after the operation - and use the difference to determine the amount of I/O performed by that operation?
    This can be implemented in a start/stop watch fashion (instead of measuring time, measuring I/O) using the v$sesstat virtual performance view.

  • Virtual column partitioning - explain plan takes lot of time.

    I have some problem with table with partitioning based on virtual column.
    Explain plan generates for some simple select 2-5 minutes,
    but the same select but without part of where clausule generate in secounds.
    In both query there is the same explain plan.
    Could someone explain why?
    Table:
    CREATE TABLE "SUBSCRIPTION"
    "CUSTOMER_ID" VARCHAR2(100 BYTE),
    "IDENT_SOURCE_ID" VARCHAR2(20 BYTE),
    "ACCOUNT_ID" VARCHAR2(100 BYTE),
    "MSISDN" VARCHAR2(500 BYTE),
    "IMSI" VARCHAR2(500 BYTE),
    "SIM" VARCHAR2(500 BYTE),
    "IMEI" VARCHAR2(500 BYTE),
    "MEID" VARCHAR2(15 BYTE),
    "EMAIL" VARCHAR2(100 BYTE),
    "TELCOOP" VARCHAR2(1000 BYTE),
    "MSISDN_TYPE" VARCHAR2(20 BYTE),
    "GSM" NUMBER(1,0),
    "CDMA" NUMBER(1,0),
    "VALID_FROM" DATE,
    "VALID_TO" DATE,
    "MSISDN_HASH" NUMBER(3,0) GENERATED ALWAYS AS (MOD(TO_NUMBER(NVL2(RTRIM(TRANSLATE(NVL(SUBSTR("MSISDN",-3),NVL("MSISDN",'err')),'123456789','000000000'),'0'),'-1',NVL(SUBSTR("MSISDN",-3),"MSISDN"))),125)) VIRTUAL VISIBLE, --generali mod from 3 last digits of msisdn
    ) PARTITION BY LIST ( "MSISDN_HASH" )
    PARTITION "PCHR" VALUES ( -1 )
    PARTITION "P000" VALUES ( 0 )
    PARTITION "P001" VALUES ( 1 )
    ... and so on till...
    PARTITION "P124" VALUES (124)
    PARALLEL 4;
    Slow select:
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from dbident2.subscription
    where MSISDN = '600489461'
    AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    Fast select:
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from dbident2.subscription
    where MSISDN = '600489461'
    AND MSISDN_HASH = 86

    --Slower select trace:
    Registered qb: SEL$1 0xf4ea2a20 (PARSER)
    QUERY BLOCK SIGNATURE
    signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
    SPM: statement not found in SMB
    SPM: statement not a candidate for auto-capture
    Dynamic sampling level auto-adjusted from 6 to 6
    Automatic degree of parallelism (ADOP)
    Automatic degree of parallelism is disabled: Parameter.
    PM: Considering predicate move-around in query block SEL$1 (#0)
    Predicate Move-Around (PM)
    OPTIMIZER INFORMATION
    ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
    explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    Legend
    The following abbreviations are used by optimizer trace.
    CBQT - cost-based query transformation
    JPPD - join predicate push-down
    OJPPD - old-style (non-cost-based) JPPD
    FPD - filter push-down
    PM - predicate move-around
    CVM - complex view merging
    SPJ - select-project-join
    SJC - set join conversion
    SU - subquery unnesting
    OBYE - order by elimination
    OST - old style star transformation
    ST - new (cbqt) star transformation
    CNT - count(col) to count(*) transformation
    JE - Join Elimination
    JF - join factorization
    SLP - select list pruning
    DP - distinct placement
    qb - query block
    LB - leaf blocks
    DK - distinct keys
    LB/K - average number of leaf blocks per key
    DB/K - average number of data blocks per key
    CLUF - clustering factor
    NDV - number of distinct values
    Resp - response cost
    Card - cardinality
    Resc - resource cost
    NL - nested loops (join)
    SM - sort merge (join)
    HA - hash (join)
    CPUSPEED - CPU Speed
    IOTFRSPEED - I/O transfer speed
    IOSEEKTIM - I/O seek time
    SREADTIM - average single block read time
    MREADTIM - average multiblock read time
    MBRC - average multiblock read count
    MAXTHR - maximum I/O system throughput
    SLAVETHR - average slave I/O throughput
    dmeth - distribution method
    1: no partitioning required
    2: value partitioned
    4: right is random (round-robin)
    128: left is random (round-robin)
    8: broadcast right and partition left
    16: broadcast left and partition right
    32: partition left using partitioning of right
    64: partition right using partitioning of left
    256: run the join in serial
    0: invalid distribution method
    sel - selectivity
    ptn - partition
    PARAMETERS USED BY THE OPTIMIZER
    PARAMETERS WITH ALTERED VALUES
    Compilation Environment Dump
    pgamax_size = 1258280 KB
    parallel_query_default_dop = 32
    db_file_multiblock_read_count = 16
    Bug Fix Control Environment
    PARAMETERS IN OPT_PARAM HINT
    Column Usage Monitoring is ON: tracking level = 1
    Considering Query Transformations on query block SEL$1 (#0)
    Query transformations (QT)
    JF: Checking validity of join factorization for query block SEL$1 (#0)
    JF: Bypassed: not a UNION or UNION-ALL query block.
    ST: not valid since star transformation parameter is FALSE
    TE: Checking validity of table expansion for query block SEL$1 (#0)
    TE: Bypassed: No relevant table found.
    CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
    CBQT: Validity checks failed for afjvvjmx6tqgr.
    CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
    Common Subexpression elimination (CSE)
    CSE: CSE not performed on query block SEL$1 (#0).
    OBYE: Considering Order-by Elimination from view SEL$1 (#0)
    Order-by elimination (OBYE)
    OBYE: OBYE bypassed: no order by to eliminate.
    CVM: Considering view merge in query block SEL$1 (#0)
    query block SEL$1 (#0) unchanged
    Considering Query Transformations on query block SEL$1 (#0)
    Query transformations (QT)
    JF: Checking validity of join factorization for query block SEL$1 (#0)
    JF: Bypassed: not a UNION or UNION-ALL query block.
    ST: not valid since star transformation parameter is FALSE
    TE: Checking validity of table expansion for query block SEL$1 (#0)
    TE: Bypassed: No relevant table found.
    CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
    CBQT: Validity checks failed for afjvvjmx6tqgr.
    CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
    Common Subexpression elimination (CSE)
    CSE: CSE not performed on query block SEL$1 (#0).
    SU: Considering subquery unnesting in query block SEL$1 (#0)
    Subquery Unnest (SU)
    SJC: Considering set-join conversion in query block SEL$1 (#0)
    Set-Join Conversion (SJC)
    SJC: not performed
    PM: Considering predicate move-around in query block SEL$1 (#0)
    Predicate Move-Around (PM)
    PM: PM bypassed: Outer query contains no views.
    PM: PM bypassed: Outer query contains no views.
    query block SEL$1 (#0) unchanged
    FPD: Considering simple filter push in query block SEL$1 (#0)
    "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    try to generate transitive predicate from check constraints for query block SEL$1 (#0)
    finally: "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    apadrv-start sqlid=12053738773107497463
    call(in-use=8176, alloc=32712), compile(in-use=114912, alloc=116848), execution(in-use=175432, alloc=178928)
    Peeked values of the binds in SQL statement
    Final query after transformations:******* UNPARSED QUERY IS *******
    SELECT "SUBSCRIPTION"."CUSTOMER_ID" "CUSTOMER_ID","SUBSCRIPTION"."IDENT_SOURCE_ID" "IDENT_SOURCE_ID","SUBSCRIPTION"."ACCOUNT_ID" "ACCOUNT_ID","SUBSCRIPTION"."MSISDN" "MSISDN","SUBSCRIPTION"."IMSI" "IMSI","SUBSCRIPTION"."SIM" "SIM","SUBSCRIPTION"."IMEI" "IMEI","SUBSCRIPTION"."MEID" "MEID","SUBSCRIPTION"."EMAIL" "EMAIL","SUBSCRIPTION"."TELCOOP" "TELCOOP" FROM "DBIDENT2"."SUBSCRIPTION" "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    kkoqbc: optimizing query block SEL$1 (#0)
    call(in-use=8320, alloc=32712), compile(in-use=115880, alloc=116848), execution(in-use=175432, alloc=178928)
    kkoqbc-subheap (create addr=0x2b24ebece950)
    QUERY BLOCK TEXT
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    QUERY BLOCK SIGNATURE
    signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=0 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
    SYSTEM STATISTICS INFORMATION
    Using NOWORKLOAD Stats
    CPUSPEEDNW: 714 millions instructions/sec (default is 100)
    IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
    IOSEEKTIM: 10 milliseconds (default is 10)
    MBRC: -1 blocks (default is 16)
    BASE STATISTICAL INFORMATION
    Table Stats::
    Table: SUBSCRIPTION Alias: SUBSCRIPTION Partition [87]
    #Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
    #Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
    Index Stats::
    Index: SUBSCRIPTION_NDX_ACCID Col#: 3
    LVLS: 3 #LB: 121036 #DK: 9767936 LB/K: 1.00 DB/K: 1.00 CLUF: 13921256.00
    Index: SUBSCRIPTION_NDX_CUSID Col#: 1 2 18
    LVLS: 3 #LB: 142123 #DK: 24665396 LB/K: 1.00 DB/K: 1.00 CLUF: 24842146.00
    Index: SUBSCRIPTION_NDX_EMAIL Col#: 9
    LVLS: 2 #LB: 8365 #DK: 1361827 LB/K: 1.00 DB/K: 1.00 CLUF: 1361798.00
    Index: SUBSCRIPTION_NDX_EXT1 Col#: 19
    LVLS: 2 #LB: 65756 #DK: 67792 LB/K: 1.00 DB/K: 80.00 CLUF: 5446485.00
    Index: SUBSCRIPTION_NDX_IMEI Col#: 7
    LVLS: 2 #LB: 44539 #DK: 9199616 LB/K: 1.00 DB/K: 1.00 CLUF: 10413439.00
    Index: SUBSCRIPTION_NDX_IMSI Col#: 5
    LVLS: 3 #LB: 92914 #DK: 12846080 LB/K: 1.00 DB/K: 1.00 CLUF: 23472821.00
    Index: SUBSCRIPTION_NDX_MEID Col#: 8
    LVLS: 1 #LB: 132 #DK: 12585 LB/K: 1.00 DB/K: 1.00 CLUF: 18419.00
    Index: SUBSCRIPTION_NDX_MSISDN Col#: 4 PARTITION [87]
    LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
    LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
    Index: SUBSCRIPTION_NDX_SIM Col#: 6
    LVLS: 2 #LB: 88153 #DK: 13169664 LB/K: 1.00 DB/K: 1.00 CLUF: 24727298.00
    Index: SUBSCRIPTION_NDX_SRCID Col#: 2 17
    LVLS: 2 #LB: 81729 #DK: 4 LB/K: 20432.00 DB/K: 257314.00 CLUF: 1029257.00
    Access path analysis for SUBSCRIPTION
    SINGLE TABLE ACCESS PATH
    Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
    *** 2012-06-12 12:34:53.283
    ** Performing dynamic sampling initial checks. **
    Column (#14):
    NewDensity:0.000020, OldDensity:0.000366 BktCnt:254, PopBktCnt:22, PopValCnt:1, NDV:46252
    Column (#14):
    NewDensity:0.000163, OldDensity:0.000378 BktCnt:254, PopBktCnt:12, PopValCnt:1, NDV:5852
    Column (#14): VALID_FROM( Part#: 87
    AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
    Column (#14): VALID_FROM(
    AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
    Column (#4):
    NewDensity:0.000000, OldDensity:0.000000 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:9730048
    Column (#4):
    NewDensity:0.000013, OldDensity:0.000033 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:74848
    Column (#4): MSISDN( Part#: 87
    AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
    Column (#4): MSISDN(
    AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
    ** Dynamic sampling initial checks returning TRUE (level = 6).
    *** 2012-06-12 12:34:53.284
    ** Generated dynamic sampling query:
    query text :
    SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("SUBSCRIPTION") FULL("SUBSCRIPTION") NO_PARALLEL_INDEX("SUBSCRIPTION") */ 1 AS C1, CASE WHEN "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss') THEN 1 ELSE 0 END AS C2 FROM "DBIDENT2"."SUBSCRIPTION" SAMPLE BLOCK (1.153706 , 1) SEED (1) "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) SAMPLESUB
    *** 2012-06-12 12:36:44.452
    ** Executed dynamic sampling query:
    level : 6
    sample pct. : 1.153706
    total partitions : 1
    partitions for sampling : 1
    actual sample size : 342182
    filtered sample card. : 0
    orig. card. : 218104
    block cnt. table stat. : 11008
    block cnt. for sampling: 11008
    max. sample block cnt. : 128
    sample block cnt. : 127
    min. sel. est. : 0.00001260
    ** Not using dynamic sampling for single table sel. or cardinality.
    DS Failed for : ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
    explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    Column (#21):
    NewDensity:0.002912, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:126, NDV:126
    Column (#21): MSISDN_HASH( Part#: 87
    AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
    Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
    Column (#21): MSISDN_HASH(
    AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
    Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
    Column (#1):
    NewDensity:0.000000, OldDensity:0.000241 BktCnt:254, PopBktCnt:31, PopValCnt:2, NDV:9768960
    Column (#1):
    NewDensity:0.000009, OldDensity:0.000250 BktCnt:254, PopBktCnt:36, PopValCnt:3, NDV:99208
    Column (#1): CUSTOMER_ID( Part#: 87
    AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
    Column (#1): CUSTOMER_ID(
    AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
    Column (#2):
    NewDensity:0.000639, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:3, NDV:3
    Column (#2):
    NewDensity:0.000786, OldDensity:0.000002 BktCnt:13365, PopBktCnt:13365, PopValCnt:3, NDV:3
    Column (#2): IDENT_SOURCE_ID( Part#: 87
    AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
    Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
    Column (#2): IDENT_SOURCE_ID(
    AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
    Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
    ColGroup (#1, Index) SUBSCRIPTION_NDX_CUSID
    Col#: 1 2 18 CorStregth: -1.00
    ColGroup (#2, Index) SUBSCRIPTION_NDX_SRCID
    Col#: 2 17 CorStregth: -1.00
    ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
    ***** Virtual column Adjustment ******
    Column name MSISDN_HASH
    cost_cpu 2300.00
    cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
    ***** End virtual column Adjustment ******
    Table: SUBSCRIPTION Alias: SUBSCRIPTION
    Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
    Access Path: TableScan
    Cost: 2420.71 Resp: 672.42 Degree: 0
    Cost_io: 2409.00 Cost_cpu: 100334308
    Resp_io: 669.17 Resp_cpu: 27870641
    kkofmx: index filter:"SUBSCRIPTION"."MSISDN_HASH"=86
    ***** Virtual column Adjustment ******
    Column name MSISDN_HASH
    cost_cpu 2300.00
    cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
    ***** End virtual column Adjustment ******
    Access Path: index (AllEqRange)
    Index: SUBSCRIPTION_NDX_MSISDN
    resc_io: 6.00 resc_cpu: 36840
    ix_sel: 0.000013 ix_sel_with_filters: 0.000013
    ***** Logdef predicate Adjustment ******
    Final IO cst 0.00 , CPU cst 2300.00
    ***** End Logdef Adjustment ******
    Cost: 6.01 Resp: 6.01 Degree: 1
    Best:: AccessPath: IndexRange
    Index: SUBSCRIPTION_NDX_MSISDN
    Cost: 6.01 Degree: 1 Resp: 6.01 Card: 2.75 Bytes: 0
    OPTIMIZER STATISTICS AND COMPUTATIONS
    GENERAL PLANS
    Considering cardinality-based initial join order.
    Permutations for Starting Table :0
    Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
    Best so far: Table#: 0 cost: 6.0051 card: 2.7487 bytes: 291
    ****** Recost for parallel table scan *******
    Access path analysis for SUBSCRIPTION
    SINGLE TABLE ACCESS PATH
    Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
    *** 2012-06-12 12:36:44.454
    ** Performing dynamic sampling initial checks. **
    ** TABLE SUBSCRIPTION Alias: SUBSCRIPTION : reused cached dynamic sampling result (failure).
    ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
    ***** Virtual column Adjustment ******
    Column name MSISDN_HASH
    cost_cpu 2300.00
    cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
    ***** End virtual column Adjustment ******
    Table: SUBSCRIPTION Alias: SUBSCRIPTION
    Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
    Access Path: TableScan
    Cost: 2420.71 Resp: 672.42 Degree: 0
    Cost_io: 2409.00 Cost_cpu: 100334308
    Resp_io: 669.17 Resp_cpu: 27870641
    Best:: AccessPath: TableScan
    Cost: 672.42 Degree: 4 Resp: 672.42 Card: 2.75 Bytes: 97
    Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
    Join order aborted: cost > best plan cost
    (newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:2000
    Number of join permutations tried: 1
    Enumerating distribution method (advanced)
    Trying or-Expansion on query block SEL$1 (#0)
    Transfer Optimizer annotations for query block SEL$1 (#0)
    id=0 frofkks[i] (index start key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
    id=0 frofkke[i] (index stop key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
    id=0 frofand predicate="SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    Final cost for query block SEL$1 (#0) - All Rows Plan:
    Best join order: 1
    Cost: 6.0051 Degree: 1 Card: 3.0000 Bytes: 291
    Resc: 6.0051 Resc_io: 6.0000 Resc_cpu: 43740
    Resp: 6.0051 Resp_io: 6.0000 Resc_cpu: 43740
    kkoqbc-subheap (delete addr=0x2b24ebece950, in-use=21280, alloc=32840)
    kkoqbc-end:
    call(in-use=252920, alloc=343912), compile(in-use=129048, alloc=133000), execution(in-use=192248, alloc=195240)
    kkoqbc: finish optimizing query block SEL$1 (#0)
    apadrv-end
    call(in-use=252920, alloc=343912), compile(in-use=129960, alloc=133000), execution(in-use=192248, alloc=195240)
    Starting SQL statement dump
    user_id=115 user_name=xxx module=SQL*Plus action=
    sql_id=afjvvjmx6tqgr plan_hash_value=1672204165 problem_type=3
    ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
    explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    sql_text_length=266
    sql=explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH2
    sql=4:MI:SS')
    ----- Explain Plan Dump -----
    ----- Plan Table -----
    ============
    Plan Table
    ============
    -----------------------------------------------------------------------------------------------------------------------+
    | Id | Operation | Name | Rows | Bytes | Cost | Time | Pstart| Pstop |
    -----------------------------------------------------------------------------------------------------------------------+
    | 0 | SELECT STATEMENT | | | | 6 | | | |
    | 1 | PARTITION LIST SINGLE | | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
    | 2 | TABLE ACCESS BY LOCAL INDEX ROWID | SUBSCRIPTION | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
    | 3 | INDEX RANGE SCAN | SUBSCRIPTION_NDX_MSISDN| 3 | | 3 | 00:00:01 | 88 | 88 |
    -----------------------------------------------------------------------------------------------------------------------+
    Predicate Information:
    2 - filter("VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
    3 - access("MSISDN"='600600600')
    Content of other_xml column
    ===========================
    nodeid/pflags: 1 1 db_version : 11.2.0.2
    parse_schema : xxx
    plan_hash : 1672204165
    plan_hash_2 : 1960934971
    Outline Data:
    /*+
    BEGIN_OUTLINE_DATA
    IGNORE_OPTIM_EMBEDDED_HINTS
    OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
    DB_VERSION('11.2.0.2')
    OPT_PARAM('optimizer_dynamic_sampling' 6)
    ALL_ROWS
    OUTLINE_LEAF(@"SEL$1")
    INDEX_RS_ASC(@"SEL$1" "SUBSCRIPTION"@"SEL$1" ("SUBSCRIPTION"."MSISDN"))
    END_OUTLINE_DATA
    Query Block Registry:
    SEL$1 0xf4ea2a20 (PARSER) [FINAL]
    call(in-use=259392, alloc=343912), compile(in-use=170344, alloc=270888), execution(in-use=344120, alloc=346656)
    End of Optimizer State Dump
    Dumping Hints
    =============
    ====================== END SQL Statement Dump ======================
    Edited by: user3754081 on 2012-06-12 08:07

  • Cpu time is not getting displayed in explain plan

    Hi All,
    I am trying to analyze one query using explain plan .like below
    1) explain plan for
    SELECT /*+ parallel(tsp,8) use_hash( tsp tp) */ count(1)
    FROM router tp,
    receiver tsp
    WHERE tp.rs = tsp.rp
    AND creater_date >=to_date('04032009000000','ddmmyyyyhh24miss')
    and tsp.XVF is not null
    and tp.XVF is not null
    and tp.role_name='BR';
    2)@$ORACLE_HOME/rdbms/admin/utlxpls.sql
    But i am getting only following columns in result .
    | Id | Operation | Name | Rows | Bytes | Cost |
    No Cpu time preset .
    How can i extimate CPU time ?
    Pls help
    Thanks

    am_73798 wrote:
    I am trying to analyze one query using explain plan .like below
    But i am getting only following columns in result .
    | Id | Operation | Name | Rows | Bytes | Cost |
    No Cpu time preset .
    How can i extimate CPU time ?You need to mention your database version (4-digits, e.g. 9.2.0.8).
    In Oracle 9i CPU costing is disabled by default, you need to gather WORKLOAD system statistics to enable the CPU costing.
    In 10g CPU costing is enabled by default and uses default NOWORKLOAD system statistics if no WORKLOAD system statistics have been gathered. It can only be disabled by setting an undocumented parameter or by changing the OPTIMIZER_FEATURES_ENABLE parameter back to 9i compatibility.
    You can check the status of your system statistics by running the following query in SQL*Plus:
    column sname format a20
    column pname format a20
    column pval2 format a20
    select
    sname
    , pname
    , pval1
    , pval2
    from
    sys.aux_stats$;Can you show us the actual (complete) output you get from "utlxpls.sql"? Use the \ tag to preserve formatting here:
    \output
    \will show asoutput
    Regards,
    Randolf
    Oracle related stuff blog:
    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/                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Same sqlID with different  execution plan  and  Elapsed Time (s), Executions time

    Hello All,
    The AWR reports for two days  with same sqlID with different  execution plan  and  Elapsed Time (s), Executions time please help me to find out what is  reason for this change.
    Please find the below detail 17th  day my process are very slow as compare to 18th
    17th Oct                                                                                                          18th Oct
    221,808,602
    21
    2tc2d3u52rppt
    213,170,100
    72,495,618
    9c8wqzz7kyf37
    209,239,059
    71,477,888
    9c8wqzz7kyf37
    139,331,777
    1
    7b0kzmf0pfpzn
    144,813,295
    1
    0cqc3bxxd1yqy
    102,045,818
    1
    8vp1ap3af0ma5
    128,892,787
    16,673,829
    84cqfur5na6fg
    89,485,065
    1
    5kk8nd3uzkw13
    127,467,250
    16,642,939
    1uz87xssm312g
    67,520,695
    8,058,820
    a9n705a9gfb71
    104,490,582
    12,443,376
    a9n705a9gfb71
    62,627,205
    1
    ctwjy8cs6vng2
    101,677,382
    15,147,771
    3p8q3q0scmr2k
    57,965,892
    268,353
    akp7vwtyfmuas
    98,000,414
    1
    0ybdwg85v9v6m
    57,519,802
    53
    1kn9bv63xvjtc
    87,293,909
    1
    5kk8nd3uzkw13
    52,690,398
    0
    9btkg0axsk114
    77,786,274
    74
    1kn9bv63xvjtc
    34,767,882
    1,003
    bdgma0tn8ajz9
    Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
    The other big difference is the average read time on two days
    Tablespace IO Stats
    17th Oct
    Tablespace
    Reads
    Av Reads/s
    Av Rd(ms)
    Av Blks/Rd
    Writes
    Av Writes/s
    Buffer Waits
    Av Buf Wt(ms)
    INDUS_TRN_DATA01
    947,766
    59
    4.24
    4.86
    185,084
    11
    2,887
    6.42
    UNDOTBS2
    517,609
    32
    4.27
    1.00
    112,070
    7
    108
    11.85
    INDUS_MST_DATA01
    288,994
    18
    8.63
    8.38
    52,541
    3
    23,490
    7.45
    INDUS_TRN_INDX01
    223,581
    14
    11.50
    2.03
    59,882
    4
    533
    4.26
    TEMP
    198,936
    12
    2.77
    17.88
    11,179
    1
    732
    2.13
    INDUS_LOG_DATA01
    45,838
    3
    4.81
    14.36
    348
    0
    1
    0.00
    INDUS_TMP_DATA01
    44,020
    3
    4.41
    16.55
    244
    0
    1,587
    4.79
    SYSAUX
    19,373
    1
    19.81
    1.05
    14,489
    1
    0
    0.00
    INDUS_LOG_INDX01
    17,559
    1
    4.75
    1.96
    2,837
    0
    2
    0.00
    SYSTEM
    7,881
    0
    12.15
    1.04
    1,361
    0
    109
    7.71
    INDUS_TMP_INDX01
    1,873
    0
    11.48
    13.62
    231
    0
    0
    0.00
    INDUS_MST_INDX01
    256
    0
    13.09
    1.04
    194
    0
    2
    10.00
    UNDOTBS1
    70
    0
    1.86
    1.00
    60
    0
    0
    0.00
    STG_DATA01
    63
    0
    1.27
    1.00
    60
    0
    0
    0.00
    USERS
    63
    0
    0.32
    1.00
    60
    0
    0
    0.00
    INDUS_LOB_DATA01
    62
    0
    0.32
    1.00
    60
    0
    0
    0.00
    TS_AUDIT
    62
    0
    0.48
    1.00
    60
    0
    0
    0.00
    18th Oct
    Tablespace
    Reads
    Av Reads/s
    Av Rd(ms)
    Av Blks/Rd
    Writes
    Av Writes/s
    Buffer Waits
    Av Buf Wt(ms)
    INDUS_TRN_DATA01
    980,283
    91
    1.40
    4.74

    The AWR reports for two days  with same sqlID with different  execution plan  and  Elapsed Time (s), Executions time please help me to find out what is  reason for this change.
    Please find the below detail 17th  day my process are very slow as compare to 18th
    You wrote with different  execution plan, I  think, you saw plans. It is very difficult, you get old plan.
    I think Execution plans is not changed in  different days, if you not added index  or ...
    What say ADDM report about this script?
    As you know, It is normally, different Elapsed Time for same statement in different  day.
    It is depend your database workload.
    It think you must use SQL Access and SQl Tuning advisor for this script.
    You can get solution for slow running problem.
    Regards
    Mahir M. Quluzade

  • Explain plan generating it self taking very long time !!! What to do ?

    Hi,
    I am trying to generate explain plan for a query which is running more than 2 hours. I am trying to generate explain plan for query by "explin plan for select ..." but it self is taking very long time.
    Kindly suggest me how to reduce time for explain plan ? Secondly why explain plan itself taking very long time ?
    thanks & regards
    PKP

    Just guessing here, but I've experienced this behaviour when I did two explain's within a second. This is because a plan is identified by a statement_id or, if you don't provide a statement_id, by the timestamp (of DATE datatype). So if you execute two explain plans within the second (using a script), it has two sets of data with the same primary key. The hierarchical query that needs to be executed to provide you the nicely indented text, will exponentially expand in this case.
    Maybe time to clean up your plan_table ?
    Hope this helps.
    Regards,
    Rob.

  • Explain Plan and Execution Plan in 10gR2.

    Hi,
    Version 10.2.0.1.0.
    I have two questions:
    1) If the explain plan differs from the execution path in this version, then, is it safe to assume that the statistics are stale (or not gathered at all) on the underlying tables?
    2) Can you in any way make a query use RBO instead of CBO? (I know it doesn't make any sense since CBO is lot smarter, but, for purely academic reasons).
    Thank you,
    Rahul.

    The rule based optimizer is most definitely present in 10gR2. It might not be in the documentation, but it is still there.
    C:\sql>sqlplus test/test
    SQL*Plus: Release 10.2.0.2.0 - Production on Tue Oct 10 15:43:34 2006
    Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
    With the Partitioning, OLAP and Data Mining options
    test@SVTEST> set autotrace traceonly
    test@SVTEST> alter session set optimizer_mode=rule;
    Session altered.
    Elapsed: 00:00:00.01
    test@SVTEST> select * from dual;
    Elapsed: 00:00:00.03
    Execution Plan
    Plan hash value: 272002086
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | TABLE ACCESS FULL| DUAL |
    Note
    - rule based optimizer used (consider using cbo)
    Statistics
    1 recursive calls
    0 db block gets
    3 consistent gets
    2 physical reads
    0 redo size
    407 bytes sent via SQL*Net to client
    381 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    test@SVTEST>

  • Explain plan - lower cost but higher response time in 11g compared to 10g

    Hello,
    I have a strange scenario where 'm migrating a db from standalone Sun FS running 10g RDBMS to a 2-Node Sun/ASM 11g RAC env. The issue is with response time of queries -
    In 11g Env:
    SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
    LAST_ANALYZED NUM_ROWS
    11-08-2012 18:21:12 3413956
    Elapsed: 00:00:00.30
    In 10g Env:
    SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
    LAST_ANAL NUM_ROWS
    07-NOV-12 3502160
    Elapsed: 00:00:00.04If you look @ the response times, even a simple query on the dba_tables takes ~8 times. Any ideas what might be causing this? I have compared the XPlans and they are exactly the same, moreover, the cost is less in the 11g env compared to the 10g env, but still the response time is higher.
    BTW - 'm running the queries directly on the server, so no network latency in play here.
    Thanks in advance
    aBBy.

    *11g Env:*
    PLAN_TABLE_OUTPUT
    Plan hash value: 4147636274
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1104 | 376K| 394 (1)| 00:00:05 |
    | 1 | SORT ORDER BY | | 1104 | 376K| 394 (1)| 00:00:05 |
    | 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1104 | 376K| 393 (1)| 00:00:05 |
    |* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1136 | | 15 (0)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
    3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
    15 rows selected.
    *10g Env:*
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 4147636274
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1137 | 373K| 389 (1)| 00:00:05 |
    | 1 | SORT ORDER BY | | 1137 | 373K| 389 (1)| 00:00:05 |
    | 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1137 | 373K| 388 (1)| 00:00:05 |
    |* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1137 | | 15 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
    15 rows selected.
    The query used is:
    explain plan for
    select
    NCP_DETAIL_ID ,
    NCP_ID ,
    STATUS_ID ,
    FIBER_NODE ,
    NODE_DESC ,
    GL ,
    FTA_ID ,
    OLD_BUS_ID ,
    VIRTUAL_NODE_IND ,
    SERVICE_DELIVERY_TYPE ,
    HHP_AUDIT_QTY ,
    COMMUNITY_SERVED ,
    CMTS_CARD_ID ,
    OPTICAL_TRANSMITTER ,
    OPTICAL_RECEIVER ,
    LASER_GROUP_ID ,
    UNIT_ID ,
    DS_SLOT ,
    DOWNSTREAM_PORT_ID ,
    DS_PORT_OR_MOD_RF_CHAN ,
    DOWNSTREAM_FREQ ,
    DOWNSTREAM_MODULATION ,
    UPSTREAM_PORT_ID ,
    UPSTREAM_PORT ,
    UPSTREAM_FREQ ,
    UPSTREAM_MODULATION ,
    UPSTREAM_WIDTH ,
    UPSTREAM_LOGICAL_PORT ,
    UPSTREAM_PHYSICAL_PORT ,
    NCP_DETAIL_COMMENTS ,
    ROW_CHANGE_IND ,
    STATUS_DATE ,
    STATUS_USER ,
    MODEM_COUNT ,
    NODE_ID ,
    NODE_FIELD_ID ,
    CREATE_USER ,
    CREATE_DT ,
    LAST_CHANGE_USER ,
    LAST_CHANGE_DT ,
    UNIT_ID_IP ,
    US_SLOT ,
    MOD_RF_CHAN_ID ,
    DOWNSTREAM_LOGICAL_PORT ,
    STATE
    from markethealth.NCP_DETAIL_TAB
    WHERE UNIT_ID = :B1
    ORDER BY UNIT_ID, DS_SLOT, DS_PORT_OR_MOD_RF_CHAN, FIBER_NODE
    This is the query used for Query 1.
    Stats differences are:
    1. Rownum differes by apprx - 90K more rows in 10g env
    2. RAC env has 4 additional columns (excluded in the select statement for analysis purposes).
    3. Gather Stats was performed with estimate_percent = 20 in 10g and estimate_percent = 50 in 11g.

  • Resource plan to limit execution time

    Hi,
    I am using 11.1.0.7 database. Can anyone guide me how should i create a resource consumer group/resource plan and assign to my user "dev" so that any query run by this user should not take more than 10 minutes for execution and should abort if execution time exceeds 10 minutes.
    Thanks
    Salman

    BEGIN
    dbms_resource_manager.clear_pending_area();
    dbms_resource_manager.create_pending_area();
    dbms_resource_manager.create_consumer_group(consumer_group => 'mytest_group', comment => '', cpu_mth => 'ROUND-ROBIN');
    dbms_resource_manager.submit_pending_area();
    END;
    BEGIN
    dbms_resource_manager.clear_pending_area();
    dbms_resource_manager.create_pending_area();
    dbms_resource_manager.create_plan( 'MYTEST_PLAN', '');
    dbms_resource_manager.create_plan_directive(
        plan => 'MYTEST_PLAN',
        group_or_subplan => 'MYTEST_GROUP',
        comment => '',
        cpu_p1 => NULL, cpu_p2 => NULL, cpu_p3 => NULL, cpu_p4 => NULL,
        cpu_p5 => NULL, cpu_p6 => NULL, cpu_p7 => NULL, cpu_p8 => NULL,
        parallel_degree_limit_p1 => NULL,
        active_sess_pool_p1 => NULL,
        queueing_p1 => NULL,
        switch_group => 'KILL_SESSION',
        switch_time => 600,
        switch_estimate => false,
        max_est_exec_time => NULL,
        undo_pool => NULL,
        max_idle_time => NULL,
        max_idle_blocker_time => NULL,
        switch_time_in_call => NULL
    dbms_resource_manager.create_plan_directive(
        plan => 'MYTEST_PLAN',
        group_or_subplan => 'OTHER_GROUPS',
        comment => '',
        cpu_p1 => NULL, cpu_p2 => NULL, cpu_p3 => NULL, cpu_p4 => NULL,
        cpu_p5 => NULL, cpu_p6 => NULL, cpu_p7 => NULL, cpu_p8 => NULL,
        parallel_degree_limit_p1 => NULL,
        active_sess_pool_p1 => NULL,
        queueing_p1 => NULL,
        switch_group => NULL,
        switch_time => NULL,
        switch_estimate => false,
        max_est_exec_time => NULL,
        undo_pool => NULL,
        max_idle_time => NULL,
        max_idle_blocker_time => NULL,
        switch_time_in_call => NULL
    dbms_resource_manager.submit_pending_area();
    END;
    BEGIN
    dbms_resource_manager.clear_pending_area();
    dbms_resource_manager.create_pending_area();
    dbms_resource_manager.set_consumer_group_mapping(
        dbms_resource_manager.oracle_user,
        'DEV',
        'MYTEST_GROUP'
    dbms_resource_manager.submit_pending_area();
    END;

Maybe you are looking for

  • Problem in Moving Files Locally after FTP

    I am being stuck in the middle of my application development. What simple I need to do is to get all the files from location and put them all on FTP site. After doing FTP I need to put these files locally to other flder. I am done with FTP site files

  • Need to upgrage Ram to HP laptop HP G62-361TX

    Hi Friends, i need to upgrade Ram in HP Laptop Model:G62-361TX -  I am 4 GB Ram ( 4GB 1RX8 - PC3L-12800S-11-12-84) it possible to upgrade in laptop

  • Sapscripts to adobe forms successfully completed.

    I have converted years old sapscripts to adobe forms with an average time of completing the form as 1.5 month. These are all offline and interactive adobe forms with barcodes Areas I have covered are SD,MM,HR,FI I am offering help and advise for peop

  • LDAP and CF8

    Hi everyone, I have been unsuccessful in getting CFLDAP to query a LDAP from Site Server. I did get it to work in ASP. Could it be that ASP has a better way of connecting to the datasource? Ravi.

  • Vendor doesn't exist.

    Dear all, I want to make an A/P entry but it says the vender HG12 doesn’t exist. Could you please tell me where I can make necessary settings so that I can able to post to that particular vendor. Thanks in advance!!