Explain Plan different in SQLPlus then production
We have a query that is consuming 95%+ of the CPU in production, but the same query in sqlplus takes seconds. The explain plan through OEM is different than the explain plan in sqlplus, but the query is the same? Any thoughts?
Thanks.
Your explanation raises many question.
We have a query that is consuming 95%+ of the CPU in production, How do you measure this?
but the same query in sqlplus takes seconds.What do you mean, by running in production or running in sqlplus?
How do you run on production? I mean, do you run through any application or what?
Are they running under the same user?
It is possible to post both execution plans and a more explanation on what you are saying.
Similar Messages
-
Explain plan different for same query
Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme -
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 different with no stats but with no rows & rows in a table
Hi All,
This is in Oracle 8.1.7.4.0 DB.
1. Query was taking long time to return rows. It was based on a view.
2. View has multiple tables.
3. The explain plan was showing one of the Table(e.g. TABLE1) using incorrect INDEX. At the time of explain plan table has no statistics.
4. truncated Table TABLE1
5. The explain plan now taking correct INDEX for the table TABLE1.
How does optimizer choosing the incorrect index when rows in a table & correct index when there are no rows in the table ?
any insights.
Thanks
SandeepI don't know about your particular db version, but CBO in absence of statistics uses some default values (e.g. average row length 100 bytes) and also uses actual number of block for the table. I assume something similar might be for indexes.
To be sure what has changed you can run 10053 level trace.
Gints Plivna
http://www.gplivna.eu -
Real explain plan differs from one in v$sqlarea
I have some more or less complex queries which I catch on runtime by reading v$sqlarea table to find sql with high cost..
but..
I found some highly costed sql, but when I run it through client ti see it's explain plan and execution time, it's much faster with very little cost
why?
am I wrong when I read v$sqlarea?
I'm using Oracle 11g R2This is not at all surprising. Jonathan Lewis and many other have discussed this numerous times both in these forums, in books, in white papers, and in conference presentations.
That said ... you should be looking in gv$sql_plan. -
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> -
I like the explain plan functionality - it is good for doing spot checks on execution plans. Unfortunately, I cannot copy the plan once it is produced, so if I need to send someone a copy of the plan, I revert to producing the execution plan in TOAD.
Yes ..
I too feel same.
I right-click explain plan in TOAD and then paste it in excel.
It goes there row by row...Useful Feature.
--Sanjeev -
Differenet Explain Plan for Same Query
DB Version : 11.2.0.3
OS Version : AIX 6
I have two Queries ( The Difference between Them Only 940 and 584 ) When I Generate Explain Plan Different Output Why ? Why CPU time is Different Each Time
First Query Statement :
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120131 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120131 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPXXX'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '950'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan for First Query :
PLAN_TABLE_OUTPUT
Plan hash value: 3901722890
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 2866 | 134K| 197 (3)| 00:00:03 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | VIEW | | 2866 | 134K| 197 (3)| 00:00:03 | | |
|* 4 | SORT ORDER BY STOPKEY | | 2866 | 333K| 197 (3)| 00:00:03 | | |
| 5 | NESTED LOOPS | | 2866 | 333K| 196 (2)| 00:00:03 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 1419 | 148K| 196 (2)| 00:00:03 | | |
|* 7 | HASH JOIN | | 1419 | 141K| 196 (2)| 00:00:03 | | |
| 8 | NESTED LOOPS | | 91 | 1911 | 2 (0)| 00:00:01 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | 0 (0)| 00:00:01 | | |
|* 11 | INDEX FULL SCAN | PK_SUNITUSERGROUP | 91 | 1001 | 1 (0)| 00:00:01 | | |
| 12 | PARTITION RANGE SINGLE | | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 13 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 14 | INDEX SKIP SCAN | IX_RMESG | 415 | | 14 (15)| 00:00:01 | 2 | 2 |
|* 15 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | 0 (0)| 00:00:01 | | |
|* 16 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | 0 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
7 - access("X_INST0_UNIT_NAME"="UNIT")
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
11 - access("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
filter("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
13 - filter("RMESG"."MESG_SENDER_X1"='SOGEFRPPXXX' AND "RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND
"RMESG"."MESG_FRMT_NAME"='Swift')
14 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-31 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='950' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-31 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='950')
15 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
16 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
40 rows selected.
Second query
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120117 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120117 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPGSS'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '548'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan For Second Query :
PLAN_TABLE_OUTPUT
Plan hash value: 4106071428
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | | |
| 3 | VIEW | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
|* 4 | SORT ORDER BY STOPKEY | | 1073 | 124K| | 2622 (1)| 00:00:32 | | |
| 5 | NESTED LOOPS | | 1073 | 124K| | 2621 (1)| 00:00:32 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 531 | 56817 | | 2621 (1)| 00:00:32 | | |
| 7 | NESTED LOOPS | | 531 | 54162 | | 2621 (1)| 00:00:32 | | |
| 8 | NESTED LOOPS | | 543 | 49413 | | 2621 (1)| 00:00:32 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | | 0 (0)| 00:00:01 | | |
| 11 | PARTITION RANGE SINGLE | | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
|* 12 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
| 13 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 14 | BITMAP AND | | | | | | | | |
| 15 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
|* 16 | INDEX RANGE SCAN | IX_SENDER | 25070 | | | 894 (1)| 00:00:11 | 2 | 2 |
PLAN_TABLE_OUTPUT
| 17 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
| 18 | SORT ORDER BY | | | | 408K| | | | |
|* 19 | INDEX RANGE SCAN | IX_RMESG | 25070 | | | 1405 (1)| 00:00:17 | 2 | 2 |
|* 20 | INDEX UNIQUE SCAN | PK_SUNITUSERGROUP | 1 | 11 | | 0 (0)| 00:00:01 | | |
|* 21 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | | 0 (0)| 00:00:01 | | |
|* 22 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | | 0 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
12 - filter("RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND "RMESG"."MESG_FRMT_NAME"='Swift')
16 - access("RMESG"."MESG_SENDER_X1"='SOGEFRPPGSS')
19 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss'))
20 - access("X_INST0_UNIT_NAME"="UNIT" AND "SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
21 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
22 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
45 rows selected.
Table Structure TEMPSEARCHRESULT
CREATE GLOBAL TEMPORARY TABLE TEMPSEARCHRESULT
T_AID NUMBER(3),
T_UMIDL NUMBER(10),
T_UMIDH NUMBER(10),
X_CREA_DATE_TIME_MESG DATE
ON COMMIT PRESERVE ROWS
NOCACHE;
CREATE INDEX SIDE.TEMP_SEARCH_INDEX ON SIDE.TEMPSEARCHRESULT
(T_AID, T_UMIDL, T_UMIDH, X_CREA_DATE_TIME_MESG);Again Thank you For your amazing Answer.
For indexes it's a balance. Check this query which is Simple
Select * from RMESGI generated Explain Plan for it to see effect of indexes .
PLAN_TABLE_OUTPUT
Plan hash value: 1686435785
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 11M| 8920M| 376K (1)| 01:15:20 | | |
| 1 | PARTITION RANGE ALL| | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
| 2 | TABLE ACCESS FULL | RMESG | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
---------------------------------------------------------------------------------------------1:15:20 For table access and Full Scan Also , I generate new Indexes on the table like the following
CREATE TABLE RMESG(
aid NUMBER(3) NOT NULL,
mesg_s_umidl NUMBER(10) NOT NULL,
mesg_s_umidh NUMBER(10) NOT NULL,
mesg_validation_requested CHAR(18) NOT NULL,
mesg_validation_passed CHAR(18) NOT NULL,
mesg_class CHAR(16) NOT NULL,
mesg_is_text_readonly NUMBER(1) NOT NULL,
mesg_is_delete_inhibited NUMBER(1) NOT NULL,
mesg_is_text_modified NUMBER(1) NOT NULL,
mesg_is_partial NUMBER(1) NOT NULL,
mesg_crea_mpfn_name CHAR(24) NOT NULL,
mesg_crea_rp_name CHAR(24) NOT NULL,
mesg_crea_oper_nickname CHAR(151) NOT NULL,
mesg_crea_date_time DATE NOT NULL,
mesg_mod_oper_nickname CHAR(151) NOT NULL,
mesg_mod_date_time DATE NOT NULL,
mesg_frmt_name VARCHAR2(17) NOT NULL,
mesg_nature CHAR(14) NOT NULL,
mesg_sender_x1 CHAR(11) NOT NULL,
mesg_sender_corr_type VARCHAR2(24) NOT NULL,
mesg_uumid VARCHAR2(50) NOT NULL,
mesg_uumid_suffix NUMBER(10) NOT NULL,
x_own_lt CHAR(8) NOT NULL,
x_inst0_unit_name VARCHAR2(32) default 'NONE' NOT NULL,
x_category CHAR(1) NOT NULL,
archived NUMBER(1) NOT NULL,
restored NUMBER(1) NOT NULL,
mesg_related_s_umid CHAR(16) NULL,
mesg_status CHAR(12) NULL,
mesg_crea_appl_serv_name CHAR(24) NULL,
mesg_verf_oper_nickname CHAR(151) NULL,
mesg_data_last NUMBER(10) NULL,
mesg_token NUMBER(10) NULL,
mesg_batch_reference VARCHAR2(46) NULL,
mesg_cas_sender_reference VARCHAR2(40) NULL,
mesg_cas_target_rp_name VARCHAR2(20) NULL,
mesg_ccy_amount VARCHAR2(501) NULL,
mesg_copy_service_id VARCHAR2(4) NULL,
mesg_data_keyword1 VARCHAR2(80) NULL,
mesg_data_keyword2 VARCHAR2(80) NULL,
mesg_data_keyword3 VARCHAR2(80) NULL,
mesg_delv_overdue_warn_req NUMBER(1) NULL,
mesg_fin_ccy_amount VARCHAR2(24) NULL,
mesg_fin_value_date CHAR(6) NULL,
mesg_is_live NUMBER(1) NULL,
mesg_is_retrieved NUMBER(1) NULL,
mesg_mesg_user_group VARCHAR2(24) NULL,
mesg_network_appl_ind CHAR(3) NULL,
mesg_network_delv_notif_req NUMBER(1) NULL,
mesg_network_obso_period NUMBER(10) NULL,
mesg_network_priority CHAR(12) NULL,
mesg_possible_dup_creation VARCHAR2(8) NULL,
mesg_receiver_alia_name VARCHAR2(32) NULL,
mesg_receiver_swift_address CHAR(12) NULL,
mesg_recovery_accept_info VARCHAR2(80) NULL,
mesg_rel_trn_ref VARCHAR2(80) NULL,
mesg_release_info VARCHAR2(32) NULL,
mesg_security_iapp_name VARCHAR2(80) NULL,
mesg_security_required NUMBER(1) NULL,
mesg_sender_x2 VARCHAR2(21) NULL,
mesg_sender_x3 VARCHAR2(21) NULL,
mesg_sender_x4 VARCHAR2(21) NULL,
mesg_sender_branch_info VARCHAR2(71) NULL,
mesg_sender_city_name VARCHAR2(36) NULL,
mesg_sender_ctry_code VARCHAR2(3) NULL,
mesg_sender_ctry_name VARCHAR2(71) NULL,
mesg_sender_institution_name VARCHAR2(106) NULL,
mesg_sender_location VARCHAR2(106) NULL,
mesg_sender_swift_address CHAR(12) NULL,
mesg_sub_format VARCHAR2(6) NULL,
mesg_syntax_table_ver VARCHAR2(8) NULL,
mesg_template_name VARCHAR2(32) NULL,
mesg_trn_ref VARCHAR2(16) NULL,
mesg_type CHAR(3) NULL,
mesg_user_issued_as_pde NUMBER(1) NULL,
mesg_user_priority_code CHAR(4) NULL,
mesg_user_reference_text VARCHAR2(30) NULL,
mesg_zz41_is_possible_dup NUMBER(1) NULL,
x_fin_ccy CHAR(3) NULL,
x_fin_amount NUMBER(21,4) NULL,
x_fin_value_date DATE NULL,
x_fin_ocmt_ccy CHAR(3) NULL,
x_fin_ocmt_amount NUMBER(21,4) NULL,
x_receiver_x1 CHAR(11) NULL,
x_receiver_x2 VARCHAR2(21) NULL,
x_receiver_x3 VARCHAR2(21) NULL,
x_receiver_x4 VARCHAR2(21) NULL,
last_update DATE NULL,
set_id NUMBER(10) NULL,
mesg_requestor_dn VARCHAR2(101) NULL,
mesg_service VARCHAR2(31) NULL,
mesg_request_type VARCHAR2(31) NULL,
mesg_identifier VARCHAR2(31) NULL,
mesg_xml_query_ref1 VARCHAR2(101) NULL,
mesg_xml_query_ref2 VARCHAR2(101) NULL,
mesg_xml_query_ref3 VARCHAR2(101) NULL,
mesg_appl_sender_reference VARCHAR2(51) NULL,
mesg_payload_type VARCHAR2(31) NULL,
mesg_sign_digest_reference VARCHAR2(41) NULL,
mesg_sign_digest_value VARCHAR2(51) NULL,
mesg_use_pki_signature NUMBER(1) NULL
PARTITION BY RANGE(MESG_CREA_DATE_TIME) (
PARTITION SIDE_MIN VALUES LESS THAN (TO_DATE(20000101, 'YYYYMMDD')) TABLESPACE TBS_SIDEDB_DA_01);
CREATE UNIQUE INDEX SIDE.IX_PK_RMESG on SIDE.RMESG (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) LOCAL;
ALTER TABLE SIDE.RMESG ADD CONSTRAINT IX_PK_RMESG PRIMARY KEY (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) USING INDEX SIDE.IX_PK_RMESG;
CREATE INDEX SIDE.ix_rmesg_cassender ON SIDE.rmesg (MESG_CAS_SENDER_REFERENCE) LOCAL;
CREATE INDEX SIDE.ix_rmesg_creationdate ON SIDE.rmesg (MESG_CREA_DATE_TIME) LOCAL;
CREATE INDEX SIDE.ix_rmesg_trnref ON SIDE.rmesg (MESG_TRN_REF) LOCAL;
CREATE INDEX SIDE.ix_rmesg_uumid ON SIDE.rmesg (MESG_UUMID, MESG_UUMID_SUFFIX) LOCAL;
CREATE INDEX SIDE.IX_UNIT_NAME_RMESG on RMESG(mesg_crea_date_time,X_INST0_UNIT_NAME) LOCAL;
CREATE INDEX SIDE.IX_RMESG on RMESG(mesg_crea_date_time ,mesg_type,x_fin_ccy) LOCAL;
CREATE INDEX SIDE.IX_NAME_FORMAT_TYPE_RMESG on RMESG(mesg_frmt_name,mesg_sub_format,mesg_type,mesg_crea_date_time ) LOCAL;same Explain Plan Same Result .
I always remember TOM Quote "full scans are not evil, indexes are not good"
Which Mean Something Wrong Goes with Indexes , the partition depend on MESG_CREA_DATE_TIME Column I create Index for this column but same explain plan Appear every time. With Same Time.
Thank you
Osama -
'Identical' schemas on different servers - different explain plan costs
Hello,
I have two servers, 1 development and 1 production. I have a query which produces wildly different explain plan costs on the two servers:
The development server provides a cost of just over 800 and the production servers is over 100000. I have 2-3 different versions of the schema (These are data warehouse schemas) on both servers and the cost numbers are similar regardless of the version used. Whenever I run the query on development, it's around 800. On production the same query is over 100000.
The data on both servers is (should be) identical - I used impdp and expdp to transfer the data between the servers. I have run:
DBMS_STATS.GATHER_SCHEMA_STATS ('SCHEMAV26', cascade=>TRUE);
on the production server after importing the data. As far as I can see, the indices are identical on both servers. The difference in the execution plan is one additional line:
Filter Predicates CE.ID < 5
Can anyone help me figure out why the explain plans are different? The servers have similar hardware specs, and are running the same version of Oracle (11.2.0.2.0)
Thanks,
Dan Scott
http://danieljamesscott.org
Edited by: danscott on Mar 4, 2011 11:43 AMThanks for all the help/suggestions - as you've probably guessed, I'm a little new to all this.
A little background first:
We have an items table and events table. itemid is the primary key for the items table and a foreign key in the events table. The events table contains itemids, timestamps and data values (along with a few other IDs) The query I'm running is used to create a materialized view which provides statistics for each itemid to assist users in finding a particular itemid containing the data they're interested in. Generally, we create the view on the full list of itemids (and so the indices are not used, as expected). However, we occasionally run the query for a small number of itemids, and the index on events.itemid is used on one server, but not on the other.
Here's the SQL (Apologies for the length).
WITH ChartItems as (
select distinct ci.itemid, ci.label, ci.category, ci.description,
case
when
(count(distinct ce.value1) over (partition by ci.itemid) > 0 OR
count(distinct ce.value2) over (partition by ci.itemid) > 0)
AND
(count(distinct ce.value1num) over (partition by ci.itemid) > 0 OR
count(distinct ce.value2num) over (partition by ci.itemid) > 0)
then 'H'
when
count(distinct ce.value1num) over (partition by ci.itemid) > 0 OR
count(distinct ce.value2num) over (partition by ci.itemid) > 0
then 'N'
when
count(distinct ce.value1) over (partition by ci.itemid) > 0 OR
count(distinct ce.value2) over (partition by ci.itemid) > 0
then 'S'
else
'X'
end as value_type,
-- The value column
case
when
(count(distinct ce.value1) over (partition by ci.itemid) > 0 OR
count(distinct ce.value1num) over (partition by ci.itemid) > 0)
and
(count(distinct ce.value2) over (partition by ci.itemid) > 0 OR
count(distinct ce.value2num) over (partition by ci.itemid) > 0)
then 'both'
when
count(distinct ce.value1) over (partition by ci.itemid) > 0 OR
count(distinct ce.value1num) over (partition by ci.itemid) > 0
then 'value1'
when
count(distinct ce.value2) over (partition by ci.itemid) > 0 OR
count(distinct ce.value2num) over (partition by ci.itemid) > 0
then 'value2'
else
'none'
end as value_column
from items ci,
events ce
where ce.itemid = ci.itemid
and ci.itemid < 5
, RawData as (
select distinct ci.itemid, ci.label, ci.category, ci.description,
ci.value_type, ci.value_column,
count(*)
over (partition by ci.itemid) as rows_num,
count(distinct ce.subject_id)
over (partition by ci.itemid) as subjects_num,
avg(abs(cast(ce.realtime as date) - cast(ce.charttime as date)) * 24 * 60)
over (partition by ci.itemid) as chart_vs_realtime_delay_mean,
stddev(abs(cast(ce.realtime as date) - cast(ce.charttime as date)) * 24 * 60)
over (partition by ci.itemid) as chart_vs_realtime_delay_stddev,
case
when ci.value_column in ('value1', 'both') then
case
when (last_value(ce.value1uom)
over (partition by ci.itemid
order by ce.value1uom nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
count(distinct ce.value1uom)
over (partition by ci.itemid) + 1
else
count(distinct ce.value1uom)
over (partition by ci.itemid)
end
else
0
end as value1_uom_num,
case
when ci.value_column in ('value1', 'both') then
case
when (last_value(ce.value1uom)
over (partition by ci.itemid
order by ce.value1uom nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
'Y'
else
'N'
end
else
null
end as value1_uom_has_nulls,
first_value(ce.value1uom) ignore nulls
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value1_uom_sample1,
last_value(ce.value1uom) ignore nulls
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value1_uom_sample2,
case
when ci.value_column in ('value1', 'both') then
case
when (last_value(ce.value1)
over (partition by ci.itemid
order by ce.value1 nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
count(distinct ce.value1)
over (partition by ci.itemid) + 1
else
count(distinct ce.value1)
over (partition by ci.itemid)
end
else
0
end as value1_distinct_num,
case
when ci.value_column in ('value1', 'both') then
case
when (last_value(ce.value1)
over (partition by ci.itemid
order by ce.value1 nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
'Y'
else
'N'
end
else
null
end as value1_has_nulls,
first_value(ce.value1) ignore nulls
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value1_sample1,
last_value(ce.value1) ignore nulls
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value1_sample2,
min(length(ce.value1))
over (partition by ci.itemid) as value1_length_min,
max(length(ce.value1))
over (partition by ci.itemid) as value1_length_max,
avg(length(ce.value1))
over (partition by ci.itemid) as value1_length_mean,
min(ce.value1num)
over (partition by ci.itemid) as value1num_min,
max(ce.value1num)
over (partition by ci.itemid) as value1num_max,
avg(ce.value1num)
over (partition by ci.itemid) as value1num_mean,
stddev(ce.value1num)
over (partition by ci.itemid) as value1num_stddev,
case
when ci.value_column in ('value2', 'both') then
case
when (last_value(ce.value2uom)
over (partition by ci.itemid
order by ce.value2uom nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
count(distinct ce.value2uom)
over (partition by ci.itemid) + 1
else
count(distinct ce.value2uom)
over (partition by ci.itemid)
end
else
0
end as value2_uom_num,
case
when ci.value_column in ('value2', 'both') then
case
when (last_value(ce.value2uom)
over (partition by ci.itemid
order by ce.value2uom nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
'Y'
else
'N'
end
else
null
end as value2_uom_has_nulls,
first_value(ce.value2uom) ignore nulls
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value2_uom_sample1,
last_value(ce.value2uom) ignore nulls
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value2_uom_sample2,
case
when ci.value_column in ('value2', 'both') then
case
when (last_value(ce.value2)
over (partition by ci.itemid
order by ce.value2 nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
count(distinct ce.value2)
over (partition by ci.itemid) + 1
else
count(distinct ce.value2)
over (partition by ci.itemid)
end
else
0
end as value2_distinct_num,
case
when ci.value_column in ('value2', 'both') then
case
when (last_value(ce.value2)
over (partition by ci.itemid
order by ce.value2 nulls last
ROWS BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING)
) is null then
'Y'
else
'N'
end
else
null
end as value2_has_nulls,
first_value(ce.value2)
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value2_sample1,
last_value(ce.value2)
over (partition by ci.itemid
order by ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as value2_sample2,
min(length(ce.value2))
over (partition by ci.itemid) as value2_length_min,
max(length(ce.value2))
over (partition by ci.itemid) as value2_length_max,
avg(length(ce.value2))
over (partition by ci.itemid) as value2_length_mean,
min(ce.value2num)
over (partition by ci.itemid) as value2num_min,
max(ce.value2num)
over (partition by ci.itemid) as value2num_max,
avg(ce.value2num)
over (partition by ci.itemid) as value2num_mean,
stddev(ce.value2num)
over (partition by ci.itemid) as value2num_stddev
from ChartItems ci,
events ce
where ce.itemid = ci.itemid
-- order by ci.itemid, ci.label
select label, trim(lower(label)) label_lower, itemid, category, description,
value_type, value_column,
rows_num, subjects_num,
round(chart_vs_realtime_delay_mean, 2) as chart_vs_realtime_delay_mean,
round(chart_vs_realtime_delay_stddev, 2) as chart_vs_realtime_delay_stddev,
value1_uom_num, value1_uom_has_nulls,
value1_uom_sample1, value1_uom_sample2,
value1_distinct_num, value1_has_nulls,
value1_sample1, value1_sample2,
value1_length_min, value1_length_max,
round(value1_length_mean, 2) as value1_length_mean,
round(value1num_min, 2) as value1num_min,
round(value1num_max, 2) as value1num_max,
round(value1num_mean, 2) as value1num_mean,
round(value1num_stddev, 2) as value1num_stddev,
value2_uom_num, value2_uom_has_nulls,
value2_uom_sample1, value2_uom_sample2,
value2_distinct_num, value2_has_nulls,
value2_sample1, value2_sample2,
value2_length_min, value2_length_max,
round(value2_length_mean, 2) as value2_length_mean,
round(value2num_min, 2) as value2num_min,
round(value2num_max, 2) as value2num_max,
round(value2num_mean, 2) as value2num_mean,
round(value2num_stddev, 2) as value2num_stddev
from RawData
order by label, itemid; -
Same query with different explain plans
Hi All,
I have one of the select query with different explain plans on two separate env, the query fetches the correct index on test env whereas on prod it's not fetching the same index.
The structure, indices, no. of rows are similar in CRMINFO table with up-to-date statistics.
Env Details :
OS - Sun Solaris 5.10
DB - 10.2.0.4
Init param:
Optimizer_mode = ALL_ROWS
optimizer_dynamic_sampling integer 5
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 90
optimizer_index_cost_adj integer 30
Query :*
SELECT COUNT (*)
FROM CRMINFO
WHERE RETAILER = :1
AND STATUS = 20
AND EXC = :1
AND SUBNO IS NULL
Expain Plan (TST):
SELECT STATEMENT ALL_ROWSCost: 916 Bytes: 19 Cardinality: 1
3 SORT AGGREGATE Bytes: 19 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE TST.CRMINFO Cost: 916 Bytes: 16,663 Cardinality: 877
1 INDEX RANGE SCAN INDEX TST.CRMINFO_X1 Cost: 42 Cardinality: 12,549
Index (TST):
CRMINFO_X1(EXC, RETAILER, STATUS)
Explain Plan (PROD):
SELECT STATEMENT ALL_ROWSCost: 1,832 Bytes: 19 Cardinality: 1
3 SORT AGGREGATE Bytes: 19 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE PROD.CRMINFO Cost: 1,832 Bytes: 2,052 Cardinality: 108
1 INDEX RANGE SCAN INDEX PROD.CRMINFO_X2 Cost: 117 Cardinality: 42,519
Index (PROD):
CRMINFO_X2 (RETAILER)
How does Oracle calculates the cost and decides which index it should fetch ? Why it didn't choose the same index as of test env? How should i approach and which domains i need to dig-in to find the cause?
I did try playing with the above mentioned init parameters but it didn't help at all.
Thanks.
Regards,
~PointerPointer wrote:
Hmm, my worry is how do i force oracle to grap the proper index on prod i.e (CRMINFO_X1). I certainly believe it's a bad approach on adding a hint in the select statement and to force oralce to fetch that index.Why do you believe that, the index you mention is the "proper" index versus what Oracle is choosing? Can you prove with hinting that the "proper" index results in a faster and more efficient execution plan? If it does, then the next place I would look at is the statistics for the tables and columns of interest. From here you could try and estimate why Oracle thinks the other index is better. Another option is to run a 10053 (CBO) trace and see why Oracle thinks it is better.
I would not support a hint in a production environment, except in the most extreme cases. Usually the CBO makes the right choice, but it only can if the statistics match the distribution of data.
Refreshing the data may help me simulating the issue on TST but it wouldn't help me to understand why on prod it uses CRMINFO_X2 instead of CRMINFO_X1 which has all the three columns in the Where clause of the query.It would help because it's a test environment and you wouldn't have to do any queries directly on your production system to achieve the same results.
>
A bad thought here :( , if i create a new index by changing the column positioning say like ( RETAILER, STATUS , EXC) instead of (EXC, RETAILER, STATUS) will oracle fetch it ? or would it help in reducing the cost and cardinatlity of the select query.It's not that easy. There is a lot that goes into the cost calculation, some of that is known (through the great work by Jonathan Lewis and Richard Foote), and some of that is purely internal to Oracle. If you are more interested in the internals Cost-Based Oracle Fundamentals by Jonathan Lewis is a great book.
HTH! -
Same query, same dataset, same ddl setup, but wildly different explain plan
Hello o fountains of oracle knowledge!
We have a problem that caused us a full stop when rolling out a new version of our system to a customer and a whole Sunday to boot.
The scenario is as follows:
1. An previous version database schema
2. The current version database schema
3. A migration script to migrate the old schema to the new
So we perform the following migration:
1. Export the previous version database schema
2. Import into a new schema called schema_old
3. Create a new schema called schema_new
4. Run migration script which creates objects, copies data, creates indexes etc etc in schema_new
The migration runs fine in all environments (development, test and production)
In our development and test environments performance is stellar, on the customer production server the performance is terrible.
This using the exact same export file (from the production environment) and performing the exact same steps with the exact same migration script.
Database version is 10.2.0.1.0 EE on all databases. OS is Microsoft Windows Server 2003 EE SP2 on all servers.
The system is not in any sense under a heavy load (we have tested with no other load than ourselves).
Looking at the explain plan for a query that is run frequently and does not use bind variables we see wildly different explain plans.
The explain plan cost on our development and test servers is estimated to *7* for this query and there are no full table scans.
On the production server the cost is *8433* and there are two full table scans of which one is on the largest table.
We have tried to run analyse on all objects with very little effect. The plan changed very slightly, but still includes the two full table scans on the problem server and the cost is still the same.
All tables and indexes are identical (including storage options), created from the same migration script.
I am currently at loss for where to look? What can be causing this? I assume this could be caused by some parameter that is set on the server, but I don't know what to look for.
I would be very grateful for any pointers.
Thanks,
HåkonThank you for your answer.
We collected statistics only after we determined that the production server where not behaving according to expectations.
In this case we used TOAD and the tool within to collect statistics for all objects. We used 'Analyze' and 'Compute Statistics' options.
I am not an expert, so sorry if this is too naive an approach.
Here is the query:SELECT count(0)
FROM score_result sr, web_scorecard sc, product p
WHERE sr.score_final_decision like 'VENT%'
AND sc.CREDIT_APPLICATION_ID = sr.CREDIT_APPLICATION_ID
AND sc.application_complete='Y'
AND p.product = sc.web_product
AND p.inactive_product = '2' ;I use this as an example, but the problem exists for virtually all queries.
The output from the 'good' server:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 39 | 7 (0)|
| 1 | SORT AGGREGATE | | 1 | 39 | |
| 2 | NESTED LOOPS | | 1 | 39 | 7 (0)|
| 3 | NESTED LOOPS | | 1 | 30 | 6 (0)|
| 4 | TABLE ACCESS BY INDEX ROWID| SCORE_RESULT | 1 | 17 | 4 (0)|
| 5 | INDEX RANGE SCAN | SR_FINAL_DECISION_IDX | 1 | | 3 (0)|
| 6 | TABLE ACCESS BY INDEX ROWID| WEB_SCORECARD | 1 | 13 | 2 (0)|
| 7 | INDEX UNIQUE SCAN | WEB_SCORECARD_PK | 1 | | 1 (0)|
| 8 | TABLE ACCESS BY INDEX ROWID | PRODUCT | 1 | 9 | 1 (0)|
| 9 | INDEX UNIQUE SCAN | PK_PRODUCT | 1 | | 0 (0)|
---------------------------------------------------------------------------------------------The output from the 'bad' server:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 32 | 8344 (3)|
| 1 | SORT AGGREGATE | | 1 | 32 | |
| 2 | HASH JOIN | | 10887 | 340K| 8344 (3)|
| 3 | TABLE ACCESS FULL | PRODUCT | 6 | 42 | 3 (0)|
| 4 | HASH JOIN | | 34381 | 839K| 8340 (3)|
| 5 | VIEW | index$_join$_001 | 34381 | 503K| 2193 (3)|
| 6 | HASH JOIN | | | | |
| 7 | INDEX RANGE SCAN | SR_FINAL_DECISION_IDX | 34381 | 503K| 280 (3)|
| 8 | INDEX FAST FULL SCAN| SCORE_RESULT_PK | 34381 | 503K| 1371 (2)|
| 9 | TABLE ACCESS FULL | WEB_SCORECARD | 489K| 4782K| 6137 (4)|
----------------------------------------------------------------------------------------I hope the formatting makes this readable.
Stats (from SQL Developer), good table:NUM_ROWS 489716
BLOCKS 27198
AVG_ROW_LEN 312
SAMPLE_SIZE 489716
LAST_ANALYZED 15.12.2009
LAST_ANALYZED_SINCE 15.12.2009Stats (from SQL Developer), bad table:
NUM_ROWS 489716
BLOCKS 27199
AVG_ROW_LEN 395
SAMPLE_SIZE 489716
LAST_ANALYZED 17.12.2009
LAST_ANALYZED_SINCE 17.12.2009I'm unsure what would cause the difference in average row length.
I could obviously try to tune our sql-statements to work on the server not behaving better, but I would rather understand why they are different and make sure that we can expect similar behaviour between environments.
Thank you again for trying to help me.
Håkon
Edited by: ergates on 17.des.2009 05:57
Edited by: ergates on 17.des.2009 06:02 -
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. -
Different explain plan between 10.2.0.3 and 10.2.0.4
Had a problem with an explain plan changing after upgrade from 10.2.0.3 to 10.2.0.4. Managed to simplify as much as possible for now:
Query is :
SELECT * FROM m_promo_chk_str
WHERE (m_promo_chk_str.cust_cd) IN (
SELECT cust_cd
FROM s_usergrp_pda
GROUP BY cust_cd)
On 10.2.0.3 explain plan is:
| 0 | SELECT STATEMENT | | 1 | 1227 | 26 (16)| 00:00:01 |
|* 1 | HASH JOIN SEMI | | 1 | 1227 | 26 (16)| 00:00:01 |
| 2 | TABLE ACCESS FULL | M_PROMO_CHK_STR | 1 | 1185 | 14 (0)| 00:00:01 |
| 3 | VIEW | VW_NSO_1 | 137 | 5754 | 11 (28)| 00:00:01 |
| 4 | HASH GROUP BY | | 137 | 548 | 11 (28)| 00:00:01 |
| 5 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 9 (12)| 00:00:01 |
On 10.2.0.4 with same data is:
| 0 | SELECT STATEMENT | | 1 | 1201 | 46 (5)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 1201 | 46 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 1 | 1201 | 45 (3)| 00:00:01 |
| 3 | TABLE ACCESS FULL| M_PROMO_CHK_STR | 1 | 1197 | 29 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 15 (0)| 00:00:01 |
Explain plan is reasonable for when M_PROMO_CHK_STR is empty, however we have the case where stats are gathered when table is empty, but table is then populated and the query runs slowly. I understand that this is not a problem with the database exactly, but want to try to understand why the different behaviour.
Will look into CBO trace tommorrow, but for now anyone want to share any thoughts?PatHK wrote:
Here is further simplification to reproduce the different behaviour - I think about as simple as I can get it!
SELECT * FROM dual WHERE (dummy) IN (SELECT dummy FROM dual GROUP BY dummy);
On 10.2.0.3
| 0 | SELECT STATEMENT | | 1 | 4 | 5 (20)| 00:00:01 |
| 1 | NESTED LOOPS SEMI | | 1 | 4 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
|* 3 | VIEW | VW_NSO_1 | 1 | 2 | 3 (34)| 00:00:01 |
| 4 | SORT GROUP BY | | 1 | 2 | 3 (34)| 00:00:01 |
| 5 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |On 10.2.0.4
| 0 | SELECT STATEMENT | | 1 | 4 | 4 (0)| 00:00:01 |
| 1 | SORT GROUP BY NOSORT| | 1 | 4 | 4 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 4 | 4 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
Timur's suggestion to look at a 10053 trace file is a good idea. It might be the case that someone disabled complex view merging in the 10.2.0.3 database instance. See the following:
_complex_view_merging
http://jonathanlewis.wordpress.com/2007/03/08/transformation-and-optimisation/
Here is a test you might try on both database versions:
ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=TRUE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST1';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=FALSE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST2';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';The first plan output:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 8 (100)| |
| 1 | SORT GROUP BY NOSORT| | 1 | 4 | 8 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 4 | 8 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | DUAL | 1 | 2 | 4 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL | DUAL | 1 | 2 | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("DUMMY"="DUMMY")The second plan output:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 9 (100)| |
| 1 | NESTED LOOPS SEMI | | 1 | 4 | 9 (12)| 00:00:01 |
| 2 | TABLE ACCESS FULL | DUAL | 1 | 2 | 4 (0)| 00:00:01 |
|* 3 | VIEW | VW_NSO_1 | 1 | 2 | 5 (20)| 00:00:01 |
| 4 | SORT GROUP BY | | 1 | 2 | 5 (20)| 00:00:01 |
| 5 | TABLE ACCESS FULL| DUAL | 1 | 2 | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("DUMMY"="$nso_col_1")From the first 10053 trace file:
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
_pga_max_size = 368640 KB
pgamax_size is the only parameter non-default value which could affect the optimizer.
From the second 10053 trace file:
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
_pga_max_size = 368640 KB
_complex_view_merging = false
*********************************This section in the first 10053 trace seems to show the complex view merging:
SU: Considering interleaved complex view merging
SU: Transform an ANY subquery to semi-join or distinct.
CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
CVM: CBQT Marking query block SEL$683B0107 (#2)as valid for CVM.
CVM: Merging complex view SEL$683B0107 (#2) into SEL$5DA710D3 (#1).
qbcp:******* UNPARSED QUERY IS *******
SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM (SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY") "VW_NSO_2","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
vqbcp:******* UNPARSED QUERY IS *******
SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY"
CVM: result SEL$5DA710D3 (#1).
******* UNPARSED QUERY IS *******
SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM "SYS"."DUAL" "DUAL","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="DUAL"."DUMMY" GROUP BY "DUAL"."DUMMY","DUAL".ROWID,"DUAL"."DUMMY"
Registered qb: SEL$C9C6826C 0x155e2020 (VIEW MERGE SEL$5DA710D3; SEL$683B0107)
signature (): qb_name=SEL$C9C6826C nbfros=2 flg=0
fro(0): flg=0 objn=258 hint_alias="DUAL"@"SEL$1"
fro(1): flg=0 objn=258 hint_alias="DUAL"@"SEL$2"
FPD: Considering simple filter push in SEL$C9C6826C (#1)
FPD: Current where clause predicates in SEL$C9C6826C (#1) :
"DUAL"."DUMMY"="DUAL"."DUMMY"
kkogcp: try to generate transitive predicate from check constraints for SEL$C9C6826C (#1)
predicates with check contraints: "DUAL"."DUMMY"="DUAL"."DUMMY"
after transitive predicate generation: "DUAL"."DUMMY"="DUAL"."DUMMY"
finally: "DUAL"."DUMMY"="DUAL"."DUMMY"
CVM: Costing transformed query.
kkoqbc-start
: call(in-use=25864, alloc=65448), compile(in-use=115280, alloc=118736)
kkoqbc-subheap (create addr=000000001556CD70)This is the same section from the second 10053 trace:
SU: Considering interleaved complex view merging
SU: Transform an ANY subquery to semi-join or distinct.
CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
FPD: Considering simple filter push in SEL$5DA710D3 (#1)
FPD: Current where clause predicates in SEL$5DA710D3 (#1) :
"DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
predicates with check contraints: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
after transitive predicate generation: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
finally: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
FPD: Considering simple filter push in SEL$683B0107 (#2)
FPD: Current where clause predicates in SEL$683B0107 (#2) :
CVM: Costing transformed query.
kkoqbc-start
: call(in-use=25656, alloc=65448), compile(in-use=113992, alloc=114592)
kkoqbc-subheap (create addr=00000000157E9078)Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Explain plan results are different in SQL Developer than SQL Plus
My Environment:
SQL Developer 1.0.0.15.27
Platform where SQL Developer is running: Windows XP 2002 SP2
Oracle Database and Client 9.2.0.7
Optimizer_mode: FIRST_ROWS
I have the following SQL statement:
SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE :b2 = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > :b1
When I run an Explain in SQL Developer I get the following access path (which is the one I really want):
SELECT STATEMENT TABLE ACCESS(BY INDEX ROWID) FEDLINK.AU_COMPANY NESTED LOOPS INDEX(RANGE SCAN)
FEDLINK.UX2_TEMP_AU_COMPANY
INDEX(RANGE SCAN) FEDLINK.PX1_COMPANY
However, when I execute the statement with sql_trace turned on and use tkprof to generate the actual access path, the statement executes as follows (which is WAY more expensive):
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 3.58 6.68 28136 29232 0 0
total 3 3.58 6.69 28136 29232 0 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 979 (FEDLINK) (recursive depth: 1)
Rows Row Source Operation
0 NESTED LOOPS
0 TABLE ACCESS FULL AU_COMPANY
0 INDEX RANGE SCAN UX2_TEMP_AU_COMPANY (object id 49783)
Notice the FULL access of au_company.
I understand that SQL Developer has nothing to do with why the statement executed the way it did, but why is the Explain in SQL Developer different than the actual execution plan?
Added note....when I run the explain in SQL Plus it is the same as the actual execution. Here is the explain from SQL Plus:
explain plan for SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE '1' = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > '01-MAY-2006';
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 76 | 2597 |
| 1 | NESTED LOOPS | | 2 | 76 | 2597 |
| 2 | TABLE ACCESS FULL | AU_COMPANY | 2 | 42 | 2595 |
| 3 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 1 | 17 | 2
Thanks,
BrendaThe explain is different (full scan of au_company in SQL Plus / index access in SQL Developer) even when I use variables in SQL Plus. Here is the output for SQL Plus using variables instead of literals:
SQL> variable b1 varchar2
SQL> variable b2 char
SQL> explain plan for SELECT a1.comp_id
2 FROM temp_au_company a0, au_company a1
3 WHERE :b2 = a0.temp_emp_code
4 AND a0.comp_id = a1.comp_id
5 AND a0.sls_terr_code != a1.sls_terr_code
6 AND a1.last_mdfy_date > :b1
7 /
Explained.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 3184 | 118K| 2995 |
| 1 | HASH JOIN | | 3184 | 118K| 2995 |
| 2 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 3187 | 54179 | 3 |
| 3 | TABLE ACCESS FULL | AU_COMPANY | 24009 | 492K| 2983 |
Any other ideas? They should be the same.
Brenda -
Explain Plan in SQL Developer vs. SQLPlus
Hi everyone,
I've got a quick question. Why would an explain plan hang in SQL Developer but come back immediately in SQL Plus?
For example, in SQL developer, I write my statement and use the F6 command to bring up the explain plan and it just hangs and hangs. It looks like it's trying to generate an explain plan, but it's been running for hours now.
When I log into SQL Plus, I do a
SQL> explain plan for <query>:
SQL> select * from table(dbms_xplan.display);That whole process takes less than a minute to get the explain plan.
Is there something fundamentally different being executed by SQL Developer?
Thanks!
-JoeJoe,
F6 in SQL Developer runs an AutoTrace, which actually runs the SQL and also displays timings and the explain plan. If you only want the explain plan, use F10.
Regards,
Bob
Maybe you are looking for
-
I previously loaded iTunes on my Dell, Windows XP for my visiting brother using his software and it worked fine. He left and I uninstalled the old iTunes/Quicktime from my computer. I bought a nano and tried to load the iTunes software from the disc.
-
Hello all, How can I ensure that my key figure is cumulated only per fiscal year? Thus, now I have: January 2006 - 8.850.678 February 2006 - 17.449.955 March 2006 - 25.914.014 April 2006 - 32.849.374 M
-
Sysvol was not shared\replicating after the DCpromo windows 2012 R2 datacenter
SYSVOL does not shared\replicating after the DCpromo windows 2012 R2 datacenter, and the partner DC is 2008 R2 Standard. both the forest & domain level is Windows2008R2.
-
Hi Experts, Please tell me how to access the Spool reports in XI. And what roles are needed to access. Thanks in advance. MK
-
Photoshop 10.0.1 Power Mac G5 OSX 10.4.11 2GB DDR SDRAM Memory When I open PSD or TIFF (unsure about other file formats) files previously worked on, saved, and then closed at a specific resolution (example 1" x 1" at 300ppi), they now open at 4.167"