Explain plan output format
Dear All,
Please let me know how to publish my explain plan output properly here. Earlier i used [code] ..... [/code]
Thanks,
Kods
Who knows?
Are you just looking at random explain plans to find a problem?
Or did you look at the explain plan for a specific performance problem?
Please format code and explain plan output with code tags.
See also this thread, How to post a SQL tuning request:
HOW TO: Post a SQL statement tuning request - template posting
At the end of the day are the row estimates accurate?
If they are, then everything's probably ok.
If not, then everything might be ok or it might not be.
Merge Join Cartesian + Buffer Sort operations are often, but not always, an indication of a problem particularly when the associated estimates are inaccurate for whatever reason.
Similar Messages
-
Verbose EXPLAIN PLAN output when asking for explain plan on simple SQL
Hello. In a nutshell I have two issues: first, inability to execute EXPLAIN PLAN via SET AUTOTRACE ON EXPLAIN, and second, extremely verbose output when I log on as SYSDBA to circumvent the first issue.
So, issue number one:
I am trying to get an EXPLAIN PLAN via SET AUTOTRACE ON EXPLAIN for a simple SQL query:
1 select decode(rownum,1,'JAN', 2,'FEB',3,'MAR',4,'APR',5,'MAY',6,'JUN',7,'JUL',8,'AUG',9,'SEP',10,'OCT',11,'NOV',12,'DEC')
2* from all_objects where rownum<13
HR@XE> /
DEC
JAN
FEB
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
NOV
DEC
12 rows selected.
HR@XE> set autotrace on explain
HR@XE> /
DEC
JAN
FEB
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
NOV
DEC
12 rows selected.
Execution Plan
ERROR:
ORA-01039: insufficient privileges on underlying objects of the viewSo, first question, why am I getting this error? ALL_OBJECTS should be available to everybody, no?
So to circumvent this I log on as sysdba and get the second issue: the following extremely verbose output
HR@XE> connect / as sysdba
Connected.
SYS@XE> select decode(rownum,1,'JAN', 2,'FEB',3,'MAR',4,'APR',5,'MAY',6,'JUN',7,'JUL',8,'AUG',9,'SEP',10,'OCT',11,'NOV',12,'DEC')
2 from all_objects where rownum<13;
DEC
JAN
FEB
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
NOV
DEC
12 rows selected.
SYS@XE> set autotrace on explain
SYS@XE> /
DEC
JAN
FEB
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
NOV
DEC
12 rows selected.
Execution Plan
Plan hash value: 1291336664
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 12 | 3240 | 5 (20)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN | | 32 | 8640 | 5 (20)| 00:00:01 |
| 4 | INDEX FULL SCAN | I_USER2 | 49 | 1078 | 1 (0)| 00:00:01 |
|* 5 | HASH JOIN | | 32 | 5248 | 4 (25)| 00:00:01 |
| 6 | INDEX FULL SCAN | I_USER2 | 49 | 196 | 1 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | OBJ$ | 33 | 2640 | 2 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID | IND$ | 1 | 8 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 |
|* 10 | HASH JOIN | | 1 | 24 | 3 (34)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 2 (0)| 00:00:01 |
| 12 | FIXED TABLE FULL | X$KZSRO | 100 | 1300 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | | | | |
| 16 | NESTED LOOPS | | 1 | 73 | 6 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 1 | 63 | 4 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 1 | 52 | 3 (0)| 00:00:01 |
| 19 | MERGE JOIN CARTESIAN | | 1 | 48 | 2 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | I_OBJ5 | 1 | 35 | 2 (0)| 00:00:01 |
| 21 | BUFFER SORT | | 100 | 1300 | 0 (0)| 00:00:01 |
| 22 | FIXED TABLE FULL | X$KZSRO | 100 | 1300 | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | I_USER2 | 1 | 4 | 1 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 1 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | I_DEPENDENCY1 | 4 | | 1 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID | DEPENDENCY$ | 1 | 10 | 2 (0)| 00:00:01 |
|* 27 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 28 | HASH JOIN | | 1 | 24 | 3 (34)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 2 (0)| 00:00:01 |
| 30 | FIXED TABLE FULL | X$KZSRO | 100 | 1300 | 0 (0)| 00:00:01 |
|* 31 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 32 | NESTED LOOPS | | 2 | 48 | 2 (0)| 00:00:01 |
|* 33 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 2 (0)| 00:00:01 |
|* 34 | FIXED TABLE FULL | X$KZSRO | 2 | 26 | 0 (0)| 00:00:01 |
| 35 | NESTED LOOPS | | 1 | 38 | 2 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | 1 | 25 | 2 (0)| 00:00:01 |
|* 37 | TABLE ACCESS BY INDEX ROWID | TRIGGER$ | 1 | 14 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | I_TRIGGER2 | 1 | | 0 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 1 (0)| 00:00:01 |
|* 40 | FIXED TABLE FULL | X$KZSRO | 1 | 13 | 0 (0)| 00:00:01 |
|* 41 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 42 | NESTED LOOPS | | | | | |
| 43 | NESTED LOOPS | | 1 | 73 | 6 (0)| 00:00:01 |
| 44 | NESTED LOOPS | | 1 | 63 | 4 (0)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 52 | 3 (0)| 00:00:01 |
| 46 | MERGE JOIN CARTESIAN | | 1 | 48 | 2 (0)| 00:00:01 |
|* 47 | INDEX RANGE SCAN | I_OBJ5 | 1 | 35 | 2 (0)| 00:00:01 |
| 48 | BUFFER SORT | | 100 | 1300 | 0 (0)| 00:00:01 |
| 49 | FIXED TABLE FULL | X$KZSRO | 100 | 1300 | 0 (0)| 00:00:01 |
|* 50 | INDEX RANGE SCAN | I_USER2 | 1 | 4 | 1 (0)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 1 (0)| 00:00:01 |
|* 52 | INDEX RANGE SCAN | I_DEPENDENCY1 | 4 | | 1 (0)| 00:00:01 |
|* 53 | TABLE ACCESS BY INDEX ROWID | DEPENDENCY$ | 1 | 10 | 2 (0)| 00:00:01 |
|* 54 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 55 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 56 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 57 | NESTED LOOPS | | 2 | 68 | 2 (0)| 00:00:01 |
| 58 | NESTED LOOPS | | 1 | 21 | 2 (0)| 00:00:01 |
| 59 | TABLE ACCESS BY INDEX ROWID | TABPART$ | 1 | 10 | 1 (0)| 00:00:01 |
|* 60 | INDEX UNIQUE SCAN | I_TABPART_OBJ$ | 1 | | 0 (0)| 00:00:01 |
|* 61 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 1 (0)| 00:00:01 |
|* 62 | FIXED TABLE FULL | X$KZSRO | 2 | 26 | 0 (0)| 00:00:01 |
|* 63 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 64 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 65 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 66 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 67 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 68 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 69 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 70 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 71 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 72 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 73 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 74 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 75 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 76 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
|* 77 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 78 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 79 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 80 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 81 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 82 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 83 | NESTED LOOPS | | 2 | 42 | 2 (0)| 00:00:01 |
|* 84 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 8 | 2 (0)| 00:00:01 |
|* 85 | FIXED TABLE FULL | X$KZSRO | 2 | 26 | 0 (0)| 00:00:01 |
|* 86 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 87 | NESTED LOOPS | | 2 | 42 | 2 (0)| 00:00:01 |
|* 88 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 8 | 2 (0)| 00:00:01 |
|* 89 | FIXED TABLE FULL | X$KZSRO | 2 | 26 | 0 (0)| 00:00:01 |
|* 90 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 91 | VIEW | | 1 | 16 | 1 (0)| 00:00:01 |
| 92 | SORT GROUP BY | | 1 | 86 | 1 (0)| 00:00:01 |
| 93 | NESTED LOOPS | | 1 | 86 | 1 (0)| 00:00:01 |
| 94 | MERGE JOIN CARTESIAN | | 1 | 78 | 0 (0)| 00:00:01 |
| 95 | NESTED LOOPS | | 1 | 65 | 0 (0)| 00:00:01 |
|* 96 | INDEX UNIQUE SCAN | I_OLAP_CUBES$ | 1 | 13 | 0 (0)| 00:00:01 |
|* 97 | TABLE ACCESS BY INDEX ROWID| OLAP_DIMENSIONALITY$ | 1 | 52 | 0 (0)| 00:00:01 |
|* 98 | INDEX RANGE SCAN | I_OLAP_DIMENSIONALITY$ | 1 | | 0 (0)| 00:00:01 |
| 99 | BUFFER SORT | | 1 | 13 | 0 (0)| 00:00:01 |
| 100 | INDEX FULL SCAN | I_OLAP_CUBE_DIMENSIONS$ | 1 | 13 | 0 (0)| 00:00:01 |
|*101 | INDEX RANGE SCAN | I_OBJ1 | 1 | 8 | 1 (0)| 00:00:01 |
| 102 | NESTED LOOPS | | 1 | 30 | 2 (0)| 00:00:01 |
|*103 | INDEX SKIP SCAN | I_USER2 | 1 | 20 | 1 (0)| 00:00:01 |
|*104 | INDEX RANGE SCAN | I_OBJ4 | 1 | 10 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(ROWNUM<13)
2 - filter(("O"."TYPE#"<>1 AND "O"."TYPE#"<>10 OR "O"."TYPE#"=1 AND (SELECT 1 FROM "SYS"."IND$"
"I" WHERE "I"."OBJ#"=:B1 AND ("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4 OR
"I"."TYPE#"=6 OR "I"."TYPE#"=7 OR "I"."TYPE#"=9))=1) AND (("O"."SPARE3"=USERENV('SCHEMAID') OR
"O"."SPARE3"=1) OR "O"."TYPE#"=13 AND ( EXISTS (SELECT 0 FROM "SYS"."OBJAUTH$" "OA",SYS."X$KZSRO"
"X$KZSRO" WHERE "OA"."GRANTEE#"="KZSROROL" AND "OA"."OBJ#"=:B2 AND ("OA"."PRIVILEGE#"=12 OR
"OA"."PRIVILEGE#"=26)) OR EXISTS (SELECT 0 FROM SYS."X$KZSPR" "X$KZSPR" WHERE
"INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-184) OR (-"KZSPRPRV")=(-181) OR
(-"KZSPRPRV")=(-241)))) OR ("O"."TYPE#"=1 OR "O"."TYPE#"=2 OR "O"."TYPE#"=3 OR "O"."TYPE#"=4 OR
"O"."TYPE#"=5 OR "O"."TYPE#"=19 OR "O"."TYPE#"=20 OR "O"."TYPE#"=34 OR "O"."TYPE#"=35) AND EXISTS
(SELECT 0 FROM SYS."X$KZSPR" "X$KZSPR" WHERE "INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-45)
OR (-"KZSPRPRV")=(-47) OR (-"KZSPRPRV")=(-48) OR (-"KZSPRPRV")=(-49) OR (-"KZSPRPRV")=(-50))) OR
"O"."TYPE#"=11 AND ( EXISTS (SELECT 0 FROM "SYS"."OBJAUTH$" "OA","SYS"."DEPENDENCY$"
"DEP",SYS."USER$" "U",SYS."OBJ$" "O",SYS."X$KZSRO" "X$KZSRO" WHERE "O"."NAME"=:B3 AND
"O"."SPARE3"=:B4 AND "O"."TYPE#"=9 AND "O"."TYPE#"<>88 AND "O"."OWNER#"="U"."USER#" AND
"DEP"."D_OBJ#"=:B5 AND "DEP"."P_OBJ#"="O"."OBJ#" AND "OA"."OBJ#"="O"."OBJ#" AND "OA"."PRIVILEGE#"=26
AND "OA"."GRANTEE#"="KZSROROL") OR EXISTS (SELECT 0 FROM SYS."X$KZSPR" "X$KZSPR" WHERE
((-"KZSPRPRV")=(-141) OR (-"KZSPRPRV")=(-241)) AND "INST_ID"=USERENV('INSTANCE'))) OR ("O"."TYPE#"=7
OR "O"."TYPE#"=8 OR "O"."TYPE#"=9 OR "O"."TYPE#"=28 OR "O"."TYPE#"=29 OR "O"."TYPE#"=30 OR
"O"."TYPE#"=56) AND ( EXISTS (SELECT 0 FROM "SYS"."OBJAUTH$" "OA",SYS."X$KZSRO" "X$KZSRO" WHERE
"OA"."GRANTEE#"="KZSROROL" AND "OA"."OBJ#"=:B6 AND ("OA"."PRIVILEGE#"=12 OR "OA"."PRIVILEGE#"=26)) OR
EXISTS (SELECT 0 FROM SYS."X$KZSPR" "X$KZSPR" WHERE "INST_ID"=USERENV('INSTANCE') AND
((-"KZSPRPRV")=(-144) OR (-"KZSPRPRV")=(-141) OR (-"KZSPRPRV")=(-241)))) OR "O"."TYPE#"<>14 AND
"O"."TYPE#"<>28 AND "O"."TYPE#"<>29 AND "O"."TYPE#"<>30 AND "O"."TYPE#"<>56 AND "O"."TYPE#"<>93 AND
"O"."TYPE#"<>7 AND "O"."TYPE#"<>8 AND "O"."TYPE#"<>9 AND "O"."TYPE#"<>11 AND "O"."TYPE#"<>12 AND
"O"."TYPE#"<>13 AND EXISTS (SELECT 0 FROM "SYS"."OBJAUTH$" "OBJAUTH$",SYS."X$KZSRO" "X$KZSRO" WHERE
"GRANTEE#"="KZSROROL" AND "OBJ#"=:B7 AND ("PRIVILEGE#"=3 OR "PRIVILEGE#"=6 OR "PRIVILEGE#"=7 OR
"PRIVILEGE#"=9 OR "PRIVILEGE#"=10 OR "PRIVILEGE#"=11 OR "PRIVILEGE#"=12 OR "PRIVILEGE#"=16 OR
"PRIVILEGE#"=17 OR "PRIVILEGE#"=18)) OR "O"."TYPE#"=12 AND ( EXISTS (SELECT 0 FROM "SYS"."OBJAUTH$"
"OA","SYS"."TRIGGER$" "T",SYS."X$KZSRO" "X$KZSRO" WHERE "OA"."GRANTEE#"="KZSROROL" AND "T"."OBJ#"=:B8
AND BITAND("T"."PROPERTY",24)=0 AND "OA"."OBJ#"="T"."BASEOBJECT" AND "OA"."PRIVILEGE#"=26) OR EXISTS
(SELECT 0 FROM SYS."X$KZSPR" "X$KZSPR" WHERE ((-"KZSPRPRV")=(-152) OR (-"KZSPRPRV")=(-241)) AND
"INST_ID"=USERENV('INSTANCE'))) OR "O"."TYPE#"=14 AND ( EXISTS (SELECT 0 FROM "SYS"."OBJAUTH$"
"OA","SYS"."DEPENDENCY$" "DEP",SYS."USER$" "U",SYS."OBJ$" "O",SYS."X$KZSRO" "X$KZSRO" WHERE
"O"."NAME"=:B9 AND "O"."SPARE3"=:B10 AND "O"."TYPE#"=13 AND "O"."TYPE#"<>88 AND
"O"."OWNER#"="U"."USER#" AND "DEP"."D_OBJ#"=:B11 AND "DEP"."P_OBJ#"="O"."OBJ#" AND
"OA"."OBJ#"="O"."OBJ#" AND "OA"."PRIVILEGE#"=26 AND "OA"."GRANTEE#"="KZSROROL") OR EXISTS (SELECT 0
FROM SYS."X$KZSPR" "X$KZSPR" WHERE ((-"KZSPRPRV")=(-181) OR (-"KZSPRPRV")=(-241)) AND
"INST_ID"=USERENV('INSTANCE'))) OR ("O"."TYPE#"=66 OR "O"."TYPE#"=100) AND EXISTS (SELECT 0 FROM
SYS."X$KZSPR" "X$KZSPR" WHERE (-"KZSPRPRV")=(-265) AND "INST_ID"=USERENV('INSTANCE')) OR
("O"."TYPE#"=67 OR "O"."TYPE#"=79) AND EXISTS (SELECT 0 FROM SYS."X$KZSPR" "X$KZSPR" WHERE
((-"KZSPRPRV")=(-265) OR (-"KZSPRPRV")=(-266)) AND "INST_ID"=USERENV('INSTANCE')) OR "O"."TYPE#"=19
AND EXISTS (SELECT 0 FROM SYS."TABPART$" "TABPART$","SYS"."OBJAUTH$" "OBJAUTH$",SYS."X$KZSRO"
"X$KZSRO" WHERE "GRANTEE#"="KZSROROL" AND "BO#"="OBJ#" A)
3 - access("O"."OWNER#"="U"."USER#")
5 - access("O"."SPARE3"="U"."USER#")
7 - filter("O"."NAME"<>'_NEXT_OBJECT' AND "O"."NAME"<>'_default_auditing_options_' AND
BITAND("O"."FLAGS",128)=0 AND "O"."LINKNAME" IS NULL)
8 - filter("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4 OR "I"."TYPE#"=6 OR
"I"."TYPE#"=7 OR "I"."TYPE#"=9)
9 - access("I"."OBJ#"=:B1)
10 - access("OA"."GRANTEE#"="KZSROROL")
11 - access("OA"."OBJ#"=:B1)
filter("OA"."PRIVILEGE#"=12 OR "OA"."PRIVILEGE#"=26)
13 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-184) OR (-"KZSPRPRV")=(-181) OR
(-"KZSPRPRV")=(-241)))
14 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-45) OR (-"KZSPRPRV")=(-47) OR
(-"KZSPRPRV")=(-48) OR (-"KZSPRPRV")=(-49) OR (-"KZSPRPRV")=(-50)))
20 - access("O"."SPARE3"=:B1 AND "O"."NAME"=:B2 AND "O"."TYPE#"=9)
filter("O"."TYPE#"=9 AND "O"."TYPE#"<>88)
23 - access("O"."OWNER#"="U"."USER#")
24 - access("OA"."OBJ#"="O"."OBJ#" AND "OA"."GRANTEE#"="KZSROROL" AND "OA"."PRIVILEGE#"=26)
filter("OA"."PRIVILEGE#"=26 AND "OA"."GRANTEE#"="KZSROROL")
25 - access("DEP"."D_OBJ#"=:B1)
26 - filter("DEP"."P_OBJ#"="O"."OBJ#")
27 - filter(((-"KZSPRPRV")=(-141) OR (-"KZSPRPRV")=(-241)) AND "INST_ID"=USERENV('INSTANCE'))
28 - access("OA"."GRANTEE#"="KZSROROL")
29 - access("OA"."OBJ#"=:B1)
filter("OA"."PRIVILEGE#"=12 OR "OA"."PRIVILEGE#"=26)
31 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-144) OR (-"KZSPRPRV")=(-141) OR
(-"KZSPRPRV")=(-241)))
33 - access("OBJ#"=:B1)
filter("PRIVILEGE#"=3 OR "PRIVILEGE#"=6 OR "PRIVILEGE#"=7 OR "PRIVILEGE#"=9 OR "PRIVILEGE#"=10
OR "PRIVILEGE#"=11 OR "PRIVILEGE#"=12 OR "PRIVILEGE#"=16 OR "PRIVILEGE#"=17 OR "PRIVILEGE#"=18)
34 - filter("GRANTEE#"="KZSROROL")
37 - filter(BITAND("T"."PROPERTY",24)=0)
38 - access("T"."OBJ#"=:B1)
39 - access("OA"."OBJ#"="T"."BASEOBJECT" AND "OA"."PRIVILEGE#"=26)
filter("OA"."PRIVILEGE#"=26)
40 - filter("OA"."GRANTEE#"="KZSROROL")
41 - filter(((-"KZSPRPRV")=(-152) OR (-"KZSPRPRV")=(-241)) AND "INST_ID"=USERENV('INSTANCE'))
47 - access("O"."SPARE3"=:B1 AND "O"."NAME"=:B2 AND "O"."TYPE#"=13)
filter("O"."TYPE#"=13 AND "O"."TYPE#"<>88)
50 - access("O"."OWNER#"="U"."USER#")
51 - access("OA"."OBJ#"="O"."OBJ#" AND "OA"."GRANTEE#"="KZSROROL" AND "OA"."PRIVILEGE#"=26)
filter("OA"."PRIVILEGE#"=26 AND "OA"."GRANTEE#"="KZSROROL")
52 - access("DEP"."D_OBJ#"=:B1)
53 - filter("DEP"."P_OBJ#"="O"."OBJ#")
54 - filter(((-"KZSPRPRV")=(-181) OR (-"KZSPRPRV")=(-241)) AND "INST_ID"=USERENV('INSTANCE'))
55 - filter((-"KZSPRPRV")=(-265) AND "INST_ID"=USERENV('INSTANCE'))
56 - filter(((-"KZSPRPRV")=(-265) OR (-"KZSPRPRV")=(-266)) AND "INST_ID"=USERENV('INSTANCE'))
60 - access("OBJ#"=:B1)
61 - access("BO#"="OBJ#" AND "PRIVILEGE#"=9)
filter("PRIVILEGE#"=9)
62 - filter("GRANTEE#"="KZSROROL")
63 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-189) OR (-"KZSPRPRV")=(-190) OR
(-"KZSPRPRV")=(-191) OR (-"KZSPRPRV")=(-192)))
64 - filter((-"KZSPRPRV")=(-109) AND "INST_ID"=USERENV('INSTANCE'))
65 - filter(((-"KZSPRPRV")=(-177) OR (-"KZSPRPRV")=(-178)) AND "INST_ID"=USERENV('INSTANCE'))
66 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-45) OR (-"KZSPRPRV")=(-47) OR
(-"KZSPRPRV")=(-48) OR (-"KZSPRPRV")=(-49) OR (-"KZSPRPRV")=(-50)))
67 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-205) OR (-"KZSPRPRV")=(-206) OR
(-"KZSPRPRV")=(-207) OR (-"KZSPRPRV")=(-208)))
68 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-200) OR (-"KZSPRPRV")=(-201) OR
(-"KZSPRPRV")=(-202) OR (-"KZSPRPRV")=(-203) OR (-"KZSPRPRV")=(-204)))
69 - filter(((-"KZSPRPRV")=(-222) OR (-"KZSPRPRV")=(-223)) AND "INST_ID"=USERENV('INSTANCE'))
70 - filter((-"KZSPRPRV")=12 AND "INST_ID"=USERENV('INSTANCE'))
71 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-251) OR (-"KZSPRPRV")=(-252) OR
(-"KZSPRPRV")=(-253) OR (-"KZSPRPRV")=(-254)))
72 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-258) OR (-"KZSPRPRV")=(-259) OR
(-"KZSPRPRV")=(-260) OR (-"KZSPRPRV")=(-261)))
73 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-246) OR (-"KZSPRPRV")=(-247) OR
(-"KZSPRPRV")=(-248) OR (-"KZSPRPRV")=(-249)))
74 - filter(((-"KZSPRPRV")=(-268) OR (-"KZSPRPRV")=(-267)) AND "INST_ID"=USERENV('INSTANCE'))
77 - filter(((-"KZSPRPRV")=(-277) OR (-"KZSPRPRV")=(-278)) AND "INST_ID"=USERENV('INSTANCE'))
78 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-292) OR (-"KZSPRPRV")=(-293) OR
(-"KZSPRPRV")=(-294)))
79 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-282) OR (-"KZSPRPRV")=(-283) OR
(-"KZSPRPRV")=(-284) OR (-"KZSPRPRV")=(-285)))
80 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-302) OR (-"KZSPRPRV")=(-303) OR
(-"KZSPRPRV")=(-304) OR (-"KZSPRPRV")=(-305) OR (-"KZSPRPRV")=(-306) OR (-"KZSPRPRV")=(-307)))
81 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-315) OR (-"KZSPRPRV")=(-316) OR
(-"KZSPRPRV")=(-317) OR (-"KZSPRPRV")=(-318)))
82 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-320) OR (-"KZSPRPRV")=(-321) OR
(-"KZSPRPRV")=(-322)))
84 - access("OBJ#"=:B1)
85 - filter("GRANTEE#"="KZSROROL")
86 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-309) OR (-"KZSPRPRV")=(-310) OR
(-"KZSPRPRV")=(-311) OR (-"KZSPRPRV")=(-312) OR (-"KZSPRPRV")=(-313)))
88 - access("OBJ#"=:B1)
89 - filter("GRANTEE#"="KZSROROL")
90 - filter("INST_ID"=USERENV('INSTANCE') AND ((-"KZSPRPRV")=(-302) OR (-"KZSPRPRV")=(-303) OR
(-"KZSPRPRV")=(-304) OR (-"KZSPRPRV")=(-305) OR (-"KZSPRPRV")=(-306) OR (-"KZSPRPRV")=(-307)))
96 - access("C"."OBJ#"=:B1)
97 - filter("DIML"."DIMENSION_TYPE"=11)
98 - access("DIML"."DIMENSIONED_OBJECT_ID"=:B1 AND "DIML"."DIMENSIONED_OBJECT_TYPE"=1)
101 - access("DIML"."DIMENSION_ID"="DO"."OBJ#")
filter("DO"."OBJ#"="DIM"."OBJ#")
103 - access("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','current_edition_id')))
filter("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','current_edition_id')))
104 - access("O2"."DATAOBJ#"=:B1 AND "O2"."TYPE#"=88 AND "O2"."OWNER#"="U2"."USER#")
SYS@XE>Many thanks in advance.
JasonWelcome to the forum!
Whenever you post please provide your 4 digit Oracle Version (result of SELECT * FROM V$VERSION).
>
So, first question, why am I getting this error? ALL_OBJECTS should be available to everybody, no?
>
Your user probably does have access to ALL_OBJECTS. But you need to have dba privileges to access views base objects.
The "ORA-01039: insufficient privileges on underlying objects of the view" message is telling you that the user does not have privileges to access the BASE OBJECTS that used to build the view. Access to those base objects is necessary to generate the plan you are trying to see.
So to circumvent this I log on as sysdba and get the second issue: the following extremely verbose output
>
And that is because sysdba DOES have access to the base objects of the view. You asked for a plan and you got it. That verbose output IS the plan and all of those oddly named tables are being accessed to satisfy your query so are included in the plan.
Do your query using DUAL or the SCOTT.EMP table and you won't get the error. -
Explain plan output for a sql in JSP page
Hello all,
I have a requirement to give SQL query as an input and get the output and explain plan in the same JSP page. i could get the SQL result, but i want to get the EXPLAIN Plan.
can any one help me in this.
Thanks
KiranHello all,
I have a requirement to give SQL query as an input and get the output and explain plan in the same JSP page. i could get the SQL result, but i want to get the EXPLAIN Plan.
can any one help me in this.
Thanks
Kiran -
Understanding explain plan output
Hi,
Version 11202.
Bellow is the output of tkprof against a statment which has cpu time = elapsed time =~3000 sec.
The statment is related to oracle EBS , but the question bellow is regarding the execution plan.
As you can see in the plan bellow most of the time is spend on the following step :
0 0 0 TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
2059303280 2059303280 2059303280 INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)What i am trying to understand is why 2 billions rows (2059303280) has been accessed by the index IBY_PMT_INSTR_USES_ALL_N2
SQL> select table_name,num_rows,sample_size,last_analyzed from dba_tables where table_name='IBY_PMT_INSTR_USES_ALL';
TABLE_NAME NUM_ROWS SAMPLE_SIZE LAST_ANAL
IBY_PMT_INSTR_USES_ALL 2414470 241447 28-JAN-13
SQL> select table_name,distinct_keys,clustering_factor,num_rows,sample_size,last_analyzed from dba_indexes where index_name='IBY_PMT_INSTR_USES_ALL_N2';
TABLE_NAME DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE LAST_ANAL
IBY_PMT_INSTR_USES_ALL 304515 267170 2407170 240717 28-JAN-13The whole statment and is plan is as followed :
insert into iby_pmt_instr_uses_all (instrument_payment_use_id,payment_flow,
ext_pmt_party_id,instrument_type,instrument_id,payment_function,
order_of_preference,created_by,creation_date,last_updated_by,
last_update_date,last_update_login,object_version_number,start_date,
end_date,debit_auth_flag,debit_auth_method,debit_auth_reference,
debit_auth_begin,debit_auth_end)select iby_pmt_instr_uses_all_s.nextval ,
'FUNDS_CAPTURE' ,iep.ext_payer_id ,'BANKACCOUNT' ,eba.ext_bank_account_id ,
'CUSTOMER_PAYMENT' ,DECODE(cbi.primary_flag,'Y',1,10) ,:b0 ,SYSDATE ,:b0 ,
SYSDATE ,:b2 ,1 ,cbi.start_date ,cbi.end_date ,'' ,'' ,'' ,'' ,'' from
iby_external_payers_all iep ,hz_cust_accounts hca ,hz_cust_site_uses_all
csu ,hz_cust_acct_sites_all cas ,hz_parties hzba ,hz_relationships hzr ,
hz_code_assignments hcba ,hz_parties hzbb ,hz_organization_profiles hop ,
hz_code_assignments hcbb ,iby_ext_bank_accounts eba ,
ra_customer_banks_int_all cbi where
(((((((((((((((((((((((((((((((((((((((cbi.interface_status is null and
cbi.request_id=:b3) and UPPER(cbi.bank_name)=UPPER(hzba.party_name)) and
hzba.party_id=hop.party_id) and SYSDATE between
TRUNC(hop.effective_start_date) and NVL(TRUNC(hop.effective_end_date),
(SYSDATE+1))) and hcba.class_category='BANK_INSTITUTION_TYPE') and
hcba.class_code='BANK') and hcba.owner_table_name='HZ_PARTIES') and
hcba.owner_table_id=hzba.party_id) and cbi.bank_home_country=
hop.home_country) and hzbb.party_id=hcbb.owner_table_id) and
hcbb.owner_table_name='HZ_PARTIES') and hcbb.class_category=
'BANK_INSTITUTION_TYPE') and hcbb.class_code='BANK_BRANCH') and
nvl(hcbb.status,'A')='A') and hzbb.party_id=hzr.subject_id) and
hzba.party_id=hzr.object_id) and hzr.relationship_type='BANK_AND_BRANCH')
and hzr.relationship_code='BRANCH_OF') and hzr.status='A') and
hzr.subject_table_name='HZ_PARTIES') and hzr.subject_type='ORGANIZATION')
and hzr.object_table_name='HZ_PARTIES') and hzr.object_type='ORGANIZATION')
and UPPER(cbi.bank_branch_name)=UPPER(hzbb.party_name)) and hzbb.party_id=
eba.branch_id) and hzba.party_id=eba.bank_id) and eba.bank_account_num=
cbi.bank_account_num) and eba.currency_code=cbi.bank_account_currency_code)
and cbi.orig_system_customer_ref=hca.orig_system_reference) and
iep.cust_account_id=hca.cust_account_id) and iep.party_id=hca.party_id) and
((cbi.orig_system_address_ref is null and iep.org_id is null ) or
iep.org_id=cbi.org_id)) and ((cbi.orig_system_address_ref is null and
iep.org_type is null ) or iep.org_type='OPERATING_UNIT')) and cbi.org_id=
cas.org_id(+)) and nvl(iep.acct_site_use_id,(-1))=
decode(cbi.orig_system_address_ref,null ,(-1),csu.site_use_id)) and
cbi.orig_system_address_ref=cas.orig_system_reference(+)) and
(csu.site_use_id=(select min(site_use_id) from hz_cust_site_uses_all hcsua
where ((hcsua.cust_acct_site_id=cas.cust_acct_site_id and
hcsua.site_use_code='BILL_TO') and hcsua.status='A')) or csu.site_use_id is
null )) and cas.cust_acct_site_id=csu.cust_acct_site_id(+)) and not exists
(select 'x' from iby_pmt_instr_uses_all ipi where (((ipi.ext_pmt_party_id=
iep.ext_payer_id and ipi.instrument_type='BANKACCOUNT') and
ipi.instrument_id=eba.ext_bank_account_id) and ipi.payment_function=
'CUSTOMER_PAYMENT')))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 3049.58 3080.23 31827 44696023 1587 1175
Fetch 0 0.00 0.00 0 0 0 0
total 2 3049.58 3080.23 31827 44696023 1587 1175
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 57 (APPS)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
0 0 0 LOAD TABLE CONVENTIONAL (cr=44696030 pr=31827 pw=0 time=2870820188 us)
1175 1175 1175 SEQUENCE IBY_PMT_INSTR_USES_ALL_S (cr=44695967 pr=31774 pw=0 time=3270855802 us)
1175 1175 1175 FILTER (cr=44695960 pr=31774 pw=0 time=3270803657 us)
1175 1175 1175 NESTED LOOPS ANTI (cr=44695844 pr=31774 pw=0 time=3270739008 us cost=251 size=497 card=1)
1175 1175 1175 NESTED LOOPS (cr=64952 pr=217 pw=0 time=2991575 us cost=248 size=457 card=1)
1175 1175 1175 NESTED LOOPS (cr=64827 pr=205 pw=0 time=2949382 us cost=245 size=423 card=1)
1175 1175 1175 NESTED LOOPS OUTER (cr=63494 pr=205 pw=0 time=2921176 us cost=243 size=403 card=1)
1175 1175 1175 NESTED LOOPS (cr=63377 pr=205 pw=0 time=2893312 us cost=240 size=391 card=1)
1175 1175 1175 NESTED LOOPS (cr=61415 pr=205 pw=0 time=2850064 us cost=236 size=348 card=1)
47434 47434 47434 NESTED LOOPS (cr=57058 pr=205 pw=0 time=2565056 us cost=234 size=328 card=1)
41203 41203 41203 NESTED LOOPS OUTER (cr=42422 pr=0 pw=0 time=581594 us cost=230 size=296 card=1)
41203 41203 41203 HASH JOIN (cr=1049 pr=0 pw=0 time=173751 us cost=229 size=277 card=1)
2333 2333 2333 NESTED LOOPS (cr=1013 pr=0 pw=0 time=32850 us)
2333 2333 2333 NESTED LOOPS (cr=825 pr=0 pw=0 time=22036 us cost=208 size=172 card=1)
514 514 514 NESTED LOOPS (cr=691 pr=0 pw=0 time=16378 us cost=206 size=88 card=1)
514 514 514 NESTED LOOPS (cr=588 pr=0 pw=0 time=7190 us cost=95 size=2501 card=41)
514 514 514 TABLE ACCESS BY INDEX ROWID HZ_CODE_ASSIGNMENTS (cr=20 pr=0 pw=0 time=1716 us cost=10 size=1681 card=41)
514 514 514 INDEX RANGE SCAN HZ_CODE_ASSIGNMENTS_N1 (cr=7 pr=0 pw=0 time=464 us cost=4 size=0 card=164)(object id 464630)
514 514 514 TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=568 pr=0 pw=0 time=2797 us cost=2 size=20 card=1)
514 514 514 INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=54 pr=0 pw=0 time=1059 us cost=1 size=0 card=1)(object id 421661)
514 514 514 TABLE ACCESS BY INDEX ROWID HZ_ORGANIZATION_PROFILES (cr=103 pr=0 pw=0 time=5913 us cost=3 size=27 card=1)
514 514 514 INDEX RANGE SCAN BZ_HZ_ORGANIZATION_PROFILE_N1 (cr=76 pr=0 pw=0 time=2873 us cost=2 size=0 card=1)(object id 9378840)
2333 2333 2333 INDEX RANGE SCAN HZ_RELATIONSHIPS_N2 (cr=134 pr=0 pw=0 time=3962 us cost=1 size=0 card=1)(object id 11581198)
2333 2333 2333 TABLE ACCESS BY INDEX ROWID HZ_RELATIONSHIPS (cr=188 pr=0 pw=0 time=7476 us cost=2 size=84 card=1)
1175 1175 1175 TABLE ACCESS FULL RA_CUSTOMER_BANKS_INT_ALL (cr=36 pr=0 pw=0 time=9479 us cost=21 size=123375 card=1175)
41203 41203 41203 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=41373 pr=0 pw=0 time=304952 us cost=1 size=19 card=1)
41203 41203 41203 INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U2 (cr=170 pr=0 pw=0 time=93830 us cost=1 size=0 card=1)(object id 421730)
47434 47434 47434 TABLE ACCESS BY INDEX ROWID IBY_EXT_BANK_ACCOUNTS (cr=14636 pr=205 pw=0 time=2375333 us cost=4 size=32 card=1)
47434 47434 47434 INDEX RANGE SCAN IBY_EXT_BANK_ACCOUNTS_N6 (cr=3548 pr=94 pw=0 time=1112297 us cost=2 size=0 card=1)(object id 14313177)
1175 1175 1175 TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=4357 pr=0 pw=0 time=171450 us cost=2 size=20 card=1)
1203 1203 1203 INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=3154 pr=0 pw=0 time=107886 us cost=1 size=0 card=1)(object id 421661)
1175 1175 1175 TABLE ACCESS BY INDEX ROWID HZ_CODE_ASSIGNMENTS (cr=1962 pr=0 pw=0 time=41107 us cost=3 size=43 card=1)
1175 1175 1175 INDEX RANGE SCAN HZ_CODE_ASSIGNMENTS_U2 (cr=1611 pr=0 pw=0 time=25716 us cost=2 size=0 card=1)(object id 14355645)
1175 1175 1175 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=117 pr=0 pw=0 time=14875 us cost=3 size=12 card=1)
1175 1175 1175 INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=86 pr=0 pw=0 time=10600 us cost=2 size=0 card=1)(object id 464289)
1175 1175 1175 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=1333 pr=0 pw=0 time=22634 us cost=2 size=20 card=1)
1175 1175 1175 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U3 (cr=158 pr=0 pw=0 time=9307 us cost=1 size=0 card=1)(object id 9438627)
1175 1175 1175 TABLE ACCESS BY INDEX ROWID IBY_EXTERNAL_PAYERS_ALL (cr=125 pr=12 pw=0 time=131366 us cost=3 size=34 card=1)
1175 1175 1175 INDEX RANGE SCAN IBY_EXTERNAL_PAYERS_ALL_U2 (cr=109 pr=4 pw=0 time=51266 us cost=2 size=0 card=1)(object id 14313089)
0 0 0 TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
2059303280 2059303280 2059303280 INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)
1000 1000 1000 SORT AGGREGATE (cr=116 pr=0 pw=0 time=39211 us)
1000 1000 1000 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=116 pr=0 pw=0 time=27041 us cost=4 size=22 card=1)
1000 1000 1000 INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=85 pr=0 pw=0 time=19027 us cost=3 size=0 card=1)(object id 464289)Yoav wrote:
and not exists
(select 'x' from iby_pmt_instr_uses_all ipi where (((ipi.ext_pmt_party_id=
iep.ext_payer_id and ipi.instrument_type='BANKACCOUNT') and
ipi.instrument_id=eba.ext_bank_account_id) and ipi.payment_function=
'CUSTOMER_PAYMENT')))
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
0 0 0 LOAD TABLE CONVENTIONAL (cr=44696030 pr=31827 pw=0 time=2870820188 us)
1175 1175 1175 SEQUENCE IBY_PMT_INSTR_USES_ALL_S (cr=44695967 pr=31774 pw=0 time=3270855802 us)
1175 1175 1175 FILTER (cr=44695960 pr=31774 pw=0 time=3270803657 us)
1175 1175 1175 NESTED LOOPS ANTI (cr=44695844 pr=31774 pw=0 time=3270739008 us cost=251 size=497 card=1)
1175 1175 1175 NESTED LOOPS (cr=64952 pr=217 pw=0 time=2991575 us cost=248 size=457 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
2059303280 2059303280 2059303280 INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)
1000 1000 1000 SORT AGGREGATE (cr=116 pr=0 pw=0 time=39211 us)
1000 1000 1000 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=116 pr=0 pw=0 time=27041 us cost=4 size=22 card=1)
1000 1000 1000 INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=85 pr=0 pw=0 time=19027 us cost=3 size=0 card=1)(object id 464289)
You have a "not exists" subquery that the optimizer has turned into a nested loop anti join.
For each of the 1175 rows returned by the previous step Oracle does a range scan of what it thinks is the most appropriate index - the figures for cost (2) and card (8) at that line show that something has gone wrong with the optimizer's estimates, and for each of the 1175 prior rows it has acquired an average 1.7M index entries based on the index predicates, then visited the table and discarded resulting row.
It looks as if the index is a bad choice of index - you need to check the index predicates for the plan - use dbms_xplan to pull it from memory; and check your indexes to see if there is a better one that the optimizer should have chosen
Regards
Jonathan Lewis -
Understanding the COST column of an explain plan
Hello,
I executed the following query, and obtained the corresponding explain plan:
select * from isis.clas_rost where cour_off_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS 2 10 1540
TABLE ACCESS BY INDEX ROWID ISIS CLAS_ROST 2 10 1540
INDEX RANGE SCAN ISIS CLAS_ROST_N2 1 10
I don't understand how these cost values add up. What is the significance of the cost in each row of the explain plan output?
By comparison, here is another plan output for the following query:
select * from isis.clas_rost where clas_rost_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS 1 1 154
TABLE ACCESS BY INDEX ROWID ISIS CLAS_ROST 1 1 154
INDEX UNIQUE SCAN ISIS CLAS_ROST_U1 1 1
Thanks!For the most part, you probably want to ignore the cost column. The cardinality column is generally what you want to pay attention to.
Ideally, the cost column is Oracle's estimate of the amount of work that will be required to execute a query. It is a unitless value that attempts to combine the cost of I/O and CPU (depending on the Oracle version and whether CPU costing is enabled) and to scale physical and logical I/O appropriately). As a unitless number, it doesn't really relate to something "real" like the expected number of buffer gets. It is also determined in part by initialization parameters,session settings, system statistics, etc. that may artificially increase or decrease the cost of certain operations.
Beyond that, however, cost is problematic because it is only as accurate as the optimizer's estimates. If the optimizer's estimates are accurate, that implies that the cost is reasonably representative (in the sense that a query with a cost of 200 will run in less time than a query with a cost of 20000). But if you're looking at a query plan, it's generally because you believe there may be a problem which means that you are inherently suspicious that some of the optimizer's estimates are incorrect. If that's the case, you should generally distrust the cost.
Justin -
Explain Plan from TKPROF trace file.
Hello,
My procedure is taking time for that i have trace on in procedure fo find explain plan of particular query.
Using below statement Trace is on.
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE = TRUE';
EXECUTE IMMEDIATE 'ALTER SESSION SET TIMED_STATISTICS = TRUE';Now for getting expalin plan from TKPROF i have used below statement but for some query i have found explain paln and some case i cant found explain plan.
tkprof mf_ora_23773.trc mf_ora_23773.txt explain =abc/abc
can u please help me to analyze where i m wrong?
Thanks.First of all, you should best avoid using the explain= clause on the tkprof command line.
This will run explain plan on the statement in the trace file, and that explain plan can even be wrong, as there is no information on datatypes in the trace file.
The real explain plan data is flushed to the trace file, when the program issues commit or rollback. Oracle always issues an implicit commit when the program disconnects, so when you run the program to completion you should have explain plan output in your trace files.
You won't get explain plan output if you don't have access to the objects in the SQL statement. Also recursive SQL won't produce explain plan result.
One would need to see part of your trace file to verify your assertion the explain clause doesn't always work.
Sybrand Bakker
Senior Oracle DBA -
Looking for a book or link to understand indexes stats an explain plan
Please,
Where could I find a good book or link to leran more about indexes statistics:
My Concerns are:
How could I know indexes in the database that are most used,less used and used at all in order to get rid of the last one?
A book or link to fully undertstand how to analyze explain plan give some advices from that.
Thank a lot for your coperationThere is any link where I can find how to analyze explain plan output?Again, the manuals are usually a good place to start:
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231 -
The goal is to obtain the overall system statistics and explain plans for the entire system.
1. The only tool that I can think of is "StatsPack".
2. With AWR there are 2 issues:-
a. It is not free
b. It does not give Explain plan output.
3. We can use 10046 / 10053 Trace's however it wont give you as comphrehensive an output as statspack, you would also have to enable trace for each individual application while its running, grab the trace file, look at the report.
4. We can also use outlines to store the explain plan this was primarily for Oracle version 10g.
5. The last option we have is sql managed baselines. This is good , however it does not tell me conclusively how my system was executing a sql lets say 10 days back. It wont accept the new sql unless we promote it. Still there is no guarantee that the underlying sql plan will not change.
So far statspack with level 6 appears to be the only solution.Personally I'd spend the money and get AWR.
The problem with StatsPack is that when you run it, after an issue, it is too late to capture anything of value. With AWR snapshots are taken as often as you wish, 24 hours a day, and then when someone tells you there was a problem at 4:15 in the morning ... you have something to work with. -
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/ -
Explain Plan not showing correct results.
Hi Gurus,
Please help me to understand below issue.
Whenever I am doing explain plan on any of the sql statements it says as explained but when retriving the explain plan output it shows same results again and again.
DB - 11gR2 Stand alone
ASM - Configured.
OS - RHEL 6.2.
SQL> select count(*) from t2114;
COUNT(*)
639292
SQL> explain plan for select count(*) from t2114;
Explained.
SQL> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 1497650422
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 1 | SORT ORDER BY | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| T2210 | 6634 | 524K| 2947 (17)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T2210_T | 6842 | | 108 (22)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("T2210"."C490008000"=:SYS_B_0 AND "T2210"."C490009100"=:SYS_B_2
AND "T2210"."C301363300"=TO_NUMBER(:SYS_B_1))
16 rows selected.
SQL> explain plan for
2 SELECT T2114.C1 FROM T2114 WHERE ((T2114.C1000000001 = :"SYS_B_0") AND (T2114.C536871442 = :"SYS_B_1") AND (T2114.C536871477 = :"SYS_B_2") AND ((:"SYS_B_3" - T2114.C3) >= :"SYS_B_4") AND ((:"SYS_B_5" - T2114.C3) <= :"SYS_B_6") AND (T2114.C1000000217 LIKE :"SYS_B_7") AND (T2114.C536871478 < :"SYS_B_8")) ORDER BY C1000000161 DESC, :"SYS_B_9" ASC;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1497650422
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 1 | SORT ORDER BY | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| T2210 | 6634 | 524K| 2947 (17)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T2210_T | 6842 | | 108 (22)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("T2210"."C490008000"=:SYS_B_0 AND "T2210"."C490009100"=:SYS_B_2
AND "T2210"."C301363300"=TO_NUMBER(:SYS_B_1))
16 rows selected.Hi Dom,
Thanks for your immediate response.
I am getting two values for PLAN_TABLE. Please let me know if we need to drop any of them??
SQL> SELECT *
FROM all_objects
WHERE object_name = 'PLAN_TABLE'; 2 3
OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE CREATED LAST_DDL_TIME TIMESTAMP STATUS T G S NAMESPACE EDITION_NAME
PUBLIC PLAN_TABLE 5127 SYNONYM 17-SEP-11 17-SEP-11 2011-09-17:09:47:47 VALID N N N 1
ARADMIN PLAN_TABLE 219426 219426 TABLE 07-APR-13 07-APR-13 2013-04-07:23:01:12 VALID N N N 1 -
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. -
Understand the output of explain plan
I am trying to understand the output of explain plan. I have 2 plans below and don't understand it completely.
In below SQL I would expect optimizer to fetch "ROWNUM < 500" first and then do the outer join. But below explain plan doesn't list it as No. 1. So I don't really understand how to intepret the sequence from the explain plan:
select TASK0_.TASK_ID from
( select TASK0_.TASK_ID from
( select task0_.task_id from task task0_) TASK0_ where ROWNUM < 500 ) TASK0_
left outer join f_message_task task0_1_ on task0_.task_id=task0_1_.task_id
left outer join b_a_task task0_2_ on task0_.task_id=task0_2_.task_id
left outer join i_task task0_3_ on task0_.task_id=task0_3_.task_id
left outer join o_task task0_4_ on task0_.task_id=task0_4_.task_id
left outer join r_transmission_task task0_5_ on task0_.task_id=task0_5_.task_id
left outer join s_error_task task0_6_ on task0_.task_id=task0_6_.task_id
PLAN_TABLE_OUTPUT
Plan hash value: 707970537
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 499 | 19461 | 1042 (6)| 00:00:13 |
|* 1 | HASH JOIN OUTER | | 499 | 19461 | 1042 (6)| 00:00:13 |
|* 2 | HASH JOIN OUTER | | 499 | 16966 | 757 (6)| 00:00:10 |
| 3 | NESTED LOOPS OUTER | | 499 | 14471 | 589 (4)| 00:00:08 |
| 4 | NESTED LOOPS OUTER | | 499 | 12475 | 588 (4)| 00:00:08 |
| 5 | NESTED LOOPS OUTER | | 499 | 10479 | 588 (4)| 00:00:08 |
| 6 | NESTED LOOPS OUTER | | 499 | 8982 | 588 (4)| 00:00:08 |
| 7 | VIEW | | 499 | 2495 | 588 (4)| 00:00:08 |
|* 8 | COUNT STOPKEY | | | | | |
| 9 | INDEX FAST FULL SCAN| PK_TASK | 697K| 3403K| 588 (4)| 00:00:08 |
|* 10 | INDEX UNIQUE SCAN | PK_r_TRANSMISSION | 1 | 13 | 0 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | PK_b_a_TASK | 1 | 3 | 0 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | PK_s_ERROR_TASK | 1 | 4 | 0 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | PK_i_TASK | 1 | 4 | 0 (0)| 00:00:01 |
| 14 | INDEX FAST FULL SCAN | PK_o_TASK | 347K| 1695K| 161 (6)| 00:00:02 |
| 15 | INDEX FAST FULL SCAN | PK_f_MESSAGE | 392K| 1917K| 276 (4)| 00:00:04 |
Predicate Information (identified by operation id):
1 - access("TASK0_"."TASK_ID"="TASK0_1_"."TASK_ID"(+))
2 - access("TASK0_"."TASK_ID"="TASK0_4_"."TASK_ID"(+))
8 - filter(ROWNUM<500)
10 - access("TASK0_"."TASK_ID"="TASK0_5_"."TASK_ID"(+))
11 - access("TASK0_"."TASK_ID"="TASK0_2_"."TASK_ID"(+))
12 - access("TASK0_"."TASK_ID"="TASK0_6_"."TASK_ID"(+))
13 - access("TASK0_"."TASK_ID"="TASK0_3_"."TASK_ID"(+))
In below SQL I expect rownum to be applied at the end but it gets applied first:
select * from ( select TASK0_.TASK_ID from ( select task0_.task_id from task task0_
left outer join f_message_task task0_1_ on task0_.task_id=task0_1_.task_id
left outer join b_a_task task0_2_ on task0_.task_id=task0_2_.task_id
left outer join i_task task0_3_ on task0_.task_id=task0_3_.task_id
left outer join o_task task0_4_ on task0_.task_id=task0_4_.task_id
left outer join r_t_task task0_5_ on task0_.task_id=task0_5_.task_id
left outer join s_error_task task0_6_ on task0_.task_id=task0_6_.task_id
) TASK0_ where ROWNUM < 500 ) TASK0_;
PLAN_TABLE_OUTPUT
Plan hash value: 673345378
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 499 | 6487 | 507 (1)| 00:00:07 |
| 1 | VIEW | | 499 | 6487 | 507 (1)| 00:00:07 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | NESTED LOOPS OUTER | | 501 | 19539 | 507 (1)| 00:00:07 |
| 4 | NESTED LOOPS OUTER | | 501 | 17034 | 5 (20)| 00:00:01 |
| 5 | NESTED LOOPS OUTER | | 501 | 15030 | 5 (20)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 501 | 13026 | 5 (20)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 501 | 11523 | 5 (20)| 00:00:01 |
| 8 | NESTED LOOPS OUTER | | 501 | 5010 | 5 (20)| 00:00:01 |
| 9 | INDEX FAST FULL SCAN| PK_TASK | 499 | 2495 | 2 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | PK_o_TASK | 1 | 5 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | PK_r_T | 1 | 13 | 0 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | PK_b_a_TASK | 1 | 3 | 0 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | PK_s_ERROR_TASK | 1 | 4 | 0 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | PK_i_TASK | 1 | 4 | 0 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PK_f_MESSAGE | 1 | 5 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(ROWNUM<500)
10 - access("TASK0_"."TASK_ID"="TASK0_4_"."TASK_ID"(+))
11 - access("TASK0_"."TASK_ID"="TASK0_5_"."TASK_ID"(+))
12 - access("TASK0_"."TASK_ID"="TASK0_2_"."TASK_ID"(+))
13 - access("TASK0_"."TASK_ID"="TASK0_6_"."TASK_ID"(+))
14 - access("TASK0_"."TASK_ID"="TASK0_3_"."TASK_ID"(+))
15 - access("TASK0_"."TASK_ID"="TASK0_1_"."TASK_ID"(+))Edited by: user628400 on Feb 20, 2009 12:14 PM
Edited by: user628400 on Feb 20, 2009 12:15 PMPlease read the FAQ: http://forums.oracle.com/forums/help.jspa
And learn how to post code and explain plans using the tags. -
Help in interpreting the output of explain plan
Hi,
I have written a query in two different ways and then run an explain plan on both of them. Both these queries give same result. I want to know which one will be more efficient. I am giving the output of explain plan for both the queries:
The second plan has a lower cost but has much higher consistent gets !!
Please advise.
Plan 1:
Execution Plan
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=8637 Card= 1 Bytes=10132)
1 0 SORT (ORDER BY) (Cost=8637 Card=1 Bytes=10132)
2 1 WINDOW (SORT) (Cost=8637 Card=1 Bytes=10132)
3 2 COUNT (STOPKEY)
4 3 VIEW (Cost=8635 Card=1 Bytes=10132)
5 4 SORT (ORDER BY) (Cost=8635 Card=1 Bytes=862)
6 5 WINDOW (SORT) (Cost=8635 Card=1 Bytes=862)
7 6 MAT_VIEW ACCESS (FULL) OF 'PRD_SEARCH_MVW' (MAT_VIEW) (Cost=8633 Card=1 Bytes=862)
Statistics
577 recursive calls
0 db block gets
39202 consistent gets
34798 physical reads
0 redo size
72348 bytes sent via SQL*Net to client
4295 bytes received via SQL*Net from client
9 SQL*Net roundtrips to/from client
10 sorts (memory)
0 sorts (disk)
100 rows processed
Plan-2
Execution Plan
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=982 Card=1 Bytes=10145)
1 0 SORT (ORDER BY) (Cost=982 Card=1 Bytes=10145)
2 1 WINDOW (SORT) (Cost=982 Card=1 Bytes=10145)
3 2 COUNT (STOPKEY)
4 3 VIEW (Cost=980 Card=1 Bytes=10145)
5 4 SORT (ORDER BY) (Cost=980 Card=1 Bytes=10132)
6 5 WINDOW (SORT) (Cost=980 Card=1 Bytes=10132)
7 6 WINDOW (SORT) (Cost=980 Card=1 Bytes=10132)
8 7 VIEW (Cost=977 Card=1 Bytes=10132)
9 8 WINDOW (SORT PUSHED RANK) (Cost=977 Card=1 Bytes=889)
10 9 NESTED LOOPS (Cost=976 Card=1 Bytes=889)
11 10 HASH JOIN (Cost=305 Card=670 Bytes=18090)
12 11 HASH JOIN (Cost=23 Card=140 Bytes=2240)
13 12 INDEX (FAST FULL SCAN) OF 'GLCAT_GRP_TO_CAT_PK' (INDEX (UNIQUE)) (Cost=2 Card=52 Bytes=364)
14 12 MAT_VIEW ACCESS (FULL) OF 'GLCAT_CAT_TO_MCAT' (MAT_VIEW) (Cost=20 Card=1039 Bytes=9351)
15 11 INDEX (FAST FULL SCAN) OF 'PCITEM2GLCATMCAT_FK_IDS' (INDEX) (Cost=281 Card=16903 Bytes=185933)
16 10 MAT_VIEW ACCESS (BY INDEX ROWID) OF 'PRD_SEARCH_MVW' (MAT_VIEW) (Cost=1 Card=1 Bytes=862)
17 16 INDEX (UNIQUE SCAN) OF 'PK_PRD_SEARCH_ID' (INDEX (UNIQUE)) (Cost=0 Card=1)
Statistics
481 recursive calls
2 db block gets
195742 consistent gets
7516 physical reads
0 redo size
71567 bytes sent via SQL*Net to client
6629 bytes received via SQL*Net from client
9 SQL*Net roundtrips to/from client
15 sorts (memory)
1 sorts (disk)
100 rows processedRegards
Madhup
Message was edited by:
MadhupThanks a lot for you input. I am posting both the queries below. My requirements are following:
1) I have a products table
2) I have Created grouping hierarchy - Groups, Categories and then Micro-categories - and have setup a separate table for each of them in my database
3) Then I have mapping tables, i.e. a table that stores group to category mapping, another table that stores category to micro-category mapping.
4) Products are mapped directly to micro-categories and one product could be mapped to multiple micro-categories.
5) I have created a materialized view on product and store the mappings as comma separated list of IDs - I have three fields there, on to store comma separated group id, second to store comma separated category ids and third to store the comma separated micro category ids to which the product is mapped.
Now I want to write a query that will return a specified number of matches from this table based on user defined criterion. There are few other filter cirterion apart from Group/Category and Microcategory. These are Company Name, Country, Type of company etc.
This query when run on production will be accessed very frequently - I expect the access to be in the tune of around 5-10 times per second.
There are 50 records in the group table
There are 500 categories
There are 20000 micro-categories
Group to category mapping table has around 1000 records
Category to microcategory table has around 25000 records
The product table has around 100,000 products.
Product to microcategory mapping table has 350000 records
The product mview has the same number of records as that in products table.
The first query uses the single materialized view to access data, however, it always does a full table scan and does not use any index.
When I noticed this in the explain plan, then I tried to write the second query which is using JOINs to arrive at the same output.
The explain plan now says that it is using Index scans.
I did a sample run of both the queries on my production system and I had to withdraw both of them as both brought my system to grinding halt within few minutes of going live.
My system at present receives around 3000 requests per hour during peak load and around 600 requests per hour during off-peak hours.
And I was testing these queries in Off-peak hours !!
Here are the two sql queries just for reference - there are several variables plugged in where clause which are the key drivers of the query:
SQL-1
SELECT DECODE(:OPT,2,A.SC,(MAX(A.SC) OVER (PARTITION BY A.PRD_SEARCH_COMPANY))) AS SO,
A.SC, A.PRD_SEARCH_ID,
A.PRD_SEARCH_COMPANY_ID, A.PRD_SEARCH_COMPANY, A.PRD_SEARCH_COMPANYID_ENCRYPTED,
A.PRD_SEARCH_PCID, A.PRD_SEARCH_URL, A.PRD_SEARCH_PC_CLNT_HOME,
A.PRD_SEARCH_CLNT_ENABLED, A.PRD_SEARCH_CODE, A.PRD_SEARCH_NAME,
A.PRD_SEARCH_DESC_SMALL, A.PRD_SEARCH_DESC_DETAILED, A.PRD_SEARCH_DESC_HTML,
A.PRD_SEARCH_IMG_SMALL, A.PRD_SEARCH_IMG_LARGE, A.PRD_SEARCH_WEIGHT_ITEM,
A.PRD_SEARCH_MODIFIEDDATE, A.PRD_SEARCH_SIZE, A.PRD_SEARCH_LABEL1,
A.PRD_SEARCH_LABEL1_VALUE, A.PRD_SEARCH_LABEL2, A.PRD_SEARCH_LABEL2_VALUE,
A.PRD_SEARCH_LABEL3, A.PRD_SEARCH_LABEL3_VALUE, A.PRD_SEARCH_LABEL4,
A.PRD_SEARCH_LABEL4_VALUE, A.PRD_SEARCH_LABEL5, A.PRD_SEARCH_LABEL5_VALUE,
A.PRD_SEARCH_LABEL6, A.PRD_SEARCH_LABEL6_VALUE, A.PRD_SEARCH_CAT_ID,
A.PRD_SEARCH_CAT_NAME, A.PRD_SEARCH_CAT_FLNAME, A.PRD_SEARCH_NAVIGATION_TREE,
A.PRD_SEARCH_NAVIGATION_TREE_ID,A.PRD_SEARCH_CITY, A.PRD_SEARCH_STATE,
A.PRD_SEARCH_COUNTRY, A.PRD_SEARCH_PRICE_SALE, A.PRD_SEARCH_PC_CLNT_TYPE,
A.PRD_SEARCH_PC_CLNT_TYPE_DESC,
A.PRD_SEARCH_COMPANY_PHONE, A.PRD_SEARCH_COMPANY_MOBILE, A.PRD_SEARCH_COMPANY_FAX,
A.PRD_SEARCH_COMPANY_EMAIL, A.PRD_SEARCH_GLCAT_MCAT_ID_LIST, A.PRD_SEARCH_GLCAT_CAT_ID_LIST,
A.PRD_SEARCH_GLCAT_GRP_ID_LIST, A.PRD_SEARCH_GL_COUNTRY_ISO, A.PRD_SEARCH_GLUSR_USR_ID,
A.PRD_SEARCH_TRUSTSEAL_CODE, A.PRD_SEARCH_CUSTTYPE_ID, A.PRD_SEARCH_CUSTTYPE_NAME,
A.PRD_SEARCH_CUSTTYPE_WEIGHT, A.PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, A.PRD_SEARCH_CUSTTYPE_RANK,
A.PRD_SEARCH_PC_ITEM_HOTNEW, A.RK
FROM
(SELECT /*+ FIRST_ROWS (500) */ DECODE(:S_MODE,2,1,3,to_number(to_char(PRD_SEARCH_MODIFIEDDATE,'yyyymmdd')),1) AS SC,
PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW,
ROW_NUMBER() OVER (PARTITION BY PRD_SEARCH_COMPANY_ID
ORDER BY DECODE(:S_MODE,2,1,3,to_number(to_char(PRD_SEARCH_MODIFIEDDATE,'yyyymmdd')),1) DESC) AS RK
FROM PRD_SEARCH
WHERE DECODE(:GRP_ID_STR,NULL,1,REGEXP_INSTR(','||REPLACE(PRD_SEARCH_GLCAT_GRP_ID_LIST,' ','')||',',:MYGRP_ID_STR)) > 0
AND DECODE(:CAT_ID_STR,NULL,1,REGEXP_INSTR(','||REPLACE(PRD_SEARCH_GLCAT_CAT_ID_LIST,' ','')||',',:MYCAT_ID_STR)) > 0
AND DECODE(:MCAT_ID_STR,NULL,1,REGEXP_INSTR(','||REPLACE(PRD_SEARCH_GLCAT_MCAT_ID_LIST,' ','')||',',:MYMCAT_ID_STR)) > 0
AND DECODE(:ITEM_ID_STR,NULL,1,REGEXP_INSTR(','||PRD_SEARCH_ID||',',:MYITEM_ID_STR)) > 0
AND DECODE(:COUNTRY_ISO,NULL,1,REGEXP_INSTR(','||PRD_SEARCH_GL_COUNTRY_ISO||',',:COUNTRY_ISO)) > 0
AND DECODE(nvl(NULL,0),0,1,PRD_SEARCH_COMPANY_ID) = DECODE(nvl(NULL,0),0,1,NULL)
AND DECODE(nvl(NULL,0),0,1,PRD_SEARCH_GLUSR_USR_ID) = DECODE(nvl(NULL,0),0,1,NULL)
AND PRD_SEARCH_CLNT_ENABLED >= nvl(:LIST_TYPE,0)
AND NVL(Length(PRD_SEARCH_TRUSTSEAL_CODE),0) >= :TSONLY
ORDER BY SC DESC, PRD_SEARCH_CUSTTYPE_WEIGHT ASC, DBMS_RANDOM.RANDOM
) A
WHERE A.RK <= :MY_PRD_PER_COMP
AND ROWNUM <= :MYMAXREC
ORDER BY SO DESC, DECODE(:OPT,2,'1',A.PRD_SEARCH_COMPANY), A.RK ASC, DBMS_RANDOM.RANDOM
SQL-2
SELECT
DECODE(:OPT,2,SC,(MAX(SC) OVER (PARTITION BY PRD_SEARCH_COMPANY))) AS SO,
SC, PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW, RK
FROM
SELECT
/*+ FIRST_ROWS (500) */ DECODE(:OPT,2,SC,(MAX(SC) OVER (PARTITION BY PRD_SEARCH_COMPANY))) AS SO,
SC,PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW,
ROW_NUMBER() OVER (PARTITION BY PRD_SEARCH_COMPANY_ID
ORDER BY DECODE(:S_MODE,2,1,3,TO_NUMBER(TO_CHAR(PRD_SEARCH_MODIFIEDDATE,'YYYYMMDD')),1) DESC) AS RK
FROM
SELECT
DECODE(:S_MODE,2,1,3,TO_NUMBER(TO_CHAR(PRD_SEARCH_MODIFIEDDATE,'YYYYMMDD')),1) AS SC,
PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW,
ROW_NUMBER() OVER (PARTITION BY P.PRD_SEARCH_ID ORDER BY P.PRD_SEARCH_ID) RK1
FROM
GLCAT_GRP_TO_CAT G2C, GLCAT_CAT_TO_MCAT C2M, PC_ITEM_TO_GLCAT_MCAT M, PRD_SEARCH P
WHERE
G2C.FK_GLCAT_CAT_ID = C2M.FK_GLCAT_CAT_ID
AND C2M.FK_GLCAT_MCAT_ID = M.FK_GLCAT_MCAT_ID
AND M.FK_PC_ITEM_ID = P.PRD_SEARCH_ID
AND DECODE(:MCAT_ID_STR, NULL, 1, INSTR(','||:MCAT_ID_STR||',',','||M.FK_GLCAT_MCAT_ID||',',1))> 0
AND DECODE(:CAT_ID_STR, NULL, 1, INSTR(','||:CAT_ID_STR||',',','||C2M.FK_GLCAT_CAT_ID||',',1)) > 0
AND DECODE(:GRP_ID_STR, NULL, 1, INSTR(','||:GRP_ID_STR||',',','||G2C.FK_GLCAT_GRP_ID||',',1)) > 0
AND DECODE(:ITEM_ID_STR,NULL,1,INSTR(','||:ITEM_ID_STR||',' , ','||P.PRD_SEARCH_ID||',')) > 0
AND DECODE(:COUNTRY_ISO,NULL,1,INSTR(','||:COUNTRY_ISO||',', ','||P.PRD_SEARCH_GL_COUNTRY_ISO||',')) > 0
AND DECODE(NVL(:COMPANY_ID,0),0,1,P.PRD_SEARCH_COMPANY_ID) = DECODE(NVL(:COMPANY_ID,0),0,1,:COMPANY_ID)
AND DECODE(NVL(:GLUSR_ID,0),0,1,P.PRD_SEARCH_GLUSR_USR_ID) = DECODE(NVL(:GLUSR_ID,0),0,1,:GLUSR_ID)
AND P.PRD_SEARCH_CLNT_ENABLED >= NVL(:LIST_TYPE,0)
AND NVL(LENGTH(P.PRD_SEARCH_TRUSTSEAL_CODE),0) >= :TSONLY
WHERE RK1=1
ORDER BY SC DESC, PRD_SEARCH_CUSTTYPE_WEIGHT ASC, DBMS_RANDOM.RANDOM
) A
WHERE A.RK <= :MY_PRD_PER_COMP
AND ROWNUM <= :MYMAXREC
ORDER BY A.SO DESC, DECODE(:OPT,2,'1', A.PRD_SEARCH_COMPANY), A.RK ASC, DBMS_RANDOM.RANDOMRegards
Madhup -
Formatting html file for an explain plan.
Hi,
I would like to create a formatting html file for an explain plan.
Oracle 11.2.0.3 on Linux.
I can't use DBMS_XPLAN.DISPLAY_PLAN beacuse I get the info from the memory cursor and and I can't set the statement_id.
How can I do that?user10931224 wrote:
Hi,
I would like to create a formatting html file for an explain plan.
Oracle 11.2.0.3 on Linux.
I can't use DBMS_XPLAN.DISPLAY_PLAN beacuse I get the info from the memory cursor and and I can't set the statement_id.
How can I do that?
does SQL_ID reside within AWR repository? -
Help with interpreting explain plan (dbms_xplan) output
Hi all,
I'm trying to get to grips with reading and interpreting the explain plan or dbms_xplan output, and so I hope someone can help with the output below.
So, with the explain shown below, does it mean that...
a) it starts with step 8 and sends all rows to the nested loop in step 5
b) it only sends (or thinks it sends) 1 row to step 5 from step 8
c) For each row supplied from step 5, there will be an index lookup at step 8 to access the table at step 6
d) Step 8 only gets (or think it gets) 1 row
If it does mean that only 1 row is expected by the optimizer, and yet the full table scan should return 150,000 records, and the table has up to date statistiucs, what else would cause the cardinality to be so far off?
If it doesn't mean it will return 1 row then what does it mean ?
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 945 (100)| |
| 1 | SORT GROUP BY | | 1 | 283 | 945 (3)| 00:00:05 |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 283 | 944 (3)| 00:00:05 |
| 5 | NESTED LOOPS | | 1 | 108 | 929 (3)| 00:00:05 |
|* 6 | MAT_VIEW ACCESS FULL | DEMOGRAPHICS_MV | 1 | 97 | 927 (3)| 00:00:05 |
|* 7 | MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV | 1 | 11 | 2 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | ORG_MV_IDX1 | 1 | | 1 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PAY_IDX8 | 252 | | 4 (0)| 00:00:01 |
|* 10 | TABLE ACCESS BY INDEX ROWID | PAY_ALL | 1 | 175 | 15 (0)| 00:00:01 |
Predicate Information (identified by operation id):
8 - access("ORG_MV"."ORG_ID"="DEMO_MV"."ORG_ID")Many thanks for your help.Thank you Hemant and rp0428,
I read through that white paper which was really useful.
I ran query using GATHER_PLAN_STATISTICS and go tthe Estimate and Actual rows - wow - it is a long way out!!
| Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | | 945 (100)| | 0 |00:18:11.39 | 2552K| 361K| | | |
| 1 | SORT GROUP BY | | 1 | 1 | 283 | 945 (3)| 00:00:05 | 0 |00:18:11.39 | 2552K| 361K| 1024 | 1024 | |
|* 2 | FILTER | | 1 | | | | | 0 |00:18:11.39 | 2552K| 361K| | | |
| 3 | NESTED LOOPS | | 1 | | | | | 0 |00:18:11.39 | 2552K| 361K| | | |
| 4 | NESTED LOOPS | | 1 | 1 | 283 | 944 (3)| 00:00:05 | 44M|00:04:59.03 | 598K| 63442 | | | |
| 5 | NESTED LOOPS | | 1 | 1 | 108 | 929 (3)| 00:00:05 | 109K|00:00:01.73 | 7807 | 7 | | | |
|* 6 | MAT_VIEW ACCESS FULL | DEMOGRAPHICS_MV | 1 | 1 | 97 | 927 (3)| 00:00:05 | 126K|00:00:00.26 | 5417 | 1 | | | |
|* 7 | MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV | 126K| 1 | 11 | 2 (0)| 00:00:01 | 109K|00:00:01.27 | 2390 | 6 | | | |
|* 8 | INDEX RANGE SCAN | ORG_MV_IDX1 | 126K| 1 | | 1 (0)| 00:00:01 | 126K|00:00:00.69 | 2023 | 6 | | | |
|* 9 | INDEX RANGE SCAN | PAY_IDX8 | 109K| 252 | | 4 (0)| 00:00:01 | 44M|00:04:03.07 | 590K| 63435 | | | |
|* 10 | TABLE ACCESS BY INDEX ROWID | PAY_ALL | 44M| 1 | 175 | 15 (0)| 00:00:01 | 0 |00:13:09.85 | 1954K| 297K| | | |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------When I unravel the WHERE clause and remove the decode(nvl statements (which only evaluate the passed in parameters and provide default values where they are NULL) I get a much better plan and values
| Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | | 157K(100)| | 0 |00:00:43.10 | 343K| 45190 | | | |
| 1 | SORT GROUP BY | | 1 | 1 | 283 | 157K (1)| 00:13:47 | 0 |00:00:43.10 | 343K| 45190 | 1024 | 1024 | |
| 2 | NESTED LOOPS | | 1 | | | | | 0 |00:00:43.10 | 343K| 45190 | | | |
| 3 | NESTED LOOPS | | 1 | 1 | 283 | 157K (1)| 00:13:47 | 0 |00:00:43.10 | 343K| 45190 | | | |
|* 4 | HASH JOIN | | 1 | 1 | 272 | 157K (1)| 00:13:47 | 0 |00:00:43.10 | 343K| 45190 | 720K| 720K| 171K (0)|
|* 5 | TABLE ACCESS BY INDEX ROWID | PAY_ALL | 1 | 2 | 350 | 156K (1)| 00:13:43 | 0 |00:00:43.10 | 343K| 45190 | | | |
|* 6 | INDEX RANGE SCAN | PAY_IDX7 | 1 | 3596K| | 15565 (1)| 00:01:22 | 7251K|00:00:50.88 | 45190 | 45190 | | | |
|* 7 | MAT_VIEW ACCESS FULL | DEMOGRAPHICS_MV | 0 | 126K| 11M| 919 (2)| 00:00:05 | 0 |00:00:00.01 | 0 | 0 | | | |
|* 8 | INDEX RANGE SCAN | ORG_MV_IDX1 | 0 | 1 | | 1 (0)| 00:00:01 | 0 |00:00:00.01 | 0 | 0 | | | |
|* 9 | MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV | 0 | 1 | 11 | 2 (0)| 00:00:01 | 0 |00:00:00.01 | 0 | 0 | | | |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Even though the result set is zero, the time to establish this came down from 35 minutes to 30 seconds and the plan has changed and is using a different index now!
Thanks for your help!
Maybe you are looking for
-
What happened to the Get/Set Date and Time utilities from RT 7.1?
I'd like to use the Get/Set Date and Time utilities that were available in 7.1, but disappeared after that. I see that the 7.1 utilites call a dll that does not appear to be installed with LabVIEW RT 8 and later. What do I need to do to use the util
-
Messages sending to iPhone as SMS instead of iMessage
I have an iPhone 6 Plus running iOS 8.3 and a MacBook Pro 17" running OS X Yosemite (10.10.2). My wife has an iPhone 6 and a MacBook running an older version of OS X. Occasionally when I try to send her an iMessage using the OS X Messages app, it tri
-
Trying to update my apps through iTunes, and I keep getting an -50 download error on all of them. I don't know if this is related but on top of idiots refusing to sync the iPad these apps are on as well. What's causing this and is there a way to fix
-
Great converter program for Mac
I have a ton of wmv files for professional presentations from my 'pre-Mac' days, and because work computers are Windows based. One of my friends with the same issues of needing to edit wmv on her Mac recommended iSkysoft Video Converter - it's about
-
F.27 Account statement form name
Hello All: Very new to the SAP form world, any help will be greatly appreciated! I want to get the form that's print from the current F.27 Customer Account statement function. I debug the RFKORK00 function and couldn't find anything that indi