Explain plans differ: same query, cloned databases.
oracle 10.2.0.2.0
solaris 10
same query, different databases (cloned from same source), different explain plans.
db parameters are identical.
Any ideas?
DB1 (production)
SQL> explain plan for
2 SELECT V__101.*, SHAPE.fid,SHAPE.numofpts,SHAPE.entity,SHAPE.points,
3 SHAPE.rowid
4 FROM
5 (SELECT b.OBJECTID,b.CRT_DTE,b.CRT_SRC_CDE,b.CRT_AQUI_MTHD_CDE,b.CRT_USR_ID,
6 b.ADT_ACTN_CDE,b.ADT_ACTN_DTE,b.ADT_ACTN_SRC_CDE,b.ADT_ACTN_USR_ID,
7 b.TP_SITE_POINT_ID,b.SHAPE,b.SRC_ID,b.SRC_CRT_DTE,b.SRC_TYPE_CDE,
8 b.LCTN_STAT_CDE,b.FRZN_LCTN_IND,b.TP_NOTES FROM AMSOWNER.TP_SITE_POINT b
9 WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM
10 AMSOWNER.D101 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
SDE.state_lineages l WHERE l.lineage_name = :source_lineage_name AND
11 12 l.lineage_id <= :source_state_id) AND SDE_STATE_ID = :"SYS_B_0") UNION ALL
SELECT a.OBJECTID,a.CRT_DTE,a.CRT_SRC_CDE,a.CRT_AQUI_MTHD_CDE,a.CRT_USR_ID,
13 14 a.ADT_ACTN_CDE,a.ADT_ACTN_DTE,a.ADT_ACTN_SRC_CDE,a.ADT_ACTN_USR_ID,
15 a.TP_SITE_POINT_ID,a.SHAPE,a.SRC_ID,a.SRC_CRT_DTE,a.SRC_TYPE_CDE,
16 a.LCTN_STAT_CDE,a.FRZN_LCTN_IND,a.TP_NOTES FROM AMSOWNER.A101 a,
17 SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+
18 HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM AMSOWNER.D101 WHERE
19 DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
20 l.lineage_name = :source_lineage_name AND l.lineage_id <= :source_state_id)
21 AND SDE_STATE_ID > :"SYS_B_1") AND a.SDE_STATE_ID = SL.lineage_id AND
22 SL.lineage_name = :source_lineage_name AND SL.lineage_id <=
23 :source_state_id ) V__101 , AMSOWNER.F15 SHAPE where SHAPE.FID(+) =
24 V__101.SHAPE;
Explained.
SQL> @?/rdbms/admin/utlxplp.sql;
PLAN_TABLE_OUTPUT
Plan hash value: 254376361
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 113K| 49M| | 2926 (1)| 00:00:41 |
|* 1 | HASH JOIN RIGHT OUTER | | 113K| 49M| 17M| 2926 (1)| 00:00:41 |
| 2 | TABLE ACCESS FULL | F15 | 113K| 15M| | 344 (2)| 00:00:05 |
| 3 | VIEW | | 113K| 34M| | 331 (2)| 00:00:05 |
| 4 | UNION-ALL | | | | | | |
|* 5 | HASH JOIN RIGHT ANTI | | 113K| 8948K| | 332 (2)| 00:00:05 |
| 6 | VIEW | VW_NSO_1 | 1 | 13 | | 2 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 50 | | 2 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| D101 | 1 | 39 | | 1 (0)| 00:00:01 |
|* 9 | INDEX SKIP SCAN | D101_IDX1 | 1 | | | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 11 | | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS FULL | TP_SITE_POINT | 113K| 7512K| | 329 (2)| 00:00:05 |
|* 12 | HASH JOIN ANTI | | 1 | 375 | | 5 (20)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 349 | | 2 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | A101 | 1 | 338 | | 1 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | A101_STATEID_IX1 | 1 | | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 11 | | 1 (0)| 00:00:01 |
|* 17 | VIEW | VW_NSO_2 | 1 | 26 | | 2 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 1 | 50 | | 2 (0)| 00:00:01 |
|* 19 | INDEX FULL SCAN | D101_PK | 1 | 39 | | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 11 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("SHAPE"."FID"(+)="V__101"."SHAPE")
5 - access("B"."OBJECTID"="$nso_col_1")
9 - access("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
filter("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
10 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
12 - access("A"."OBJECTID"="$nso_col_1" AND "A"."SDE_STATE_ID"="$nso_col_2")
15 - access("A"."SDE_STATE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
16 - access("SL"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
"A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("SL"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
17 - filter("$nso_col_2"<=TO_NUMBER(:SOURCE_STATE_ID))
19 - access("SDE_STATE_ID">TO_NUMBER(:SYS_B_1))
filter("SDE_STATE_ID">TO_NUMBER(:SYS_B_1))
20 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
47 rows selected.DB2 (staging)
SQL> explain plan for
2 SELECT V__101.*, SHAPE.fid,SHAPE.numofpts,SHAPE.entity,SHAPE.points,
SHAPE.rowid
FROM
3 4 5 (SELECT b.OBJECTID,b.CRT_DTE,b.CRT_SRC_CDE,b.CRT_AQUI_MTHD_CDE,b.CRT_USR_ID,
b.ADT_ACTN_CDE,b.ADT_ACTN_DTE,b.ADT_ACTN_SRC_CDE,b.ADT_ACTN_USR_ID,
6 7 b.TP_SITE_POINT_ID,b.SHAPE,b.SRC_ID,b.SRC_CRT_DTE,b.SRC_TYPE_CDE,
8 b.LCTN_STAT_CDE,b.FRZN_LCTN_IND,b.TP_NOTES FROM AMSOWNER.TP_SITE_POINT b
9 WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM
10 AMSOWNER.D101 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
11 SDE.state_lineages l WHERE l.lineage_name = :source_lineage_name AND
12 l.lineage_id <= :source_state_id) AND SDE_STATE_ID = :"SYS_B_0") UNION ALL
13 SELECT a.OBJECTID,a.CRT_DTE,a.CRT_SRC_CDE,a.CRT_AQUI_MTHD_CDE,a.CRT_USR_ID,
14 a.ADT_ACTN_CDE,a.ADT_ACTN_DTE,a.ADT_ACTN_SRC_CDE,a.ADT_ACTN_USR_ID,
15 a.TP_SITE_POINT_ID,a.SHAPE,a.SRC_ID,a.SRC_CRT_DTE,a.SRC_TYPE_CDE,
16 a.LCTN_STAT_CDE,a.FRZN_LCTN_IND,a.TP_NOTES FROM AMSOWNER.A101 a,
17 SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+
HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM AMSOWNER.D101 WHERE
18 19 DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
20 l.lineage_name = :source_lineage_name AND l.lineage_id <= :source_state_id)
21 AND SDE_STATE_ID > :"SYS_B_1") AND a.SDE_STATE_ID = SL.lineage_id AND
22 SL.lineage_name = :source_lineage_name AND SL.lineage_id <=
23 :source_state_id ) V__101 , AMSOWNER.F15 SHAPE where SHAPE.FID(+) =
24 V__101.SHAPE;
Explained.
SQL> @?/rdbms/admin/utlxplp.sql;
PLAN_TABLE_OUTPUT
Plan hash value: 4287458713
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 145 | 68150 | 401 (1)| 00:00:06 |
| 1 | NESTED LOOPS OUTER | | 145 | 68150 | 401 (1)| 00:00:06 |
| 2 | VIEW | | 145 | 47125 | 328 (1)| 00:00:05 |
| 3 | UNION-ALL | | | | | |
|* 4 | HASH JOIN ANTI | | 144 | 10224 | 324 (1)| 00:00:05 |
| 5 | TABLE ACCESS FULL | TP_SITE_POINT | 145 | 8410 | 322 (1)| 00:00:05 |
| 6 | VIEW | VW_NSO_1 | 1 | 13 | 2 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 50 | 2 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| D101 | 1 | 39 | 1 (0)| 00:00:01 |
|* 9 | INDEX SKIP SCAN | D101_IDX1 | 1 | | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 11 | 1 (0)| 00:00:01 |
|* 11 | FILTER | | | | | |
| 12 | NESTED LOOPS | | 1 | 349 | 2 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | A101 | 1 | 338 | 1 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | A101_STATEID_IX1 | 1 | | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 11 | 1 (0)| 00:00:01 |
|* 16 | FILTER | | | | | |
| 17 | NESTED LOOPS | | 1 | 50 | 2 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID| D101 | 1 | 39 | 1 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | D101_IDX1 | 1 | | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 11 | 1 (0)| 00:00:01 |
| 21 | TABLE ACCESS BY INDEX ROWID | F15 | 1 | 145 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | F15_UK1 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - access("B"."OBJECTID"="$nso_col_1")
8 - filter("DELETED_AT"<=TO_NUMBER(:SOURCE_STATE_ID))
9 - access("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
filter("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
10 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
"DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
11 - filter( NOT EXISTS (SELECT /*+ HASH_AJ */ 0 FROM "AMSOWNER"."D101"
"D101","SDE"."STATE_LINEAGES" "L" WHERE :B1>TO_NUMBER(:SYS_B_1) AND
"DELETED_AT"="L"."LINEAGE_ID" AND "L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
"L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID) AND "SDE_STATE_ID"=:B2 AND
"SDE_DELETES_ROW_ID"=:B3 AND "DELETED_AT"<=TO_NUMBER(:SOURCE_STATE_ID) AND
"SDE_STATE_ID">TO_NUMBER(:SYS_B_1)))
14 - access("A"."SDE_STATE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
15 - access("SL"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
"A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("SL"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
16 - filter(:B1>TO_NUMBER(:SYS_B_1))
18 - filter("DELETED_AT"<=TO_NUMBER(:SOURCE_STATE_ID))
19 - access("SDE_DELETES_ROW_ID"=:B1 AND "SDE_STATE_ID"=:B2)
filter("SDE_STATE_ID">TO_NUMBER(:SYS_B_1))
20 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
"DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
22 - access("SHAPE"."FID"(+)="V__101"."SHAPE")
58 rows selected.
rocr wrote:
oracle 10.2.0.2.0
solaris 10
same query, different databases (cloned from same source), different explain plans.
db parameters are identical.
DB1 (production)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 113K| 49M| | 2926 (1)| 00:00:41 |DB2 (staging)
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 145 | 68150 | 401 (1)| 00:00:06 |
If you check the execution plans it's quite obvious that the two environments can not be identical. If you have the same (amount of) data, then one of the two estimates is way off. Which one is in the right ballpark, how many rows are returned by the query? The same applies to the remaining operation ids of the plan, which estimate is correct?
It's very likely that the underlying table/index statistics are not the same, and therefore you get different plans.
By the way, you're using bind variables, therefore the output of the EXPLAIN PLAN is only of limited use, since the actual plan at run time might be completely different due to bind variable peeking and potentially histograms created on some of the columns (which is the default in 10g due to the "FOR ALL COLUMNS SIZE AUTO" method_opt default parameter value).
If you haven't disabled the pre-configured statistics collection job that runs every night in 10g, you might get different statistics due to this job already.
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/
Similar Messages
-
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 -
Explain plan for same query in three databases
Hi,
We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
Please help.
Thanks
Clinuser627471 wrote:
Hi,
We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
Please help.
Thanks
Clinpost both EXPLAIN PLAN here -
Same query is taking different times in two databses.
Both dababases are similar being refreshed from one.
Below are the the explain plan from both queries.
Can anything be conclusive from this information.
Second explain plan is for a faster execution.
SELECT STATEMENT ALL_ROWSCost: 245,393
18 PX COORDINATOR
17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
16 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
15 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
14 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
13 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 15 Bytes: 129,220 Cardinality: 2,485
2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 15 Bytes: 129,220 Cardinality: 2,485
1 TABLE ACCESS FULL TABLE myschema.team Cost: 15 Bytes: 129,220 Cardinality: 2,485
12 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT myschema.mytable Cost: 18,117 Bytes: 4,777,136 Cardinality: 183,736
11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT Cost: 198,125 Bytes: 300,959,928 Cardinality: 8,359,998
8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT
6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001
5 TABLE ACCESS FULL TABLE myschema.dim Cost: 12 Bytes: 450 Cardinality: 45
10 PX PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 38 Cardinality: 183,736 Partition #: 17
9 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT myschema.IDX_TDATE_DC_FLAG Cost: 38 Cardinality: 183,736 Partition #: 17
SELECT STATEMENT CHOOSECost: 2,830
14 PX COORDINATOR
13 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
12 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
11 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
10 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
9 HASH JOIN BUFFERED PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 19 Bytes: 129,272 Cardinality: 2,486
2 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 19 Bytes: 129,272 Cardinality: 2,486
1 TABLE ACCESS FULL TABLE myschema.team Cost: 19 Bytes: 129,272 Cardinality: 2,486
8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
7 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10001 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
5 MAT_VIEW REWRITE ACCESS FULL MAT_VIEW REWRITE PARALLEL_COMBINED_WITH_PARENT myschema.matv_2 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed
Edited by: user610910 on Feb 13, 2009 5:12 AMSELECT STATEMENT CHOOSE Cost: 2,830
14 PX COORDINATOR
13 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
12 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
11 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
10 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
9 HASH JOIN BUFFERED PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 19 Bytes: 129,272 Cardinality: 2,486
2 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 19 Bytes: 129,272 Cardinality: 2,486
1 TABLE ACCESS FULL TABLE MYSCHEMA.TEAM Cost: 19 Bytes: 129,272 Cardinality: 2,486
8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
7 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10001 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
5 MAT_VIEW REWRITE ACCESS FULL MAT_VIEW REWRITE PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MATVW Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
SELECT STATEMENT ALL_ROWSCost: 245,393
18 PX COORDINATOR
17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
16 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
15 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
14 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
13 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 15 Bytes: 129,220 Cardinality: 2,485
2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 15 Bytes: 129,220 Cardinality: 2,485
1 TABLE ACCESS FULL TABLE MYSCHEMA.TEAM Cost: 15 Bytes: 129,220 Cardinality: 2,485
12 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MY_TABLE Cost: 18,117 Bytes: 4,777,136 Cardinality: 183,736
11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT Cost: 198,125 Bytes: 300,959,928 Cardinality: 8,359,998
8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT
6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001
5 TABLE ACCESS FULL TABLE MYSCHEMA.DIM Cost: 12 Bytes: 450 Cardinality: 45
10 PX PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 38 Cardinality: 183,736 Partition #: 17
9 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MY_IDX Cost: 38 Cardinality: 183,736 Partition #: 17 I think this one looks better. -
Different query plans for same query on same DB
Hi,
HP-Ux
Oracle Database 10.2.0.4
We are experiencing a strange issue. One of our night batch process is taking invariably more time to execute. The process does not consume time at 1 particular query. Everyday we find a new query taking more time than previous execution.
Now, when we see the explain plan while the query is executing, we see NESTED LOOP SEMI (with improper index being used). At the same time if we take the query and see the explain plan seperately, we get HASH JOIN SEMI (with proper index being used). Also, if we execute this query with the values as in procedure, it finishes within mili seconds (as it should).
The tables and indexes are analyzed everyday before the process starts.
Can anybody explain, why the same query shows two different plans at the same time ?
Thanks a lot in advance :)Aalap Sharma wrote:
HP-Ux
Oracle Database 10.2.0.4
We are experiencing a strange issue. One of our night batch process is taking invariably more time to execute. The process does not consume time at 1 particular query. Everyday we find a new query taking more time than previous execution.
Now, when we see the explain plan while the query is executing, we see NESTED LOOP SEMI (with improper index being used). At the same time if we take the query and see the explain plan seperately, we get HASH JOIN SEMI (with proper index being used). Also, if we execute this query with the values as in procedure, it finishes within mili seconds (as it should).
The tables and indexes are analyzed everyday before the process starts.
Can anybody explain, why the same query shows two different plans at the same time ?As already mentioned, you might hit typical issues in 10.2: The column workload based SIZE AUTO statistics gathering feature and/or bind variable peeking.
How do you analyze the tables and indexes before the process starts? Can you share the exact call with parameters?
Some ideas:
1. If your process is "new", then the column workload monitoring of the database might recognize the column usage pattern and generate histograms on some of your columns. It might take a while until the workload has been established so that all columns got histograms according to the workload (It needs a certain number of usages/executions before the workload is registered as relevant). Until then you might get different execution plans each time the statistics are refreshed due to new histograms being added.
2. If the default 10g statistics gathering job is active, it might gather different statistics during the night than your individual job that runs prior to the processing. This could be one possible explanation why you get different plans on the next day.
3. "Bind Variable Peeking" is possibly another issue you might run into. How do you test the query so that you get a different, well performing plan? Does your original statement use bind variables? Do you use literals to reproduce? Note that using EXPLAIN PLAN on statements involving bind variables can lie, since it doesn't perform bind variable peeking by default.
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/ -
Explain Plan Diff not available yet on Mac ?
Hi,
I followed the Online tutorial for the new Explain Plan Diff feature, however when I right-click the tab of the auto-trace no menu appears at all.
Am I doing something wrong or is this feature not yet available on the Mac version or has it been forgotten ?
I have this version:
Oracle SQL Developer 3.0.02
Version 3.0.02
Build MAIN-02.83
Copyright © 2005,2010 Oracle. All Rights Reserved.
IDE Version: 11.1.1.4.37.58.80
Product ID: oracle.sqldeveloper
Product Version: 11.1.2.02.83
jdk 1.6.0_22
thanks, ArjanAlthough I don't have a native Mac or Linux environment to test this, the context menus for the various worksheet tabs (Query Results / Autotrace / Explain Plan) have problems. I tried the following using a fresh install of SQL Dev 3.0 EA2 (including JRE 1.6.0_11):
1) VNC between two Windows XP boxes. Context menus work fine.
2) VNC (RealVNC 4.1.3 or TightVNC 2.0.2 clients) from Windows XP to Linux (Xvnc 4.0). Context menus do not appear.
3) Tarantella (Sun Secure Global Desktop Native Client [4.31.953]) from Windows XP to Linux. Context menus do not appear.
Finally, I tried the SQL Dev 2.1.1.64.65 on the OTN Developer Days image (OEL 5) under Sun Virtual Box on my XP box. No context menus. -
I want to know the concept of this 'Explain Plan' of a query & why it is used. Could u also give the syntax of how a explain plan for a query can be done. Please help in solving the doubt as it is urgent.
Hi,
set autotrace traceonly explain or
-- create your plan table in your schema (only once)
@ ?/rdbms/admin/utlxplan
-- populate the plan table for your select
explain plan for select ...;
-- display output out of the PLAN_TABLE
@ ?/rdbms/admin/ultxplsRegards
Laurent -
Why two different explain plan for same objects?
Believe or not there are two different databases, one for processing and one for reporting, plan is show different for same query. Table structure and indexes are same. It's 11G
Thanks
Good explain plan .. works fine..
Plan
SELECT STATEMENT ALL_ROWSCost: 12,775 Bytes: 184 Cardinality: 1
27 SORT UNIQUE Cost: 12,775 Bytes: 184 Cardinality: 1
26 NESTED LOOPS
24 NESTED LOOPS Cost: 12,774 Bytes: 184 Cardinality: 1
22 HASH JOIN Cost: 12,772 Bytes: 178 Cardinality: 1
20 NESTED LOOPS SEMI Cost: 30 Bytes: 166 Cardinality: 1
17 NESTED LOOPS Cost: 19 Bytes: 140 Cardinality: 1
14 NESTED LOOPS OUTER Cost: 16 Bytes: 84 Cardinality: 1
11 VIEW DSSADM. Cost: 14 Bytes: 37 Cardinality: 1
10 NESTED LOOPS
8 NESTED LOOPS Cost: 14 Bytes: 103 Cardinality: 1
6 NESTED LOOPS Cost: 13 Bytes: 87 Cardinality: 1
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_FAMILY_TBL Cost: 10 Bytes: 51 Cardinality: 1
1 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9 Cardinality: 1
5 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3 Bytes: 36 Cardinality: 1
4 INDEX RANGE SCAN INDEX DSSADM.STAN_JB_FN_IDX Cost: 2 Cardinality: 1
7 INDEX UNIQUE SCAN INDEX (UNIQUE) DSSODS.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0 Cardinality: 1
9 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOBCODE_TBL_RPT Cost: 1 Bytes: 16 Cardinality: 1
13 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PSXLATITEM_RPT Cost: 2 Bytes: 47 Cardinality: 1
12 INDEX RANGE SCAN INDEX DSSODS.PK_DRV_RIXLATITEM_RPT Cost: 1 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3 Bytes: 56 Cardinality: 1
15 INDEX RANGE SCAN INDEX DSSADM.DIM_JOBCODE_EXPDT1 Cost: 2 Cardinality: 1
19 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_RPT Cost: 11 Bytes: 438,906 Cardinality: 16,881
18 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_JOBCODE_RPT Cost: 2 Cardinality: 8
21 INDEX FAST FULL SCAN INDEX (UNIQUE) DSSADM.Z_PK_JOBCODE_PROMPT_TBL Cost: 12,699 Bytes: 66,790,236 Cardinality: 5,565,853
23 INDEX RANGE SCAN INDEX DSSADM.DIM_PERSON_EMPL_RCD_SEQ_KEY Cost: 1 Cardinality: 1
25 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_PERSON_EMPL_RCD Cost: 2 Bytes: 6 Cardinality: 1 This bad plan ... show merge join cartesian and full table ..
Plan
SELECT STATEMENT ALL_ROWSCost: 3,585 Bytes: 237 Cardinality: 1
26 SORT UNIQUE Cost: 3,585 Bytes: 237 Cardinality: 1
25 NESTED LOOPS SEMI Cost: 3,584 Bytes: 237 Cardinality: 1
22 NESTED LOOPS Cost: 3,573 Bytes: 211 Cardinality: 1
20 MERGE JOIN CARTESIAN Cost: 2,864 Bytes: 70,446 Cardinality: 354
17 NESTED LOOPS
15 NESTED LOOPS Cost: 51 Bytes: 191 Cardinality: 1
13 NESTED LOOPS OUTER Cost: 50 Bytes: 180 Cardinality: 1
10 HASH JOIN Cost: 48 Bytes: 133 Cardinality: 1
6 NESTED LOOPS
4 NESTED LOOPS Cost: 38 Bytes: 656 Cardinality: 8
2 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 14 Bytes: 448 Cardinality: 8
1 INDEX RANGE SCAN INDEX REPORT2.STAN_PROM_JB_IDX Cost: 6 Cardinality: 95
3 INDEX RANGE SCAN INDEX REPORT2.SETID_JC_IDX Cost: 2 Cardinality: 1
5 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 3 Bytes: 26 Cardinality: 1
9 INLIST ITERATOR
8 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_FAMILY_TBL Cost: 10 Bytes: 51 Cardinality: 1
7 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PSXLATITEM_RPT Cost: 2 Bytes: 47 Cardinality: 1
11 INDEX RANGE SCAN INDEX REPORT2.PK_DRV_RIXLATITEM_RPT Cost: 1 Cardinality: 1
14 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORT2.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOBCODE_TBL_RPT Cost: 1 Bytes: 11 Cardinality: 1
19 BUFFER SORT Cost: 2,863 Bytes: 4,295,552 Cardinality: 536,944
18 TABLE ACCESS FULL TABLE REPORT2.DIM_PERSON_EMPL_RCD Cost: 2,813 Bytes: 4,295,552 Cardinality: 536,944
21 INDEX RANGE SCAN INDEX (UNIQUE) REPORT2.Z_PK_JOBCODE_PROMPT_TBL Cost: 2 Bytes: 12 Cardinality: 1
24 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_RPT Cost: 11 Bytes: 1,349,920 Cardinality: 51,920
23 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_JOBCODE_RPT Cost: 2 Cardinality: 8user550024 wrote:
I am really surprise that the stat for good sql are little old. I just computed the states of bad sql so they are uptodate..
There is something terribly wrong..Not necessarily. Just using the default stats collection I've seen a few cases of things suddenly going wrong. As the data increases, it gets closer to an edge case where the inadequacy of the statistics convinces the optimizer to do a wrong plan. To fix, I could just go into dbconsole, set the stats back to a time when they worked, and locked them. In most cases it's definitely better to figure out what is really going on, though, to give the optimizer better information to work with. Aside from the value of learning how to do it, for some cases it's not so simple. Also, many think the default settings of the database statistic collection may be wrong in general (in 10.2.x, at least). So much depends on your application and data that you can't make too many generalizations. You have to look at the evidence and figure it out. There is still a steep learning curve for the tools to look at the evidence. People are here to help with that.
Most of the time it works better than a dumb rule based optimizer, but at the cost of a few situations where people are smarter than computers. It's taken a lot of years to get to this point. -
SQL Explain differs with same query
DB 1: Oracle EE 11gR1 64-bit
DB 2: Oracle XE 11gR2 64-bit
Both on OEL 64-bit
DB 1 does not do a SORT related to the subquery whereas DB 2 does do a SORT. Otherwise EXPLAN PLAN identical. But performance on DB 2 noticeably faster.
Here is the SQL:
select col4
from tab1 join tab2 on tab1.col1 = tab2.col1
where tab2.col3 = (select max(col3) from tab3);
Explain plan (brief)
DB 2:
FILTER-
HASH JOIN
SORT
DB 1:
FILTER
HASH JOIN
Any hints (no pun) on what might cause this to occur? Is the optimizer different from XE 11gR4 and EE 11gR1 (wouldn't think so)? Or is it a parameter setting, memory or temp space (default settings apply for both DBs).
ThanksYes, the optimizer is different in 11gR2 than 11gR1. Also the optimizer in Enterprise Edition will have more choices available than in XE (partitioning, for example; parallel processing, since XE uses only 1 CPU), but in this case I doubt the difference is that deep.
Besides optimizer differences, you need to consider these questions first when you see different plans:
Is the volume of data the same in both databases?
Are statistics up to date in both databases?
Are statistics gathered the same way in each database?
For anything more specific we need to see the 4-digit oracle version for each database, exact explain plans (copy-paste), and possibly some CREATE TABLE and INSERT statements if someone wants to reproduce what you are seeing in their database. -
Different execution plan for same query but for different condition value
Hi All,
I'm facing a strange situation where same query for different condition not working.
1--
Select top 10 * from revenuefact(nolock)
where feecode ='OW4'
2--
Select top 10 * from revenuefact(nolock)
where feecode ='BTE'
1st query is returning result easily but 2nd query is taking too long. Column
feecode has already Non-clustered index and Clustered index is also available for another col RevenueSID.
I was surprised when checked the query execution plan for both the above queries which is quite different (as per attached below). Can anyone suggest me the reason behind it.
And solution for the same. One more thing that data for feecode BTE is inserting through different source instead of others feecode and table contains more than 300 million rows.When I speak with people inside Microsoft who work with the optimizer, the refuse to accept the work "bug" when a query produces the correct result, but with a suboptimal plan. They prefer to use the word "limitation".
The limitation here is that when the optimizer compares two plans, it only looks at the estimated cost. As far as I know, it does not perform any analysis from the perspective "what if the statistics are wrong"? They do provide the hint OPTIMIZE
FOR UNKNOWN, but that does not work then there is a constant as in this case.
The optimizer will surely distinguish between TOP 10 and TOP 10000000. With the latter, you have all reason to expect a Clustered Index Scan no matter which value you search for - unless you pick a value for which the histogram indicates that there are no
rows.
Interesting enough, I was able to reproduce the situation in my Northgale database, which is an inflated version of Northwind, and where statistics should be accurate.
SELECT TOP 10 * FROM Orders WHERE EmployeeID = 8
results in a CI scan, and so does also EmployeeID = 7, and even 5. There are only 2292 rows out of a total of 344305 rows. If I try EmployeeID 808 for which there are 1797, the optimizer goes for the index seek.
Erland Sommarskog, SQL Server MVP, [email protected] -
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')); -
Explain Plan understand technique & Query optimizing check list
Hello gurus,
Can some body help me with doc available or your experience to tell on how to understand Explain Plan & Query optimizing check list.
Thanks..That's correct,
But unfortunately the institute is pretty far from home.. and travelling time will be high..
I am a working man..
Please suggest if some good book or link.
Thanks. -
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 -
Query Regarding Explain Plan on Query
Hello,
I have one big query which shows report of 50000 daily records from @ 20,00,000 records.
I have two databases UAT and PROD.when i do Explain Plan on the query is these different database i get the different plan where everything is same in both database.
In UAT it is doing Index scan where as in PROD it is doing Full TableScan. Below are the results.
In production it is not using any of the indexes present but in UAT it is.What could be the reasong behind this?Sure.
UAT Explain Plan (Please copy in Textpad for better View)
SELECT STATEMENT, GOAL = HINT: ALL_ROWS Cost=371 Cardinality=238 Optimizer=HINT: ALL_ROWS Bytes=134470
VIEW Object owner=SWNET1 Cost=371 Cardinality=238 Bytes=134470
COUNT STOPKEY
VIEW Object owner=SWNET1 Cost=371 Cardinality=238 Bytes=131376
SORT ORDER BY STOPKEY Cost=371 Cardinality=238 Bytes=54026
FILTER
HASH JOIN RIGHT ANTI Cost=370 Cardinality=238 Bytes=54026
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID Object owner=SWNET1 Object name=IS_TB_END_POINT Cost=1 Cardinality=1 Optimizer=ANALYZED Bytes=31
INDEX RANGE SCAN Object owner=SWNET1 Object name=IS_UK_EP_NAME Cost=1 Cardinality=1 Optimizer=ANALYZED
TABLE ACCESS BY INDEX ROWID Object owner=SWNET1 Object name=IS_TB_TRANSACTION Cost=368 Cardinality=253 Optimizer=ANALYZED Bytes=49588
INDEX FULL SCAN Object owner=SWNET1 Object name=IS_IX_T_DESTINATION_EP Cost=18 Cardinality=13909 Optimizer=ANALYZED
PRODUCTION Explain Plan
SELECT STATEMENT, GOAL = HINT: ALL_ROWS Cost=65702 Cardinality=1000 Optimizer=HINT: ALL_ROWS Bytes=565000
VIEW Object owner=SWNET1 Cost=65702 Cardinality=1000 Bytes=565000
COUNT STOPKEY
VIEW Object owner=SWNET1 Cost=65702 Cardinality=38739 Bytes=21383928
SORT ORDER BY STOPKEY Cost=65702 Cardinality=38739 Bytes=9646011
FILTER
HASH JOIN RIGHT ANTI Cost=63616 Cardinality=38739 Bytes=9646011
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID Object owner=SWNET1 Object name=IS_TB_END_POINT Cost=1 Cardinality=2 Optimizer=ANALYZED Bytes=64
INDEX UNIQUE SCAN Object owner=SWNET1 Object name=IS_UK_EP_NAME Cost=1 Cardinality=2 Optimizer=ANALYZED
TABLE ACCESS FULL Object owner=SWNET1 Object name=IS_TB_TRANSACTION Cost=63614 Cardinality=44697 Optimizer=ANALYZED Bytes=9699249
Index Query (Same on both places)
create index IS_IX_T_DESTINATION_EP on IS_TB_TRANSACTION (T_DESTINATION_EP)
tablespace IS_XML_IND
pctfree 10
initrans 2
maxtrans 255
storage
initial 128M
next 128K
minextents 1
maxextents unlimited
pctincrease 0
); -
How to improve the query performance or tune query from Explain Plan
Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
21 FILTER
16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
243 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
SID
310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
VALUE
163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID CHILD_NUMBER
04mpgrzhsv72w 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
: call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Maybe you are looking for
-
ACL found but not expected.................
I powered up my iMac (intel) and I got a blank white screen - up until this point it would be up and running in a second or two so this was a shock. I forced a shut down and had to restart a couple of times before I got a white screen with the apple
-
Layout problem with smartform..Little Urgent
Hi gurus, I have a window of size 1 cm.. In this i want to print a number which should be of the same size as the window(1 cm in height). But the maximum font i can give in the character format is 99 pt. and this is making the number to printed in le
-
My phone is filling up with spam BBmessages - all junk/ unreadable/ foreign characters. It went quiet for a whil e but I have had over 500 so far this afternoon alone. I have deleted messenger, but they just appear on my mainscreen. I have changed my
-
Lsmw problem: for mm01 basic data text two language
Dear, I want to realize, in mm01, under 'basic data text' tab, have English and French text. I use lsmw, direct input,object:0020, method:0000, program name:RMDATIND. The basic data text function should be done in structure BMMH7. Now, I add some cod
-
We have had a plan that included five phone numbers. Three members of our plan wanted to create their own plan with additional features. I called a Verizon representative on our about March 14, 2011, to receive instructions on how to let our three me