Query needs tuning; Explain plan attached
DB version:10gR2
Currently, the below query is taking more than 28 secs to complete. The table stats are up-to-date.
Is there a way to rewrite/tune this query?
SELECT DISTINCT TASK_HDR.TASK_ID,
TASK_HDR.WHSE,
TASK_HDR.TASK_DESC,
TASK_HDR.INVN_TYPE,
TASK_HDR.INVN_NEED_TYPE,
TASK_HDR.DFLT_TASK_PRTY,
TASK_HDR.CURR_TASK_PRTY,
TASK_HDR.XPECTD_DURTN,
TASK_HDR.ACTL_DURTN,
TASK_HDR.ERLST_START_DATE_TIME,
TASK_HDR.LTST_START_DATE_TIME,
TASK_HDR.LTST_CMPL_DATE_TIME,
TASK_HDR.BEGIN_AREA,
TASK_HDR.BEGIN_ZONE,
TASK_HDR.BEGIN_AISLE,
TASK_HDR.END_AREA,
TASK_HDR.END_ZONE,
TASK_HDR.END_AISLE,
TASK_HDR.START_CURR_WORK_GRP,
TASK_HDR.START_CURR_WORK_AREA,
TASK_HDR.END_CURR_WORK_GRP,
TASK_HDR.END_CURR_WORK_AREA,
TASK_HDR.START_DEST_WORK_GRP,
TASK_HDR.START_DEST_WORK_AREA,
TASK_HDR.END_DEST_WORK_GRP,
TASK_HDR.END_DEST_WORK_AREA,
TASK_HDR.TASK_TYPE,
TASK_HDR.TASK_GENRTN_REF_CODE,
TASK_HDR.TASK_GENRTN_REF_NBR,
TASK_HDR.NEED_ID,
TASK_HDR.TASK_BATCH,
TASK_HDR.STAT_CODE,
TASK_HDR.CREATE_DATE_TIME,
TASK_HDR.MOD_DATE_TIME,
TASK_HDR.USER_ID,
TASK_HDR.RLS_DATE_TIME,
TASK_HDR.SKU_ID,
TASK_HDR.TASK_CMPL_REF_CODE,
TASK_HDR.TASK_CMPL_REF_NBR,
TASK_HDR.OWNER_USER_ID,
TASK_HDR.ONE_USER_PER_GRP,
TASK_HDR.NEXT_TASK_ID,
TASK_HDR.EXCEPTION_CODE,
TASK_HDR.CURR_LOCN_ID,
TASK_HDR.TASK_PARM_ID,
TASK_HDR.RULE_ID,
TASK_HDR.VOCOLLECT_ASSIGN_ID,
TASK_HDR.CURR_USER_ID,
TASK_HDR.MHE_FLAG,
TASK_HDR.PICK_TO_TOTE_FLAG,
TASK_HDR.MHE_ORD_STATE,
TASK_HDR.PRT_TASK_LIST_FLAG,
TASK_HDR.RPT_PRTR_REQSTR,
TASK_HDR.ORIG_TASK_ID
FROM INVN_NEED_TYPE, TASK_DTL, TASK_HDR
WHERE (TASK_HDR.TASK_ID = TASK_DTL.TASK_ID(+))
AND TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
(INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
(TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1) AND
TASK_HDR.MOD_DATE_TIME <= sysdate-85
ORDER BY TASK_HDR.CREATE_DATE_TIME DESC
The explain plan:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 10032 | 1969K| | 3143 (2)|
| 1 | SORT ORDER BY | | 10032 | 1969K| 4232K| 3143 (2)|
| 2 | HASH UNIQUE | | 10032 | 1969K| 4232K| 2689 (2)|
| 3 | FILTER | | | | | |
| 4 | NESTED LOOPS OUTER | | 10032 | 1969K| | 2235 (1)|
| 5 | NESTED LOOPS | | 3226 | 570K| | 284 (3)|
| 6 | TABLE ACCESS BY INDEX ROWID| TASK_HDR | 3412 | 559K| | 282 (2)|
| 7 | INDEX RANGE SCAN | TASK_HDR_IND_3 | 9042 | | | 8 (13)|
| 8 | INDEX UNIQUE SCAN | PK_INVN_NEED_TYPE | 1 | 13 | | 1 (0)|
| 9 | TABLE ACCESS BY INDEX ROWID | TASK_DTL | 3 | 60 | | 1 (0)|
| 10 | INDEX RANGE SCAN | PK_TASK_DTL | 3 | | | 1 (0)|
---------------------------------------------------------------------------------------------------
My apologies, yes, it is:
SELECT TASK_HDR.TASK_ID,
TASK_HDR.WHSE,
TASK_HDR.TASK_DESC,
TASK_HDR.INVN_TYPE,
TASK_HDR.INVN_NEED_TYPE,
TASK_HDR.DFLT_TASK_PRTY,
TASK_HDR.CURR_TASK_PRTY,
TASK_HDR.XPECTD_DURTN,
TASK_HDR.ACTL_DURTN,
TASK_HDR.ERLST_START_DATE_TIME,
TASK_HDR.LTST_START_DATE_TIME,
TASK_HDR.LTST_CMPL_DATE_TIME,
TASK_HDR.BEGIN_AREA,
TASK_HDR.BEGIN_ZONE,
TASK_HDR.BEGIN_AISLE,
TASK_HDR.END_AREA,
TASK_HDR.END_ZONE,
TASK_HDR.END_AISLE,
TASK_HDR.START_CURR_WORK_GRP,
TASK_HDR.START_CURR_WORK_AREA,
TASK_HDR.END_CURR_WORK_GRP,
TASK_HDR.END_CURR_WORK_AREA,
TASK_HDR.START_DEST_WORK_GRP,
TASK_HDR.START_DEST_WORK_AREA,
TASK_HDR.END_DEST_WORK_GRP,
TASK_HDR.END_DEST_WORK_AREA,
TASK_HDR.TASK_TYPE,
TASK_HDR.TASK_GENRTN_REF_CODE,
TASK_HDR.TASK_GENRTN_REF_NBR,
TASK_HDR.NEED_ID,
TASK_HDR.TASK_BATCH,
TASK_HDR.STAT_CODE,
TASK_HDR.CREATE_DATE_TIME,
TASK_HDR.MOD_DATE_TIME,
TASK_HDR.USER_ID,
TASK_HDR.RLS_DATE_TIME,
TASK_HDR.SKU_ID,
TASK_HDR.TASK_CMPL_REF_CODE,
TASK_HDR.TASK_CMPL_REF_NBR,
TASK_HDR.OWNER_USER_ID,
TASK_HDR.ONE_USER_PER_GRP,
TASK_HDR.NEXT_TASK_ID,
TASK_HDR.EXCEPTION_CODE,
TASK_HDR.CURR_LOCN_ID,
TASK_HDR.TASK_PARM_ID,
TASK_HDR.RULE_ID,
TASK_HDR.VOCOLLECT_ASSIGN_ID,
TASK_HDR.CURR_USER_ID,
TASK_HDR.MHE_FLAG,
TASK_HDR.PICK_TO_TOTE_FLAG,
TASK_HDR.MHE_ORD_STATE,
TASK_HDR.PRT_TASK_LIST_FLAG,
TASK_HDR.RPT_PRTR_REQSTR,
TASK_HDR.ORIG_TASK_ID
FROM INVN_NEED_TYPE,TASK_HDR
WHERE TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
(INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
TASK_HDR.MOD_DATE_TIME <= sysdate-85
AND EXISTS (SELECT 1
FROM TASK_DTL
WHERE TASK_HDR.TASK_ID = TASK_DTL.TASK_ID
AND (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1))
ORDER BY TASK_HDR.CREATE_DATE_TIME DESCAlthough you have an OUTER JOIN on TASK_DTL.TASK_ID, this is converted to an INNER JOIN with (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1), which is the equivalent of the 'EXISTS' version above.
I haven't been able to test this.
Similar Messages
-
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! -
Tuning needed for sql:EXPLAIN PLAN attached
DB Version:10gR2
The below sql was running slow, so i took an explain plan
SQL> explain plan for
2 SELECT COUNT(1) FROM SHIP_DTL WHERE
3 SHIP_DTL.PLT_ID = 'AM834'
4 AND SHIP_DTL.WHSE = '34' AND
5 SHIP_DTL.STAT_CODE != '845'
6 ORDER BY SHIP_DTL.LOAD_SEQ ASC;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 18 | 5 (20)|
| 1 | SORT AGGREGATE | | 1 | 18 | |
|* 2 | TABLE ACCESS BY INDEX ROWID| SHIP_DTL | 200 | 3600 | 5 (20)|
|* 3 | INDEX RANGE SCAN | SHIP_DTL_IND_4 | 203 | | 3 (0)|
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter("SHIP_DTL"."WHSE"='34' AND "SHIP_DTL"."STAT_CODE"<>845)
3 - access("SHIP_DTL"."PLT_ID"='AM834')Why is there an INDEX RANGE scan where there is no BETWEEN operator in the query? What are various options(indexes, rewriting query) in tuning this query?james_p wrote:
DB Version:10gR2
The below sql was running slow, so i took an explain planCheck your plan, the optimizer estimates that the following query:
select count(*)
from SHIP_DTL
where "SHIP_DTL"."PLT_ID"='AM834';only returns 200 records. Is this correct? Please post the result of above query.
It probably isn't the case, because retrieving 200 records per index range scan and single row random table access shouldn't take long, at maximum a couple of seconds if you need to read each block actually from disk rather than from the cache.
If the estimate is wrong you need to check the statistics on the table and index that were used by the optimizer to come to that conclusion.
Are you sure that this plan is the actual plan used at execution time? You can check for the actual plans used to execute by using the DBMS_XPLAN.DISPLAY_CURSOR function in 10g if the SQL is still cached in the Shared Pool. You need to pass the SQL_ID and SQL_CHILD_NUMBER which you can retrieve from V$SESSION while the statement is executing.
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/ -
SQL Tuning- slow query on GL_BALANCES- Explain plan provided
Hi- I really need some help here.
The following SQL statement has been identified to perform poorly.
It currently takes from 2-3 minutes to execute. I see it is because GL_BALANCES has so many rows.
Is there any way around this? Explain and info below. Thanks gurus!
This is the SQL statement:
SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
FROM gl_balances GLB, gl_code_combinations GCC
WHERE GLB.ACTUAL_FLAG = 'A'
AND GLB.Last_Update_Date > to_date('11-JAN-2010','DD-MON-YYYY')
AND GLB.code_combination_id = GCC.code_combination_id
AND EXISTS (
SELECT 1
FROM fnd_flex_value_sets A, fnd_flex_values B
WHERE A.flex_value_set_name = 'XXX_XXX'
AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
AND A.flex_value_set_id = b.flex_value_set_id
AND GCC.segment11 = b.flex_value
);The version of the database is 11.1.0.7.
These are the parameters relevant to the optimizer:
NAME TYPE VALUE
optimizerautostats_job boolean FALSE
optimizerextended_cursor_sharing_r string NONE
el
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean FALSE
optimizer_use_invisible_indexes boolean FALSE
NAME TYPE VALUE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
optimizerextended_cursor_sharing_r string NONE
el
cursor_sharing string EXACT
select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO STATUS
COMPLETED
SYSSTATS_INFO DSTART
09-02-2006 14:35
SYSSTATS_INFO DSTOP
09-02-2006 14:35
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 451.262136
SYSSTATS_MAIN IOSEEKTIM 10
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN SLAVETHR
13 rows selected.
SQL> explain plan for
2 SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
3 FROM gl_balances GLB, gl_code_combinations GCC
4 WHERE GLB.code_combination_id = GCC.code_combination_id
5 AND GLB.ACTUAL_FLAG = 'A'
6 AND GLB.Last_Update_Date > '11-JAN-2010'
7 AND EXISTS (SELECT 1
8 FROM fnd_flex_value_sets A, fnd_flex_values B
9 WHERE A.flex_value_set_id = b.flex_value_set_id
10 AND A.flex_value_set_name = 'XXX_XXX'
11 AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
12 AND GCC.segment11 = b.flex_value);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1839014065
| Id | Operation | Name | Rows | By
tes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 4102 |
296K| 955K (3)| 03:11:03 |
| 1 | HASH UNIQUE | | 4102 |
296K| 955K (3)| 03:11:03 |
|* 2 | HASH JOIN | | 4102 |
296K| 955K (3)| 03:11:03 |
| 3 | NESTED LOOPS | | |
| | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 23907 | 1
354K| 2598 (1)| 00:00:32 |
| 5 | NESTED LOOPS | | 1 |
45 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUE_SETS | 1 |
28 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | FND_FLEX_VALUE_SETS_U2 | 1 |
PLAN_TABLE_OUTPUT
| 1 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUES | 1 |
17 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | FND_FLEX_VALUES_N2 | 53 |
| 1 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N11 | 25427 |
| 106 (1)| 00:00:02 |
PLAN_TABLE_OUTPUT
| 11 | TABLE ACCESS BY INDEX ROWID | GL_CODE_COMBINATIONS | 18664 |
236K| 2593 (1)| 00:00:32 |
|* 12 | TABLE ACCESS FULL | GL_BALANCES | 1022K|
15M| 952K (3)| 03:10:32 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("GLB"."CODE_COMBINATION_ID"="GCC"."CODE_COMBINATION_ID")
7 - access("A"."FLEX_VALUE_SET_NAME"='SSA_SGL')
8 - filter(UPPER("B"."ATTRIBUTE3")='APPORTIONMENT')
9 - access("A"."FLEX_VALUE_SET_ID"="B"."FLEX_VALUE_SET_ID")
10 - access("GCC"."SEGMENT11"="B"."FLEX_VALUE")
12 - filter("GLB"."LAST_UPDATE_DATE">TO_DATE(' 2010-01-11 00:00:00', 'syyyy-mm
-dd hh24:mi:ss') AND
"GLB"."ACTUAL_FLAG"='A')
30 rows selected.As per the other replies, you've not really given enough information to go on - what are you trying to achieve, versions, etc.
On my old apps 11.5.8 system, the explain plan for your query uses GL_CODE_COMBINATIONS_U1 rather than a full scan of gl_code_combinations.
Check your stats are up to date (select table_name, num_rows, last_analyzed from dba_tables where ...)
See if you can also use period_name and/or period_set_name (or period_num) from GL_Periods rather than period_year (i.e. use P_YEAR to lookup the period_name/period_set_name/period_num from gl_periods). It might be faster to do per period and then consolidate for the whole year, as there are indexes on gl_balances for columns period_name, period_set_name, period_num.
regards, Ivan -
Any room for improvement for this query? Explain Plan attached.
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??
select sum(CONF
when (cd.actl_qty - cd.total_alloc_qty - lsd.Q < 0) then
0
else
cd.actl_qty - cd.total_alloc_qty - lsd.Q
end)
from (select sum(reqd_qty) as Q, ITEM_ID as ITEM
from SHIP_DTL SD
where exists (select 1
from CONF_dtl
where CONF_nbr = '1'
and ITEM_id = SD.ITEM_id)
group by ITEM_id) lsd,
CONF_dtl cd
where lsd.ITEM = cd.ITEM_id
and cd.CONF_nbr = '1'Total number of rows in the tables involved
select count(*) from CONF_DTL;
COUNT(*)
1785889
select count(*) from shp_dtl;
COUNT(*)
286675
Explain Plan
PLAN_TABLE_OUTPUT
Plan hash value: 2325658044
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 39 | 4 (25)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 39 | | |
| 2 | VIEW | | 1 | 39 | 4 (25)| 00:00:01 |
| 3 | HASH GROUP BY | | 1 | 117 | 4 (25)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID | SHIP_DTL | 1 | 15 | 1 (0)| 00:00:01
| 5 | NESTED LOOPS | | 1 | 117 | 3 (0)| 00:00:01 |
| 6 | MERGE JOIN CARTESIAN | | 1 | 102 | 2 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | CONF_DTL | 1 | 70 | 1 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | PK_CONF_DTL | 1 | | 1 (0)| 00:00:01 |
| 9 | BUFFER SORT | | 1 | 32 | 1 (0)| 00:00:01 |
| 10 | SORT UNIQUE | | 1 | 32 | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| CONF_DTL | 1 | 32 | 1 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | PK_CONF_DTL | 1 | | 1 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | SHIP_DTL_IND_6 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
8 - access("CD"."CONF_NBR"='1')
12 - access("CONF_NBR"='1')
13 - access("ITEM_ID"="SD"."ITEM_ID")
filter("ITEM_ID"="CD"."ITEM_ID")Citizen_2 wrote:
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??You say that the table stats are up-to-date, but is the following assumption of the optimizer correct:
select count(*)
from CONF_dtl
where CONF_nbr = '1';Does this query return a count of 1? I doubt that, but that's what Oracle estimates in the EXPLAIN PLAN output. Based on that assumption you get a cartesian join between the two CONF_DTL table instances, and the result - which is still expected to be one row at most - is then joined to the SHIP_DTL table using a NESTED LOOP.
If above assumption is incorrect, the number of rows generated by the cartesian join can be tremendous rendering the NESTED LOOP operation quite inefficient.
You can verify this by using the DBMS_XPLAN.DISPLAY_CURSOR function together with the GATHER_PLAN_STATISTICS hint, if you're already on 10g or later.
For more information regarding the DISPLAY_CURSOR function, see e.g. here: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
It will show you the actual cardinalities compared to the estimated cardinalities.
If the estimate of the optimizer is incorrect, you should find out why. There still might be some issues with the statistics, since this is most obvious reason for incorrect estimates.
Are your index statistics up-to-date?
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/ -
Query with diff. explain plans
Hi,
Our query returns different execution plans in Prod and non-prod. It is slow in PROD. The data size is the same in both DBs and stats are gathered at 50% estimate for both schemas:
Prod (slow) explain plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 852 | 33 (4)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 852 | 33 (4)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 852 | 32 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 802 | 31 (0)| 00:00:01 |
| 5 | NESTED LOOPS OUTER | | 1 | 785 | 30 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 742 | 29 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 732 | 29 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 678 | 26 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 666 | 26 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 623 | 25 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 580 | 24 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 576 | 24 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 2 | 1076 | 13 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 2 | 1040 | 13 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 2 | 1028 | 13 (0)| 00:00:01 |
| 16 | NESTED LOOPS | | 2 | 996 | 13 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 2 | 988 | 13 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 2 | 954 | 13 (0)| 00:00:01 |
| 19 | NESTED LOOPS | | 2 | 944 | 13 (0)| 00:00:01 |
| 20 | NESTED LOOPS | | 2 | 920 | 13 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 2 | 912 | 13 (0)| 00:00:01 |
| 22 | NESTED LOOPS | | 2 | 826 | 11 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 370 | 9 (0)| 00:00:01 |
| 24 | NESTED LOOPS | | 1 | 306 | 8 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 263 | 7 (0)| 00:00:01 |
| 26 | NESTED LOOPS | | 1 | 220 | 6 (0)| 00:00:01 |
| 27 | NESTED LOOPS | | 1 | 177 | 5 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 129 | 4 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 86 | 3 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 2 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 48 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 64 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 46 | INLIST ITERATOR | | | | | |
| 47 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 86 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 52 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 12 | 0 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 17 | 0 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 16 | 0 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 6 | 0 (0)| 00:00:01 |
|* 58 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 18 | 0 (0)| 00:00:01 |
| 59 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 38 | 6 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 5 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 12 | 0 (0)| 00:00:01 |
| 67 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 54 | 3 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 10 | 0 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 72 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 17 | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
|* 74 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 50 | 1 (0)| 00:00:01 |
|* 75 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Non Prod (Fast) Plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 383 | 28 (0)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | NESTED LOOPS | | 1 | 383 | 17 (0)| 00:00:01 |
| 3 | NESTED LOOPS OUTER | | 1 | 350 | 16 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 308 | 15 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 266 | 14 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 262 | 14 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 258 | 14 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 2 | 438 | 7 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 2 | 428 | 7 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 2 | 420 | 7 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 2 | 410 | 7 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 2 | 402 | 7 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 159 | 5 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 126 | 4 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 84 | 3 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 24 | INLIST ITERATOR | | | | | |
| 25 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 84 | 2 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 39 | 4 (0)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 3 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 35 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 33 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
| 41 | SORT AGGREGATE | | 1 | 252 | | |
| 42 | NESTED LOOPS | | 1 | 252 | 11 (0)| 00:00:01 |
| 43 | NESTED LOOPS | | 1 | 240 | 10 (0)| 00:00:01 |
| 44 | NESTED LOOPS | | 1 | 205 | 7 (0)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 200 | 7 (0)| 00:00:01 |
| 46 | NESTED LOOPS | | 1 | 196 | 7 (0)| 00:00:01 |
| 47 | NESTED LOOPS | | 1 | 191 | 7 (0)| 00:00:01 |
| 48 | NESTED LOOPS | | 1 | 187 | 7 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 183 | 7 (0)| 00:00:01 |
| 50 | NESTED LOOPS | | 1 | 150 | 6 (0)| 00:00:01 |
| 51 | NESTED LOOPS | | 1 | 120 | 5 (0)| 00:00:01 |
| 52 | NESTED LOOPS | | 1 | 90 | 4 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 60 | 3 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 71 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 35 | 3 (0)| 00:00:01 |
|* 72 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 73 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 12 | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Database version is 10.2.0.4. Can anyone help me understand what else to be looking for to make it work faster?Please see the following threads for the ideal information required:
How to post a sql tuning request:
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long:
When your query takes too long ... -
SQL Tuning - Explain plan analysis
Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..
UNIT ENVT
==========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 4739K| 646M| | 85917 (1)| 00:19:12 |
| 1 | LOAD TABLE CONVENTIONAL | F_DRV_FUEL_W | | | | | |
| 2 | HASH UNIQUE | | 4739K| 646M| 726M| 85917 (1)| 00:19:12 |
|* 3 | HASH JOIN RIGHT OUTER | | 4739K| 646M| | 7881 (3)| 00:01:46 |
| 4 | VIEW | | 20936 | 756K| | 1456 (1)| 00:00:20 |
|* 5 | HASH JOIN RIGHT OUTER | | 10468 | 572K| | 594K (5)| 02:12:51 |
| 6 | TABLE ACCESS FULL | X_SNI_TRK_STP_P | 2754 | 33048 | | 5 (0)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 10468 | 449K| | 594K (5)| 02:12:51 |
| 8 | TABLE ACCESS FULL | X_SNI_FUEL_CMPLY_DTL_P | 10468 | 184K| | 14 (0)| 00:00:01 |
| 9 | VIEW | | 1 | 26 | | 57 (6)| 00:00:01 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 1 | 59 | | 57 (6)| 00:00:01 |
|* 12 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 1 | 28 | | 27 (0)| 00:00:01 |
|* 13 | VIEW | | 17659 | 534K| | 29 (7)| 00:00:01 |
|* 14 | WINDOW SORT PUSHED RANK| | 17659 | 448K| | 29 (7)| 00:00:01 |
| 15 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 17659 | 448K| | 27 (0)| 00:00:01 |
|* 16 | HASH JOIN RIGHT OUTER | | 4739K| 479M| 14M| 6404 (3)| 00:01:26 |
|* 17 | TABLE ACCESS FULL | XO_E_PER_ASSIGNMENT_P | 276K| 11M| | 2616 (2)| 00:00:36 |
|* 18 | HASH JOIN | | 699K| 42M| 20M| 2704 (3)| 00:00:37 |
|* 19 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_PRD_P | 702K| 12M| | 536 (3)| 00:00:08 |
|* 20 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_P | 695K| 30M| | 1202 (3)| 00:00:17 |
Predicate Information (identified by operation id):
3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
"X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1
AND "XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
49 rows selected.
UAT ENVT
=========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 998K| 139M| | 34826 (1)| 00:07:47 |
| 1 | LOAD TABLE CONVENTIONAL | F_DRV_FUEL_W | | | | | |
| 2 | HASH UNIQUE | | 998K| 139M| 157M| 34826 (1)| 00:07:47 |
|* 3 | HASH JOIN RIGHT OUTER | | 998K| 139M| 44M| 18001 (2)| 00:04:02 |
| 4 | VIEW | | 931K| 33M| | 4250 (1)| 00:00:57 |
|* 5 | HASH JOIN RIGHT OUTER | | 62082 | 3576K| | 25M (2)| 96:08:31 |
| 6 | TABLE ACCESS FULL | X_SNI_TRK_STP_P | 5603 | 61633 | | 10 (0)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 30548 | 1431K| | 25M (2)| 96:08:31 |
| 8 | TABLE ACCESS FULL | X_SNI_FUEL_CMPLY_DTL_P | 30548 | 715K| | 46 (3)| 00:00:01 |
| 9 | VIEW | | 1 | 24 | | 845 (2)| 00:00:12 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 1 | 57 | | 845 (2)| 00:00:12 |
|* 12 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 1 | 29 | | 150 (2)| 00:00:03 |
|* 13 | VIEW | | 151K| 4155K| | 694 (2)| 00:00:10 |
|* 14 | WINDOW SORT PUSHED RANK| | 151K| 3413K| 5376K| 694 (2)| 00:00:10 |
| 15 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 151K| 3413K| | 150 (2)| 00:00:03 |
|* 16 | HASH JOIN RIGHT OUTER | | 998K| 103M| 15M| 11138 (2)| 00:02:30 |
|* 17 | TABLE ACCESS FULL | XO_E_PER_ASSIGNMENT_P | 296K| 11M| | 5060 (2)| 00:01:08 |
|* 18 | HASH JOIN | | 1028K| 65M| 31M| 4555 (3)| 00:01:02 |
|* 19 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_PRD_P | 1037K| 19M| | 1000 (2)| 00:00:14 |
|* 20 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_P | 1020K| 45M| | 2088 (3)| 00:00:28 |
Predicate Information (identified by operation id):
3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
"X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND
"XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1 AND
"XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
Note
- SQL profile "SYS_SQLPROF_0139a0175fb30006" used for this statementOra DBA wrote:
Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..As a first step towards diagnosis, I would check following:
1) First step would be to isolate the problem. So you may want to verify if the SELECT part or the INSERT part is contributing more to run-time (It looks like the SELECT part but always good to confirm). That way, you can concentrate on, for e.g., tuning only SELECT part.
2) When trying to compare the runtime from 2 environments, ensure that you are using almost similar (if not same) data volumes and same tables/index structures
3) As both environments produce same plan, presumably the tables involved have similar pattern of statistics. But the actual data volume may be quite different. So check whether statistics are representative of actual data
4) Fortunately, your plan uses all FULL TABLE ACCESS and HASH JOIN (except one NESTED LOOP). So for a query that runs for more than 5 hours, you should be able to monitor individual steps using v$session_longops. As you are on 11G, you may also make use of Real-time SQL monitoring.
5) While it is not possible to decisively conclude anything based on EXPLAIN PLAN output, you may want to compare the PGA settings and TEMP file disk I/O capabilities of both environments. For e.g. in UNIT env, all the HASH JOINS that spill to disk are expected to be completed quicker than the corresponding HASH JOINS on UAT env. (Again, same volume of data would benefit the comparison here).
6) You may want to get rid of any HINTs used to check how CBO decides to process the query when left on its own.
7) Last but not the least, you may want to check the table design, especially as this query appears to involve lots of outer joins and analytical functions. Difficult to say anything conclusive without knowing the query but the following part of the plan suggests that there might be an opportunity to validate the logic used.
| 9 | VIEW | | 1 | 26 | | 57 (6)| 00:00:01 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 1 | 59 | | 57 (6)| 00:00:01 |
|* 12 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 1 | 28 | | 27 (0)| 00:00:01 |
|* 13 | VIEW | | 17659 | 534K| | 29 (7)| 00:00:01 |
|* 14 | WINDOW SORT PUSHED RANK| | 17659 | 448K| | 29 (7)| 00:00:01 |
| 15 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 17659 | 448K| | 27 (0)| 00:00:01 |This looks like a self-join of a table with itself, combined with usage of analytic function. Both might not be necessary and may be re-written to either avoid self-join or the analytic function part or replace them with a simpler query, which, in turn may impact the CBO's choice of subsequent NESTED LOOP join.
Hope this helps. -
TUNNING A SQL QUERY AND UNSERSTAND EXPLAIN PLAN
I was trying my handing in tunning sql queries -
Though I have manged to reduce the cost lil ..creating some index, but have genarated a g8 interesting in tunning - Can some experts ( I know there are lots available :-) ) help me on the approch on "HOW TO TUNE A QUERY"
moreover I also would like to understand - how to debug a explain plan, - please help ...
Regards..Hi,
Welcome to this forum...
I would suggest your to read first the official documentations :
- The concepts of an Oracle DBMS (this is important to know, because Oracle structures, processes, objects (etc) are the building blocks of your database)
- SQL reference guide
- PL/SQL reference guide
and then at a later stage the Performance and tuning guide:
You can start there:
http://download.oracle.com/docs/cd/B14117_01/nav/portal_1.htm
Once it's done maybe read the Performance and tuning guide:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/toc.htm
(Chapter 19 explain ... how to interpret the explain plan ..)
I wish you good chance and be patient: I'm working with Oracle for more that 10 years and I'm still learning! ...
Rem: The Oracle website is full of interesting articles, and examples, just "search" your special points of interests .. -
GL Code combination query Need tuning
Hi,
I'm trying to tune the following query
select *
FROM fnd_flex_values val1,
fnd_flex_values_tl flex1,
fnd_flex_values val2,
fnd_flex_values_tl flex2,
fnd_flex_values val3,
fnd_flex_values_tl flex3,
fnd_flex_values val4,
fnd_flex_values_tl flex4,
fnd_flex_values val5,
fnd_flex_values_tl flex5,
gl_code_combinations gc
WHERE val1.FLEX_VALUE_SET_ID = 1111001
AND val1.FLEX_VALUE = gc.segment1
AND val1.FLEX_VALUE_ID = flex1.FLEX_VALUE_ID
AND flex1.language = 'US'
AND val2.FLEX_VALUE_SET_ID = 1111002
AND val2.FLEX_VALUE = gc.segment2
AND val2.FLEX_VALUE_ID = flex2.FLEX_VALUE_ID
AND flex2.language = 'US'
AND val3.FLEX_VALUE_SET_ID = 1111003
AND val3.FLEX_VALUE = gc.segment3
AND val3.FLEX_VALUE_ID = flex3.FLEX_VALUE_ID
AND flex3.language = 'US'
AND val4.FLEX_VALUE_SET_ID = 1111004
AND val4.FLEX_VALUE = gc.segment4
AND val4.FLEX_VALUE_ID = flex4.FLEX_VALUE_ID
AND flex4.language = 'US'
AND val5.FLEX_VALUE_SET_ID = 1111005
AND val5.FLEX_VALUE = gc.segment5
AND val5.FLEX_VALUE_ID = flex5.FLEX_VALUE_ID
AND flex5.language = 'US'
The explain plan is
Plan
SELECT STATEMENT ALL_ROWSCost: 29,834 Bytes: 98,617,600 Cardinality: 81,100
28 HASH JOIN Cost: 29,834 Bytes: 98,617,600 Cardinality: 81,100
1 TABLE ACCESS FULL TABLE APPLSYS.FND_FLEX_VALUES_TL Cost: 1,404 Bytes: 33,076,982 Cardinality: 312,047
27 HASH JOIN Cost: 22,334 Bytes: 90,021,000 Cardinality: 81,100
2 TABLE ACCESS FULL TABLE APPLSYS.FND_FLEX_VALUES_TL Cost: 1,404 Bytes: 33,076,982 Cardinality: 312,047
26 HASH JOIN Cost: 15,243 Bytes: 81,424,400 Cardinality: 81,100
3 TABLE ACCESS FULL TABLE APPLSYS.FND_FLEX_VALUES_TL Cost: 1,404 Bytes: 33,076,982 Cardinality: 312,047
25 HASH JOIN Cost: 8,559 Bytes: 72,827,800 Cardinality: 81,100
4 TABLE ACCESS FULL TABLE APPLSYS.FND_FLEX_VALUES_TL Cost: 1,404 Bytes: 33,076,982 Cardinality: 312,047
24 HASH JOIN Cost: 2,284 Bytes: 64,231,200 Cardinality: 81,100
6 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 15 Bytes: 44,772 Cardinality: 364
5 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N2 Cost: 4 Cardinality: 364
23 HASH JOIN Cost: 2,264 Bytes: 54,261,252 Cardinality: 81,108
8 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 15 Bytes: 44,772 Cardinality: 364
7 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N2 Cost: 4 Cardinality: 364
22 HASH JOIN Cost: 2,238 Bytes: 136,517,472 Cardinality: 250,032
10 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 15 Bytes: 44,772 Cardinality: 364
9 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N2 Cost: 4 Cardinality: 364
21 HASH JOIN Cost: 2,211 Bytes: 105,774,111 Cardinality: 250,057
12 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 15 Bytes: 44,772 Cardinality: 364
11 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N2 Cost: 4 Cardinality: 364
20 NESTED LOOPS Cost: 2,185 Bytes: 75,024,300 Cardinality: 250,081
17 NESTED LOOPS Cost: 746 Bytes: 83,356 Cardinality: 364
14 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 15 Bytes: 44,772 Cardinality: 364
13 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N2 Cost: 4 Cardinality: 364
16 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES_TL Cost: 2 Bytes: 106 Cardinality: 1
15 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_FLEX_VALUES_TL_U1 Cost: 1 Cardinality: 1
19 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 266 Bytes: 48,777 Cardinality: 687
18 INDEX RANGE SCAN INDEX GL.GL_CODE_COMBINATIONS_N3 Cost: 3 Cardinality: 687
Thanks,
KiranPlease post the details of the application release, database version and OS.
Please see these links.
https://forums.oracle.com/forums/search.jspa?threadID=&q=Query+AND+Tuning&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
https://forums.oracle.com/forums/search.jspa?threadID=&q=Query+AND+Tuning&objID=c84&dateRange=all&userID=&numResults=15&rankBy=10001
Thanks,
Hussein -
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 -
Query returns different Explain Plan
Hi,
I have two databases that are identical to each other. But I have a query that runs on both and returns different explain plans in both. It runs slower in one than other. How can I troubleshoot this further to get faster times in the slower database?
THanks,
PrachiQuery:
=====
SELECT sum(total_contacts), sum(email_partner_news), sum(email_tech_news),
sum(email_enduser_news), sum(email), sum(email_gmo), sum(gmo_nophone),
sum(email_gmo_noaddress), sum(email_gmo_address), sum(
email_gmo_nocertaddr), sum(email_gmo_certaddress), sum(
email_gmo_nophone_noaddr), sum(phone_number), sum(gmo_with_phone),
sum(phone_number_email_gmo_noaddr), sum(phone_number_email_gmo_nocert),
sum(phone_number_address), sum(phone_number_address_noemail), sum(
phone_address_email_nogmo), sum(phone_number_address_email), sum(
phone_number_certaddr), sum(phone_number_certaddr_noemail), sum(
phone_certaddr_email_nogmo), sum(phone_number_address_gmo), sum(
phone_certaddr_email_gmo), sum(address), sum(
address_nophone_number_nogmo), sum(address_certified), sum(
certaddr_nophone_nogmo), sum(address_email_nophone_gmo), sum(
certaddr_email_nophone_gmo), sum(phone_gmo), sum(smail_gmo), sum(fax_gmo
), sum(email_wcast), sum(email_inews), sum(email_salrt), sum(
phone_gmo_phone), sum(smail_gmo_address), sum(fax_gmo_fax)
FROM contact_values_vw_tc_2 cv, ((SELECT gcd_contact_id
FROM contact_values)
INTERSECT
((SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 1)
INTERSECT
(SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.sub_region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 2)) ) sl
WHERE cv.gcd_contact_id = sl.gcd_contact_id
AND cv.country_id IN (SELECT cm.country_id
FROM segmentation_user_country_map cm
WHERE cm.user_name = 'E30590')
========================================
Execution Plan - FAST
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=32931 Card=1 Bytes=73)
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=32931 Card=386388 Bytes=28206324)
3 2 VIEW (Cost=29617 Card=1142043 Bytes=14846559)
4 3 INTERSECTION
5 4 SORT (UNIQUE)
6 5 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1907737 Bytes=11446422)
7 4 INTERSECTION
8 7 SORT (UNIQUE)
9 8 HASH JOIN (Cost=655 Card=1998575 Bytes=57958675)
10 9 HASH JOIN (Cost=6 Card=110 Bytes=2200)
11 10 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
12 11 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_ PK' (UNIQUE) (Cost=2 Card=15)
13 10 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
14 9 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
15 7 SORT (UNIQUE)
16 15 HASH JOIN (Cost=655 Card=1142043 Bytes=33119247)
17 16 HASH JOIN (Cost=6 Card=63 Bytes=1260)
18 17 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
19 18 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=15)
20 17 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
21 16 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
22 2 HASH JOIN (Cost=2174 Card=645445 Bytes=38726700)
23 22 SORT (UNIQUE)
24 23 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP' (Cost=5 Card=43 Bytes=473)
25 22 TABLE ACCESS (FULL) OF 'CONTACT_VALUES1' (Cost=2151 Card=1907737 Bytes=93479113)
=====================================================
Execution Plan -SLOW
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8751 Card=1 Bytes=73 )
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (SEMI) (Cost=8751 Card=14477 Bytes=1056821)
3 2 MERGE JOIN (Cost=8583 Card=89527 Bytes=5550674)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'CONTACT_VALUES1' ( Cost=826 Card=1852109 Bytes=90753341)
5 4 INDEX (FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=26 Card=1852109)
6 3 SORT (JOIN) (Cost=7757 Card=89527 Bytes=1163851)
7 6 VIEW (Cost=7454 Card=89527 Bytes=1163851)
8 7 INTERSECTION
9 8 SORT (UNIQUE)
10 9 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1852109 Bytes=11112654)
11 8 INTERSECTION
12 11 SORT (UNIQUE)
13 12 HASH JOIN (Cost=640 Card=250676 Bytes=7269604)
14 13 HASH JOIN (Cost=6 Card=28 Bytes=560)
15 14 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
16 15 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
17 14 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
18 13 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
19 11 SORT (UNIQUE)
20 19 HASH JOIN (Cost=640 Card=89527 Bytes=25962 83)
21 20 HASH JOIN (Cost=6 Card=10 Bytes=200)
22 21 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
23 22 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
24 21 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
25 20 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
26 2 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP'
(Cost=5 Card=45 Bytes=495) -
Hi,
Can anyone send me good link to learn explain plan..Hi,
Please check [Tuning SQL Statements Using Explain Plan|http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:231814117467] and [19 Using EXPLAIN PLAN|http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i19260] (for 10.2, but there is similar information for other versions in the correlated manual), I hope it can help you.
Regards, -
Help needed in EXPLAIN PLAN for a partitioned table
Oracle Version 9i
(Paste execution plan in a spreadsheet to make sense out of it)
I am trying to tune this query -
select * from comm c ,dates d
where
d.active_period = 'Y'
and c.period = d.period;
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 5 M 278887
HASH JOIN 5 M 5G 278887
TABLE ACCESS FULL SCHEMA.DATES 24 1 K 8
PARTITION LIST ALL 1 8
TABLE ACCESS FULL SCHEMA.COMM 6 M 5G 277624 1 8
However, I know that the dates table will return only one record. So, if I add another condition to the above query, I get this execution plan. The comm table is huge but it is partitioned on period.
select * from comm c ,dates d
where
d.active_period = 'Y'
and c.period = qd.period
and c.period = 'OCT-07'
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 1 8
MERGE JOIN CARTESIAN 1 9 K 8
TABLE ACCESS FULL SCHEMA.DATES 1 69 8
BUFFER SORT 1 9 K
TABLE ACCESS BY LOCAL INDEX ROWID SCHEMA.COMM 1 9 K 7 7
INDEX RANGE SCAN SCHEMA.COMM_NP9 1 7 7
How can I make the query such that the comm table does not have to traverse all of its partitions? The partitioning is based on quarters so it will get its data in one partition only (in the above example - partition no. 7)
Thanks in advance for writing in your replies :)You need to specify period = 'OCT-07', otherwise there is no way the optimizer can know it needs to access only one partition.
Alternatively, partition the DATES table in exactly the same way on "period", and partition-wise joins should kick in, and effectively accessing only the active partition. -
Explain plan for running query
Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
Shareef912856 wrote:
Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
ShareefYOu can also use dbms_xplain to generate plan used in v$sql. like for example
SQL>SELECT SQL_ID, CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select * from em%';
SQL_ID CHILD_NUMBER
6kd5fkqdjb8fu 0
SQL>SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('6kd5fkqdjb8fu',0,'ALLSTATS'));If you need the actual tuntime statistics used by sql statement then you need to put hint /*+ gather_plan_statistics */ in sql ststement, something like
select /*+ gather_plan_statistics */ * from emp;
and then generate the explain plan for this
Have a look
http://hoopercharles.wordpress.com/2010/03/01/dbms_xplan-format-parameters/
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); -
Query Performance tuning and scope of imporvement
Hi All ,
I am on oracle 10g and on Linux OS.
I have this below query which I am trying to optimise :
SELECT 'COMPANY' AS device_brand, mach_sn AS device_source_id,
'COMPANY' AS device_brand_raw,
CASE
WHEN fdi.serial_number IS NOT NULL THEN
fdi.serial_number
ELSE
mach_sn || model_no
END AS serial_number_raw,
gmd.generic_meter_name AS counter_id,
meter_name AS counter_id_raw,
meter_value AS counter_value,
meter_hist_tstamp AS device_timestamp,
rcvd_tstamp AS server_timestamp
FROM rdw.v_meter_hist vmh
JOIN rdw.generic_meter_def gmd
ON vmh.generic_meter_id = gmd.generic_meter_id
LEFT OUTER JOIN fdr.device_info fdi
ON vmh.mach_sn = fdi.clean_serial_number
WHERE meter_hist_id IN
(SELECT /*+ PUSH_SUBQ */ MAX(meter_hist_id)
FROM rdw.v_meter_hist
WHERE vmh.mach_sn IN
('URR893727')
AND vmh.meter_name IN
('TotalImpressions','TotalBlackImpressions''TotalColorImpressions')
AND vmh.meter_hist_tstamp >=to_date ('04/16/2011', 'mm/dd/yyyy')
AND vmh.meter_hist_tstamp <= to_date ('04/18/2011', 'mm/dd/yyyy')
GROUP BY mach_sn, vmh.meter_def_id)
ORDER BY device_source_id, vmh.meter_def_id, meter_hist_tstamp;Earlier , it was taking too much time but it started to work faster when i added this :
/*+ PUSH_SUBQ */ in the select query.
The explain plan generated for the same is :
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 29M| 3804M| | 15M (4)| 53:14:08 |
| 1 | SORT ORDER BY | | 29M| 3804M| 8272M| 15M (4)| 53:14:08 |
|* 2 | FILTER | | | | | | |
|* 3 | HASH JOIN | | 29M| 3804M| | 8451K (2)| 28:10:19 |
| 4 | TABLE ACCESS FULL | GENERIC_METER_DEF | 11 | 264 | | 3 (0)| 00:00:01 |
|* 5 | HASH JOIN RIGHT OUTER| | 29M| 3137M| 19M| 8451K (2)| 28:10:17 |
| 6 | TABLE ACCESS FULL | DEVICE_INFO | 589K| 12M| | 799 (2)| 00:00:10 |
|* 7 | HASH JOIN | | 29M| 2527M| 2348M| 8307K (2)| 27:41:29 |
|* 8 | HASH JOIN | | 28M| 2016M| | 6331K (2)| 21:06:19 |
|* 9 | TABLE ACCESS FULL | METER_DEF | 33 | 990 | | 4 (0)| 00:00:01 |
| 10 | TABLE ACCESS FULL | METER_HIST | 3440M| 137G| | 6308K (2)| 21:01:44 |
| 11 | TABLE ACCESS FULL | MACH_XFER_HIST | 436M| 7501M| | 1233K (1)| 04:06:41 |
|* 12 | FILTER | | | | | | |
| 13 | HASH GROUP BY | | 1 | 26 | | 6631K (7)| 22:06:15 |
|* 14 | FILTER | | | | | | |
| 15 | TABLE ACCESS FULL | METER_HIST | 3440M| 83G| | 6304K (2)| 21:00:49 |
------------------------------------------------------------------------------------------------------Is there any other way to optimise it more ... PLease suggest since I am new to query tuning.
Thanks and Regards
KKHi Dom ,
Greetings. Sorry for the delayed response. I have read the How to Post document.
I will provide all the required information here now :
Version : 10.2.0.4
OS : LinuxThe SQL Query which is facing the performance issue :
SELECT mh.meter_hist_id, mxh.mach_sn, mxh.collectiontag, mxh.rcvd_tstamp,
mxh.mach_xfer_id, md.meter_def_id, md.meter_name, md.meter_type,
md.meter_units, md.meter_desc, mh.meter_value, mh.meter_hist_tstamp,
mh.max_value, md.generic_meter_id
FROM meter_hist mh JOIN mach_xfer_hist mxh
ON mxh.mach_xfer_id = mh.mach_xfer_id
JOIN meter_def md ON md.meter_def_id = mh.meter_def_id;Explain plan for this query :
Plan hash value: 1878059220
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3424M| 497G| | 17M (1)| 56:42:49 |
|* 1 | HASH JOIN | | 3424M| 497G| | 17M (1)| 56:42:49 |
| 2 | TABLE ACCESS FULL | METER_DEF | 423 | 27918 | | 4 | 00:00:01 |
|* 3 | HASH JOIN | | 3424M| 287G| 26G| 16M (1)| 56:38:16 |
| 4 | TABLE ACCESS FULL| MACH_XFER_HIST | 432M| 21G| | 1233K (1)| 04:06:40 |
| 5 | TABLE ACCESS FULL| METER_HIST | 3438M| 115G| | 6299K (2)| 20:59:54 |
Predicate Information (identified by operation id):
1 - access("MD"."METER_DEF_ID"="MH"."METER_DEF_ID")
3 - access("MH"."MACH_XFER_ID"="MXH"."MACH_XFER_ID")Parameters :
show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 70
optimizer_index_cost_adj integer 50
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUEshow parameter db_file_multi
db_file_multiblock_read_count integer 8
show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
select sname , pname , pval1 , pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-12-2011 09:22
SYSSTATS_INFO DSTOP 07-12-2011 09:52
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN CPUSPEEDNW 1153.92254
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM 4.398
SYSSTATS_MAIN MREADTIM 3.255
SYSSTATS_MAIN CPUSPEED 180
SYSSTATS_MAIN MBRC 8
SYSSTATS_MAIN MAXTHR 244841472
SYSSTATS_MAIN SLAVETHR 933888
show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192Please let me me if any other information is needed. This Query is currently taking almost one hour to run right now.
Also , we have two indexes on the columns : xfer_id and meter_def_id in both the tables , but its not getting used without any filtering ( Where clause).
Do addition of hint in the query above will be of some help.
Thanks and Regards
KK
Maybe you are looking for
-
When trying to download the latest version of iTunes, I receive the following error "Apple Application Support was not found", any suggestions?
-
I'm pretty new to this, so I appreciate any help in advance. I have imported a clip. I can see it and hear it fine. I've made in & out edit points and can drag it around (copy it etc.) on the timeline. But here's the odd thing... I can hear it when t
-
Problems with files with no types or creator infos
I installed Ffmegx which converts videos in differents formats. In order to work, that software needs extra files (mencoder, mplayer, mpeg2enc). After I downloaded them, the two first ones were seen as Unix Executable files by Mac OSX, the third is s
-
OK Jerry - but DVCPRO HD's not cheap either!
Current requirements and very tight budget prevaling, we've virtually made the decision to invest in a Panasonic AG-HVX200 for its Selectable Frame Rates, DVCPRO (& DVCPRO HD) Buffering (& Looping) - plus it's vastly improved workflow over Tape Captu
-
hi in rosource and rodeltam we find deffirent delta like add,aie,after image for data source, can i get based on delta what delta cases we use dso and what cases we use direcly cube. incase we use dso what cases we use overwrire and addition option.