Strange behavior of explain plan
Hello i don't know if this is the correct category for posting my issue.
I ma facing a strange behavior of the explain plan. What i mean!
I have a query which runs very fast and it is well optimized. the explain plan shows very good results in cost and execution time.
when i am running the query for a second or a third time is appearing a different explain plan with not such a good cost and execution time.
Could you please guide me what it might be wrong???
thanks a lot
HI i found the correct category
thanks
Similar Messages
-
Strange behavior of Planning manager
Hi All,
I am working on forecast interface, facing a strange behavior of Planning manager.
Our application planning manager is in active status, we set MRP:Planning Manager Batch Size profile value as 2000 and MRP:Planning Manager Max Workers value as 10 in our application(11.5.10.2).
we have loaded 2Lac's of records in MRP_FORECAST_INTERFACE table with process_status=2. Almost running for 12hours, even one record status(process_status) also not changed. the code which we are using to load in interface table is using in production since 3 years.. Can any one help me to figerout the issue ..
Thanksplease search this forum. it has been answered many times
over.
i dont have the thread that answers it right way - but if you
do a search im sure youll find it (i did jsut recently) -
Strange explain plan when query SYS tables
Oracle Version 9.2.0.7
We have an application that runs the following query on Oracle 9.2.0.7
SELECT T1.TABLE_NAME,T1.COLUMN_NAME, T1.SRID, T2.SDO_UB, T2.SDO_LB, T1.OWNER FROM ALL_SDO_GEOM_METADATA T1, TABLE(T1.DIMINFO) T2 WHERE T1.OWNER=UPPER(:"SYS_B_0") AND T1.TABLE_NAME=UPPER(:"SYS_B_1")
Without the self join the query is fine, but with the self join on our customers database the explain plan is doing full table scans and Hash Joins on SYS tables and takes 2 minutes.
Rows Row Source Operation
2 FILTER
2 NESTED LOOPS
1 TABLE ACCESS FULL SDO_GEOM_METADATA_TABLE
2 COLLECTION ITERATOR PICKLER FETCH
1 UNION-ALL
0 FILTER
0 NESTED LOOPS OUTER
0 HASH JOIN
37 TABLE ACCESS FULL TS$
0 HASH JOIN OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS FULL USER$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
0 FILTER
0 NESTED LOOPS OUTER
0 HASH JOIN
54 TABLE ACCESS FULL USER$
0 HASH JOIN
29447 TABLE ACCESS FULL OBJ$
0 HASH JOIN OUTER
0 HASH JOIN OUTER
0 HASH JOIN OUTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS CLUSTER TS$
0 INDEX UNIQUE SCAN I_TS# (object id 7)
0 TABLE ACCESS CLUSTER COL$
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER COLTYPE$
0 TABLE ACCESS FULL USER$
0 TABLE ACCESS FULL OBJ$
0 TABLE ACCESS FULL USER$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
On our development database it takes 0.07 sec with no full table scans and no hash joins.
Rows Row Source Operation
2 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
1 INDEX RANGE SCAN SDO_GEOM_IDX (object id 36753)
1 UNION-ALL
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS CLUSTER TS$
0 INDEX UNIQUE SCAN I_TS# (object id 7)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS CLUSTER TS$
0 INDEX UNIQUE SCAN I_TS# (object id 7)
0 TABLE ACCESS CLUSTER COL$
0 TABLE ACCESS CLUSTER COLTYPE$
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX RANGE SCAN I_OBJ3 (object id 38)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
2 COLLECTION ITERATOR PICKLER FETCH
ALL_SDO_GEOM_METADATA is a view in the MDSYS schema (generated by Oracle ).
SELECT SDO_OWNER OWNER,
SDO_TABLE_NAME TABLE_NAME,
SDO_COLUMN_NAME COLUMN_NAME,
SDO_DIMINFO DIMINFO,
SDO_SRID SRID
FROM SDO_GEOM_METADATA_TABLE
WHERE
(exists
(select table_name from all_tables
where table_name=sdo_table_name
and owner = sdo_owner
union all
select table_name from all_object_tables
where table_name=sdo_table_name
and owner = sdo_owner
union all
select view_name table_name from all_views
where view_name=sdo_table_name
and owner = sdo_owner))
Statistics have been gathered for the MDSYS user.
If this had not been SYS schema I would have immediately concluded that fresh statistics are required. The SYS objects concerend are valid with all indexes
From my understanding you are not meant to gather stats for the SYS schema in Oracle 9 as Data Dictionary queries still uses RBO?
Any ideas as to why Oracle is doing full table scans when querying SYS tables? The optimizer_mode is set to FIRST_ROWS.
Any ideas greatly recevied.
ThanksMaybe I'm missing something but this:
INDEX FULL SCAN SISESTAT I0_ESTRUTURA_COMERCIALindicates that one of those indexes is being used.
This:
T_ESTRUTURA_COMERCIALIs nowhere to be found in your Explain Plan. It appears that either you have posted the wrong plan
or Oracle is doing a query rewrite to a materialized view. -
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/ -
We have two schemes in our database. One general and one history. When record in general scheme is modified trigger updates record in history scheme and inserts one new row in history scheme. There are indexes on columns that are used in updates(where part :)) and as i can see(using explain plan for) indexes are used. Problem is that when client application fires update it takes too long(6 sec) to be executed. Actually there is very strange behavior, it executes 5 updates in one second then next one takes 6 seconds. Tables have only around 1000 rows. Is there any way to see whole explain plan including trigger execution, when i issue exp plan for update of general scheme i get only exp plan for update - there are no informations about trigger. Also if anybody has some advice I am more than willing to hear :)
You might want to consider enabling a SQL Trace via DBMS_MONITOR for more recent versions or setting the SQL_TRACE parameter in past versions. Once you have the output you can use TKPROF. Once you have the TKPROF report you can try and find the queries that are taking the most time to execute.
Hope that helps! -
Problems with explain plan and statement
Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AMtobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
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/ -
Strange Behavior with gMSA in Server 2012 R2
Greetings,
I have been doing some testing with gMSA Accounts in a Server 2012 R2 environment (two separate environments, actually), and I have noticed something very strange that occurred in both environments, which does not appear to be occurring in one of our customer's
self-managed environments.
We created a Group Managed Service Account using the following article:
http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx
Everything went smoothly, and the account installs/tests successfully on both of the hosts that we are testing on. I am able to set my services to run under the account, and most of them appear to work fine. I am having some issues with a few of my services,
and I believe that the strange behavior I am seeing may have something to do with this - described below:
As soon as I set the service's Log On Account (via the Log On Tab under the Service's Properties), the entirety of the "Log On" tab changes to "greyed out," and I am unable to change the Log On account back via the GUI (Screenshot
attached).
I found that I am able to successfully change the account via Command Line using sc.exe, but the Log On tab remains greyed out! So far, I have found nothing to remedy this, but confirmed that it happens for any service I set to use the gMSA as the Logon
Account, and that it happens in 2 separate test environments, but not in a Customer's production environment - very strange.
All servers in this environment are running Server 2012 R2, and domain Functional Level is currently Server 2012.
I have been unable to find any information online about this behavior, so I am hoping someone has seen this before, and can explain why this is happening.
NickVIvian,
Yes, we used the Install-AdServiceAccount gMSA command on each host using the gMSA account, and then ran Test-AdServiceAccount gMSA, which returned "True."
However, one thing I noticed is that if I run Test-ADServiceAccount gMSA as a Local Administrator, it fails with the following:
PS C:\Users\Administrator> Test-AdServiceAccount gMSA$
Test-AdServiceAccount : The server has rejected the client credentials.
At line:1 char:1
+ Test-AdServiceAccount gMSA$
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : SecurityError: (:) [Test-ADServiceAccount], AuthenticationException
+ FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.Security.Authentication.AuthenticationException,Microsoft.A
ctiveDirectory.Management.Commands.TestADServiceAccount
If I run Test-ADServiceAccount gMSA as Domain Administrator, it returns true:
PS C:\Users\Administrator.<domainname>> Test-AdServiceAccount gMSA$
True
Is this normal?
Overall, I think the issue I am running into is at the Application Level, and not a problem with the gMSA, as it appears to be working. (Can Start/Stop services without any issues). I will be investigating my issue further with 3rd-party vendors, unless
you think there is something wrong with my gMSA accounts based on the information I have provided.
Nick -
SQL strange behavior after 11g upgrade
Hi all,
After upgrading from 10.2.0.3 to 11.2.0.1 (64-bit RedHat), one of my SQLs behaves very strangely.
These are the facts:
- This is upgrade evaluation phase in 'lab' environment
- First run (after db restart) returns results very quickly (acceptable 0.4 secs)
- Every consecutive run is very slow (3-4 minutes)
- Explain Plan did NOT change between runs;
- Number of 'consistent gets' changed drastically (from few thousands to few millions) ...which would usually lead to inefficient data access plan (index), but again, the explain plan did not change!
- If I flush shared_pool, next run is quick again, and the story repeats ... flushing shared_poll is possible in test system only, it's out of question for prod system of course
- All above happens in 'lab' environment, i.e. no multi-user load yet ... practically 'one-session' system
- I have tried both AMM and ASSM memory management(s) and same problem happens regardless (my old 10g database uses ASSM and I am trying to implement ASM in new 11g db)
- On same server, the SQL in question performs correctly if I run it in 10g environment;
- I have updated my 11g Oracle software/db with the latest CPU;
In addition, I have played with 'result cache' in 11g, and putting 'result_cache' hint in my sql resolved the issue. But that will open a lot of new questions for implementation in real app environment ... so at this moment, I don't want to evaluate result cache ...if I don't have to
I am thinking to try this on another server and eliminate eventual issue with some kind of faulty memory on existing server ... after that - to open ticket with Oracle ...
Any similar experience out there? Any thoughts?
Thanks a lot ...Welcome to the forums !
How to post a tuning request
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long ...
HTH
Srini -
Strange behavior of the Macbook pro display
Hi to all
I'm using my MacBook pro, and notice some strange behavior after open several windows or applications, I don't know how to explain, so here is a photo:
http://www.flickr.com/photos/86155326@N00/
I have tried: go back to 10.4.6 / create a new account / Hardware test... and Nothing.
Any suggestions?
PedroI am having the exact same problem(and no one is replying to my post either), I read in another post of someone who had a somewhat similar issue and someone commented that it was bad VRAM and warranted the logic board to be replaced. I'm hoping this is not the case, or at least hoping the problem does not get worse because I am in school and can't be without this computer for 2 weeks while it gets repaired..I'm hoping I can last til the holidays...
pictures of my problem:
http://www.rpi.edu/~neala/pics/display/Messed%20up%20desktop.png
http://www.rpi.edu/~neala/pics/display/Picture%204.png
Sometimes I can make it go away by moving windows, and sometimes that makes it worse... this computer is only 100 days old...come on apple..help us out! -
The below same query runs fast at PL/SQL , while the same query run from front end (EBS R 12.0.4) using concurrent request runs verl slow , both has diffrent plan , please share some thought.
Below query when i run from backend (PL/SQL Developer) it returns row within a second
SELECT /*+ gather_plan_statistics product_item_2.txt */ OH.ORG_ID,BUNIT.BU_ID,OL.INVENTORY_ITEM_ID,CUST.account_number,CUST.ACCOUNT_NAME,CUST.CUSTOMER_CLASS_CODE,
NVL(SUM(OL.FULFILLED_QUANTITY),0) as sale_qty
FROM
OE_ORDER_HEADERS_ALL OH,OE_ORDER_LINES_ALL OL,
HZ_CUST_ACCOUNTS CUST,mtl_categories_vl CAT,
mtl_item_categories IC,(select FLEX_VALUE BU_ID,DESCRIPTION B_NAME from fnd_flex_values_vl t
where t.FLEX_VALUE_SET_ID ='1012990') BUNIT
WHERE OH.HEADER_ID = OL.HEADER_ID
AND CUST.CUST_ACCOUNT_ID =
(SELECT DISTINCT ACCT.CUST_ACCOUNT_ID
FROM HZ_CUST_ACCOUNTS ACCT,HZ_CUST_ACCT_SITES_ALL ACCT_SITE,
HZ_LOCATIONS LOC,HZ_PARTY_SITES PARTY_SITE,
HZ_CUST_SITE_USES_ALL SUSE,HZ_PARTIES P
WHERE ACCT.PARTY_ID = PARTY_SITE.PARTY_ID
AND ACCT.CUST_ACCOUNT_ID = ACCT_SITE.CUST_ACCOUNT_ID
AND SUSE.CUST_ACCT_SITE_ID = ACCT_SITE.CUST_ACCT_SITE_ID
AND ACCT_SITE.PARTY_SITE_ID = PARTY_SITE.PARTY_SITE_ID
AND LOC.LOCATION_ID = PARTY_SITE.LOCATION_ID
AND SUSE.SITE_USE_ID = OL.SHIP_TO_ORG_ID
AND P.PARTY_ID = ACCT.PARTY_ID
AND P.PARTY_ID = PARTY_SITE.PARTY_ID
AND SUSE.SITE_USE_CODE = 'SHIP_TO'
AND ACCT_SITE.ORG_ID = &P_ORG_ID
AND OH.ORG_ID = &P_ORG_ID
AND OL.ACTUAL_SHIPMENT_DATE BETWEEN &P_FROM_DATE AND &P_TO_DATE
AND OL.UNIT_SELLING_PRICE != 0
AND OL.LINE_CATEGORY_CODE = 'ORDER'
AND OL.ORDERED_ITEM = NVL(&ITEM_HIGH, OL.ORDERED_ITEM)
AND BUNIT.BU_ID = nvl(&p_business_unit,bunit.bu_id)
AND CAT.CATEGORY_ID = IC.CATEGORY_ID
AND CAT.STRUCTURE_ID = 50289
AND IC.INVENTORY_ITEM_ID = OL.INVENTORY_ITEM_ID
AND IC.ORGANIZATION_ID = OH.SHIP_FROM_ORG_ID
and cat.SEGMENT3 = BUNIT.BU_ID
GROUP BY
OH.ORG_ID,BUNIT.BU_ID,OL.INVENTORY_ITEM_ID,CUST.account_number,CUST.ACCOUNT_NAME,CUST.CUSTOMER_CLASS_CODE
ORDER BY 1Plan for above query is as follows
SQL> set pagesize 1000
SQL> /
PLAN_TABLE_OUTPUT
SQL_ID 5g71mvqaat8x3, child number 0
Plan hash value: 610424373
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
| 1 | HASH GROUP BY | | 1 | 1 | 2 |00:00:00.64 | 144K| | | |
| 2 | NESTED LOOPS | | 1 | 1 | 71 |00:00:00.30 | 144K| | | |
| 3 | NESTED LOOPS | | 1 | 1 | 1704 |00:00:00.26 | 138K| | | |
|* 4 | HASH JOIN | | 1 | 1 | 3312 |00:00:00.05 | 132K| 887K| 887K| 1236K (0)|
| 5 | TABLE ACCESS BY INDEX ROWID | MTL_ITEM_CATEGORIES | 1 | 506 | 1075 |00:00:00.02 | 361 | | | |
| 6 | NESTED LOOPS | | 1 | 1 | 1077 |00:00:00.04 | 24 | | | |
| 7 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 19 | | | |
| 8 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 18 | | | |
| 9 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 15 | | | |
|* 10 | TABLE ACCESS BY INDEX ROWID | FND_FLEX_VALUES | 1 | 1 | 1 |00:00:00.01 | 13 | | | |
|* 11 | INDEX RANGE SCAN | IDX$$_65860003 | 1 | 22 | 52 |00:00:00.01 | 2 | | | |
|* 12 | INDEX UNIQUE SCAN | FND_FLEX_VALUES_TL_U1 | 1 | 1 | 1 |00:00:00.01 | 2 | | | |
|* 13 | TABLE ACCESS BY INDEX ROWID | MTL_CATEGORIES_B | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 14 | INDEX RANGE SCAN | IDX$$_79530001 | 1 | 1 | 2 |00:00:00.01 | 1 | | | |
|* 15 | INDEX UNIQUE SCAN | MTL_CATEGORIES_TL_U1 | 1 | 1 | 1 |00:00:00.01 | 1 | | | |
|* 16 | INDEX RANGE SCAN | IDX$$_78250002 | 1 | 1528 | 1075 |00:00:00.01 | 5 | | | |
|* 17 | TABLE ACCESS BY INDEX ROWID | OE_ORDER_LINES_ALL | 1 | 51 | 138 |00:00:00.01 | 132K| | | |
|* 18 | INDEX SKIP SCAN | OE_ORDER_LINES_N26 | 1 | 14977 | 113K|00:00:00.57 | 1208 | | | |
| 19 | TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS | 3312 | 1 | 1704 |00:00:00.09 | 5188 | | | |
|* 20 | INDEX UNIQUE SCAN | HZ_CUST_ACCOUNTS_U1 | 3312 | 1 | 1704 |00:00:00.04 | 3484 | | | |
| 21 | NESTED LOOPS | | 8 | 1 | 2 |00:00:00.01 | 76 | | | |
| 22 | NESTED LOOPS | | 8 | 1 | 2 |00:00:00.01 | 72 | | | |
| 23 | NESTED LOOPS | | 8 | 1 | 2 |00:00:00.01 | 66 | | | |
| 24 | NESTED LOOPS | | 8 | 1 | 2 |00:00:00.01 | 62 | | | |
| 25 | NESTED LOOPS | | 8 | 1 | 2 |00:00:00.01 | 56 | | | |
|* 26 | TABLE ACCESS BY INDEX ROWID| HZ_CUST_SITE_USES_ALL | 8 | 1 | 8 |00:00:00.01 | 32 | | | |
|* 27 | INDEX UNIQUE SCAN | HZ_CUST_SITE_USES_U1 | 8 | 1 | 8 |00:00:00.01 | 24 | | | |
|* 28 | TABLE ACCESS BY INDEX ROWID| HZ_CUST_ACCT_SITES_ALL | 8 | 25087 | 2 |00:00:00.01 | 24 | | | |
|* 29 | INDEX UNIQUE SCAN | HZ_CUST_ACCT_SITES_U1 | 8 | 1 | 8 |00:00:00.01 | 16 | | | |
| 30 | TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS | 2 | 176K| 2 |00:00:00.01 | 6 | | | |
|* 31 | INDEX UNIQUE SCAN | HZ_CUST_ACCOUNTS_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
|* 32 | INDEX UNIQUE SCAN | HZ_PARTIES_U1 | 2 | 176K| 2 |00:00:00.01 | 4 | | | |
|* 33 | TABLE ACCESS BY INDEX ROWID | HZ_PARTY_SITES | 2 | 188K| 2 |00:00:00.01 | 6 | | | |
|* 34 | INDEX UNIQUE SCAN | HZ_PARTY_SITES_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
|* 35 | INDEX UNIQUE SCAN | HZ_LOCATIONS_U1 | 2 | 174K| 2 |00:00:00.01 | 4 | | | |
|* 36 | TABLE ACCESS BY INDEX ROWID | OE_ORDER_HEADERS_ALL | 1704 | 1 | 71 |00:00:00.05 | 6816 | | | |
|* 37 | INDEX UNIQUE SCAN | OE_ORDER_HEADERS_U1 | 1704 | 1 | 1704 |00:00:00.03 | 5112 | | | |
Predicate Information (identified by operation id):
4 - access("IC"."INVENTORY_ITEM_ID"="OL"."INVENTORY_ITEM_ID")
10 - filter("B"."FLEX_VALUE"=NVL('02',"B"."FLEX_VALUE"))
11 - access("B"."FLEX_VALUE_SET_ID"=1012990)
12 - access("B"."FLEX_VALUE_ID"="T"."FLEX_VALUE_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
13 - filter("B"."STRUCTURE_ID"=50289)
14 - access("B"."SEGMENT3"="B"."FLEX_VALUE")
filter("B"."SEGMENT3" IS NOT NULL)
15 - access("B"."CATEGORY_ID"="T"."CATEGORY_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
16 - access("B"."CATEGORY_ID"="IC"."CATEGORY_ID")
17 - filter(("OL"."ORDERED_ITEM"=NVL('101468',"OL"."ORDERED_ITEM") AND "OL"."UNIT_SELLING_PRICE"<>0))
18 - access("OL"."LINE_CATEGORY_CODE"='ORDER' AND "OL"."ACTUAL_SHIPMENT_DATE">=TO_DATE('2012-02-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"OL"."ACTUAL_SHIPMENT_DATE"<=TO_DATE('2012-02-23 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
filter(("OL"."ACTUAL_SHIPMENT_DATE">=TO_DATE('2012-02-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "OL"."LINE_CATEGORY_CODE"='ORDER'
AND "OL"."ACTUAL_SHIPMENT_DATE"<=TO_DATE('2012-02-23 00:00:00', 'yyyy-mm-dd hh24:mi:ss')))
20 - access("CUST"."CUST_ACCOUNT_ID"=)
26 - filter("SUSE"."SITE_USE_CODE"='SHIP_TO')
27 - access("SUSE"."SITE_USE_ID"=:B1)
28 - filter("ACCT_SITE"."ORG_ID"=142)
29 - access("SUSE"."CUST_ACCT_SITE_ID"="ACCT_SITE"."CUST_ACCT_SITE_ID")
31 - access("ACCT"."CUST_ACCOUNT_ID"="ACCT_SITE"."CUST_ACCOUNT_ID")
32 - access("P"."PARTY_ID"="ACCT"."PARTY_ID")
33 - filter(("ACCT"."PARTY_ID"="PARTY_SITE"."PARTY_ID" AND "P"."PARTY_ID"="PARTY_SITE"."PARTY_ID"))
34 - access("ACCT_SITE"."PARTY_SITE_ID"="PARTY_SITE"."PARTY_SITE_ID")
35 - access("LOC"."LOCATION_ID"="PARTY_SITE"."LOCATION_ID")
36 - filter(("OH"."ORG_ID"=142 AND "IC"."ORGANIZATION_ID"="OH"."SHIP_FROM_ORG_ID"))
37 - access("OH"."HEADER_ID"="OL"."HEADER_ID")
85 rows selected.Below plan for the above same query when i run from front end concurrent request it completed within an hour.
SQL> select * from table(dbms_xplan.display_cursor('1gnb26b0q2vxx',NULL,'ALLSTATS LAST'))
2 /
PLAN_TABLE_OUTPUT
SQL_ID 1gnb26b0q2vxx, child number 0
Plan hash value: 408306916
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
| 1 | HASH GROUP BY | | 1 | 1 | 2 |00:36:41.83 | 379M| | | |
| 2 | CONCATENATION | | 1 | | 71 |00:09:30.14 | 379M| | | |
|* 3 | FILTER | | 1 | | 0 |00:00:00.01 | 0 | | | |
| 4 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 5 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 6 | HASH JOIN | | 0 | 4 | 0 |00:00:00.01 | 0 | 715K| 715K| |
| 7 | TABLE ACCESS BY INDEX ROWID | MTL_ITEM_CATEGORIES | 0 | 506 | 0 |00:00:00.01 | 0 | | | |
| 8 | NESTED LOOPS | | 0 | 26 | 0 |00:00:00.01 | 0 | | | |
| 9 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 10 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 11 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 12 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUES | 0 | 22 | 0 |00:00:00.01 | 0 | | | |
|* 13 | INDEX RANGE SCAN | IDX$$_65860003 | 0 | 22 | 0 |00:00:00.01 | 0 | | | |
|* 14 | TABLE ACCESS BY INDEX ROWID| MTL_CATEGORIES_B | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 15 | INDEX RANGE SCAN | MTL_CATEGORIES_B_N3 | 0 | 2 | 0 |00:00:00.01 | 0 | | | |
|* 16 | INDEX UNIQUE SCAN | FND_FLEX_VALUES_TL_U1 | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 17 | INDEX UNIQUE SCAN | MTL_CATEGORIES_TL_U1 | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 18 | INDEX RANGE SCAN | IDX$$_78250002 | 0 | 1528 | 0 |00:00:00.01 | 0 | | | |
|* 19 | TABLE ACCESS FULL | OE_ORDER_LINES_ALL | 0 | 97 | 0 |00:00:00.01 | 0 | | | |
|* 20 | TABLE ACCESS BY INDEX ROWID | OE_ORDER_HEADERS_ALL | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 21 | INDEX UNIQUE SCAN | OE_ORDER_HEADERS_U1 | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 22 | TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 23 | INDEX UNIQUE SCAN | HZ_CUST_ACCOUNTS_U1 | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 24 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 34 | | | |
| 25 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 30 | | | |
| 26 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 24 | | | |
| 27 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 20 | | | |
| 28 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 14 | | | |
|* 29 | TABLE ACCESS BY INDEX ROWID| HZ_CUST_SITE_USES_ALL | 2 | 1 | 2 |00:00:00.01 | 8 | | | |
|* 30 | INDEX UNIQUE SCAN | HZ_CUST_SITE_USES_U1 | 2 | 1 | 2 |00:00:00.01 | 6 | | | |
|* 31 | TABLE ACCESS BY INDEX ROWID| HZ_CUST_ACCT_SITES_ALL | 2 | 9420 | 2 |00:00:00.01 | 6 | | | |
|* 32 | INDEX UNIQUE SCAN | HZ_CUST_ACCT_SITES_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
| 33 | TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS | 2 | 176K| 2 |00:00:00.01 | 6 | | | |
|* 34 | INDEX UNIQUE SCAN | HZ_CUST_ACCOUNTS_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
|* 35 | INDEX UNIQUE SCAN | HZ_PARTIES_U1 | 2 | 176K| 2 |00:00:00.01 | 4 | | | |
|* 36 | TABLE ACCESS BY INDEX ROWID | HZ_PARTY_SITES | 2 | 188K| 2 |00:00:00.01 | 6 | | | |
|* 37 | INDEX UNIQUE SCAN | HZ_PARTY_SITES_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
|* 38 | INDEX UNIQUE SCAN | HZ_LOCATIONS_U1 | 2 | 174K| 2 |00:00:00.01 | 4 | | | |
|* 39 | FILTER | | 1 | | 71 |00:09:30.14 | 379M| | | |
| 40 | NESTED LOOPS | | 1 | 1 | 71 |00:09:30.14 | 379M| | | |
| 41 | NESTED LOOPS | | 1 | 1 | 71 |00:09:30.11 | 379M| | | |
| 42 | NESTED LOOPS | | 1 | 18 | 16M|00:03:49.48 | 34M| | | |
| 43 | NESTED LOOPS | | 1 | 1 | 1075 |00:00:00.03 | 351 | | | |
| 44 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 9 | | | |
| 45 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 8 | | | |
| 46 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 6 | | | |
| 47 | TABLE ACCESS BY INDEX ROWID | FND_FLEX_VALUES | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 48 | INDEX RANGE SCAN | FND_FLEX_VALUES_N4 | 1 | 1 | 1 |00:00:00.01 | 2 | | | |
|* 49 | TABLE ACCESS BY INDEX ROWID | MTL_CATEGORIES_B | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 50 | INDEX RANGE SCAN | IDX$$_79530001 | 1 | 1 | 2 |00:00:00.01 | 1 | | | |
|* 51 | INDEX UNIQUE SCAN | FND_FLEX_VALUES_TL_U1 | 1 | 1 | 1 |00:00:00.01 | 2 | | | |
|* 52 | INDEX UNIQUE SCAN | MTL_CATEGORIES_TL_U1 | 1 | 1 | 1 |00:00:00.01 | 1 | | | |
| 53 | TABLE ACCESS BY INDEX ROWID | MTL_ITEM_CATEGORIES | 1 | 506 | 1075 |00:00:00.02 | 342 | | | |
|* 54 | INDEX RANGE SCAN | IDX$$_78250002 | 1 | 1528 | 1075 |00:00:00.01 | 5 | | | |
|* 55 | TABLE ACCESS BY INDEX ROWID | OE_ORDER_HEADERS_ALL | 1075 | 6485 | 16M|00:12:38.97 | 34M| | | |
|* 56 | INDEX RANGE SCAN | OE_ORDER_HEADER_ALL_ORG_ID_NDX | 1075 | 141K| 394M|00:19:52.50 | 2141K| | | |
|* 57 | TABLE ACCESS BY INDEX ROWID | OE_ORDER_LINES_ALL | 16M| 1 | 71 |00:23:47.72 | 345M| | | |
|* 58 | INDEX RANGE SCAN | OE_ORDER_LINES_N21 | 16M| 6 | 108M|00:08:35.98 | 32M| | | |
| 59 | TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS | 71 | 1 | 71 |00:00:00.01 | 247 | | | |
|* 60 | INDEX UNIQUE SCAN | HZ_CUST_ACCOUNTS_U1 | 71 | 1 | 71 |00:00:00.01 | 176 | | | |
| 61 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 34 | | | |
| 62 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 30 | | | |
| 63 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 24 | | | |
| 64 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 20 | | | |
| 65 | NESTED LOOPS | | 2 | 1 | 2 |00:00:00.01 | 14 | | | |
|* 66 | TABLE ACCESS BY INDEX ROWID| HZ_CUST_SITE_USES_ALL | 2 | 1 | 2 |00:00:00.01 | 8 | | | |
|* 67 | INDEX UNIQUE SCAN | HZ_CUST_SITE_USES_U1 | 2 | 1 | 2 |00:00:00.01 | 6 | | | |
|* 68 | TABLE ACCESS BY INDEX ROWID| HZ_CUST_ACCT_SITES_ALL | 2 | 9420 | 2 |00:00:00.01 | 6 | | | |
|* 69 | INDEX UNIQUE SCAN | HZ_CUST_ACCT_SITES_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
| 70 | TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS | 2 | 176K| 2 |00:00:00.01 | 6 | | | |
|* 71 | INDEX UNIQUE SCAN | HZ_CUST_ACCOUNTS_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
|* 72 | INDEX UNIQUE SCAN | HZ_PARTIES_U1 | 2 | 176K| 2 |00:00:00.01 | 4 | | | |
|* 73 | TABLE ACCESS BY INDEX ROWID | HZ_PARTY_SITES | 2 | 188K| 2 |00:00:00.01 | 6 | | | |
|* 74 | INDEX UNIQUE SCAN | HZ_PARTY_SITES_U1 | 2 | 1 | 2 |00:00:00.01 | 4 | | | |
|* 75 | INDEX UNIQUE SCAN | HZ_LOCATIONS_U1 | 2 | 174K| 2 |00:00:00.01 | 4 | | | |
Predicate Information (identified by operation id):
3 - filter((:P_FROM_DATE<=:P_TO_DATE AND :P_BUSINESS_UNIT IS NULL))
6 - access("IC"."INVENTORY_ITEM_ID"="OL"."INVENTORY_ITEM_ID")
12 - filter("B"."FLEX_VALUE" IS NOT NULL)
13 - access("B"."FLEX_VALUE_SET_ID"=1012990)
14 - filter("B"."STRUCTURE_ID"=50289)
15 - access("B"."SEGMENT3"="B"."FLEX_VALUE")
filter("B"."SEGMENT3" IS NOT NULL)
16 - access("B"."FLEX_VALUE_ID"="T"."FLEX_VALUE_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
17 - access("B"."CATEGORY_ID"="T"."CATEGORY_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
18 - access("B"."CATEGORY_ID"="IC"."CATEGORY_ID")
19 - filter(("OL"."ACTUAL_SHIPMENT_DATE">=:P_FROM_DATE AND "OL"."ACTUAL_SHIPMENT_DATE"<=:P_TO_DATE AND
"OL"."ORDERED_ITEM"=NVL(:ITEM_HIGH,"OL"."ORDERED_ITEM") AND "OL"."LINE_CATEGORY_CODE"='ORDER' AND "OL"."UNIT_SELLING_PRICE"<>0))
20 - filter(("OH"."ORG_ID"=:P_ORG_ID AND "IC"."ORGANIZATION_ID"="OH"."SHIP_FROM_ORG_ID"))
21 - access("OH"."HEADER_ID"="OL"."HEADER_ID")
23 - access("CUST"."CUST_ACCOUNT_ID"=)
29 - filter("SUSE"."SITE_USE_CODE"='SHIP_TO')
30 - access("SUSE"."SITE_USE_ID"=:B1)
31 - filter("ACCT_SITE"."ORG_ID"=:P_ORG_ID)
32 - access("SUSE"."CUST_ACCT_SITE_ID"="ACCT_SITE"."CUST_ACCT_SITE_ID")
34 - access("ACCT"."CUST_ACCOUNT_ID"="ACCT_SITE"."CUST_ACCOUNT_ID")
35 - access("P"."PARTY_ID"="ACCT"."PARTY_ID")
36 - filter(("ACCT"."PARTY_ID"="PARTY_SITE"."PARTY_ID" AND "P"."PARTY_ID"="PARTY_SITE"."PARTY_ID"))
37 - access("ACCT_SITE"."PARTY_SITE_ID"="PARTY_SITE"."PARTY_SITE_ID")
38 - access("LOC"."LOCATION_ID"="PARTY_SITE"."LOCATION_ID")
39 - filter((:P_FROM_DATE<=:P_TO_DATE AND :P_BUSINESS_UNIT IS NOT NULL))
48 - access("B"."FLEX_VALUE"=:P_BUSINESS_UNIT AND "B"."FLEX_VALUE_SET_ID"=1012990)
49 - filter("B"."STRUCTURE_ID"=50289)
50 - access("B"."SEGMENT3"="B"."FLEX_VALUE")
filter("B"."SEGMENT3" IS NOT NULL)
51 - access("B"."FLEX_VALUE_ID"="T"."FLEX_VALUE_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
52 - access("B"."CATEGORY_ID"="T"."CATEGORY_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
54 - access("B"."CATEGORY_ID"="IC"."CATEGORY_ID")
55 - filter("IC"."ORGANIZATION_ID"="OH"."SHIP_FROM_ORG_ID")
56 - access("OH"."ORG_ID"=:P_ORG_ID)
57 - filter(("OL"."ACTUAL_SHIPMENT_DATE">=:P_FROM_DATE AND "OL"."ACTUAL_SHIPMENT_DATE"<=:P_TO_DATE AND
"OL"."ORDERED_ITEM"=NVL(:ITEM_HIGH,"OL"."ORDERED_ITEM") AND "OL"."LINE_CATEGORY_CODE"='ORDER' AND "OL"."UNIT_SELLING_PRICE"<>0 AND
"IC"."INVENTORY_ITEM_ID"="OL"."INVENTORY_ITEM_ID"))
58 - access("OH"."HEADER_ID"="OL"."HEADER_ID")
60 - access("CUST"."CUST_ACCOUNT_ID"=)
66 - filter("SUSE"."SITE_USE_CODE"='SHIP_TO')
67 - access("SUSE"."SITE_USE_ID"=:B1)
68 - filter("ACCT_SITE"."ORG_ID"=:P_ORG_ID)
69 - access("SUSE"."CUST_ACCT_SITE_ID"="ACCT_SITE"."CUST_ACCT_SITE_ID")
71 - access("ACCT"."CUST_ACCOUNT_ID"="ACCT_SITE"."CUST_ACCOUNT_ID")
72 - access("P"."PARTY_ID"="ACCT"."PARTY_ID")
73 - filter(("ACCT"."PARTY_ID"="PARTY_SITE"."PARTY_ID" AND "P"."PARTY_ID"="PARTY_SITE"."PARTY_ID"))
74 - access("ACCT_SITE"."PARTY_SITE_ID"="PARTY_SITE"."PARTY_SITE_ID")
75 - access("LOC"."LOCATION_ID"="PARTY_SITE"."LOCATION_ID")
145 rows selected.one thing looking strange at predicate section at line 23 and 60 access("CUST"."CUST_ACCOUNT_ID"=),Plan is also differing why?Just look at filter predicates 3 and 39 which I highlighted previously.
With a query using bind variable, p_business_unit might be supplied with a null value and therefore two possible paths exist in the CONCATENTATION plan to cope with those possibilities (and the possibility that P_FROM_DATE is not <= P_TO_DATE).
If instead of using bind variable you supply a literal - i.e. '101468' - then the optimizer doesn't not have to worry about the fact that '101468' might be null. As far as this piece of SQL is concerned, it's a constant.
Therefore you shouldn't compare SQL that runs with binds with SQl that runs with literals, particularly where the sql involves conditional predicates.
To use a simplification, consider the difference here:
SQL> explain plan for
2 select 1 from dual where 1 = nvl(1,1);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1388734953
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
8 rows selected.
SQL> explain plan for
2 select 1 from dual where 1 = nvl(:1,1);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4034615273
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
|* 1 | FILTER | | | | |
| 2 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(NVL(:1,1)=1)
14 rows selected.Furthermore, to emphasis my point about substition variables (&variable_name) consider this:
SQL> explain plan for
2 select 1 from dual where 1 = nvl(&1,1);
Enter value for 1: 1
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1388734953
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
8 rows selected.
SQL> Does the substitution variable behave like a bind variable or like a literal?
A literal, because that's what it is. Substituted in before the statement is sent to the database and parsed. -
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. -
Query with same explain-plan but slower in one env
Hi there
I have a stored procedure which is executed from a web application. It contains a query (insert-select-from statement). When this stored procedure is called by the web application in PROD, it takes 13sec but it takes 19sec in TEST env. I checked the explain plan for this insert statement in both instances and it is same (see below). Actually, the cost is lower in TEST env.
ENV: Oracle 10gR2 EE, on ASM - RHEL 64bit
The TEST server is on a better/faster hardware and will become the new PROD in near future (faster and 16 CPUs vs 8 in PROD, high performance SAN, 132GB RAM vs 96GB in PROD, etc). The TEST database has exact same init parameter and version/patch level as current PROD. So the application is being tested against it at the moment.
Here are the explain-plans from both environments:
From PROD Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 143 Bytes: 696 Cardinality: 3
18 SORT ORDER BY Cost: 143 Bytes: 696 Cardinality: 3
17 HASH UNIQUE Cost: 142 Bytes: 696 Cardinality: 3
16 WINDOW SORT Cost: 143 Bytes: 696 Cardinality: 3
15 HASH JOIN Cost: 141 Bytes: 696 Cardinality: 3
13 HASH JOIN Cost: 128 Bytes: 519 Cardinality: 3
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 125 Bytes: 1,728 Cardinality: 12
10 NESTED LOOPS Cost: 125 Bytes: 1,992 Cardinality: 12
3 HASH JOIN Cost: 5 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 2 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 2 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 19 Cardinality: 4,920
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 89 Cardinality: 4,920
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 2 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,809 Cardinality: 3,251
From TEST Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 107 Bytes: 232 Cardinality: 1
18 SORT ORDER BY Cost: 107 Bytes: 232 Cardinality: 1
17 HASH UNIQUE Cost: 106 Bytes: 232 Cardinality: 1
16 WINDOW SORT Cost: 107 Bytes: 232 Cardinality: 1
15 HASH JOIN Cost: 105 Bytes: 232 Cardinality: 1
13 HASH JOIN Cost: 93 Bytes: 173 Cardinality: 1
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 89 Bytes: 864 Cardinality: 6
10 NESTED LOOPS Cost: 89 Bytes: 996 Cardinality: 6
3 HASH JOIN Cost: 7 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 3 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 3 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 9 Cardinality: 2,977
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 59 Cardinality: 2,977
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 3 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,868 Cardinality: 3,252
What else can I check to find out why the query is slower in TEST env?
Please advise.
Best regardsHere is some more info. The query is below:
select distinct dr.line_num
,row_number() over (partition by di.HEADINGNO,di.DIRECTORYNO order by reportyear,to_number(di.monthno)) monthposition
,di.SATID,di.REPORTYEAR,di.MONTHNO,di.MONTHEN,di.MONTHFR,di.HEADINGNO,hn.NAME_EN,hn.NAME_FR,di.DIRECTORYNO
,di.SUPERDIRECTORYNO,di.PRINTDIRCODE,di.DIRECTORYNAME,round(to_number(di.IMPTTOTAL)) imptotal
,round(to_number(di.IMPBEST)) impbest ,round(to_number(di.IMPTAVERAGE)) imptaverage
,round(to_number(di.CLICKTOTAL)) clicktotal,round(to_number(di.CLICKBEST)) clickbest
,round(to_number(di.CLICKAVERAGE)) clickaverage
,round(avg(to_number(impttotal)) over(partition by di.HEADINGNO,di.DIRECTORYNO)) avgimp
from satdataimport di,tmpg_clicks_hdgs hd,tmpg_clicks_dirs dr, months12 m12, ref_west_category hn
where di.headingno = hd.id
and di.directoryno = dr.id
and dr.line_num=hd.line_num
and di.reportyear = m12.year
and di.monthno = m12.month
and hn.CATEGORY_CODE = di.headingno
order by di.headingno, di.directoryno,di.reportyear,to_number(di.monthno)
The largest table is "satdataimport" in the query has "12274818" rows. Rest of the tables are very small containing few rows to less than 4000 rows.
I have refreshed the statistics of the larger table but this did not help either. Even a simple query like "select count(*) from satdataimport" is taking 15sec in TEST while it takes 4Sec in PROD when I run it from TOAD.
The other strange thing is that when I run this stored procedure from TOAD, it takes 200 milli sec to complete. There is a logging table to which the stored procedure records the elapsed time taken by this INSERT statement.
Since this query is in a stored procedure being called from the web app, the QA team wants quicker response. Current PROD is faster.
The tables have same indexes, etc and contain identical data as that in PROD (were refreshed from PROD yesterday).
What else can I check?
Best regards -
Multiple DB env with different explain plan
Hi,
I have DEV DB and QA DB , both located in USA. There is a table called Customer which contains the respective index , pk, constraints, etc which is available in
both the environments. Now In DEV DB we have Customer table with 1000 records, but in QA DB we have about 50000 records.
Now in DEV DB when i take a explain plan the columns are not going for a FULL table scan but in QA DB it is going for a full table scan? Why there is a discrepancies? Is it because of the number of records in QA is more than DEV? I hope that wont be a problem as Oracle CBO/RBO will optimize the query by itself for both the cases using the index, etc. If that is the case I am wondering what might me the problem. Whether we need to inform the Oracle using the hints? Please shed some light into this.
Thanks.First of all it is a good idea to compare the execution plans from differnt environments. Not all developers do that. The cost or time can not be properly compared, but the plan itself yes. if the plan is different, then the behaviour of the query very likely also is different.
What you didn't show us was the query and the two different plans. Maybe in a broken down test version.
What is strange is that I would have expected a reversed behaviour. In the dev db you have only 1000 records. Usually the db will do a FULL table scan on this. Simply because the amount of data is so small that it is othen faster to read the table in one big chuck and then deal with it. The parameter db_multiblock_read_count plays a role in that. If it does instead an table access by index rowid then that is fine.
If you QA Db now uses a "full table scan" instead of the "table access by index rowid" that it is something to think about. Possible reasons can be: Not current statistics. For example do you have an automatic job that collects statistics? Maybe this job didn't run yet, after you imported the data? To use hints as a solution would be wrong. However you can use hints to see, if the performace of the query improves after using the hint. If it does, then the CBO didn't have good enough information. If it doesn't then the CBO already made the right decision. -
Greetings,
We've been running HTMLDB since 1.5 and are currently at 2.2.1.00.04, but within the last two weeks we have been seeing some very strange behavior. Form submissions or moving from one page to the next in either the Development GUI or within any application will result in either blank pages (although in most cases a reload [refresh] will bring up the page that was expected) or the following errors:
Error Workspace 741023382320307 has no privileges to parse as schema.
or
Access denied by Application security check (this one will only allow us to logout, refresh doesnt work).
or
ORA-0000: normal, successful completion
Error Unable to fetch authentication_scheme in application 4000. (a refresh brings the page up normally)
We've made no major changes to hardware/operating system/software.
We have ruled out our load balancer by accessing htmldb by FQDN and port number, and have disabled webcache. Its almost as if our session variables in memory will just suddenly disappear.
[EDIT]
These pages and errors are absolutely random. I could experience 20 of them in an hour or 1 in the next week. We have done extensive log checking, but can find nothing that would explain the behavior.
[EDIT]
Has anyone experienced these issues. We are currently running a number of applications in production and this is already starting to affect them.
Thanks in Advance,
Clifford Moon
Message was edited by:
cjmoon
Message was edited by:
cjmoonHi Earl.
I just confirmed from one of the developers that it
happens either way...
Any ideas?
cliffDid you happen to change browsers recently, like IE7 perhaps?
I'm not really sure what's happening but this sounds like what I call 'browser confusion'. Basically, like what you mentioned, that the current session state gets dropped, either in the browser or the server. Don't know which.
Earl -
Hi everybody,
Can you please explain me this strange behavior of NVL function:
SQL> select nvl(10000,'none') from dual;
select nvl(10000,'none') from dual
ERROR at line 1:
ORA-01722: invalid number
SQL> select nvl('none',10000) from dual;
NVL(
none
Can you explain what goes on internally to make these statements different?
I mean why is it expecting a number(as a second arg) in Case 1 and why is it not expecting a character string as a second arg in Case 2? Has it got to do with implicit type-conversion?
Finally, does NVL need both arguments of the same type?
Any help will be greatly appreciated.
Thanks.
Kishore.The return type of NVL is the datatype of the first argument. If the two arguments have different datatypes Oracle applies a conversion. That's why you got your results: in effect what you were running was
select nvl(10000,to_number('none')) from dual;and
select nvl('none',to_char(10000)) from dual;Of course, 'none' is not a valid number, hence the ORA-1722 result, whereas 10000 can be successfully rendered as a string.
If you do not provide NVL with arguments of the same datatype it will apply an implicit conversion to the second datatype. It is always better (that is safer) to avoid implicit data conversion.
Cheers, APC
P.S. For bonus points, which argument determines the datatype of a DECODE function?
Maybe you are looking for
-
HELP - 2 iphones, 1 IPAD with one Itunes account & same PC
Hello, wondering if someone was able to assist. I have looked through the discussion and even though I can see many people have asked the same I am still stuggling to work this out..... OK, so me and my boyfriend are using the same ITUNES account on
-
How to procure material's as free goods through purchase order.
-
i saw this post about quantizing multi track drums...where is the event list ?? thanks "It's not a big deal... Use the Strip Silence feature. Double click on one audio track. Then open the 'audio window list' You'll find strip silence there. Click on
-
Hi. I have recently been trying to make movies with green screen in Imovie 11. Just recently when I put down an image to replace the background it turns out black. I have just tried putting down a regular picture (with out the green screen) and they
-
Repeating sound effect problem
I am looking to get a record scratch sound to play throughout my entire song. I have a MIDI ambient record scratch. What is the easiest way to get it to play in the whole song.