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
-
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 statementsome 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 -
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).
ThanksTom.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.
ThanksExplain 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,
SigcleThe 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 processedHi,
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 AMuser570138 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
Thanksam_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.74The 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
PKPJust 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
SalmanBEGIN
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
-
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.
-
Dear all, I want to make an A/P entry but it says the vender HG12 doesnt 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!!