Tuning SQL
I have a SQL statement that has a cpu execution time of 11 second, but a lapse time of 52 seconds. The query does 32105 physical disk reads and the number of buffers read for consistent reads is 303304. The statement uses all relavent indices. How do I reduce the lapse time for a statement?
You have to tune your query. It means that the query spent some time waiting for some thing. In this case it really waited for the physical i/o to complete. The use/non-use of the index depends on a lot of factors
(for example, Optimizer_mode or DB_FILE_MULTIBLOCK_READ_COUNT or sort area size). Using index to retrieve data may not always be the best option.
Similar Messages
-
Hi list ,
I need your help in tuning this sql.
Oracle 10g,Windows 2008 64 bit running on virtual machine.
SELECT t0.RecID, t0.PrtID, t0.RecOrdDt, t0.RecOrdID, t0.RecExtOrdID, t0.RecPocID, t0.PriID, t0.CasID, t0.CasNo, t0.CasClass, t0.CasPocID, t0.CasAdmit, t0.CasNotValid, t0.PatName, t0.PatFName, t0.PatBName, t0.PatBDate, t0.PatSex, t0.PatNotValid, t0.RstID, t0.RstState, t0.RstMeaningI18N, t0.PrtType, t0.PrtSubType, t0.RpxType, t0.RpxPrio, t0.PerID, t0.PerName, t0.PerFName, t0.PerTitle, t0.PerType, t0.AgnExtID
FROM
IXSERV.XsvRecPerInfoV t0
WHERE
((((t0.AgnExtID = '1728454694') AND (t0.PrtID IN (72, 165)))
AND (t0.RpxType IN (1, 2, 6, 3, 5)))
AND (t0.RstState IN (202, 208, 210, 203, 206)))
call count cpu elapsed disk query current rows
Parse 1 0.04 0.03 0 1999 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 4 5.39 57.42 45408 53080 0 45
total 6 5.43 57.46 45408 55079 0 45
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
45 NESTED LOOPS (cr=53080 pr=45408 pw=0 time=2611987 us)
45 NESTED LOOPS (cr=52941 pr=45355 pw=0 time=46145568 us)
45 HASH JOIN (cr=52802 pr=45314 pw=0 time=45407144 us)
1 TABLE ACCESS BY INDEX ROWID PERPERSON (cr=3 pr=6 pw=0 time=40510 us)
1 INDEX RANGE SCAN PERIDXAGNEXTID (cr=2 pr=5 pw=0 time=22311 us)(object id 56817)
23623 TABLE ACCESS BY INDEX ROWID XSVRECPERXREF (cr=52799 pr=45308 pw=0 time=50046345 us)
33893 NESTED LOOPS (cr=47543 pr=42261 pw=0 time=73003406 us)
5139 HASH JOIN (cr=37184 pr=40103 pw=0 time=56090695 us)
5 TABLE ACCESS FULL XMFREPORTSTATE (cr=7 pr=6 pw=0 time=22565 us)
66900 TABLE ACCESS BY INDEX ROWID XSVPATIENTRECORD (cr=37177 pr=40097 pw=0 time=39887547 us)
66903 NESTED LOOPS (cr=146 pr=141 pw=0 time=8095232 us)
2 INLIST ITERATOR (cr=4 pr=3 pw=0 time=37200 us)
2 TABLE ACCESS BY INDEX ROWID XMFPATIENTRECORDTYPE (cr=4 pr=3 pw=0 time=37198 us)
2 INDEX UNIQUE SCAN PKPRT (cr=2 pr=1 pw=0 time=26746 us)(object id 56143)
66900 INDEX RANGE SCAN RECIDXPRTID (cr=142 pr=138 pw=0 time=51513 us)(object id 56410)
28753 INDEX RANGE SCAN RPXIDXRECID (cr=10359 pr=2158 pw=0 time=4518986 us)(object id 56453)
45 TABLE ACCESS BY INDEX ROWID ADTCASE (cr=139 pr=41 pw=0 time=423483 us)
45 INDEX UNIQUE SCAN PK_ADTCASE (cr=94 pr=23 pw=0 time=184866 us)(object id 55295)
45 TABLE ACCESS BY INDEX ROWID ADTPATIENT (cr=139 pr=53 pw=0 time=413067 us)
45 INDEX UNIQUE SCAN PK_ADTPATIENT (cr=94 pr=21 pw=0 time=195583 us)(object id 55361)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net break/reset to client 2 0.00 0.00
SQL*Net message to client 5 0.00 0.00
SQL*Net message from client 5 114.42 128.67
SQL*Net more data to client 1 0.00 0.00
db file sequential read 27969 0.13 51.57
db file scattered read 3271 0.05 4.61
Some lines from trace fils :
WAIT #1: nam='db file sequential read' ela= 12778 file#=4 block#=3726132 blocks=1 obj#=56817 tim=249799016372
WAIT #1: nam='db file scattered read' ela= 9271 file#=4 block#=3726133 blocks=4 obj#=56817 tim=249799025761
WAIT #1: nam='db file sequential read' ela= 18141 file#=4 block#=587487 blocks=1 obj#=55853 tim=249799043945
WAIT #1: nam='db file sequential read' ela= 18304 file#=4 block#=752595 blocks=1 obj#=56219 tim=249799062471
and the view XsvRecPerInfoV is :
SELECT d.RecID, d.PrtID, d.RecOrdDt, d.RecOrdID, d.RecExtOrdID, d.PocID, d.PriID, c.CasID, c. CasNo, c.CasClass, c.PocID, c.CasAdmit, c.CasNotValid, p.PatName, p.PatFName, p.PatBName, p.PatBDate, p.PatSex, p.PatNotValid, r.RstID, r.RstState, r.RstMeaningI18N, prt.PrtType, prt.PrtSubType, x.RpxType, x.RpxPrio, per.PerID, per.PerName, per.PerFName, per.PerTitle, per.PerType, per.AgnExtID
FROM XsvPatientRecord d,
AdtCase c,
AdtPatient p,
XmfReportState r,
XmfPatientRecordType prt,
XsvRecPerXRef x,
PerPerson per
WHERE
d.RecID = x.RecID
AND d.RstID = r.RstID
AND d.PrtID = prt.PrtID
AND d.CasID = c.CasID
AND x.PerID = per.PerID
AND c.PatID = p.PatID
i have two questions :
-1 The problem in tables XSVPATIENTRECORD and XSVRECPERXREF so how can i speed this query either by rewriting it or indexs?
-2 is my system i-o is slow ?
Best wishes
Edited by: welo on Oct 6, 2010 5:05 AMhi ,
it did not work with dynamic samplying. I am posting here trace 10053 output for the correct plan and wrong plan choosed but the optimizer i need soome one to help me in understanding why the optimizer is choosing wrong join order.
Sql statement and wrong plan :
tageCurrent SQL statement for this session:
SELECT t0.RecID, t0.PrtID, t0.RecOrdDt, t0.RecOrdID, t0.RecExtOrdID, t0.RecPocID, t0.PriID, t0.CasID, t0.CasNo, t0.CasClass, t0.CasPocID, t0.CasAdmit, t0.CasNotValid, t0.PatName, t0.PatFName, t0.PatBName, t0.PatBDate, t0.PatSex, t0.PatNotValid, t0.RstID, t0.RstState, t0.RstMeaningI18N, t0.PrtType, t0.PrtSubType, t0.RpxType, t0.RpxPrio, t0.PerID, t0.PerName, t0.PerFName, t0.PerTitle, t0.PerType, t0.AgnExtID
FROM XsvRecPerInfoV t0
WHERE
((((t0.AgnExtID = '1393621382') AND (t0.PrtID IN (72, 165))) AND (t0.RpxType IN (1, 2, 6, 3, 5))) AND (t0.RstState IN (202, 208, 210, 203, 206)))
--------------------------------------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
--------------------------------------------------------------------+-----------------------------------+
| 0 | SELECT STATEMENT | | | | 842 | |
| 1 | NESTED LOOPS | | 1 | 204 | 842 | 00:00:11 |
| 2 | NESTED LOOPS | | 1 | 163 | 840 | 00:00:11 |
| 3 | HASH JOIN | | 1 | 129 | 838 | 00:00:11 |
| 4 | TABLE ACCESS BY INDEX ROWID | PERPERSON | 1 | 29 | 2 | 00:00:01 |
| 5 | INDEX RANGE SCAN | PERIDXAGNEXTID | 1 | | 1 | 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | XSVRECPERXREF | 2 | 34 | 3 | 00:00:01 |
| 7 | NESTED LOOPS | | 379 | 37K | 835 | 00:00:11 |
| 8 | HASH JOIN | | 238 | 19K | 342 | 00:00:05 |
| 9 | TABLE ACCESS FULL | XMFREPORTSTATE | 5 | 65 | 3 | 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | XSVPATIENTRECORD | 524 | 30K | 218 | 00:00:03 |
| 11 | NESTED LOOPS | | 1049 | 72K | 338 | 00:00:05 |
| 12 | INLIST ITERATOR | | | | | |
| 13 | TABLE ACCESS BY INDEX ROWID | XMFPATIENTRECORDTYPE| 2 | 22 | 2 | 00:00:01 |
| 14 | INDEX UNIQUE SCAN | PKPRT | 2 | | 1 | 00:00:01 |
| 15 | INDEX RANGE SCAN | RECIDXPRTID | 524 | | 119 | 00:00:02 |
| 16 | INDEX RANGE SCAN | RPXIDXRECID | 2 | | 2 | 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | ADTCASE | 1 | 34 | 2 | 00:00:01 |
| 18 | INDEX UNIQUE SCAN | PK_ADTCASE | 1 | | 1 | 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | ADTPATIENT | 1 | 41 | 2 | 00:00:01 |
| 20 | INDEX UNIQUE SCAN | PK_ADTPATIENT | 1 | | 1 | 00:00:01 |
--------------------------------------------------------------------+-----------------------------------+
3 - access("PER"."PERID"="X"."PERID")
5 - access("PER"."AGNEXTID"='1393621382')
6 - filter(("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6))
8 - access("D"."RSTID"="R"."RSTID")
9 - filter(("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210))
14 - access(("PRT"."PRTID"=72 OR "PRT"."PRTID"=165))
15 - access("D"."PRTID"="PRT"."PRTID")
15 - filter(("D"."PRTID"=72 OR "D"."PRTID"=165))
16 - access("X"."RECID"="D"."RECID")
18 - access("D"."CASID"="C"."CASID")
20 - access("C"."PATID"="P"."PATID")
Join order[7]: XMFPATIENTRECORDTYPE[PRT]#1 XSVPATIENTRECORD[D]#3 XMFREPORTSTATE[R]#2 XSVRECPERXREF[X]#5 PERPERSON[PER]#0 ADTCASE[C]#6 ADTPATIENT[P]#4
Now joining: XSVPATIENTRECORD[D]#3
NL Join
Outer table: Card: 2.00 Cost: 2.00 Resp: 2.00 Degree: 1 Bytes: 11
Inner table: XSVPATIENTRECORD Alias: D
Access Path: TableScan
NL Join: Cost: 53601.79 Resp: 53601.79 Degree: 1
Cost_io: 53336.00 Cost_cpu: 7967475433
Resp_io: 53336.00 Resp_cpu: 7967475433
kkofmx: index filter:
("D"."PRTID"=72 OR "D"."PRTID"=165) AND ("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6) AND ("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210) AND "PER"."PERID"="X"."PERID" AND "X"."RECID"="D"."RECID" AND "D"."RSTID"="R"."RSTID" AND "D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
kkofmx: index filter:"D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
kkofmx: index filter:
("D"."PRTID"=72 OR "D"."PRTID"=165) AND ("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6) AND ("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210) AND "PER"."PERID"="X"."PERID" AND "X"."RECID"="D"."RECID" AND "D"."RSTID"="R"."RSTID" AND "D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
Access Path: index (FullScan)
Index: IRECRECORDIDPRTID
resc_io: 43172.00 resc_cpu: 2118737558
ix_sel: 1 ix_sel_with_filters: 6.2392e-005
NL Join: Cost: 86121.14 Resp: 86121.14 Degree: 1
Cost_io: 85924.00 Cost_cpu: 5909611610
Resp_io: 85924.00 Resp_cpu: 5909611610
Access Path: index (AllEqJoinGuess)
Index: RECIDXPRTID
resc_io: 217.00 resc_cpu: 13774732
ix_sel: 0.0074074 ix_sel_with_filters: 6.2392e-005
NL Join (ordered): Cost: 338.30 Resp: 338.30 Degree: 1
Cost_io: 337.00 Cost_cpu: 39079056
Resp_io: 337.00 Resp_cpu: 39079056
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 338.30
resc: 338.30 resc_io: 337.00 resc_cpu: 39079056
resp: 338.30 resp_io: 337.00 resp_cpu: 39079056
Join Card: 1048.85 = outer (2.00) * inner (70797.49) * sel (0.0074074)
Join Card - Rounded: 1049 Computed: 1048.85
SM Join
Outer table:
resc: 2.00 card 2.00 bytes: 11 deg: 1 resp: 2.00
Inner table: XSVPATIENTRECORD Alias: D
resc: 13387.34 card: 70797.49 bytes: 59 deg: 1 resp: 13387.34
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 651 Row size: 75 Total Rows: 70797
Initial runs: 2 Merge passes: 1 IO Cost / pass: 354
Total IO sort cost: 1005 Total CPU sort cost: 97398867
Total Temp space used: 11969000
SM join: Resc: 14397.59 Resp: 14397.59 [multiMatchCost=0.00]
SM cost: 14397.59
resc: 14397.59 resc_io: 14389.81 resc_cpu: 233098276
resp: 14397.59 resp_io: 14389.81 resp_cpu: 233098276
HA Join
Outer table:
resc: 2.00 card 2.00 bytes: 11 deg: 1 resp: 2.00
Inner table: XSVPATIENTRECORD Alias: D
resc: 13387.34 card: 70797.49 bytes: 59 deg: 1 resp: 13387.34
using dmeth: 2 #groups: 1
Cost per ptn: 0.74 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 614 ppasses: 1
Hash join: Resc: 13390.08 Resp: 13390.08 [multiMatchCost=0.00]
HA cost: 13390.08
resc: 13390.08 resc_io: 13384.81 resc_cpu: 157767585
resp: 13390.08 resp_io: 13384.81 resp_cpu: 157767585
Best:: JoinMethod: NestedLoop
Cost: 338.30 Degree: 1 Resp: 338.30 Card: 1048.85 Bytes: 70
Now joining: XMFREPORTSTATE[R]#2
NL Join
Outer table: Card: 1048.85 Cost: 338.30 Resp: 338.30 Degree: 1 Bytes: 70
Inner table: XMFREPORTSTATE Alias: R
Access Path: TableScan
NL Join: Cost: 1489.04 Resp: 1489.04 Degree: 1
Cost_io: 1486.00 Cost_cpu: 91090703
Resp_io: 1486.00 Resp_cpu: 91090703
Access Path: index (UniqueScan)
Index: PK_XMFREPORTSTATE
resc_io: 1.00 resc_cpu: 8697
ix_sel: 0.030303 ix_sel_with_filters: 0.030303
NL Join: Cost: 1387.61 Resp: 1387.61 Degree: 1
Cost_io: 1386.00 Cost_cpu: 48201937
Resp_io: 1386.00 Resp_cpu: 48201937
Access Path: index (AllEqUnique)
Index: PK_XMFREPORTSTATE
resc_io: 1.00 resc_cpu: 8697
ix_sel: 0.030303 ix_sel_with_filters: 0.030303
NL Join: Cost: 1387.61 Resp: 1387.61 Degree: 1
Cost_io: 1386.00 Cost_cpu: 48201937
Resp_io: 1386.00 Resp_cpu: 48201937
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 1387.61
resc: 1387.61 resc_io: 1386.00 resc_cpu: 48201937
resp: 1387.61 resp_io: 1386.00 resp_cpu: 48201937
Join Card: 238.38 = outer (1048.85) * inner (5.00) * sel (0.045455)
Join Card - Rounded: 238 Computed: 238.38
SM Join
Outer table:
resc: 338.30 card 1048.85 bytes: 70 deg: 1 resp: 338.30
Inner table: XMFREPORTSTATE Alias: R
resc: 3.00 card: 5.00 bytes: 13 deg: 1 resp: 3.00
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 12 Row size: 87 Total Rows: 1049
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 30450620
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 25 Total Rows: 5
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976876
Total Temp space used: 0
SM join: Resc: 343.32 Resp: 343.32 [multiMatchCost=0.00]
SM cost: 343.32
resc: 343.32 resc_io: 340.00 resc_cpu: 99556133
resp: 343.32 resp_io: 340.00 resp_cpu: 99556133
HA Join
Outer table:
resc: 338.30 card 1048.85 bytes: 70 deg: 1 resp: 338.30
Inner table: XMFREPORTSTATE Alias: R
resc: 3.00 card: 5.00 bytes: 13 deg: 1 resp: 3.00
using dmeth: 2 #groups: 1
Cost per ptn: 0.51 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 11 probefrag: 1 ppasses: 1
Hash join: Resc: 341.81 Resp: 341.81 [multiMatchCost=0.00]
HA Join (swap)
Outer table:
resc: 3.00 card 5.00 bytes: 13 deg: 1 resp: 3.00
Inner table: XSVPATIENTRECORD Alias: D
resc: 338.30 card: 1048.85 bytes: 70 deg: 1 resp: 338.30
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 11 ppasses: 1
Hash join: Resc: 341.81 Resp: 341.81 [multiMatchCost=0.00]
HA cost: 341.81
resc: 341.81 resc_io: 340.00 resc_cpu: 54222464
resp: 341.81 resp_io: 340.00 resp_cpu: 54222464
Best:: JoinMethod: Hash
Cost: 341.81 Degree: 1 Resp: 341.81 Card: 238.38 Bytes: 83
Now joining: XSVRECPERXREF[X]#5
NL Join
Outer table: Card: 238.38 Cost: 341.81 Resp: 341.81 Degree: 1 Bytes: 83
Inner table: XSVRECPERXREF Alias: X
Access Path: TableScan
NL Join: Cost: 280914.52 Resp: 280914.52 Degree: 1
Cost_io: 275752.00 Cost_cpu: 154753663635
Resp_io: 275752.00 Resp_cpu: 154753663635
kkofmx: index filter:
("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6) AND ("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210) AND "PER"."PERID"="X"."PERID" AND "X"."RECID"="D"."RECID" AND "D"."RSTID"="R"."RSTID" AND "D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
Access Path: index (AllEqJoinGuess)
Index: RPXIDXRECID
resc_io: 3.00 resc_cpu: 23984
ix_sel: 1.6577e-006 ix_sel_with_filters: 1.6577e-006
NL Join: Cost: 835.02 Resp: 835.02 Degree: 1
Cost_io: 833.08 Cost_cpu: 58098995
Resp_io: 833.08 Resp_cpu: 58098995
Access Path: index (RangeScan)
Index: URPXRECPERTYPE
resc_io: 3.00 resc_cpu: 23274
ix_sel: 1.6577e-006 ix_sel_with_filters: 9.4822e-007
NL Join: Cost: 835.02 Resp: 835.02 Degree: 1
Cost_io: 833.08 Cost_cpu: 58181005
Resp_io: 833.08 Resp_cpu: 58181005
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 835.02
resc: 835.02 resc_io: 833.08 resc_cpu: 58098995
resp: 835.02 resp_io: 833.08 resp_cpu: 58098995
Join Card: 378.67 = outer (238.38) * inner (835508.80) * sel (1.9013e-006)
Join Card - Rounded: 379 Computed: 378.67
SM Join
Outer table:
resc: 341.81 card 238.38 bytes: 83 deg: 1 resp: 341.81
Inner table: XSVRECPERXREF Alias: X
resc: 1180.68 card: 835508.80 bytes: 17 deg: 1 resp: 1180.68
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 3 Row size: 102 Total Rows: 238
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 30061009
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 2967 Row size: 29 Total Rows: 835509
Initial runs: 2 Merge passes: 1 IO Cost / pass: 1608
Total IO sort cost: 4575 Total CPU sort cost: 843575684
Total Temp space used: 53699000
SM join: Resc: 6126.64 Resp: 6126.64 [multiMatchCost=0.00]
SM cost: 6126.64
resc: 6126.64 resc_io: 6074.00 resc_cpu: 1577856809
resp: 6126.64 resp_io: 6074.00 resp_cpu: 1577856809
HA Join
Outer table:
resc: 341.81 card 238.38 bytes: 83 deg: 1 resp: 341.81
Inner table: XSVRECPERXREF Alias: X
resc: 1180.68 card: 835508.80 bytes: 17 deg: 1 resp: 1180.68
using dmeth: 2 #groups: 1
Cost per ptn: 3.29 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 3 probefrag: 2958 ppasses: 1
Hash join: Resc: 1525.78 Resp: 1525.78 [multiMatchCost=0.00]
HA cost: 1525.78
resc: 1525.78 resc_io: 1499.00 resc_cpu: 802794893
resp: 1525.78 resp_io: 1499.00 resp_cpu: 802794893
Best:: JoinMethod: NestedLoop
Cost: 835.02 Degree: 1 Resp: 835.02 Card: 378.67 Bytes: 100
Now joining: PERPERSON[PER]#0
NL Join
Outer table: Card: 378.67 Cost: 835.02 Resp: 835.02 Degree: 1 Bytes: 100
Inner table: PERPERSON Alias: PER
Access Path: TableScan
NL Join: Cost: 409701.78 Resp: 409701.78 Degree: 1
Cost_io: 408070.08 Cost_cpu: 48912477468
Resp_io: 408070.08 Resp_cpu: 48912477468
Access Path: index (UniqueScan)
Index: PKPER
resc_io: 2.00 resc_cpu: 16603
ix_sel: 2.7682e-006 ix_sel_with_filters: 2.7682e-006
NL Join: Cost: 1593.23 Resp: 1593.23 Degree: 1
Cost_io: 1591.08 Cost_cpu: 64391486
Resp_io: 1591.08 Resp_cpu: 64391486
Access Path: index (AllEqJoin)
Index: PERIDXAGNEXTID
resc_io: 2.00 resc_cpu: 15703
ix_sel: 0.001065 ix_sel_with_filters: 0.001065
NL Join: Cost: 1593.22 Resp: 1593.22 Degree: 1
Cost_io: 1591.08 Cost_cpu: 64050386
Resp_io: 1591.08 Resp_cpu: 64050386
Access Path: index (AllEqUnique)
Index: PKPER
resc_io: 2.00 resc_cpu: 16603
ix_sel: 2.7682e-006 ix_sel_with_filters: 2.7682e-006
NL Join: Cost: 1593.23 Resp: 1593.23 Degree: 1
Cost_io: 1591.08 Cost_cpu: 64391486
Resp_io: 1591.08 Resp_cpu: 64391486
****** trying bitmap/domain indexes ******
Access Path: index (AllEqJoin)
Index: PERIDXAGNEXTID
resc_io: 1.00 resc_cpu: 8171
ix_sel: 0.001065 ix_sel_with_filters: 0.001065
NL Join: Cost: 1214.12 Resp: 1214.12 Degree: 1
Cost_io: 1212.08 Cost_cpu: 61195971
Resp_io: 1212.08 Resp_cpu: 61195971
Access Path: index (AllEqUnique)
Index: PKPER
resc_io: 1.00 resc_cpu: 9021
ix_sel: 2.7682e-006 ix_sel_with_filters: 2.7682e-006
NL Join: Cost: 1214.13 Resp: 1214.13 Degree: 1
Cost_io: 1212.08 Cost_cpu: 61518121
Resp_io: 1212.08 Resp_cpu: 61518121
Access path: Bitmap index - rejected
Cost: 3293.30 Cost_io: 3287.25 Cost_cpu: 181295210 Sel: 9.5086e-007
Not believed to be index-only
****** finished trying bitmap/domain indexes ******
Best NL cost: 1593.22
resc: 1593.22 resc_io: 1591.08 resc_cpu: 64050386
resp: 1593.22 resp_io: 1591.08 resp_cpu: 64050386
Join Card: 0.34 = outer (378.67) * inner (1.00) * sel (8.9286e-004)
Join Card - Rounded: 1 Computed: 0.34
SM Join
Outer table:
resc: 835.02 card 378.67 bytes: 100 deg: 1 resp: 835.02
Inner table: PERPERSON Alias: PER
resc: 2.00 card: 1.00 bytes: 29 deg: 1 resp: 2.00
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 6 Row size: 120 Total Rows: 379
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 30122624
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 42 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976353
Total Temp space used: 0
SM join: Resc: 839.02 Resp: 839.02 [multiMatchCost=0.00]
SM cost: 839.02
resc: 839.02 resc_io: 835.08 resc_cpu: 118213674
resp: 839.02 resp_io: 835.08 resp_cpu: 118213674
HA Join
Outer table:
resc: 835.02 card 378.67 bytes: 100 deg: 1 resp: 835.02
Inner table: PERPERSON Alias: PER
resc: 2.00 card: 1.00 bytes: 29 deg: 1 resp: 2.00
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 6 probefrag: 1 ppasses: 1
Hash join: Resc: 837.52 Resp: 837.52 [multiMatchCost=0.00]
HA Join (swap)
Outer table:
resc: 2.00 card 1.00 bytes: 29 deg: 1 resp: 2.00
Inner table: XSVRECPERXREF Alias: X
resc: 835.02 card: 378.67 bytes: 100 deg: 1 resp: 835.02
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 6 ppasses: 1
Hash join: Resc: 837.52 Resp: 837.52 [multiMatchCost=0.00]
HA cost: 837.52
resc: 837.52 resc_io: 835.08 resc_cpu: 73140924
resp: 837.52 resp_io: 835.08 resp_cpu: 73140924
Best:: JoinMethod: Hash
Cost: 837.52 Degree: 1 Resp: 837.52 Card: 0.34 Bytes: 129
Now joining: ADTCASE[C]#6
NL Join
Outer table: Card: 0.34 Cost: 837.52 Resp: 837.52 Degree: 1 Bytes: 129
Inner table: ADTCASE Alias: C
Access Path: TableScan
NL Join: Cost: 6458.89 Resp: 6458.89 Degree: 1
Cost_io: 6414.08 Cost_cpu: 1343349671
Resp_io: 6414.08 Resp_cpu: 1343349671
Access Path: index (UniqueScan)
Index: PK_ADTCASE
resc_io: 2.00 resc_cpu: 16573
ix_sel: 3.9499e-007 ix_sel_with_filters: 3.9499e-007
NL Join: Cost: 839.52 Resp: 839.52 Degree: 1
Cost_io: 837.08 Cost_cpu: 73157497
Resp_io: 837.08 Resp_cpu: 73157497
Access Path: index (AllEqUnique)
Index: PK_ADTCASE
resc_io: 2.00 resc_cpu: 16573
ix_sel: 3.9478e-007 ix_sel_with_filters: 3.9478e-007
NL Join: Cost: 839.52 Resp: 839.52 Degree: 1
Cost_io: 837.08 Cost_cpu: 73157497
Resp_io: 837.08 Resp_cpu: 73157497
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 839.52
resc: 839.52 resc_io: 837.08 resc_cpu: 73157497
resp: 839.52 resp_io: 837.08 resp_cpu: 73157497
Join Card: 0.34 = outer (0.34) * inner (2531689.00) * sel (3.9478e-007)
Join Card - Rounded: 1 Computed: 0.34
SM Join
Outer table:
resc: 837.52 card 0.34 bytes: 129 deg: 1 resp: 837.52
Inner table: ADTCASE Alias: C
resc: 5621.37 card: 2531689.00 bytes: 34 deg: 1 resp: 5621.37
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 152 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976353
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 14878 Row size: 48 Total Rows: 2531689
Initial runs: 2 Merge passes: 1 IO Cost / pass: 8060
Total IO sort cost: 22938 Total CPU sort cost: 2822696818
Total Temp space used: 264217000
SM join: Resc: 29492.06 Resp: 29492.06 [multiMatchCost=0.00]
SM cost: 29492.06
resc: 29492.06 resc_io: 29352.08 resc_cpu: 4196022842
resp: 29492.06 resp_io: 29352.08 resp_cpu: 4196022842
HA Join
Outer table:
resc: 837.52 card 0.34 bytes: 129 deg: 1 resp: 837.52
Inner table: ADTCASE Alias: C
resc: 5621.37 card: 2531689.00 bytes: 34 deg: 1 resp: 5621.37
using dmeth: 2 #groups: 1
Cost per ptn: 8.95 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 14217 ppasses: 1
Hash join: Resc: 6467.84 Resp: 6467.84 [multiMatchCost=0.00]
HA cost: 6467.84
resc: 6467.84 resc_io: 6414.08 resc_cpu: 1611506897
resp: 6467.84 resp_io: 6414.08 resp_cpu: 1611506897
Best:: JoinMethod: NestedLoop
Cost: 839.52 Degree: 1 Resp: 839.52 Card: 0.34 Bytes: 163
Now joining: ADTPATIENT[P]#4
NL Join
Outer table: Card: 0.34 Cost: 839.52 Resp: 839.52 Degree: 1 Bytes: 163
Inner table: ADTPATIENT Alias: P
Access Path: TableScan
NL Join: Cost: 2172.07 Resp: 2172.07 Degree: 1
Cost_io: 2161.08 Cost_cpu: 329395913
Resp_io: 2161.08 Resp_cpu: 329395913
Access Path: index (UniqueScan)
Index: PK_ADTPATIENT
resc_io: 2.00 resc_cpu: 16533
ix_sel: 1.8294e-006 ix_sel_with_filters: 1.8294e-006
NL Join: Cost: 841.52 Resp: 841.52 Degree: 1
Cost_io: 839.08 Cost_cpu: 73174030
Resp_io: 839.08 Resp_cpu: 73174030
Access Path: index (AllEqUnique)
Index: PK_ADTPATIENT
resc_io: 2.00 resc_cpu: 16533
ix_sel: 1.8294e-006 ix_sel_with_filters: 1.8294e-006
NL Join: Cost: 841.52 Resp: 841.52 Degree: 1
Cost_io: 839.08 Cost_cpu: 73174030
Resp_io: 839.08 Resp_cpu: 73174030
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 841.52
resc: 841.52 resc_io: 839.08 resc_cpu: 73174030
resp: 841.52 resp_io: 839.08 resp_cpu: 73174030
Join Card: 0.34 = outer (0.34) * inner (546621.00) * sel (1.8294e-006)
Join Card - Rounded: 1 Computed: 0.34
SM Join
Outer table:
resc: 839.52 card 0.34 bytes: 163 deg: 1 resp: 839.52
Inner table: ADTPATIENT Alias: P
resc: 1332.55 card: 546621.00 bytes: 41 deg: 1 resp: 1332.55
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 190 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976353
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 3748 Row size: 56 Total Rows: 546621
Initial runs: 2 Merge passes: 1 IO Cost / pass: 2032
Total IO sort cost: 5780 Total CPU sort cost: 591684408
Total Temp space used: 65872000
SM join: Resc: 7972.81 Resp: 7972.81 [multiMatchCost=0.00]
SM cost: 7972.81
resc: 7972.81 resc_io: 7941.08 resc_cpu: 951056673
resp: 7972.81 resp_io: 7941.08 resp_cpu: 951056673
HA Join
Outer table:
resc: 839.52 card 0.34 bytes: 163 deg: 1 resp: 839.52
Inner table: ADTPATIENT Alias: P
resc: 1332.55 card: 546621.00 bytes: 41 deg: 1 resp: 1332.55
using dmeth: 2 #groups: 1
Cost per ptn: 2.32 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 3537 ppasses: 1
Hash join: Resc: 2174.39 Resp: 2174.39 [multiMatchCost=0.00]
HA cost: 2174.39
resc: 2174.39 resc_io: 2161.08 resc_cpu: 399046339
resp: 2174.39 resp_io: 2161.08 resp_cpu: 399046339
Plan cardinality mismatch: best card= 0.33796097408 curr card= 0.33791727990
Best:: JoinMethod: NestedLoop
Cost: 841.52 Degree: 1 Resp: 841.52 Card: 0.34 Bytes: 204
Best so far: Table#: 1 cost: 2.0007 card: 2.0000 bytes: 22
Table#: 3 cost: 338.3037 card: 1048.8517 bytes: 73430
Table#: 2 cost: 341.8088 card: 238.3754 bytes: 19754
Table#: 5 cost: 835.0191 card: 378.6697 bytes: 37900
Table#: 0 cost: 837.5209 card: 0.3381 bytes: 129
Table#: 6 cost: 839.5214 card: 0.3379 bytes: 163
Table#: 4 cost: 841.5220 card: 0.3379 bytes: 204
tage -
Tuning SQL Query calling multiple views
Dear All,
I have a complex scenario in which I have created views in 3 levels for sales and Service separately so total no of views are 6.
Level 2 calls view in Level 1 and Level 3 calls level 2 in sales as well as services.
Finally Level 4 has the union of sales and Service Level 3 view.
There are 5 tables used in total and all have been indexed for better performance.
The cube processing for the above scenario has processing time of 6 mins.
The goal is to bring it down to 2-3 mins.
The amount of data currently we are looking at is not more than 2-3 GB.
Can anybody help me fine tune this scenario?
Thanks, Franco.Run the queries the cube is using in SSMS and turn on the Include Actual Execution Plan option.
https://msdn.microsoft.com/en-us/library/ms189562.aspx?f=255&MSPPError=-2147217396
Straight up it may suggest missing indexes which you can test to see if they improve the query performance. You can't take these suggestions as gospel - sometimes SQL Server gets it wrong - so you need to test them.
After that look in the query plan for any table scan operators. Unless you are actually retrieving every row in a table you shouldn't have any of these and they can probably be removed by placing a properly considered index on the table.
After that look for any RID Lookups or Key Lookups. These can generally be resolved fairly easily by adding the columns being looked up as "include" columns in the indexes.
Here are some links that might get you started.
Reading Execution Plans: http://www.mssqltips.com/sqlservertip/1873/how-to-read-sql-server-graphical-query-execution-plans/
Resolving Table Scans http://blog.sqlauthority.com/2007/03/30/sql-server-index-seek-vs-index-scan-table-scan/
Resolving Lookups: http://blog.sqlauthority.com/2009/11/09/sql-server-removing-key-lookup-seek-predicate-predicate-an-interesting-observation-related-to-datatypes/
Those are the obvious things - and generally the easiest to achieve. Performance tuning is a big area. It may be that the database queries are already performing perfectly well and the time being spent is processing the cube itself so you need
to establish where the time is going. There is no point trying to tune the database queries if they are already working well.
LucasF -
Tuning SQL with heavy hash join
Hi all,
My database is 11.1. Rac 4 node.
The sql is so simple.
create table leon_12345
nologging
as
SELECT *
FROM OOOOOOOOOO a
FULL OUTER JOIN PPPPPPPPPPP b ON a.PRMTN_SKID =
b.PRMTN_SKID
AND a.PROD_SKID =
b.PROD_SKID
AND a.MTH_SKID =
b.MTH_SKID
AND a.PRMTD_CATEG_ID =
b.PRMTD_CATEG_ID
AND a.PRMTN_FACT_ID =
b.PRMTN_FACT_IDSince these two tables have DOP settings, the exection plan looks like:
| Id | Operation | Name | E-Rows | OMem | 1Mem | Used-Mem |
| 0 | CREATE TABLE STATEMENT | | | | | |
| 1 | LOAD AS SELECT | | | 256K| 256K| |
| 2 | PX COORDINATOR | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10002 | 74M| | | |
| 4 | VIEW | VW_FOJ_0 | 74M| | | |
|* 5 | HASH JOIN FULL OUTER BUFFERED| | 74M| 1926M| 26M| |
| 6 | PX RECEIVE | | 12M| | | |
| 7 | PX SEND HASH | :TQ10000 | 12M| | | |
| 8 | PX BLOCK ITERATOR | | 12M| | | |
|* 9 | TABLE ACCESS FULL | PPPPPPPPPPP | 12M| | | |
| 10 | PX RECEIVE | | 74M| | | |
| 11 | PX SEND HASH | :TQ10001 | 74M| | | |
| 12 | PX BLOCK ITERATOR | | 74M| | | |
|* 13 | TABLE ACCESS FULL | OOOOOOOOOO | 74M| | | |
-----------------------------------------------------------------------------------------------------------I have noticed 8 slave sessions were up for this sql.(9 sessions totally of course)
With execution in parallel, the SQL still runs slowly. I want to know whether the parallel exectuion has some problem here.
Because after running several minutes, I saw four sessions became inactive and only 4 slave sessions were active.
Whether the workload was not distributed evenly or something else? Can I get some ideas on the direction of tuning this sql.
Best regards,
LeonLeon,
There is not much to tune about this SQL. There might be something to tune in your database configuration, so I'd move this question over to the Database General forum.
And while doing that, please be sure to include trace information and wait event information.
Regards,
Rob. -
Tuning sql - uneven execution times
Hi-
A common problem we have when we are performance tuning our sql queries is that an initial run of the query will be slow but subsequent runs of the same sql might be up to ten times faster. Presumably this results from some kind of caching.
This confounds our ability it to tune the sql, as we cannot distinguish changes in run time that result from changes to the sql or from whatever caching Oracle is doing.
Is there a way for us to tell Oracle "we are trying to tune this query, please don't do any caching" or some other way to get consistent run times for performance comparison?
Thanks,
Stevejgarry wrote:
Which brings up another fundamental tuning issue - how do you order the importance of problems unless you start by measuring the elapsed times?I would argue that looking at what that elapsed time is spend on (wait events) is a lot more useful.
(I happen to agree with you Billy, I'm just pointing out what some tuning methodologies say and an aspect of compulsive tuning disorder. Never really suffered from that. 90%, if not more, of all performance problems I've ever dealt with were due to either application code or application/database design.
When you pop open the hood of a RDBMS or operating system to address performance problems, then you are saying by implication that the code is 100% correct and the design is a 100% correct.
I always get uncomfortable with people wanting to immediately pop the hood to fix performance problems. Set this s/pfile parameter.. turn that Oracle knob.. throw that switch. This is second guessing as to what the actual root cause of the problem is.
When I'm given a problem SQL to tune for performance (some of these spanned a couple of A4 pages for a single SQL!), may first question is always what is the goal? What is the query suppose to do? Not setting up a SQL trace, and playing with trace events and the like. That comes afterward, when you know for a fact that the design of the query is correct.
I think people underestimate SQL. It is a relatively simple language. Unlike object orientated and even procedural languages. And because it is seen as simple, very little though goes into designing a SQL "+program+" - as that is what a SQL statement is. A program that specifies how (sometimes enormous) data sets need to be processed, applying (sometimes very complex) business logic.
Ask the same same developer to write that in Java/.Net/etc and the developer will spend a significant time in designing the program. Yet, when writing it in SQL, very little though is given (IMO) by developers as to the design of that SQL program... as with very little code you are hitting large data sets doing some pretty complex processing.
So because SQL is treated as "+simplistic+", performance problems in this regard is often treated as a SQL problems. CBO not doing it correctly. Slapping more indexes on a table. Etc. Instead of looking at the design of that SQL and first determining whether that is correct or not.
Top down. Something that was drilled into me when I started programming in Cobol on mainframes years ago. You deal with design and problems from the top down. :-)
The real reconciliation comes in recognizing the importance of context, sequencing and iteration in problem definition. When you add multiuser issues into the mix you can get things like, users complain their queries take too long, developer starts tuning the sql since hey, most performance problems are sql, but the resources are sucked by something else entirely, or even the problem sql punching itself in the face).Yep. Have seen many SQLs that hurts themselves badly (in addition to the rest of the server). Like multiple passes through the same data set.
So shouldn't there be a "typical" load on the test system when tuning, rather than fresh system or empty system with iterations? It depends...It makes sense to deal with a base line ito performance and measurement and data volumes and so on when designing and coding. -
Tuning sql automatic using SQL Tuning Advisor Tool
I need to work on Automatic sql tuning..
Please give suggestion for the below
1) I have installed oracle11g client version. confirm this is okey for my project. because i heard we should have oracle enterprise edition for this.
2) User with only sys privelage can work on this automatic sql tuning using sql tuning advisior tool.
Please clarify above suggestions.
ALso suggest me best way to proceed further
SSunny kichloo wrote:
This docs will help
http://www.oracle-base.com/articles/10g/automatic-sql-tuning-10g.php
http://www.oracle-base.com/articles/11g/automatic-sql-tuning-11gr1.php
Thanks for your link. i already seen this link.
Could u pls answer my question on above with " Yes" or "No"
Kindly reply
S -
Tuning SQL query with SDO and Contains?
I'trying to optimize a query
with a sdo_filter and an intermedia_contains
on a 3.000.000 records table,
the query look like this
SELECT COUNT(*) FROM professionnel WHERE mdsys.sdo_filter(professionnel.coor_cart,mdsys.sdo_geometry(2003, null, null,mdsys.sdo_elem_info_array(1,1003,4),mdsys.sdo_ordinate_array(809990,2087279,778784,2087279,794387,2102882)),'querytype=window') = 'TRUE' AND professionnel.code_rubr ='12 3 30' AND CONTAINS(professionnel.Ctx,'PLOMBERIE within Nom and ( RUE within Adresse1 )',1)>0
and it takes 15s on a bi 750 pentium III with
1.5Go of memory running under 8.1.6 linux.
What can i do to improve this query time?
nullHi Vincent,
We have patches for Oracle 8.1.6 Spatial
on NT and Solaris.
These patches include bug fixes and
performance enhancements.
We are in the process of making these patches
avaialble in a permanent place, but until then, I will temporarily put the patches on:
ftp://oracle-ftp.oracle.com/
Log in as anonymous and use your email for
password.
The patches are in /tmp/outgoing in:
NT816-000706.zip - NT patch
libordsdo.tar - Solaris patch
I recommend doing some analysis on
individual pieces of the query.
i.e. time the following:
1)
SELECT COUNT(*)
FROM professionnel
WHERE mdsys.sdo_filter(
professionnel.coor_cart,
mdsys.sdo_geometry(
2003, null, null,
mdsys.sdo_elem_info_array(1,1003,4),
mdsys.sdo_ordinate_array(
809990,2087279,
778784,2087279,
794387,2102882)),
'querytype=window') = 'TRUE';
2)
SELECT COUNT(*)
FROM professionnel
WHERE CONTAINS(professionnel.Ctx,
'PLOMBERIE within Nom and ( RUE within Adresse1)',1) >0;
You might want to try reorganizing the entire
query as follows (no promises).
If you contact me directly, I can try to
help to further tune the SQL.
Hope this helps. Thanks.
Dan
select count(*)
FROM
(SELECT /*+ no_merge */ rowid
FROM professionnel
WHERE mdsys.sdo_filter(
professionnel.coor_cart,
mdsys.sdo_geometry(
2003, null, null,
mdsys.sdo_elem_info_array(1,1003,4),
mdsys.sdo_ordinate_array(809990,2087279,
778784,2087279,
794387,2102882)),
'querytype=window') = 'TRUE'
) a,
(SELECT /*+ no_merge */ rowid
FROM professionnel
WHERE CONTAINS(professionnel.Ctx,
'PLOMBERIE within Nom and
( RUE within Adresse1)',1) >0
) b
where a.rowid = b.rowid
and professionnel.code_rubr ='12 3 30';
**NOTE** Try this with no index on code_rubr
null -
Hi,
Can anyone assist me in tuning the below query
Thanks in Advance
A.Gopal
SELECT nvl(sum(p.GRP_ACTUALQUANTITY),0)
FROM GOODSRECEIPTS r, GOODSRECEIPTPOSITIONS p
,reportparameters plt,reportparameters spl,reportparameters mat
WHERE r.GRH_NO = p.GRP_GRH_NO
AND TRUNC(r.GRH_ARRIVAL) BETWEEN NVL(TO_DATE('01-jan-09'), TRUNC(r.GRH_ARRIVAL)) AND NVL(TO_DATE('31-jan-09'), TRUNC(r.GRH_ARRIVAL))
AND (p.GRP_PLT_ID = 'VDN' OR 1 =0)
AND (r.GRH_SPL_ID = '15035122' OR 1 =0)
AND (p.GRP_MAT_ID = '1001360' OR 1 =0)
AND ('01.01.2009' = 'TOTAL' or trunc(r.GRH_ARRIVAL,'mm') = to_date('01.01.2009','dd.mm.yyyy'))
and plt.rep_field = 'PLT_ID' AND plt.rep_id = 'AN_EXC_RAT' AND plt.rep_user = 'ANANTGOP'
and spl.rep_field = 'SPL_ID' AND spl.rep_id = 'AN_EXC_RAT' AND spl.rep_user ='ANANTGOP'
and mat.rep_field = 'MAT_ID' AND mat.rep_id = 'AN_EXC_RAT' AND mat.rep_user = 'ANANTGOP'
and r.GRH_SPL_ID = decode(spl.rep_value,'All',r.GRH_SPL_ID,spl.rep_value)
and p.GRp_plt_ID = decode(plt.rep_value,'All',p.GRp_plt_ID,plt.rep_value)
and p.GRp_mat_ID = decode(mat.rep_value,'All',p.GRp_mat_ID,mat.rep_value)
AND NOT EXISTS (SELECT 1 FROM GOODSRECEIPTUSAGESTATUS u
WHERE p.GRP_GRH_NO = u.GRU_GRP_GRH_NO
AND p.GRP_NO =u.GRU_GRP_NO
AND u.GRU_UST_ID = 'CANCEL')This query is used in my Oracle report. The original query is like beow
SELECT nvl(sum(p.GRP_ACTUALQUANTITY),0)
FROM GOODSRECEIPTS r, GOODSRECEIPTPOSITIONS p
,reportparameters plt,reportparameters spl,reportparameters mat
WHERE r.GRH_NO = p.GRP_GRH_NO
AND TRUNC(r.GRH_ARRIVAL) >= NVL(:l_date_from, TRUNC(r.GRH_ARRIVAL)) AND
TRUNC(r.GRH_ARRIVAL) <=NVL(:l_date_to, TRUNC(r.GRH_ARRIVAL))
AND (p.GRP_PLT_ID = :p_plt_id OR :ip_plt_group =0)
AND (r.GRH_SPL_ID = :p_spl_id OR :ip_spl_group =0)
AND (p.GRP_MAT_ID = :p_mat_id OR :ip_mat_group =0)
AND (:l_flag = 'TOTAL' or trunc(r.GRH_ARRIVAL,'mm') = to_date(:p_month_abc_sp,'dd.mm.yyyy'))
and plt.rep_field = 'PLT_ID' AND plt.rep_id = :ip_rep_id AND plt.rep_user = :ip_rep_user
and spl.rep_field = 'SPL_ID' AND spl.rep_id = :ip_rep_id AND spl.rep_user = :ip_rep_user
and mat.rep_field = 'MAT_ID' AND mat.rep_id = :ip_rep_id AND mat.rep_user = :ip_rep_user
and r.GRH_SPL_ID = decode(spl.rep_value,'All',r.GRH_SPL_ID,spl.rep_value)
and p.GRp_plt_ID = decode(plt.rep_value,'All',p.GRp_plt_ID,plt.rep_value)
and p.GRp_mat_ID = decode(mat.rep_value,'All',p.GRp_mat_ID,mat.rep_value)
AND NOT EXISTS (SELECT 1
FROM GOODSRECEIPTUSAGESTATUS u
WHERE p.GRP_GRH_NO = u.GRU_GRP_GRH_NO
AND p.GRP_NO =u.GRU_GRP_NO
AND u.GRU_UST_ID = 'CANCEL');
:ip_rep_id = 'AN_EXC_RAT'
:ip_rep_user = 'ANANTGOP
Value of :l_flag = '01.01.2009'
(:p_month_abc_sp = '01.01.2009'
Thanks
A.Gopal -
Please help me in tuning this query. This view has around 2 million of records
SELECT * FROM employee_v
WHERE status_id IN (SELECT MAX(v2.status_id)status_id
FROM employee_v v2
WHERE UPPER(v2.name) LIKE UPPER(:v_name)||'%'
GROUP BY v2.emp_id, v2.project_id)
ORDER BY status_type_id;
Here:
employees may work on one or more projects
employee working on a given project may have one or more status_ids associated.
for example:
emp_id project_id status_id
10 100 1
10 100 2
20 100 2
20 200 3
30 100 4
30 200 5
30 200 6
40 200 6
If you have any other suggestions , please let me know too. For example, I was thinking that the subquery should use actual tables instead of the view because view is based on 10 tables and the subquery can instead use two tables . Does it make sense?
Thanks a lot for the help!
Edited by: user5406804 on Apr 20, 2010 5:42 AMIf you have any other suggestions , please let me know too. Wild shot in the dark, but maybe using EXISTS instead of IN speeds up your query:
untested for obvious reasons
select *
from employee_v v
where upper(v.name) like upper(:v_name)||'%'
where not exists ( select null
from employee_v v2
and v2.status_id > v.status_id
and v2.emp_id = v.emp_id -- assuming you have some emp_id PK column
-- if necessary, you need to change the name of this column ofcourse
order by status_type_id;Do compare the resultsets, not sure this will give you the same/desired result, but it might give you an idea.
For example, I was thinking that the subquery should use actual tables instead of the view because > view is based on 10 tables and the subquery can instead
use two tables . Does it make sense?Sounds like worth a try to me, yes. Less data to plough through = faster response.
As well as using a function based index on UPPER(name) might be worth a try. -
Tuning sql with analytic function
Dear friends I've developed one sql :
with REP as
(select /*+ MATERIALIZE */ branch_code,
row_number() over(partition by branch_code, account order by bkg_date desc ) R,
account,
bkg_date,
lcy_closing_bal
from history t
select REP1.branch_code,
REP1.account,
REP1.bkg_date,
REP1.lcy_closing_bal,
NULL AS second,
REP2.bkg_date bkg_date2,
REP2.lcy_closing_bal lcy_closing_bal2,
NULL AS third,
REP3.bkg_date bkg_date3,
REP3.lcy_closing_bal lcy_closing_bal3
from (SELECT * FROM REP WHERE R=1) REP1, (SELECT * FROM REP WHERE R=2) REP2, (SELECT * FROM REP WHERE R=3) REP3
where
(REP1.BRANCH_CODE = REP2.BRANCH_CODE(+) AND REP1.ACCOUNT = REP2.ACCOUNT(+)) AND
(REP1.BRANCH_CODE = REP3.BRANCH_CODE(+) AND REP1.ACCOUNT = REP3.ACCOUNT(+))The point is I want to restrict (tune) REP before it used ,because , as you can see I need maximum three value from REP (where R=1,R=2,R=3) . Which analytic function and with wich options I have to use to receive only 3 values in each branch_code,account groups at the materializing time ?Radrigez wrote:
Dear friends I've developed one sql :
with REP as
from (SELECT * FROM REP WHERE R=1) REP1,
(SELECT * FROM REP WHERE R=2) REP2,
(SELECT * FROM REP WHERE R=3) REP3
where
(REP1.BRANCH_CODE = REP2.BRANCH_CODE(+) AND REP1.ACCOUNT = REP2.ACCOUNT(+)) AND
(REP1.BRANCH_CODE = REP3.BRANCH_CODE(+) AND REP1.ACCOUNT = REP3.ACCOUNT(+))
The first step is to put your subquery (which doesn't need to be materialized) into an inline view and restrict the result set on r in (1,2,3) as suggested by thtsang - you don't need to query the same result set three times.
Then you're looking at a simple pivot operation (assuming the number of rows you want per branch and account is fixed). If you're on 11g search the manuals for PIVOT, on earlier versions you can do this with a decode() or case() operator.
Step 1 (which could go into another factored subquery) would be something like:
select
branch_code, account,
case r = 1 then bkg_date end bkg_date,
case r = 1 then lcy_closing_bal end lcy_closing_bal,
case r = 2 then bkg_date end bkg_date2,
case r = 2 then lcy_closing_bal end lcy_closing_bal2,
case r = 3 then bkg_date end bkg_date3,
case r = 3 then lcy_closing_bal end lcy_closing_bal3
from
repThis gives you the eight necessary columns, but still (up to) three rows per branch/account.
Then you aggregate this (call it rep1) on branch and account.
select
branch_code, account,
max(bkg_date),
max(lcy_closing_bal),
max(bkg_date2),
max(lcy_closing_bal2),
max(bkg_date3),
max(lcy_closing_bal3)
from
rep1
group by
branch_code, account
order by
branch_code, accountRegards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b> -
Tuning (SQL Query has radically different Buffer GETS in each instance)
I have been noticing that on Node2 of my 10.2.0.3 RAC cluster CPU has been running 90% for the past couple of days and on Node1 we are at the normal 20-30%. I was comparing AWR for both instances and noticed that the same exact SQL was showing different GETS on each instance.
Both Instances are configured exactly the same. SGA 3GB, 2 dual core 1.5Ghz CPU on Solaris 10.
AWR For Node 1
SQL ordered by Gets
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 8,199,224
Captured SQL account for 94.2% of Total
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
4,834,470 16,465 293.62 58.96 442.34 459.42 cs3w0nz7uanhc BEGIN HRW_EC_QUERY.CHECK_STUDE...
4,561,082 16,469 276.95 55.63 411.10 430.16 6vbpbvfburc4x SELECT COUNT(SECURE_PROGRAMS.P... AWR For Node 2
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
219,779,881 9,306 23,617.01 99.26 11791.62 32202.99 cs3w0nz7uanhc BEGIN HRW_EC_QUERY.CHECK_STUDE...
219,320,634 9,302 23,577.79 99.05 11760.22 32137.23 6vbpbvfburc4x SELECT COUNT(SECURE_PROGRAMS.P... Gets on Node 2 are about 45 times what they are on node 1. We are using bind variables in the SQL. The statements are completely identical. Anyone seen this before?
Thanks,
BrianAll parameters are the same between instances. Here is the result of the query.
PLAN_TABLE_OUTPUT
SQL_ID 6vbpbvfburc4x
SELECT COUNT(SECURE_PROGRAMS.PROG_ID) FROM SECURE_PROGRAMS,HRW_EC_ACTIVE_ITEM, (SELECT ACTIVE_ITEM_ID
FROM TABLE(CAST(:B1 AS HRW_EC_ACTIVE_ITEM_ID_TABLE_T)) ) T WHERE HRW_EC_ACTIVE_ITEM.ACTIVE_ITEM_ID =
T.ACTIVE_ITEM_ID AND HRW_EC_ACTIVE_ITEM.SPROG_ID = SECURE_PROGRAMS.PROG_ID AND
SECURE_PROGRAMS.STUDENT_RESOURCES_URL = :B2
Plan hash value: 25280318
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 730 (100)| |
| 1 | SORT AGGREGATE | | 1 | 57 | | |
| 2 | HASH JOIN | | 116 | 6612 | 730 (1)| 00:00:09 |
| 3 | COLLECTION ITERATOR PICKLER FETCH| | | | | |
| 4 | NESTED LOOPS | | 48596 | 2610K| 705 (1)| 00:00:09 |
| 5 | INDEX RANGE SCAN | SECURE_PROGRAMS_IDX_04 | 4 | 76 | 2 (0)| 00:00:01 |
| 6 | INDEX RANGE SCAN | HRW_EC_ACTIVE_ITEM_IDX_03 | 10984 | 386K| 176 (1)| 00:00:03 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$62A3881B
5 - SEL$62A3881B / SECURE_PROGRAMS@SEL$1
6 - SEL$62A3881B / HRW_EC_ACTIVE_ITEM@SEL$1
SQL_ID 6vbpbvfburc4x
SELECT COUNT(SECURE_PROGRAMS.PROG_ID) FROM SECURE_PROGRAMS,HRW_EC_ACTIVE_ITEM, (SELECT ACTIVE_ITEM_ID
FROM TABLE(CAST(:B1 AS HRW_EC_ACTIVE_ITEM_ID_TABLE_T)) ) T WHERE HRW_EC_ACTIVE_ITEM.ACTIVE_ITEM_ID =
T.ACTIVE_ITEM_ID AND HRW_EC_ACTIVE_ITEM.SPROG_ID = SECURE_PROGRAMS.PROG_ID AND
SECURE_PROGRAMS.STUDENT_RESOURCES_URL = :B2
Plan hash value: 219484150
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 4845 (100)| |
| 1 | SORT AGGREGATE | | 1 | 57 | | |
| 2 | HASH JOIN | | 2066 | 115K| 4845 (2)| 00:00:59 |
| 3 | INDEX RANGE SCAN | SECURE_PROGRAMS_IDX_04 | 79 | 1501 | 2 (0)| 00:00:01 |
| 4 | HASH JOIN | | 3284 | 121K| 4843 (2)| 00:00:59 |
| 5 | COLLECTION ITERATOR PICKLER FETCH| | | | | |
| 6 | INDEX FAST FULL SCAN | HRW_EC_ACTIVE_ITEM_IDX_03 | 1373K| 47M| 4803 (2)| 00:00:58 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$62A3881B
3 - SEL$62A3881B / SECURE_PROGRAMS@SEL$1
6 - SEL$62A3881B / HRW_EC_ACTIVE_ITEM@SEL$1
Note
- SQL profile "SYS_SQLPROF_014414387fd00001" used for this statement
SQL_ID 6vbpbvfburc4x
SELECT COUNT(SECURE_PROGRAMS.PROG_ID) FROM SECURE_PROGRAMS,HRW_EC_ACTIVE_ITEM, (SELECT ACTIVE_ITEM_ID
FROM TABLE(CAST(:B1 AS HRW_EC_ACTIVE_ITEM_ID_TABLE_T)) ) T WHERE HRW_EC_ACTIVE_ITEM.ACTIVE_ITEM_ID =
T.ACTIVE_ITEM_ID AND HRW_EC_ACTIVE_ITEM.SPROG_ID = SECURE_PROGRAMS.PROG_ID AND
SECURE_PROGRAMS.STUDENT_RESOURCES_URL = :B2
Plan hash value: 740005210
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 4845 (100)| |
| 1 | SORT AGGREGATE | | 1 | 57 | | |
| 2 | HASH JOIN | | 7 | 399 | 4845 (2)| 00:00:59 |
| 3 | COLLECTION ITERATOR PICKLER FETCH| | | | | |
| 4 | HASH JOIN | | 2992 | 160K| 4821 (2)| 00:00:58 |
| 5 | INDEX RANGE SCAN | SECURE_PROGRAMS_IDX_04 | 33 | 627 | 2 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | HRW_EC_ACTIVE_ITEM_IDX_03 | 1373K| 47M| 4803 (2)| 00:00:58 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$62A3881B
5 - SEL$62A3881B / SECURE_PROGRAMS@SEL$1
6 - SEL$62A3881B / HRW_EC_ACTIVE_ITEM@SEL$1
Note
- SQL profile "SYS_SQLPROF_014414387fd00001" used for this statement
SQL_ID 6vbpbvfburc4x
SELECT COUNT(SECURE_PROGRAMS.PROG_ID) FROM SECURE_PROGRAMS,HRW_EC_ACTIVE_ITEM, (SELECT ACTIVE_ITEM_ID
FROM TABLE(CAST(:B1 AS HRW_EC_ACTIVE_ITEM_ID_TABLE_T)) ) T WHERE HRW_EC_ACTIVE_ITEM.ACTIVE_ITEM_ID =
T.ACTIVE_ITEM_ID AND HRW_EC_ACTIVE_ITEM.SPROG_ID = SECURE_PROGRAMS.PROG_ID AND
SECURE_PROGRAMS.STUDENT_RESOURCES_URL = :B2
Plan hash value: 1418188916
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 2136 (100)| |
| 1 | SORT AGGREGATE | | 1 | 57 | | |
| 2 | HASH JOIN | | 3 | 171 | 2136 (1)| 00:00:26 |
| 3 | NESTED LOOPS | | 1103 | 60665 | 2111 (1)| 00:00:26 |
| 4 | INDEX RANGE SCAN | SECURE_PROGRAMS_IDX_04 | 12 | 228 | 2 (0)| 00:00:01 |
| 5 | INDEX RANGE SCAN | HRW_EC_ACTIVE_ITEM_IDX_03 | 10984 | 386K| 176 (1)| 00:00:03 |
| 6 | COLLECTION ITERATOR PICKLER FETCH| | | | | |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$62A3881B
4 - SEL$62A3881B / SECURE_PROGRAMS@SEL$1
5 - SEL$62A3881B / HRW_EC_ACTIVE_ITEM@SEL$1 Thanks,
Brian -
We are converting from a 9i database to an 11g database. The query defined works perfectly under 9i (about 1 second) but is taking 60-70 seconds to return in 11g. The wierd thing is that it has an outer query and a subquery. If I remove the where clause from the outer query it executes in less than a second. Here is the query...
SELECT period, biweek_start, biweek_end, pay_period_complete, worker_count
FROM (SELECT to_char(en.start_date, 'yyyy/mm/dd') || ' to ' ||
to_char(en.start_date + 13, 'yyyy/mm/dd') period,
en.start_date biweek_start,
en.start_date + 13 biweek_end,
decode(sign(sysdate - en.start_date - 13),
-1,
'In Progress',
'Completed') pay_period_complete,
ta_mssauth_pkg.actual_endorser(en.start_date, '33811') worker_count
FROM (select worker_id,
default_endorser resolved_endorser,
effective_date,
expiration_date
from endorse_delegate_history_v
where default_endorser = '33811'
union
select worker_id,
temporary_delegate resolved_endorser,
effective_date,
expiration_date
from endorse_delegate_history_v
where temporary_delegate = '33811'
and temporary_delegate is not null ) de,
endorse_activity_v en
WHERE en.worker_id = de.worker_id
AND en.endorse_status = 'N'
AND en.start_date <= de.expiration_date
AND en.start_date + 13 >= de.effective_date
GROUP BY en.start_date)
WHERE worker_count > 0;
The function that is used as part of the inner query to generate worker_counts is pretty complex. But it runs subsecond if you run it manually. And it works great when you run the query without the "where worker_count > 0" portion.
So the where clause on the outer query seems to be causing the problem - it is based off a function that should have calculated a value FIRST then the outer query should run based on the result of the inner query. Below are the explain plans for the two different versions:
BAD QUERY - 60 - 70 Seconds
Description Object Owner Object Name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 617 1 41
HASH GROUP BY 617 1 41
NESTED LOOPS
NESTED LOOPS 616 1 41
VIEW CA17062 58 186 4464
SORT UNIQUE 58 186 5392
UNION-ALL
TABLE ACCESS BY INDEX ROWID TAS_AUTH ENDORSE_DELEGATE_HISTORY_TBL 42 139 4170
INDEX RANGE SCAN TAS_AUTH ENDORSE_DELEGATE_HIST_DEF_IDX 3 139
TABLE ACCESS BY INDEX ROWID TAS_AUTH ENDORSE_DELEGATE_HISTORY_TBL 14 47 1222
INDEX RANGE SCAN TAS_AUTH ENDORSE_DELEGATE_HIST_TEMP_IDX 3 47
INDEX RANGE SCAN TAS_AUTH TA_SCLENDORSE_PK 2 1
TABLE ACCESS BY INDEX ROWID TAS_AUTH ENDORSE_ACTIVITY_TBL 3 1 17
GOOD QUERY < 1 second
Description Object Owner Object Name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 617 25 1025
HASH GROUP BY 617 25 1025
NESTED LOOPS
NESTED LOOPS 616 25 1025
VIEW CA17062 58 186 4464
SORT UNIQUE 58 186 5392
UNION-ALL
TABLE ACCESS BY INDEX ROWID TAS_AUTH ENDORSE_DELEGATE_HISTORY_TBL 42 139 4170
INDEX RANGE SCAN TAS_AUTH ENDORSE_DELEGATE_HIST_DEF_IDX 3 139
TABLE ACCESS BY INDEX ROWID TAS_AUTH ENDORSE_DELEGATE_HISTORY_TBL 14 47 1222
INDEX RANGE SCAN TAS_AUTH ENDORSE_DELEGATE_HIST_TEMP_IDX 3 47
INDEX RANGE SCAN TAS_AUTH TA_SCLENDORSE_PK 2 1
TABLE ACCESS BY INDEX ROWID TAS_AUTH ENDORSE_ACTIVITY_TBL 3 1 17
So those expleain plans look pretty much identical to me - can anyone tell me why having the where clause on the outer query is causing so much trouble and how I can fix it? I've tried using NO_MERGE and PUSH_SUBQ hints - but nothing that I have done has made the bad query any better.
Thanks in advance!
CoryI have traced the queries and attached the trace files here too...
Here is the bad query...
SQL ID: 0g07hqvjma217 Plan Hash: 0
alter session set sql_trace = true
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
SQL ID: 9m7787camwh4m Plan Hash: 0
begin :id := sys.dbms_transaction.local_transaction_id; end;
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 3
Fetch 0 0.00 0.00 0 0 0 0
total 6 0.00 0.00 0 0 0 3
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
SELECT period, biweek_start, biweek_end, pay_period_complete, worker_count
FROM (SELECT to_char(en.start_date, 'yyyy/mm/dd') || ' to ' ||
to_char(en.start_date + 13, 'yyyy/mm/dd') period,
en.start_date biweek_start,
en.start_date + 13 biweek_end,
decode(sign(sysdate - en.start_date - 13),
-1,
'In Progress',
'Completed') pay_period_complete,
ta_mssauth_pkg.actual_endorser(en.start_date, '33811') worker_count
FROM (select worker_id,
default_endorser resolved_endorser,
effective_date,
expiration_date
from endorse_delegate_history_v
where default_endorser = '33811'
union
select worker_id,
temporary_delegate resolved_endorser,
effective_date,
expiration_date
from endorse_delegate_history_v
where temporary_delegate = '33811'
and temporary_delegate is not null ) de,
endorse_activity_v en
WHERE en.worker_id = de.worker_id
AND en.endorse_status = 'N'
AND en.start_date <= de.expiration_date
AND en.start_date + 13 >= de.effective_date
GROUP BY en.start_date)
WHERE worker_count > 0
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 6.11 14.77 38 455 0 6
total 3 6.11 14.77 38 455 0 6
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
6 6 6 HASH GROUP BY (cr=9330657 pr=826 pw=0 time=86392712 us cost=698 size=41 card=1)
21 21 21 NESTED LOOPS (cr=9330657 pr=826 pw=0 time=18442971 us)
49 49 49 NESTED LOOPS (cr=9330609 pr=826 pw=0 time=26482026 us cost=697 size=41 card=1)
213 213 213 VIEW (cr=32 pr=32 pw=0 time=851827 us cost=58 size=5112 card=213)
213 213 213 SORT UNIQUE (cr=32 pr=32 pw=0 time=850864 us cost=58 size=5598 card=213)
213 213 213 UNION-ALL (cr=32 pr=32 pw=0 time=4390885 us)
15 15 15 TABLE ACCESS BY INDEX ROWID ENDORSE_DELEGATE_HISTORY_TBL (cr=10 pr=10 pw=0 time=718114 us c)
15 15 15 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_DEF_IDX (cr=3 pr=3 pw=0 time=119582 us cost=3 size=)
198 198 198 TABLE ACCESS BY INDEX ROWID ENDORSE_DELEGATE_HISTORY_TBL (cr=22 pr=22 pw=0 time=7328583 us )
198 198 198 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_TEMP_IDX (cr=3 pr=3 pw=0 time=107110 us cost=3 size)
49 49 49 INDEX RANGE SCAN TA_SCLENDORSE_PK (cr=9330577 pr=794 pw=0 time=157121745 us cost=2 size=0 card)
21 21 21 TABLE ACCESS BY INDEX ROWID ENDORSE_ACTIVITY_TBL (cr=48 pr=0 pw=0 time=493 us cost=3 size=17 ca)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
6 HASH (GROUP BY)
21 NESTED LOOPS
49 NESTED LOOPS
213 VIEW
213 SORT (UNIQUE)
213 UNION-ALL
15 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
15 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_DEF_IDX' (INDEX)
198 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
198 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_TEMP_IDX' (INDEX)
49 INDEX MODE: ANALYZED (RANGE SCAN) OF 'TA_SCLENDORSE_PK'
(INDEX (UNIQUE))
21 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_ACTIVITY_TBL' (TABLE)
SQL ID: gwpkaabt9naxy Plan Hash: 2668568437
SELECT DISTINCT DE.WORKER_ID
FROM
ENDORSE_DELEGATE_HISTORY_V DE , ENDORSE_ACTIVITY_V EN ,
WORKER_ACTIVITY_AUTH_V EA WHERE DE.WORKER_ID = EN.WORKER_ID AND
EN.WORKER_ID = EA.WORKER_ID AND EN.START_DATE = :B2 AND EN.ENDORSE_STATUS =
'N' AND EA.ACTIVITY_DATE >= EN.START_DATE AND EA.ACTIVITY_DATE <=
EN.START_DATE + 13 AND EN.START_DATE <= DE.EXPIRATION_DATE AND
EN.START_DATE + 13 >= DE.EFFECTIVE_DATE AND (DE.DEFAULT_ENDORSER = :B1 OR
DE.TEMPORARY_DELEGATE = :B1 ) ORDER BY DE.WORKER_ID
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 24015 0.97 1.50 0 0 0 0
Fetch 24015 56.38 132.62 593 9318744 0 285
total 48031 57.35 134.12 593 9318744 0 285
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 3054 (TAS_AUTH) (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
0 0 0 SORT UNIQUE (cr=407 pr=43 pw=0 time=1057475 us cost=805 size=83 card=1)
0 0 0 NESTED LOOPS (cr=407 pr=43 pw=0 time=1057453 us cost=804 size=17347 card=209)
0 0 0 HASH JOIN RIGHT ANTI (cr=407 pr=43 pw=0 time=1057442 us cost=804 size=16511 card=209)
19 19 19 INDEX RANGE SCAN INDACC_02X (cr=1 pr=0 pw=0 time=78 us cost=1 size=114 card=19)(object id 5403)
0 0 0 NESTED LOOPS (cr=406 pr=43 pw=0 time=1055235 us)
0 0 0 NESTED LOOPS (cr=406 pr=43 pw=0 time=1055231 us cost=803 size=19856 card=272)
0 0 0 NESTED LOOPS (cr=406 pr=43 pw=0 time=1055226 us cost=431 size=350 card=7)
186 186 186 TABLE ACCESS BY INDEX ROWID ENDORSE_DELEGATE_HISTORY_TBL (cr=32 pr=0 pw=0 time=4375 us cost)
213 213 213 BITMAP CONVERSION TO ROWIDS (cr=6 pr=0 pw=0 time=759 us)
1 1 1 BITMAP OR (cr=6 pr=0 pw=0 time=533 us)
1 1 1 BITMAP CONVERSION FROM ROWIDS (cr=3 pr=0 pw=0 time=178 us)
15 15 15 SORT ORDER BY (cr=3 pr=0 pw=0 time=152 us)
15 15 15 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_DEF_IDX (cr=3 pr=0 pw=0 time=62 us cost=3 size=)
1 1 1 BITMAP CONVERSION FROM ROWIDS (cr=3 pr=0 pw=0 time=328 us)
198 198 198 SORT ORDER BY (cr=3 pr=0 pw=0 time=319 us)
198 198 198 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_TEMP_IDX (cr=3 pr=0 pw=0 time=214 us cost=3 siz)
0 0 0 TABLE ACCESS BY INDEX ROWID ENDORSE_ACTIVITY_TBL (cr=374 pr=43 pw=0 time=1052137 us cost=2 )
0 0 0 INDEX UNIQUE SCAN TA_SCLENDORSE_PK (cr=374 pr=43 pw=0 time=1051749 us cost=1 size=0 card=1)
0 0 0 INDEX RANGE SCAN WORKER_ACTIVITY_WRKR_IX (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=90)(ob)
0 0 0 TABLE ACCESS BY INDEX ROWID WORKER_ACTIVITY_TBL (cr=0 pr=0 pw=0 time=0 us cost=53 size=943 ca)
0 0 0 INDEX UNIQUE SCAN SCHEDULE_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=4 card=1)(object id 54342)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (UNIQUE)
0 CONCATENATION
0 NESTED LOOPS (ANTI)
19 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
186 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_TEMP_IDX' (INDEX)
213 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_ACTIVITY_TBL' (TABLE)
1 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'TA_SCLENDORSE_PK' (INDEX (UNIQUE))
1 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'WORKER_ACTIVITY_TBL' (TABLE)
15 INDEX MODE: ANALYZED (RANGE SCAN) OF
'WORKER_ACTIVITY_WRKR_IX' (INDEX)
15 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'SCHEDULE_PK'
(INDEX (UNIQUE))
1 INDEX MODE: ANALYZED (RANGE SCAN) OF 'INDACC_02X' (INDEX)
198 NESTED LOOPS (ANTI)
198 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_DEF_IDX' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_ACTIVITY_TBL' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'TA_SCLENDORSE_PK' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'WORKER_ACTIVITY_TBL' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'WORKER_ACTIVITY_WRKR_IX' (INDEX)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'SCHEDULE_PK'
(INDEX (UNIQUE))
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'INDACC_02X' (INDEX)
SQL ID: 7v8ndut1y3b99 Plan Hash: 2002979989
SELECT DEFAULT_ENDORSER
FROM
( SELECT DEFAULT_ENDORSER FROM ENDORSE_DELEGATE_HISTORY_V WHERE WORKER_ID =
:B3 AND TEMPORARY_DELEGATE IS NULL AND :B2 <= EXPIRATION_DATE AND :B1 >=
EFFECTIVE_DATE ORDER BY EXPIRATION_DATE DESC ) WHERE ROWNUM = 1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 285 0.00 0.01 0 0 0 0
Fetch 285 0.11 3.24 195 13078 0 285
total 571 0.11 3.26 195 13078 0 285
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 3054 (TAS_AUTH) (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 COUNT STOPKEY (cr=22 pr=20 pw=0 time=576320 us)
1 1 1 VIEW (cr=22 pr=20 pw=0 time=576285 us cost=23 size=72 card=12)
1 1 1 SORT ORDER BY STOPKEY (cr=22 pr=20 pw=0 time=576273 us cost=23 size=396 card=12)
2 2 2 TABLE ACCESS BY INDEX ROWID ENDORSE_DELEGATE_HISTORY_TBL (cr=22 pr=20 pw=0 time=576205 us cost)
20 20 20 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_PK (cr=3 pr=3 pw=0 time=197569 us cost=3 size=0 card=1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 COUNT (STOPKEY)
1 VIEW
1 SORT (ORDER BY STOPKEY)
2 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
20 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_PK' (INDEX (UNIQUE))
SQL ID: cf06fwacdmgfk Plan Hash: 1546270724
select 'x'
from
dual
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 1
total 3 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 FAST DUAL (cr=0 pr=0 pw=0 time=6 us cost=2 size=0 card=1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 FAST DUAL
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 5 0.00 0.00 0 0 0 0
Execute 6 0.00 0.00 0 0 0 3
Fetch 2 6.11 14.77 38 455 0 7
total 13 6.11 14.77 38 455 0 10
Misses in library cache during parse: 0
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 24300 0.97 1.51 0 0 0 0
Fetch 24300 56.49 135.87 788 9331822 0 570
total 48602 57.46 137.39 788 9331822 0 570
Misses in library cache during parse: 0
6 user SQL statements in session.
0 internal SQL statements in session.
6 SQL statements in session.
4 statements EXPLAINed in this session.
Trace file: TAST_ora_26885.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
6 user SQL statements in trace file.
0 internal SQL statements in trace file.
6 SQL statements in trace file.
6 unique SQL statements in trace file.
4 SQL statements EXPLAINed using schema:
dbo.plan_table
Schema was specified.
Existing table was used.
73341 lines in trace file.
178 elapsed seconds in trace file.
Here is the good query
SQL ID: 0g07hqvjma217 Plan Hash: 0
alter session set sql_trace = true
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
SQL ID: 9m7787camwh4m Plan Hash: 0
begin :id := sys.dbms_transaction.local_transaction_id; end;
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 3
Fetch 0 0.00 0.00 0 0 0 0
total 6 0.00 0.00 0 0 0 3
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
SELECT period, biweek_start, biweek_end, pay_period_complete, worker_count
FROM (SELECT to_char(en.start_date, 'yyyy/mm/dd') || ' to ' ||
to_char(en.start_date + 13, 'yyyy/mm/dd') period,
en.start_date biweek_start,
en.start_date + 13 biweek_end,
decode(sign(sysdate - en.start_date - 13),
-1,
'In Progress',
'Completed') pay_period_complete,
ta_mssauth_pkg.actual_endorser(en.start_date, '33811') worker_count
FROM (select worker_id,
default_endorser resolved_endorser,
effective_date,
expiration_date
from endorse_delegate_history_v
where default_endorser = '33811'
union
select worker_id,
temporary_delegate resolved_endorser,
effective_date,
expiration_date
from endorse_delegate_history_v
where temporary_delegate = '33811'
and temporary_delegate is not null ) de,
endorse_activity_v en
WHERE en.worker_id = de.worker_id
AND en.endorse_status = 'N'
AND en.start_date <= de.expiration_date
AND en.start_date + 13 >= de.effective_date
GROUP BY en.start_date)
-- WHERE worker_count > 0
call count cpu elapsed disk query current rows
Parse 1 0.02 0.03 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.02 0.13 0 841 0 6
total 3 0.04 0.16 0 841 0 6
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 331 (CA17062)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
6 6 6 HASH GROUP BY (cr=841 pr=0 pw=0 time=79927 us cost=617 size=1025 card=25)
21 21 21 NESTED LOOPS (cr=841 pr=0 pw=0 time=15116 us)
451 451 451 NESTED LOOPS (cr=409 pr=0 pw=0 time=33039 us cost=616 size=1025 card=25)
213 213 213 VIEW (cr=32 pr=0 pw=0 time=12117 us cost=58 size=4464 card=186)
213 213 213 SORT UNIQUE (cr=32 pr=0 pw=0 time=12005 us cost=58 size=5392 card=186)
213 213 213 UNION-ALL (cr=32 pr=0 pw=0 time=1313 us)
15 15 15 TABLE ACCESS BY INDEX ROWID ENDORSE_DELEGATE_HISTORY_TBL (cr=10 pr=0 pw=0 time=245 us cost=4
2 size=4170 card=139)
15 15 15 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_DEF_IDX (cr=3 pr=0 pw=0 time=122 us cost=3 size=0 ca
rd=139)(object id 54559)
198 198 198 TABLE ACCESS BY INDEX ROWID ENDORSE_DELEGATE_HISTORY_TBL (cr=22 pr=0 pw=0 time=427 us cost=1
4 size=1222 card=47)
198 198 198 INDEX RANGE SCAN ENDORSE_DELEGATE_HIST_TEMP_IDX (cr=3 pr=0 pw=0 time=222 us cost=3 size=0 c
ard=47)(object id 54560)
451 451 451 INDEX RANGE SCAN TA_SCLENDORSE_PK (cr=377 pr=0 pw=0 time=63328 us cost=2 size=0 card=1)(object
id 54553)
21 21 21 TABLE ACCESS BY INDEX ROWID ENDORSE_ACTIVITY_TBL (cr=432 pr=0 pw=0 time=2185 us cost=3 size=17 c
ard=1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
6 HASH (GROUP BY)
21 NESTED LOOPS
451 NESTED LOOPS
213 VIEW
213 SORT (UNIQUE)
213 UNION-ALL
15 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
15 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_DEF_IDX' (INDEX)
198 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_DELEGATE_HISTORY_TBL' (TABLE)
198 INDEX MODE: ANALYZED (RANGE SCAN) OF
'ENDORSE_DELEGATE_HIST_TEMP_IDX' (INDEX)
451 INDEX MODE: ANALYZED (RANGE SCAN) OF 'TA_SCLENDORSE_PK'
(INDEX (UNIQUE))
21 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'ENDORSE_ACTIVITY_TBL' (TABLE)
SQL ID: gwpkaabt9naxy Plan Hash: 2668568437
SELECT DISTINCT DE.WORKER_ID
FROM
ENDORSE_DELEGATE_HISTORY_V DE , ENDORSE_ACTIVITY_V EN ,
WORKER_ACTIVITY_AUTH_V EA WHERE DE.WORKER_ID = EN.WORKER_ID AND
EN.WORKER_ID = EA.WORKER_ID AND EN.START_DATE = :B2 AND EN.ENDORSE_STATUS =
'N' AND EA.ACTIVITY_DATE >= EN.START_DATE AND EA.ACTIVITY_DATE <=
EN.START_DATE + 13 AND EN.START_DATE <= DE.EXPIRATION_DATE AND
EN.START_DATE + 13 >= DE.EFFECTIVE_DATE AND (DE.DEFAULT_ENDORSER = :B1 OR
DE.TEMPORARY_DELEGATE = :B1 ) ORDER BY DE.WORKER_ID
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 6 0.01 0.00 0 0 0 0
Fetch 6 0.01 0.01 0 700 -
Hi,
I need your advise on the following queries (using Oracle EBS tables). I runs more than one hour for the subquery part only. I would like to achieve much faster result. I appreciate if anyone can help me tuning this query.
SELECT item_id, item_code, org_id,
CASE
WHEN COUNT (a) = 6
THEN 1
WHEN COUNT (a) = 5
THEN 2
WHEN COUNT (a) = 3 OR COUNT (a) = 4
THEN 3
WHEN COUNT (a) = 1 OR COUNT (a) = 2
THEN 4
END "MC"
FROM (SELECT oel.inventory_item_id item_id, msi.segment1 item_code,
oel.ship_from_org_id org_id, SUM (oel.ordered_quantity) a,
TO_CHAR (oel.request_date, 'Mon-YYYY') b
FROM mtl_system_items_b msi,
mtl_item_categories mic,
oe_order_headers_all oeh,
oe_order_lines_all oel
WHERE oeh.header_id = oel.header_id
AND oel.request_date BETWEEN TRUNC (ADD_MONTHS (LAST_DAY (SYSDATE), -7)) + 1
AND TRUNC (ADD_MONTHS (LAST_DAY (SYSDATE), -1)) + 1
AND msi.creation_date < TRUNC (ADD_MONTHS (LAST_DAY (SYSDATE), -7)) + 1
AND oel.ship_from_org_id = msi.organization_id
AND oeh.header_id = oel.header_id
AND oel.inventory_item_id = msi.inventory_item_id
AND msi.inventory_item_id = mic.inventory_item_id
AND msi.organization_id = mic.organization_id
AND mic.category_set_id = 1
AND mic.category_id = 178
AND oel.org_id = oeh.org_id
GROUP BY oel.inventory_item_id,
msi.segment1,
oel.ship_from_org_id,
TO_CHAR (oel.request_date, 'Mon-YYYY'))
GROUP BY item_id, item_code, org_id
Here is the explain plan for the query, seems OK, but the query took so much time.
Plan
SELECT STATEMENT CHOOSECost: 3,955 Bytes: 38 Cardinality: 1
15 SORT GROUP BY Cost: 3,955 Bytes: 38 Cardinality: 1
14 VIEW APPS. Cost: 3,955 Bytes: 38 Cardinality: 1
13 SORT GROUP BY Cost: 3,955 Bytes: 91 Cardinality: 1
12 FILTER
11 NESTED LOOPS Cost: 3,908 Bytes: 91 Cardinality: 1
8 NESTED LOOPS Cost: 3,907 Bytes: 82 Cardinality: 1
5 NESTED LOOPS Cost: 1,303 Bytes: 1,612 Cardinality: 31
2 TABLE ACCESS BY INDEX ROWID INV.MTL_ITEM_CATEGORIES Cost: 59 Bytes: 11,818 Cardinality: 622
1 INDEX SKIP SCAN NON-UNIQUE INV.MTL_ITEM_CATEGORIES_N1 Cost: 42 Cardinality: 622
4 TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B Cost: 2 Bytes: 33 Cardinality: 1
3 INDEX UNIQUE SCAN UNIQUE INV.MTL_SYSTEM_ITEMS_B_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL Cost: 84 Bytes: 30 Cardinality: 1
6 INDEX RANGE SCAN NON-UNIQUE ONT.OE_ORDER_LINES_N3 Cost: 2 Cardinality: 94
10 TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 9 Cardinality: 1
9 INDEX UNIQUE SCAN UNIQUE ONT.OE_ORDER_HEADERS_U1 Cardinality: 1
Thanks in advance,
Dapid CandraCheck out these links on how to post proper tuning requests.
{message:id=1812597}
{thread:id=863295}
After a quick look at your execution plan I noticed you have a lot of steps that report a cardinality of 1. Do you know if statistics have been gathered recently on these tables? If not, you probably should. -
Tuning SQL | Partition Table | MJC
All good hearted people -
Problem :- This SQL runs forever and returns nothing when STATS are stale. If I collect the table level stats (dbms_stats) on these partitioned table it runs again as normal (< 2 minutes).
I see Merge Join cartesian in the explain plan when it runs bad. After the stats done, this MJC disappeared from the plan and things back to normal.
Also, If convert one of those partition into a regular table(amms partition 2010-03-16 ) and join to the other partition table's (cust ) partition this works fine.
Note : After every load we run partition level stats on these tables (not table level stats).
My question is why am I getting MJC? How to solve this issue?
<code>
select aln.acct_no as acct_no, aln.as_of_dt, max(acm.appno) as appno, count( * )
from amr.amms aln, acr.cust acm <================= both tables are range partitioned by date
where acm.acctno = aln.acct_no
and acm.acctno > 0
and acm.as_of_dt = date '2010-03-16' <============ partition key on cust table < 2M rows
and aln.as_of_dt = date '2010-03-12' < ============= partition key on amms table < 2M rows
group by aln.acct_no, aln.as_of_dt
having count( * ) = 1
</code>
Env: Oracle 10g | 10.2.0.4 | ASM | 2 node RAC | Linux x86 | Archivelog | Partition | Optimizer Choose |and acm.as_of_dt = date '2010-03-16'
and aln.as_of_dt = date '2010-03-12' not valid syntax! -
Tuning SQL query with similar subqueries for select columns
Hi all,
My query is something like below:
1> SELECT
2> A.COL1,
3> SUM(CASE WHEN A.flag=100 AND NVL(B.flag,0)=0 AND
4> EXISTS (
5> SELECT 'ROW_EXISTS'
6> FROM A A0
7> WHERE A0.COL2=100 AND NVL(A0.flag,0)=0 AND 0.DIRN<>A.DIRN)
8> THEN 1
9> ELSE 0
10> END) SUM_COLUMN1,
11>SUM(CASE WHEN A.flag=100 AND
12> EXISTS (
13> SELECT 'ROW_EXISTS'
14> FROM A A0
15> WHERE A0.COL2=100 AND A0.DIRN<>A.DIRN)
16> THEN 1
17> ELSE 0
18>END) SUM_COLUMN2
19>FROM A,B
20>WHERE A.COL=B.KEY_COL
21>GROUP BY A.COL1
My problem is that I need to index scan the tables A aliased as A0 in the two exist queries. Lines: 5-7 and 13-15.
The major performance degradation i see with the query is that it has to scan A0 twice to compute SUM_COLUMN1 and SUM_COLUMN2.
Is there any way by which i can use the same subquery to scan the table just once to compute the columns.
The table A has more than a 100million records. So i need to improve performance of this query though it is a small issue.
Please feel free to ask me more if i'm not clear with the example.
Thanks in advance,
RajAlso you could use analytic functions:
SQL> select deptno, sum(case when e.mgr is not null and
2 exists (select 1 from emp e1 where e1.empno <> e.empno
3 and e1.deptno = 10 and e1.sal >= 1500)
4 then 1 else 0 end) sum1,
5 sum(case when e.mgr is not null and e.sal >= 1200 and
6 exists (select 1 from emp e1 where e1.empno <> e.empno and e1.deptno = 10)
7 then 1 else 0 end) sum2
8 from emp e
9 group by deptno
10 /
DEPTNO SUM1 SUM2
10 2 2
20 5 3
30 6 5
SQL> select deptno, sum(case when mgr is not null and
2 (d12 != empno or empno !=d11) then 1 else 0 end) sum1,
3 sum(case when mgr is not null and (d21 != empno or empno !=d22)
4 and sal >= 1200 then 1 else 0 end) sum2
5 from (
6 select deptno, empno, mgr, sal,
7 min(case when deptno = 10 and sal >= 1500
8 then empno else -1 end) over(order by null) d11,
9 max(case when deptno = 10 and sal >= 1500
10 then empno else -1 end) over(order by null) d12,
11 min(case when deptno = 10 then empno else -1 end) over(order by null) d21,
12 max(case when deptno = 10 then empno else -1 end) over(order by null) d22
13 from emp e
14 )
15 group by deptno
16 /
DEPTNO SUM1 SUM2
10 2 2
20 5 3
30 6 5In your case it could be something like
SELECT COL1,
SUM( CASE WHEN a_flag = 100 and nvl(b_flag,0)=0 and
(DIRN != MIN_A OR DIRN != MAX_A) THEN 1 ELSE 0 END) SUM_COLUMN1,
SUM( CASE WHEN a_flag = 100 and
(DIRN != MIN_B OR DIRN != MAX_B) THEN 1 ELSE 0 END) SUM_COLUMN2
FROM (
SELECT A.COL1, A.FLAG A_FLAG, B.FLAG B_FLAG, A.DIRN,
MIN(CASE WHEN A.COL2=100 and NVL(A.flag,0) = 0 THEN A.DIRN ELSE null END) OVER(order by null) MIN_A,
MAX(CASE WHEN A.COL2=100 and NVL(A.flag,0) = 0 THEN A.DIRN ELSE null END) OVER(order by null) MAX_A,
MIN(CASE WHEN A.COL2=100 THEN A.DIRN ELSE null END) OVER(order by null) MIN_B,
MAX(CASE WHEN A.COL2=100 THEN A.DIRN ELSE null END) OVER(order by null) MAX_B
FROM A,B
WHERE A.COL=B.KEY_COL
GROUP BY COL1
Rgds.
Maybe you are looking for
-
Flat file extraction with FILE
Hi BWers, I want to extract a flat file to BW with an infopackage. This flat file is located in a physical path changing according to the system : - in the developpment server, path is : ...\dev\file.csv - in the quality server, path is : ...\qual\fi
-
Not able to deploy BPM Process
HI, while deploying the bpm process i am getting the error i.e [06:41:46 PM] Error deploying archive sca_ArCnWorkflow_rev1.0.jar to partition "default" on server AdminServer [http://ddrvaka:7001] [06:41:46 PM] HTTP error code returned [500] [06:41:46
-
Advice/howto on disorganised photos that need to be imported into Aperture
I have about 5-6 years of photos that are in different folders across my backup hard drives that I want to import into Aperture. There are many duplicates as I had working folders that I copied periodically onto external drives into dated backup fold
-
Stock transfer from storage bin to another storage bin.
Hi, i would like to know the method to be followed in order to transfer the materials from one storage bin to another within the warehouse and also within a storage type. Also i would like to know how to transfer the material from one storage type to
-
Hello, 1. Does anyone know if it is possible to access, edit or delete titles, page #, DCF ID, Revision #, or otherwise all system sections which appear on DCF report form other than Header, Footer, DCM Section, Comment section and Resolution section