Suggetion For below query tuning...
Can any one suggest what to tune for following query...
Query:
SQL> SELECT count(1)
2 FROM SCOTT.IVR_CALL_MASTER
3 WHERE STARTDATETIME BETWEEN '01-Dec-2007' AND '31-Dec-2007'
4 AND SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1),LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1)
5 LIKE ';2%'
6 AND CALLENDREASON < '6'
7 AND ACCOUNTNUMBER IS NOT NULL
8 AND SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1), LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1)
9 NOT IN (';2',';21',';113')
10 /
COUNT(1)
687156
Elapsed: 00:10:02.06
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=91867 Card=1 Bytes=2
6)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'IVR_CALL_MASTER' (Cost
=91867 Card=1 Bytes=26)
3 2 INDEX (RANGE SCAN) OF 'IND_MAS_DAT' (NON-UNIQUE) (Cost
=311 Card=116534)
Statistics
0 recursive calls
0 db block gets
8392293 consistent gets
216218 physical reads
0 redo size
381 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Table_statistics:
♀OWNER EMPTY_BLOCKS BLOCKS NUM_ROWS LAST_ANAL INI_TRANS FREELISTS PCT_FREE AVG_SPACE
SCOTT 0 605599 32713980 01-JUL-07 1 1 10 0
Column_Stats:
♀COLUMN_NAME NUM_DISTINCT
ACCOUNTNUMBER 1932852
AUTHFAILREASON 3
AUTHFLAG 3
CALLENDREASON 7
CALLID 0
CLI 2672332
CRN 1130007
DESTVDN 64
DURATIONOFCALL 1063
ENDDATETIME 6518689
ENDTIME 85257
FIRSTTIMEFLAG 7
LANGUAGE 2
LINENO 240
ORIGINVDN 320
PRU_AGENTMENU 1
PRU_FOLIO 1
PRU_VM 1
STARTDATETIME 6447794
STARTTIME 85277
TRANVERSEPATH1 22338
TRANVERSEPATH2 15138
VPS_NO 7
Index_columns:
♀INDEX_NAME COLUMN_NAME COLUMN_POSITION
INDX3 CRN 1
IND_MAS_ACCNO ACCOUNTNUMBER 1
IND_MAS_CLI CLI 1
IND_MAS_DAT STARTDATETIME 1
[post]
Thanks in Advance.
I'm not sure if that will help, you'll need to test it out.
When I mean is that
SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1),
LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1) LIKE ';2%'
includes everything that being with ";2", but then you exclude three cases with this:
SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1), LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1) NOT IN (';2',';21',';113')
';113' isn't like ';2%' so it isn't included to begin with.
depending on how many "like ';2%'" values you have, it may be quicker to use an "IN" clause with just the ones you want, for example:
substr(tranversepath1,instr(tranversepath1,';',-1,1), length(tranversepath1)-instr(tranversepath1,';',-1,1)+1) in (';22',';20',';213')
Similar Messages
-
Please reply for the query tuning
Hi, i am a beginner in oracle dba, I have to know if i have studied little bit about query tuning in ORACLE.
I wanna know if i have the following query and its plan then how it can be tuned:
QUERY:
SELECT z.emplid ,h.first_name || ' ' || h.last_name ,z.grade ,z.DEPTID ,z.LOCATION
FROM sysadm.ps_lnt_latestbu_vw z, sysadm.ps_personal_data h
WHERE z.empl_status ='A' --index access
AND z.emplid = h.emplid --join
and z.emplid not in (select g.emplid from sysadm.ps_lnt_asn_skl_tbl g) --join
and z.Business_unit=
( select l.lnt_subunit from sysadm.ps_position_data l where l.position_nbr in
( select b.position_nbr from sysadm.ps_job b,sysadm.psoprdefn y
where b.effdt=( select max(g.effdt) from sysadm.ps_job g
where g.emplid=b.emplid --join costs high
and g.effdt<=SYSDATE) --filter/index
and b.effseq=
(select max(h.effseq) from sysadm.ps_job h
where h.emplid=b.emplid --join costs high
and h.effdt=b.effdt) --join costs high
and b.empl_rcd=0 --filter/index access
and y.EMPLID=b.EMPLID --join
and y.OPRID='1112' -- filter/index access
order by z.emplid
/AND its plan is:
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1 Bytes=64)
1 0 SORT (ORDER BY) (Cost=6 Card=1 Bytes=64)
2 1 NESTED LOOPS (ANTI) (Cost=4 Card=1 Bytes=64)
3 2 NESTED LOOPS (Cost=3 Card=1 Bytes=56)
4 3 VIEW OF 'PS_LNT_LATESTBU_VW' (Cost=2 Card=1 Bytes=31)
5 4 UNION-ALL
6 5 CONCATENATION
7 6 TABLE ACCESS (BY INDEX ROWID) OF 'PS_POSITION_DATA' (Cost=5 Card=90 Bytes=1890)
8 7 NESTED LOOPS
9 8 NESTED LOOPS (Cost=275 Card=1 Bytes=90)
10 9 NESTED LOOPS (Cost=275 Card=1 Bytes=82)
11 10 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=50)
12 11 INDEX (RANGE SCAN) OF 'PS2JOB' (NON-UNIQUE) (Cost=2 Card=1)
13 12 SORT (AGGREGATE)
14 13 FIRST ROW (Cost=3 Card=1 Bytes=19)
15 14 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
16 12 SORT (AGGREGATE)
17 16 FIRST ROW (Cost=3 Card=1 Bytes=22)
18 17 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
19 10 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT'(UNIQUE)
20 9 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
21 8 INDEX (RANGE SCAN) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=5 Card=90)
22 6 FILTER
23 22 NESTED LOOPS (Cost=275 Card=1 Bytes=90)
24 23 NESTED LOOPS (Cost=275 Card=1 Bytes=82)
25 24 NESTED LOOPS (Cost=275 Card=1 Bytes=71)
26 25 INDEX (FAST FULL SCAN) OF 'PS8POSITION_DATA' (NON-UNIQUE) (Cost=5 Card=90 Bytes=1890)
27 25 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=50)
28 27 INDEX (RANGE SCAN) OF 'PS2JOB' (NON-UNIQUE) (Cost=2 Card=1)
29 28 SORT (AGGREGATE)
30 29 FIRST ROW (Cost=3 Card=1 Bytes=22)
31 30 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
32 28 SORT (AGGREGATE)
33 32 FIRST ROW (Cost=3 Card=1 Bytes=19)
34 33 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
35 24 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT' (UNIQUE)
36 23 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA'(UNIQUE)
37 22 SORT (AGGREGATE)
38 37 FIRST ROW (Cost=2 Card=1 Bytes=17)
39 38 INDEX (RANGE SCAN (MIN/MAX)) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=2 Card=9000)
40 5 FILTER
41 40 NESTED LOOPS (Cost=751 Card=1 Bytes=191)
42 41 NESTED LOOPS (OUTER) (Cost=750 Card=1 Bytes=167)
43 42 NESTED LOOPS (OUTER) (Cost=749 Card=1 Bytes=143)
44 43 NESTED LOOPS (Cost=748 Card=1 Bytes=134)
45 44 NESTED LOOPS (Cost=748 Card=1 Bytes=123)
46 45 NESTED LOOPS (Cost=748 Card=1 Bytes=119)
47 46 NESTED LOOPS (Cost=747 Card=1 Bytes=98)
48 47 NESTED LOOPS (Cost=744 Card=1 Bytes=62)
49 48 NESTED LOOPS (Cost=744 Card=1Bytes=54)
50 49 VIEW OF 'PS_LNTPRJOBSYSJRVW'(Cost=741 Card=1 Bytes=9)
51 50 FILTER
52 51 NESTED LOOPS (OUTER) (Cost=735 Card=1 Bytes=68)
53 52 NESTED LOOPS (Cost=734Card=1 Bytes=51)
54 53 NESTED LOOPS (Cost=734 Card=1 Bytes=43)
55 54 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=734 Card=1 Bytes=32)
56 55 INDEX (RANGE SCAN) OF 'PSCJOB' (NON-UNIQUE) (Cost=206 Card=1013)
57 54 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT' (UNIQUE)
58 53 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
59 52 INDEX (RANGE SCAN) OF'PS_POSITION_DATA' (UNIQUE) (Cost=1 Card=1 Bytes=17)
60 51 SORT (AGGREGATE)
61 60 FIRST ROW (Cost=3 Card=1 Bytes=19)
62 61 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
63 51 SORT (AGGREGATE)
64 63 FIRST ROW (Cost=3 Card=1 Bytes=22)
65 64 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
66 51 SORT (AGGREGATE)
67 66 FIRST ROW (Cost=2 Card=1 Bytes=17)
68 67 INDEX (RANGE SCAN (MIN/MAX)) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=2 Card=9000)
69 49 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=45)
70 69 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=2 Card=1)
71 70 SORT (AGGREGATE)
72 71 INDEX (RANGE SCAN) OF'PSAJOB' (NON-UNIQUE) (Cost=3 Card=1 Bytes=19)
73 72 SORT (AGGREGATE)
74 73 FIRST ROW (Cost=3Card=8 Bytes=88)
75 74 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=25963)
76 70 SORT (AGGREGATE)
77 76 FIRST ROW (Cost=3 Card=8 Bytes=88)
78 77 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=25963)
79 48 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
80 47 TABLE ACCESS (BY INDEX ROWID) OF'PS_JOB' (Cost=3 Card=1 Bytes=36)
81 80 INDEX (RANGE SCAN) OF 'PSAJOB'(NON-UNIQUE) (Cost=2 Card=1)
82 81 SORT (AGGREGATE)
83 82 FIRST ROW (Cost=3 Card=1 Bytes=19)
84 83 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
85 81 SORT (AGGREGATE)
86 85 FIRST ROW (Cost=3 Card=1 Bytes=22)
87 86 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
88 46 INDEX (RANGE SCAN) OF 'PS8POSITION_DATA' (NON-UNIQUE) (Cost=1 Card=1 Bytes=21)
89 45 INDEX (UNIQUE SCAN) OF 'PS_BUS_UNIT_TBL_HR' (UNIQUE)
90 44 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT'(UNIQUE)
91 43 INDEX (RANGE SCAN) OF 'PS_POSITION_DATA'(UNIQUE) (Cost=1 Card=1 Bytes=9)
92 42 INDEX (FULL SCAN) OF 'PS0LOCATION_TBL' (NON-UNIQUE) (Cost=1 Card=1 Bytes=24)
93 41 INDEX (RANGE SCAN) OF 'PS0LOCATION_TBL' (NON-UNIQUE) (Cost=1 Card=1 Bytes=24)
94 40 SORT (AGGREGATE)
95 94 FIRST ROW (Cost=2 Card=1 Bytes=17)
96 95 INDEX (RANGE SCAN (MIN/MAX)) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=2 Card=9000)
97 4 TABLE ACCESS (BY INDEX ROWID) OF 'PS_POSITION_DATA' (Cost=2 Card=1 Bytes=13)
98 97 NESTED LOOPS (Cost=9 Card=1 Bytes=19)
99 98 VIEW OF 'VW_NSO_1' (Cost=5 Card=1 Bytes=6)
100 99 SORT (UNIQUE)
101 100 NESTED LOOPS (Cost=5 Card=1 Bytes=44)
102 101 TABLE ACCESS (BY INDEX ROWID) OF 'PSOPRDEFN' (Cost=2 Card=1 Bytes=14)
103 102 INDEX (UNIQUE SCAN) OF 'PS_PSOPRDEFN'(UNIQUE) (Cost=1 Card=1)
104 101 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=30)
105 104 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=2 Card=1)
106 105 SORT (AGGREGATE)
107 106 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=8 Bytes=128)
108 105 SORT (AGGREGATE)
109 108 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=1 Bytes=19)
110 98 INDEX (RANGE SCAN) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=1 Card=1)
111 3 TABLE ACCESS (BY INDEX ROWID) OF 'PS_PERSONAL_DATA'(Cost=1 Card=1 Bytes=25)
112 111 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
113 2 INDEX (RANGE SCAN) OF 'PS_LNT_ASN_SKL_TBL' (UNIQUE) (Cost=1 Card=10076 Bytes=80608)
Statistics
70 recursive calls
0 db block gets
1186931 consistent gets
5660 physical reads
60 redo size
462 bytes sent via SQL*Net to client
373 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
0 rows processedMy thoughts for this is:
1. NLJ high cost -- rewrite inner sub-query
2. sort is done for each join for max function every time so, therefore try use use sort merge hint
3. h alias has been referenced twice for table name.
PLEASE TELL ME WHAT TO DO IF I AM ORACLE DBA.
Thanks in advance.
Edited by: user2060331 on Mar 25, 2010 9:17 AM
Edited by: user2060331 on Mar 25, 2010 9:21 AM
Edited by: user2060331 on Mar 25, 2010 9:32 AM
Edited by: user2060331 on Mar 25, 2010 9:47 AMNo it's not. You should see indentations for each level of the explain plan. You've lost all of it. It should look like this (not your query):
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 16116 | 2911K| 712 | | |
| 1 | FILTER | | | | | | |
| 2 | CONNECT BY WITH FILTERING | | | | | | |
| 3 | FILTER | | | | | | |
| 4 | COUNT | | | | | | |
| 5 | HASH JOIN RIGHT OUTER | | 16116 | 2911K| 712 | | |
| 6 | REMOTE | LSW_USR_GRP_XREF | 518 | 13986 | 4 | MYPROJ~ | R->S |
| 7 | HASH JOIN RIGHT OUTER | | 16116 | 2486K| 707 | | |
| 8 | REMOTE | LSW_USR_XREF | 222 | 2886 | 4 | MYPROJ~ | R->S |
| 9 | HASH JOIN RIGHT OUTER| | 16116 | 2282K| 702 | | |
| 10 | TABLE ACCESS FULL | MYPROJ_PROCESS_MAP | 176 | 4752 | 4 | | |
| 11 | HASH JOIN OUTER | | 16116 | 1857K| 698 | | |
| 12 | TABLE ACCESS FULL | MYPROJ_MPPA | 16116 | 1243K| 71 | | |
| 13 | REMOTE | LSW_TASK | 80730 | 3074K| 625 | MYPROJ~ | R->S |
| 14 | HASH JOIN | | | | | | |
| 15 | CONNECT BY PUMP | | | | | | |
| 16 | COUNT | | | | | | |
| 17 | HASH JOIN RIGHT OUTER | | 16116 | 2911K| 712 | | |
| 18 | REMOTE | LSW_USR_GRP_XREF | 518 | 13986 | 4 | MYPROJ~ | R->S |
| 19 | HASH JOIN RIGHT OUTER | | 16116 | 2486K| 707 | | |
| 20 | REMOTE | LSW_USR_XREF | 222 | 2886 | 4 | MYPROJ~ | R->S |
| 21 | HASH JOIN RIGHT OUTER| | 16116 | 2282K| 702 | | |
| 22 | TABLE ACCESS FULL | MYPROJ_PROCESS_MAP | 176 | 4752 | 4 | | |
| 23 | HASH JOIN OUTER | | 16116 | 1857K| 698 | | |
| 24 | TABLE ACCESS FULL | MYPROJ_MPPA | 16116 | 1243K| 71 | | |
| 25 | REMOTE | LSW_TASK | 80730 | 3074K| 625 | MYPROJ~ | R->S |
--------------------------------------------------------------------------------------------------- -
Performance tuning in 11g for said query
Hello,
I have the below query which needs to be tuned:
SELECT DISTINCT a.emplid
, a.upa_fiscal_year
, b.balance_period
, 0
, a.descr
, a.UPA_CURRENT_AMT
, a.UPA_CURRENT_AMT2
, a.UPA_CURRENT_AMT3
, a.UPA_CURRENT_AMT4
FROM ps_upa_eq_incal_vw a
, ps_upa_eq_incal_vw b
WHERE a.emplid = b.emplid
AND a.UPA_FISCAL_YEAR = b.UPA_FISCAL_YEAR
AND a.balance_period = (
SELECT MAX(balance_period)
FROM ps_upa_eq_incal_vw
WHERE emplid = a.emplid
AND upa_fiscal_year = a.upa_fiscal_year
AND descr = a.descr
AND balance_period <= b.balance_period)
AND a.descr NOT IN (
SELECT DISTINCT descr
FROM ps_upa_eq_incal_vw
WHERE emplid = b.emplid
AND upa_fiscal_year = b.upa_fiscal_year
AND balance_period = b.balance_period
AND b.balance_period > a.balance_period )
UNION
SELECT emplid
, upa_fiscal_year
, balance_period
, 1
, 'Total'
, SUM ( UPA_CURRENT_AMT )
, SUM ( UPA_CURRENT_AMT2 )
, SUM ( UPA_CURRENT_AMT3 )
, SUM ( UPA_CURRENT_AMT4 )
FROM (
SELECT DISTINCT a.emplid emplid
, a.upa_fiscal_year upa_fiscal_year
, b.balance_period balance_period
, a.descr
, a.UPA_CURRENT_AMT UPA_CURRENT_AMT
, a.UPA_CURRENT_AMT2 UPA_CURRENT_AMT2
, a.UPA_CURRENT_AMT3 UPA_CURRENT_AMT3
, a.UPA_CURRENT_AMT4 UPA_CURRENT_AMT4
FROM ps_upa_eq_incal_vw a
, ps_upa_eq_incal_vw b
WHERE a.emplid = b.emplid
AND a.UPA_FISCAL_YEAR = b.UPA_FISCAL_YEAR
AND a.BALANCE_PERIOD = (
SELECT MAX(balance_period)
FROM ps_upa_eq_incal_vw
WHERE emplid = a.emplid
AND upa_fiscal_year = a.upa_fiscal_year
AND descr = a.descr
AND balance_period <= b.balance_period)
AND a.descr NOT IN (
SELECT DISTINCT descr
FROM ps_upa_eq_incal_vw
WHERE emplid = b.emplid
AND upa_fiscal_year = b.upa_fiscal_year
AND balance_period = b.balance_period
AND b.balance_period > a.balance_period ) )
GROUP BY emplid , upa_fiscal_year , balance_period;The EXPLAIN plan for this query is as under:
Plan hash value: 3550380953
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 24 | 2784 | | 429M (53)|999:59:59 |
| 1 | SORT UNIQUE | | 24 | 2784 | | 429M (53)|999:59:59 |
| 2 | UNION-ALL | | | | | | |
|* 3 | FILTER | | | | | | |
| 4 | NESTED LOOPS | | 196M| 29G| | 205M (4)|685:32:54 |
| 5 | VIEW | PS_UPA_EQ_INCAL_VW | 4513K| 146M| | 72281 (2)| 00:14:28 |
| 6 | HASH GROUP BY | | 4513K| 249M| 329M| 72281 (2)| 00:14:28 |
|* 7 | HASH JOIN | | 4513K| 249M| | 8644 (4)| 00:01:44 |
| 8 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 513 | 14364 | | 3 (0)| 00:00:01 |
|* 9 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
| 10 | VIEW PUSHED PREDICATE | PS_UPA_EQ_INCAL_VW | 1 | 127 | | 46 (5)| 00:00:01 |
| 11 | SORT GROUP BY | | 33 | 1914 | | 46 (5)| 00:00:01 |
|* 12 | HASH JOIN | | 33 | 1914 | | 45 (3)| 00:00:01 |
|* 13 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 44 | 1320 | | 41 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 44 | | | 3 (0)| 00:00:01 |
|* 16 | FILTER | | | | | | |
| 17 | HASH GROUP BY | | 1 | 53 | | 8 (25)| 00:00:01 |
|* 18 | FILTER | | | | | | |
|* 19 | HASH JOIN | | 4 | 212 | | 7 (15)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 4 | 100 | | 3 (0)| 00:00:01 |
|* 21 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 22 | SORT AGGREGATE | | 1 | 91 | | | |
| 23 | VIEW | PS_UPA_EQ_INCAL_VW | 1 | 91 | | 6 (0)| 00:00:01 |
| 24 | SORT GROUP BY | | 1 | 58 | | 6 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | | | | | |
| 26 | NESTED LOOPS | | 1 | 58 | | 6 (0)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 2 | 60 | | 4 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 1 | | | 3 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | PS_UPA_EQ_TRCD_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 30 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_TRCD_TBL | 1 | 28 | | 1 (0)| 00:00:01 |
| 31 | HASH GROUP BY | | 12 | 852 | | 214M (5)|715:46:12 |
| 32 | VIEW | | 12 | 852 | | 214M (5)|715:46:12 |
| 33 | HASH UNIQUE | | 12 | 1932 | | 214M (5)|715:46:12 |
|* 34 | FILTER | | | | | | |
| 35 | NESTED LOOPS | | 196M| 29G| | 205M (4)|685:32:54 |
| 36 | VIEW | PS_UPA_EQ_INCAL_VW | 4513K| 146M| | 72281 (2)| 00:14:28 |
| 37 | HASH GROUP BY | | 4513K| 249M| 329M| 72281 (2)| 00:14:28 |
|* 38 | HASH JOIN | | 4513K| 249M| | 8644 (4)| 00:01:44 |
| 39 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 513 | 14364 | | 3 (0)| 00:00:01 |
|* 40 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
| 41 | VIEW PUSHED PREDICATE | PS_UPA_EQ_INCAL_VW | 1 | 127 | | 46 (5)| 00:00:01 |
| 42 | SORT GROUP BY | | 33 | 1914 | | 46 (5)| 00:00:01 |
|* 43 | HASH JOIN | | 33 | 1914 | | 45 (3)| 00:00:01 |
|* 44 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 44 | 1320 | | 41 (0)| 00:00:01 |
|* 46 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 44 | | | 3 (0)| 00:00:01 |
|* 47 | FILTER | | | | | | |
| 48 | HASH GROUP BY | | 1 | 53 | | 8 (25)| 00:00:01 |
|* 49 | FILTER | | | | | | |
|* 50 | HASH JOIN | | 4 | 212 | | 7 (15)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 4 | 100 | | 3 (0)| 00:00:01 |
|* 52 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 53 | SORT AGGREGATE | | 1 | 91 | | | |
| 54 | VIEW | PS_UPA_EQ_INCAL_VW | 1 | 91 | | 6 (0)| 00:00:01 |
| 55 | SORT GROUP BY | | 1 | 58 | | 6 (0)| 00:00:01 |
| 56 | NESTED LOOPS | | | | | | |
| 57 | NESTED LOOPS | | 1 | 58 | | 6 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID| PS_UPA_EQ_DC_BAL | 2 | 60 | | 4 (0)| 00:00:01 |
|* 59 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 1 | | | 3 (0)| 00:00:01 |
|* 60 | INDEX UNIQUE SCAN | PS_UPA_EQ_TRCD_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_TRCD_TBL | 1 | 28 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE
:B1>:B2 AND "J"."BALANCE_PERIOD"=:B3 AND "J"."UPA_FISCAL_YEAR"=:B4 AND "J"."EMPLID"=:B5 AND
("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND
"J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR" AND "J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND
"V"."UPA_FISCAL_YEAR"=:B6 GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR"
HAVING "V"."DESCR"=:B7) AND "A"."BALANCE_PERIOD"= (SELECT MAX("BALANCE_PERIOD") FROM (SELECT "J"."EMPLID"
"EMPLID","J"."UPA_FISCAL_YEAR" "UPA_FISCAL_YEAR","J"."BALANCE_PERIOD" "BALANCE_PERIOD","V"."DESCR"
"DESCR",SUM(DECODE("J"."UPA_INC_TYPE",'D',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT",SUM(DECODE("J"."UPA_INC_TYPE",'M',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT2",SUM(DECODE("J"."UPA_INC_TYPE",'C',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT3",SUM(DECODE("J"."UPA_INC_TYPE",'P',"J"."UPA_CURRENT_AMT",0)) "UPA_CURRENT_AMT4" FROM
SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE "J"."BALANCE_PERIOD"<=:B8 AND
"J"."UPA_FISCAL_YEAR"=:B9 AND "J"."EMPLID"=:B10 AND ("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR
"J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND "V"."UPA_FISCAL_YEAR"=:B11 AND
"J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."DESCR"=:B12 AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR"
GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR") "PS_UPA_EQ_INCAL_VW"))
7 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
9 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
12 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
13 - filter("V"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
15 - access("J"."EMPLID"="B"."EMPLID" AND "J"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
16 - filter("V"."DESCR"=:B1)
18 - filter(:B1>:B2)
19 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
20 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
21 - filter("V"."UPA_FISCAL_YEAR"=:B1)
28 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"<=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
29 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."UPA_FISCAL_YEAR"=:B1)
filter("J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
30 - filter("V"."DESCR"=:B1)
34 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE
:B1>:B2 AND "J"."BALANCE_PERIOD"=:B3 AND "J"."UPA_FISCAL_YEAR"=:B4 AND "J"."EMPLID"=:B5 AND
("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND
"J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR" AND "J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND
"V"."UPA_FISCAL_YEAR"=:B6 GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR"
HAVING "V"."DESCR"=:B7) AND "A"."BALANCE_PERIOD"= (SELECT MAX("BALANCE_PERIOD") FROM (SELECT "J"."EMPLID"
"EMPLID","J"."UPA_FISCAL_YEAR" "UPA_FISCAL_YEAR","J"."BALANCE_PERIOD" "BALANCE_PERIOD","V"."DESCR"
"DESCR",SUM(DECODE("J"."UPA_INC_TYPE",'D',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT",SUM(DECODE("J"."UPA_INC_TYPE",'M',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT2",SUM(DECODE("J"."UPA_INC_TYPE",'C',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT3",SUM(DECODE("J"."UPA_INC_TYPE",'P',"J"."UPA_CURRENT_AMT",0)) "UPA_CURRENT_AMT4" FROM
SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE "J"."BALANCE_PERIOD"<=:B8 AND
"J"."UPA_FISCAL_YEAR"=:B9 AND "J"."EMPLID"=:B10 AND ("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR
"J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND "V"."UPA_FISCAL_YEAR"=:B11 AND
"J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."DESCR"=:B12 AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR"
GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR") "PS_UPA_EQ_INCAL_VW"))
38 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
40 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
43 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
44 - filter("V"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
46 - access("J"."EMPLID"="B"."EMPLID" AND "J"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
47 - filter("V"."DESCR"=:B1)
49 - filter(:B1>:B2)
50 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
51 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
52 - filter("V"."UPA_FISCAL_YEAR"=:B1)
59 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"<=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
60 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."UPA_FISCAL_YEAR"=:B1)
filter("J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
61 - filter("V"."DESCR"=:B1)Any directions as to how to tune this query would be greatly appreciated!
Thanks,
Suddhasatwalooks like these two steps hurts the most (causing the NL join take forever - because of the 4,5M rows)
|* 9 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
|* 40 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
9 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
40 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')do you have an index on PS_UPA_EQ_DC_BAL.UPA_INC_TYPE column?
reducing the number of rows returned in this step would be critical to speed up the NL join -
hello all
my one of query is returning result in 1-2 mins only for 1 lakh record but i am not sure if it showed me complete rows or not because when I an trying to get count of result ..its taking lot of time .when I am using this query on plsql code ..code is running slow so just wanted to confirm on query tuning point of view if its fine or not ..please look onto it and let me know if query is fine or not by explain plan .my oracle version is 11g
this is my query
SELECT ROWNUM , TRUNC(rownum/5000) + 20000 ,'FOR_UPDATE', sku_org.NAME ,
acct_promo_sku.src_num , acct_promo_sku.sub_type ,
promo_actual.sku_actual_pos
FROM siebel.s_src acct_promo_hdr,
siebel.s_src acct_title_format,
siebel.s_src acct_promo_sku,
siebel.s_src_x acct_promo_hdrx,
siebel.s_src_x acct_promo_skux,
siebel.s_prod_int prod,
siebel.s_bu promo_hdr_org,
siebel.s_bu sku_org,
siebelwb.stg_sbl_acct_promo_actuals2 promo_actual
WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
AND acct_promo_hdr.row_id = acct_title_format.par_src_id
AND acct_title_format.sub_type = 'PLAN_ACCT_PROMOTION_CATEGORY'
AND acct_title_format.row_id = acct_promo_sku.par_src_id
AND acct_promo_sku.sub_type = 'PLAN_ACCOUNT_PROMOTION_PRODUCT'
AND acct_promo_hdr.row_id = acct_promo_hdrx.par_row_id
AND acct_promo_sku.row_id = acct_promo_skux.par_row_id(+)
AND acct_promo_sku.prod_id = prod.row_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
AND acct_promo_sku.bu_id = sku_org.row_id
AND prod.x_prod_material_num = promo_actual.material_number
and prod.X_PROD_SALES_ORG=promo_actual.sales_org
AND acct_promo_hdr.row_id = promo_actual.acct_promo_id
and nvl(acct_promo_hdr.pr_accnt_id,0)=nvl(promo_actual.acct_siebel_rowid,0)
and nvl(acct_promo_hdr.x_indirect_id,0)=nvl(promo_actual.indirect_acct_siebel_rowid,0)
AND promo_actual.load_date >= TRUNC(SYSDATE)
AND promo_actual.load_date < TRUNC(SYSDATE + 1)
explain plan
PLAN_TABLE_OUTPUT
Plan hash value: 3864590768
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 298 | 2300 (1)| 00:00:28 |
| 1 | COUNT | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 298 | 2300 (1)| 00:00:28 |
| 5 | NESTED LOOPS OUTER | | 1 | 273 | 2298 (1)| 00:00:28 |
| 6 | NESTED LOOPS | | 1 | 263 | 2296 (1)| 00:00:28 |
| 7 | NESTED LOOPS | | 1 | 236 | 2295 (1)| 00:00:28 |
| 8 | NESTED LOOPS | | 1 | 165 | 2292 (1)| 00:00:28 |
| 9 | NESTED LOOPS | | 1 | 117 | 2289 (1)| 00:00:28 |
| 10 | NESTED LOOPS | | 1 | 109 | 2289 (1)| 00:00:28 |
| 11 | NESTED LOOPS | | 1 | 99 | 2287 (1)| 00:00:28 |
|* 12 | TABLE ACCESS FULL | STG_SBL_ACCT_PROMO_ACTUALS2 | 1 | 49 | 2285 (1)| 00:0
|* 13 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 50 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | 8 | 0 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 48 | 3 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 71 | 3 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
| 21 | TABLE ACCESS BY INDEX ROWID | S_BU | 1 | 27 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 25 | 2 (0)| 00:00:
Predicate Information (identified by operation id):
2 - filter(TRUNC(SYSDATE@!)<TRUNC(SYSDATE@!+1))
12 - filter("PROMO_ACTUAL"."LOAD_DATE">=TRUNC(SYSDATE@!) AND "PROMO_ACTUAL"."LOAD_DATE"<TRUNC(SYSD
13 - filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
NVL("ACCT_PROMO_HDR"."PR_ACCNT_ID",'0')=NVL("PROMO_ACTUAL"."ACCT_SIEBEL_ROWID",'0') AND
NVL("ACCT_PROMO_HDR"."X_INDIRECT_ID",'0')=NVL("PROMO_ACTUAL"."INDIRECT_ACCT_SIEBEL_ROWID",'0'
14 - access("ACCT_PROMO_HDR"."ROW_ID"="PROMO_ACTUAL"."ACCT_PROMO_ID")
15 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_PROMO_HDRX"."PAR_ROW_ID")
16 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID")
17 - filter("ACCT_TITLE_FORMAT"."SUB_TYPE"='PLAN_ACCT_PROMOTION_CATEGORY')
18 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_TITLE_FORMAT"."PAR_SRC_ID")
19 - filter("ACCT_PROMO_SKU"."PROD_ID" IS NOT NULL AND
"ACCT_PROMO_SKU"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION_PRODUCT')
20 - access("ACCT_TITLE_FORMAT"."ROW_ID"="ACCT_PROMO_SKU"."PAR_SRC_ID")
22 - access("ACCT_PROMO_SKU"."BU_ID"="SKU_ORG"."ROW_ID")
23 - access("ACCT_PROMO_SKU"."ROW_ID"="ACCT_PROMO_SKUX"."PAR_ROW_ID"(+))
24 - access("ACCT_PROMO_SKU"."PROD_ID"="PROD"."ROW_ID")
25 - filter("PROD"."X_PROD_MATERIAL_NUM" IS NOT NULL AND
"PROD"."X_PROD_MATERIAL_NUM"="PROMO_ACTUAL"."MATERIAL_NUMBER" AND
"PROD"."X_PROD_SALES_ORG"="PROMO_ACTUAL"."SALES_ORG")
55 rows selected.
thanksHi,
the plan you posted has the cost of 2300, i.e. 2300 single-block reads or equivalent number f multi-block reads. Even if none of the blocks is found in cache, 2300 reas shouldn't take more than a couple of minutes, beacause for most of the hard drives available today a disk read is typically within 5-10 ms.
This means that if there is a problem, we will never find out about it by looking in the plan. And it's quite likely that there is, in fact, a problem, because the plan contains a bunch of nested joins, and the cost of each nested join is directly proportional to the cardinality of the previous nested loop. I.e. it suffices to make one bad mistake in estimating the number of rows coming fom one of the nested rows to screw up the entire plan and get all remaining estimates (including the total cost of the query) completely wrong.
In order for us to be able to tell more, we need to see the plan with rowsource statistics, and please don't forget to use tags to preserve formatting (use the preview tab to make sure the posted plan is actually readable).
Best regards,
Nikolay -
Query tuning for data-warehousing application in Oracle 8i.
We have to pick up 24 months old data. Each month data is kept in a different partition.
2007-May month data is kept in PRESC200705 partition
SELECT r.account_id,
p.presc_num,
spm.product_id,
p.month,
t.best_call_state,
sum(p.trx_count)
FROM rlup_assigned_account r,
temp_presc_num_TEST t,
retail.prescrip_retail partition (PRESC200705) p,
sherlock.sherlock_product_mapping spm
WHERE spm.product_id like '056%'
and spm.mds6 = p.product_id
and t.CLIENT_ID = p.presc_num
and r.ndc_pyr_id = p.payer_plan
and t.best_call_state = r.ST
GROUP BY r.account_id,
p.presc_num,
spm.product_id,
p.month,
t.best_call_state
Q This Query is to be tuned
SQL> SELECT table_name,
2 partition_name,
3 high_value,
4 num_rows
5 FROM user_tab_partitions
6 ;
no rows selectedI have the following task:
Requirement:
According to the client, new partitions are created every month.
So the query should contain only the 24 most recent partions leaving one old partition every month.
So, the query becomes dynamic.
The query will have to leave one old partion every month and move ahead with the new partion created.
The total partitions accessed should not cross 24.
Is this possible?
Partition# for OCt 2007
1
2
3
4
5
6
7
24
Partition# for Nov 2007
Old|New
1
2..1
3..2
4..3
5..4
6..5
7..6
24..23
..24
Secondly, with one month data (in a partitioned table), the query takes about one hour to run.
with 24 month data accessed by the query, the query will take 24 hours to run.
I am sure that Oracle can be tuned to run on such huge data with ease and the query output can
come within seconds.. Otherwise, nobody would use oracle for datawarehousing applicaions.
Q. How do I write a dynamic query that references 24 recent partitions, using the query provided:
abc>SELECT r.account_id,
2 p.presc_num,
3 spm.product_id,
4 p.month,
5 t.best_call_state,
6 sum(p.trx_count)
7 FROM rlup_assigned_account r,
8 temp_presc_num_TEST t,
9 retail.prescrip_retail partition (PRESC200705) p,
10 sherlock.sherlock_product_mapping spm
11 WHERE spm.product_id like '056%'
12 and t.CLIENT_ID='934759'
13 and spm.mds6 = p.product_id
14 and t.CLIENT_ID = p.presc_num
15 and r.ndc_pyr_id = p.payer_plan
16 and t.best_call_state = r.ST
17 GROUP BY r.account_id,
18 p.presc_num,
19 spm.product_id,
20 p.month,
21 t.best_call_state
22 ;
retail.prescrip_retail partition (PRESC200705) p,
Partition name, PRESC200705 cannot be hardcoded into the sql.
Sql should take a range of 24 recent partitions.
And the query should execute fast too.
Now, is that what is called a challenge?
+++++++++++++++++++++++++++++++++++++++++++++++
Here are the index/constraints/explain_plan output on prescrip_retail table (which is partitioned)
as well as other tables to which prescrip_retail table is joined
This is what prescrip_retail looks like. This is the table having partitions.
It does not seem to have a primary key!
SQL> desc prescrip_retail
Name Null? Type
PRESC_NUM NUMBER
PFIER_NUM CHAR(8)
RELID NOT NULL CHAR(9)
ME_NUM NOT NULL CHAR(10)
PRODUCT_ID NOT NULL CHAR(6)
PRODUCT_FRMSTR NOT NULL CHAR(1)
PAYER_PLAN NOT NULL CHAR(6)
MONTH NOT NULL DATE
PYMT_CODE NOT NULL CHAR(1)
NRX_COUNT NOT NULL NUMBER(7)
NRX_QUANTITY NOT NULL NUMBER(9)
NRX_DOLLARS NOT NULL NUMBER(13,2)
TRX_COUNT NOT NULL NUMBER(7)
TRX_QUANTITY NOT NULL NUMBER(9)
TRX_DOLLARS NOT NULL NUMBER(13,2)
Table Size of Prescrip_Retail...
1 select table_name,tablespace_name,pct_free,pct_used,num_rows,avg_space
2 from all_tables
3* where table_name='PRESCRIP_RETAIL'
SQL> /
TABLE_NAME TABLESPACE_NAME PCT_FREE PCT_USED NUM_ROWS AVG_SPACE
PRESCRIP_RETAIL 2806673860 360
Explain Plan for the query to be tuned...
22:32:31 SQL> explain plan set statement_id='vista_query'
22:43:33 2 for
22:43:35 3 SELECT r.pfier_account_id,
22:43:41 4 p.presc_num,
22:43:41 5 spm.product_id,
22:43:41 6 p.month,
22:43:41 7 t.best_call_state,
22:43:41 8 sum(p.trx_count)
22:43:41 9 FROM rlup_assigned_account r,
22:43:41 10 temp_presc_num_TEST t,
22:43:41 11 retail.prescrip_retail partition (PRESC200705) p,
22:43:41 12 sherlock.sherlock_product_mapping spm
22:43:41 13 WHERE spm.product_id like '056%'
22:43:41 14 and spm.mds6 = p.product_id
22:43:41 15 and t.CLIENT_ID = p.presc_num
22:43:41 16 and r.ndc_pyr_id = p.payer_plan
22:43:41 17 and t.best_call_state = r.ST
22:43:41 18 GROUP BY r.pfier_account_id,
22:43:41 19 p.presc_num,
22:43:41 20 spm.product_id,
22:43:41 21 p.month,
22:43:41 22 t.best_call_state;
Explained.
SQL> select statement_id,operation,options,object_name
2 from plan_table
3 where statement_id='vista_query';
22:46:03 SQL> /
STATEMENT_ID OPERATION OPTIONS OBJECT_NAME
vista_query SELECT STATEMENT
vista_query SORT GROUP BY
vista_query HASH JOIN
vista_query TABLE ACCESS FULL TEMP_PRESC_NUM_TEST
vista_query HASH JOIN
vista_query TABLE ACCESS FULL RLUP_ASSIGNED_ACCOUNT
vista_query HASH JOIN
vista_query TABLE ACCESS FULL SHERLOCK_PRODUCT_MAPPING
vista_query TABLE ACCESS FULL PRESCRIP_RETAIL
9 rows selected.
Partition Pruning: This is supposed to provide an insight to the partitions oracle
vists internally...
I guess we can use "month>= add_months(sysdate,-24)" instead of partions too.
I don't think Oracle is visiting any partitions.
I'll also search into all_tab_partitions to verify this.
Explain_Plan for what partitions oracle visits internally (partition pruning):
SQL> ed
Wrote file afiedt.buf
1 explain plan set statement_id='vista'
2 for select * from retail.prescrip_retail
3* where month>= add_months(sysdate,-24)
SQL> /
Explained.
Elapsed: 00:00:00.05
22:13:56 SQL> select statement_id,operation,options,object_name
22:14:28 2 from plan_table
22:14:30 3 where statement_id='vista';
STATEMENT_ID OPERATION
OPTIONS OBJECT_NAME
vista SELECT STATEMENT
vista PARTITION RANGE
ITERATOR
vista TABLE ACCESS
FULL PRESCRIP_RETAIL
Elapsed: 00:00:01.00
Indexes/Constraints on PRESCRIP_RETAIL table:
SQL> ED
Wrote file afiedt.buf
1 SELECT TABLE_NAME,TABLE_TYPE,INDEX_NAME,INDEX_TYPE,PCT_FREE,STATUS,PARTITIONED
2 FROM ALL_INDEXES
3* WHERE TABLE_NAME IN ('PRESCRIP_RETAIL')
SQL> /
TABLE_NAME TABLE INDEX_NAME INDEX_TYPE PCT_FREE STATUS PAR
PRESCRIP_RETAIL TABLE BX6_PRESC_RELID BITMAP N/A YES
PRESCRIP_RETAIL TABLE BX7_PRESC_ME BITMAP N/A YES
PRESCRIP_RETAIL TABLE BX1_PRESC_PROD BITMAP N/A YES
PRESCRIP_RETAIL TABLE BX2_PRESC_PAYER BITMAP N/A YES
PRESCRIP_RETAIL TABLE BX3_PRESC_PAYERCD BITMAP N/A YES
PRESCRIP_RETAIL TABLE BX4_PRESC_PRESC BITMAP N/A YES
PRESCRIP_RETAIL TABLE BX5_PRESC_PFIER BITMAP N/A YES
7 rows selected.
SQL> ed
Wrote file afiedt.buf
1 SELECT TABLE_NAME,CONSTRAINT_NAME,CONSTRAINT_TYPE,STATUS,DEFERRABLE
2 FROM ALL_CONSTRAINTS
3* WHERE TABLE_NAME IN ('PRESCRIP_RETAIL')
SQL> /
TABLE_NAME CONSTRAINT_NAME C STATUS DEFERRABLE
PRESCRIP_RETAIL SYS_C001219 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001220 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001221 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001222 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001223 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001224 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001225 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001226 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001227 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001228 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001229 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001230 C ENABLED NOT DEFERRABLE
PRESCRIP_RETAIL SYS_C001231 C ENABLED NOT DEFERRABLE
13 rows selected.
In all_tables:
NUM_ROWS:2806673860
AVG_SPACE:360
Here is the data size in the table.
SQL> select count(*) from PRESCRIP_RETAIL;
COUNT(*)
4602980312
Again, here is the partition information and the amount of data in each partition:
SQL> ed
Wrote file afiedt.buf
1 select
2 partition_name,SUBPARTITION_COUNT,PARTITION_POSITION,TABLESPACE_NAME,
3 NUM_ROWS
4 from all_tab_partitions
5 where table_name='PRESCRIP_RETAIL'
6* order by partition_name desc
SQL> /
PARTITION_NAME SUBPARTITION_COUNT PARTITION_POSITION TABLESPACE_NAME NUM_ROWS
PRESC200705 0 36 PRESC_PARTITION_29 141147085
PRESC200704 0 35 PRESC_PARTITION_28 140299317
PRESC200703 0 34 PRESC_PARTITION_27 140703128
PRESC200702 0 33 PRESC_PARTITION_26 132592733
PRESC200701 0 32 PRESC_PARTITION_25 145832356
PRESC200612 0 31 PRESC_PARTITION_24 136702837
PRESC200611 0 30 PRESC_PARTITION_23 137421767
PRESC200610 0 29 PRESC_PARTITION_22 140836119
PRESC200609 0 28 PRESC_PARTITION_21 131273578
PRESC200608 0 27 PRESC_PARTITION_20 134967317
PRESC200607 0 26 PRESC_PARTITION_19 130785504
PRESC200606 0 25 PRESC_PARTITION_18 131472696
PRESC200605 0 24 PRESC_PARTITION_17 138590581
PRESC200604 0 23 PRESC_PARTITION_16 126849798
PRESC200603 0 22 PRESC_PARTITION_15 137164667
PRESC200602 0 21 PRESC_PARTITION_14 126938544
PRESC200601 0 20 PRESC_PARTITION_13 135408324
PRESC200512 0 19 PRESC_PARTITION_12 123285100
PRESC200511 0 18 PRESC_PARTITION_11 121245764
PRESC200510 0 17 PRESC_PARTITION_10 122112932
PRESC200509 0 16 PRESC_PARTITION_09 119137399
PRESC200508 0 15 PRESC_PARTITION_08 123372311
PRESC200507 0 14 PRESC_PARTITION_07 112905435
PRESC200506 0 13 PRESC_PARTITION_06 119581406
PRESC200505 0 12 PRESC_PARTITION_05 123977315
PRESC200504 0 11 PRESC_PARTITION_04 118975597
PRESC200503 0 10 PRESC_PARTITION_03 125782688
PRESC200502 0 9 PRESC_PARTITION_02 117448839
PRESC200501 0 8 PRESC_PARTITION_01 122214436
PRESC200412 0 7 PRESC_PARTITION_36 124799998
PRESC200411 0 6 PRESC_PARTITION_35 125471042
PRESC200410 0 5 PRESC_PARTITION_34 118457422
PRESC200409 0 4 PRESC_PARTITION_33 119537488
PRESC200408 0 3 PRESC_PARTITION_32 121319137
PRESC200407 0 2 PRESC_PARTITION_31 115226621
PRESC200406 0 1 PRESC_PARTITION_30 119143031
36 rows selected.
Data in induvidual partition of PRESCRIP_RETAIL.
SQL> SELECT COUNT(*) FROM PRESCRIP_RETAIL PARTITION(PRESC200704);
COUNT(*)
140299317
SQL> SELECT COUNT(*) FROM PRESCRIP_RETAIL PARTITION(PRESC200703);
COUNT(*)
140703128
SQL> SELECT COUNT(*) FROM PRESCRIP_RETAIL PARTITION(PRESC200702);
COUNT(*)
132592733
SQL> SELECT COUNT(*) FROM PRESCRIP_RETAIL PARTITION(PRESC200701);
COUNT(*)
145832356
SQL> SELECT COUNT(*) FROM PRESCRIP_RETAIL PARTITION(PRESC200606);
COUNT(*)
131472696
SQL> SELECT COUNT(*) FROM PRESCRIP_RETAIL PARTITION(PRESC200605);
COUNT(*)
138590581
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other tables info:
Index of other tables related to PRESCRIP_REATIL:
SQL> SELECT TABLE_NAME,TABLE_TYPE,INDEX_NAME,INDEX_TYPE,PCT_FREE,STATUS,PARTITIONED
2 FROM ALL_INDEXES
3 WHERE TABLE_NAME IN ('RLUP_ASSIGNED_ACCOUNT','TEMP_PRESC_NUM_TEST','SHERLOCK_PRODUCT_MAPPING');
SQL> /
TABLE_NAME TABLE INDEX_NAME INDEX_TYPE PCT_FREE STATUS PAR
SHERLOCK_PRODUCT_MAPPING TABLE SHERLOCK_PRODUCT_MAPPING_PK NORMAL 10 VALID NO
SHERLOCK_PRODUCT_MAPPING TABLE SHERLOCK_PRODUCT_MAPPING_X1 NORMAL 0 VALID NO
SHERLOCK_PRODUCT_MAPPING TABLE SHERLOCK_PRODUCT_MAPPING_BX1 BITMAP 0 VALID NO
SHERLOCK_PRODUCT_MAPPING TABLE SHERLOCK_PRODUCT_MAPPING_BX2 BITMAP 0 VALID NO
SHERLOCK_PRODUCT_MAPPING TABLE SHERLOCK_PRODUCT_MAPPING_BX3 BITMAP 0 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX1_RLUP_ASSIGNED_ACCT_PYR BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX2_RLUP_ASSIGNED_ACCT_TOPLVL BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX3_RLUP_ASSIGNED_ACCT_PBM BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX4_RLUP_ASSIGNED_ACCT_AA_FLAG BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX5_RLUP_ASSIGNED_ACCT_AA_CHD BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX6_RLUP_ASSIGNED_ACCT_PBM_FLG BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE BX7_RLUP_ASSIGNED_ACCT_ACCTID BITMAP 10 VALID NO
RLUP_ASSIGNED_ACCOUNT TABLE PK_RLUP_ASSIGNED_ACCOUNT NORMAL 10 VALID NO
13 rows selected.
Constraints in other tables:
SQL> SELECT TABLE_NAME,CONSTRAINT_NAME,CONSTRAINT_TYPE,STATUS,DEFERRABLE
2 FROM ALL_CONSTRAINTS
3 WHERE TABLE_NAME IN ('RLUP_ASSIGNED_ACCOUNT','TEMP_PRESC_NUM_TEST','SHERLOCK_PRODUCT_MAPPING');
TABLE_NAME CONSTRAINT_NAME C STATUS DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637753 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637754 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637755 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637756 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637757 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637758 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637759 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637760 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637761 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT SYS_C00637762 C ENABLED NOT DEFERRABLE
RLUP_ASSIGNED_ACCOUNT PK_RLUP_ASSIGNED_ACCOUNT P ENABLED NOT DEFERRABLE
TEMP_PRESC_NUM_TEST SYS_C00640536 C ENABLED NOT DEFERRABLE
12 rows selected.
TEMP_PRESC_NUM_TEST does not contain any constraints or index. -
How to write sql query for below example.
Hi,
I have requirement.
There are number of rows and I need the result through query as follows.Please help me to proved sql query for below mentioned requirement.
example: table TEST.
COLA COLB COLC COLD
MANAGER 5 NULL null
SR.MANAGE 6 3 NULL
VP 5 5 4
I have to write the sql query if COLA IS MANAGER THEN CONSIDER MANGER RECORD,AND IF ANY COLUMN FILED IS NULL FOR MANGER THEN CONSIDER COLA IS SR.MANGER, AND IF ANY COLUMN FILED IS NULL FOR SR,MANGER THEN CONSIDER VP records.
I need output as below.
COLB COLC COLD
5(MANGER) 3(sr.manger) 5(vp)
Please provide the for above mentioned output.
Thanks<<if COLA IS MANAGER THEN CONSIDER MANGER RECORD>>
What does this sentence means? COLA does not cnatin a single record but the number of records with diffrent values.
Regards
Arun -
How to write sql query for below mentioned eaxmple.
Hi,
I have requirement.
There are number of rows and I need the result through query as follows.Please help me to proved sql query for below mentioned requirement.
example: table TEST.
COLA COLB COLC COLD COLE COLF MANAGER 5 NULL NULL 3 NULL
SR.MANAGER 6 3 NULL NULL NULL
VP 5 5 4 5 5
I have to write the sql query if COLA IS MANAGER THEN CONSIDER MANGER RECORD,AND IF ANY COLUMN FILED IS NULL FOR MANGER THEN CONSIDER COLA IS SR.MANGER, AND IF ANY COLUMN FILED IS NULL FOR SR,MANGER THEN CONSIDER VP records.
I need output as below.
COLB COLC COLD COLE COLF
5(manager) 3(sr.manger) 4(vp) 3(manger) 3(vp)
Please provide the for above mentioned output.
ThanksDuplicate thread. please view the answer posted in your first thread.
how to write sql query.
And, please don't post any duplicate thread.
Regards.
Satyaki De. -
Provide sql query for below one
hi everyone,
in my source table [finanace_dept] contains two columns [finance_id,r_mature_kd] with 2 million records and sample data given below.
finance_id r_mature_kd
1 H
1 T
1 T
2 T
3 H
4 S
4 T
4 T
5 X
6 H
6 L
6 L
6 M
please provide sql query for below expected output.
expected output :
finance_id r_mature_kd
1 H
1 T
4 S
4 T
6 H
6 L
6 M
for column finance_id: '1', contains three records, but two distinct r_mature_kd hence it should retrive only two records with H,T
for column finance_id: '2','3', contains only one record hence this records should not retrive.
for column finance_id: '6', contains four records, but three distinct r_mature_kd hence it should retrive only two records with H,L,M
please help on this.WITH T(finance_id,r_mature_kd) AS (
SELECT 1, 'H' FROM DUAL UNION ALL
SELECT 1, 'T' FROM DUAL UNION ALL
SELECT 1, 'T' FROM DUAL UNION ALL
SELECT 2, 'T' FROM DUAL UNION ALL
SELECT 3, 'H' FROM DUAL UNION ALL
SELECT 4, 'S' FROM DUAL UNION ALL
SELECT 4, 'T' FROM DUAL UNION ALL
SELECT 4, 'T' FROM DUAL UNION ALL
SELECT 5, 'X' FROM DUAL UNION ALL
SELECT 6, 'H' FROM DUAL UNION ALL
SELECT 6, 'L' FROM DUAL UNION ALL
SELECT 6, 'L' FROM DUAL UNION ALL
SELECT 6, 'M' FROM DUAL
SELECT DISTINCT finance_id,r_mature_kd,C FROM(
SELECT finance_id,r_mature_kd,COUNT(1) OVER (PARTITION BY finance_id) C
FROM T
WHERE C > 1
ORDER BY 1
FINANCE_ID
R_MATURE_KD
C
1
H
3
1
T
3
4
S
3
4
T
3
6
H
4
6
L
4
6
M
4
Ramin Hashimzade -
Request for tunning the below query
Hi,
Can any one help me on the below query while improving the performance,
SELECT accdet, acceprec, accinvalid, accnetanal, accphy, accvalid,
actlabcost, actlabhrs, actualcontactdate, actualfinish, actualstart,
affecteddate, affectedemail, affectedperson, affectedphone,
alteration, aslaiddwg, assetnum, assetorgid, assetsiteid,
assumptions, basedet, basereq, bicounty, bidplo, bieasting,
bihousename, bihouseno, binorthing, bipobox, bipostcode, biposttown,
bistreet, bisubb as bisupp, boostcomp, boostcompdet, ccemail, cchouseno, ccid,
ccname, cctel1type, cctel2type, cctelephone1, cctelephone2, cdm,
changeby, changedate, CLASS, classstructureid, cocontact, cocounty,
codplo, coeasment, coeasting, cohousename, conorthing, copobox,
commodity, commoditygroup, coneasereq, consent, consents,
copostcode, coposttown, costcon, costreet, cosubb, cpi90,
createworelasset, customerref, custtype, depot, description, durt,
ecvpressuretier, ecvsize, enduserid, engdifficult, exaoq, existin,
existsdq, expid, exshq, externalrecid, extralanddetail, failurecode,
fr1code, fr2code, fuelpovscheme, g17, gbna, glaccount,
globalticketclass, globalticketid, govconf, govener, govenerdet,
govhouse, hasactivity, hasld, historyflag, impact, infill,
infoprovide, inheritstatus, internalpriority, interquote, isglobal,
isknownerror, isknownerrordate, kioskdet, kioskreq, langcode,
latecertdate, leadt, lengthpri, lengthpub, loadtype, LOCATION, m25,
maindesac, mainusage, meterboxty, metercon, meterloc, meterser,
mininforec, mininforeq, mprnno, newaoq, newpid, newsdq, newshq,
np14, nrswa, nsgno, oldquotever, oldticketid, orgid, originsgn,
origrecordclass, origrecordid, origrecorgid, origrecsiteid, owner,
ownergroup, packagesent, paymethod, payterms, permittowork, physub,
pressuretier, privateexc, problemcode, propertiesno, propertytype,
publicexc, purgerel, quotedate, quotetype, quotever, reinforcement,
reinforcementa, reinforcementb, relatedtoglobal, reportdate,
reportedby, reportedemail, reportedphone, reportedpriority,
rowstamp, sc, scj, scoreq, servicerelay, sgnbillcontact,
sgnblkbyfin, sgncusttobill, sgncusttosite, sgndisreasoth,
sgneasment, sgnenhance, sgneow, sgneowreq, sgngqmvalid,
sgninfillcost, sgninfillver, sgninfprojno, sgnisstdchrg,
sgnloadnoenter, sgnmainsreq, sgnmaxaccdate, sgnnoncont, sgnpipesiz,
sgnpurord, sgnqdaysremain, sgnqstd, sgnquotdate, sgnquotval,
sgnreasdis, sgntotalaoq, sgntotalshq, sgnvarreq, sicontact,
sicounty, sidplo, sieasting, sihousename, sihouseno, sinorthing,
sipobox, sipostcode, siposttown, sistreet, sisubb, sitecond, sitegt,
siteid, sitel1, sitel2, siteplpro, sitevisit, solution, sos,
sosrecdate, SOURCE, status, statusdate, subfinal, supervisor,
supplytype, surveycarr, surveydef, surveyreas, surveyreq, surveyret,
surveysent, targetcontactdate, targetfinish, targetstart, TEMPLATE,
templateid, termtype, thirdpartyeas, thirdpartypipe, ticketid,
ticketuid, totalaoq, totalpid, totalsdq, totalshq, traffictime,
typewo, urgency, variat, vendor, customer_enquiry_ref,
quote_version, costs, mains_infill_charge, mtr_housing_kiosk_charge,
mtr_housing_kiosk_base_charge, specialist_reinstatement,
easement_charge, total_quote_ex_vat, vat, total_quote_incl_vat,
design_charge, reinforcement_charge, reinforcement_cost,
connection_allowance, workorder.pscdate, workorder.ascdate,
workorder.fincode, workorder.istask, workorder.status,
workorder.targstartdate, workorder.targcompdate,
workorder.schedfinish, workorder.actfinish, workorder.estdur,
workorder.wonum, workorder.mprn,
workorder.sihousename AS wositehousename,
workorder.sihouseno AS wositehouseno,
workorder.sistreet AS wositestreet,
workorder.sicounty AS wositecounty,
workorder.siposttown AS wositeposttown,
workorder.sipostcode AS wositepostcode, workorder.workorderid
FROM (maximo.sr
INNER JOIN
(maximo.relatedrecord INNER JOIN maximo.workorder
ON relatedrecord.relatedreckey =
(CASE
WHEN workorder.PARENT IS NOT NULL
THEN workorder.PARENT
ELSE workorder.wonum
END
AND relatedrecord.orgid = workorder.orgid
AND relatedrecord.siteid = workorder.siteid
AND relatedrecord.relatedrecclass = 'WORKORDER')
ON sr.ticketid = relatedrecord.recordkey
AND sr.orgid = relatedrecord.orgid
AND sr.siteid = relatedrecord.siteid
AND relatedrecord.CLASS = 'SR')
LEFT JOIN
frozen_quote@gqmfof
ON sr.ticketid = customer_enquiry_ref
AND sr.quotever = quote_version
Regards,
graceCould you please provide more info.
Refer to the following link.
When your query takes too long ...
thanks -
Sql query tuning for null columns
Hi All
I have one query which runs on a table X.
This table X has one column COL1 with 10 million rows.
Out of 10million rows, 4Million rows are null.
Btree Index is availabe on this column. No other type of index feasible.
I suspect that these null rows are causing burden over my query and is slowing response.
Is there any way i can improve performance for that query?
Any help will be appreciated.
Sun10
Oracle10G 10.2.0.3.0
Thanks
aps
Edited by: aps on Apr 3, 2009 9:44 AMAps,
YOu can generated explan plan from sqlplus like this
sqlplus username/password
Note: And if user is not set with plustrace then use sqlplus '/as sysdba' and qualify your tables with schemaname.table_name
sql>set timi on;
sql> set lines 400;
sql> set autotrace traceonly;
sql>select a.account_no,a.read_no,a.inc_obj from billadjmaster a,masterdata b
where a.account_no=b.acc_no
and
b.item_type=22
and b.idate>'23-mar-2009'
order by a.account_no,a.read_no;Regards -
Hi All,
My Oracle database is running on 10.2.0.2.0 on RHEL 5.4 64 bit.
I need some tuning guide line for below SQL:
select rnii.order_id,
rnii.asin,
rnii.gl_product_group,
rnii.warehouse_id,
rtrim(rnii.vendor_ordering_id) distributor_id,
rnii.cost,
sum(rnii.rnii_quantity_available + rnii.rnii_quantity_in_progress) quantity
from
O_RECEIVED_NOT_INVOICED_ITEMS rnii
where
rnii.legal_entity_id = 101 and
rnii.received_date < to_date('2010-02-28','YYYY-MM-DD') + 1 and
rnii.snapshot_day = to_date('2010-02-28','YYYY-MM-DD') + 1 and
rnii.rnii_quantity_available + rnii.rnii_quantity_in_progress != 0
group by
rnii.order_id,
rnii.asin,
rnii.gl_product_group,
rnii.warehouse_id,
rtrim(rnii.vendor_ordering_id),
rnii.cost
having
sum(rnii.rnii_quantity_available + rnii.rnii_quantity_in_progress) != 0
/Here is execution plan :
PLAN_TABLE_OUTPUT
Plan hash value: 2086243943
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 366K| 23M| | 103K (3)| 00:20:37 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10001 | 366K| 23M| | 103K (3)| 00:20:37 | | | Q1,01 | P->S | QC (RAND) |
|* 3 | FILTER | | | | | | | | | Q1,01 | PCWC | |
| 4 | HASH GROUP BY | | 366K| 23M| 707M| 103K (3)| 00:20:37 | | | Q1,01 | PCWP | |
| 5 | PX RECEIVE | | 7326K| 475M| | 102K (3)| 00:20:35 | | | Q1,01 | PCWP | |
| 6 | PX SEND HASH | :TQ10000 | 7326K| 475M| | 102K (3)| 00:20:35 | | | Q1,00 | P->P | HASH |
| 7 | PX BLOCK ITERATOR | | 7326K| 475M| | 102K (3)| 00:20:35 | 1 | 4 | Q1,00 | PCWC | |
|* 8 | TABLE ACCESS FULL| O_RECEIVED_NOT_INVOICED_ITEMS | 7326K| 475M| | 102K (3)| 00:20:35 | 197 | 200 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
3 - filter(SUM("RNII"."RNII_QUANTITY_AVAILABLE"+"RNII"."RNII_QUANTITY_IN_PROGRESS")<>0)
8 - filter("RNII"."RNII_QUANTITY_AVAILABLE"+"RNII"."RNII_QUANTITY_IN_PROGRESS"<>0 AND "RNII"."LEGAL_ENTITY_ID"=101 AND
"RNII"."SNAPSHOT_DAY"=TO_DATE('2010-03-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "RNII"."RECEIVED_DATE"<TO_DATE('2010-03-01 00:00:00', 'yyyy-mm-dd
hh24:mi:ss'))I tried to auto trace it and got below results:
3522852 rows selected.
Elapsed: 00:03:29.65
Statistics
101 recursive calls
3 db block gets
4033298 consistent gets
4019237 physical reads
972 redo size
169791511 bytes sent via SQL*Net to client
2583851 bytes received via SQL*Net from client
234858 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
3522852 rows processed
select partition_name,num_rows,sample_size,last_analyzed from dba_tab_partitions where table_name='O_RECEIVED_NOT_INVOICED_ITEMS' AND
PARTITION_NAME LIKE '%ORNII101_2010%' ORDER BY 1;
PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED
ORNII101_201001 135228000 2704560 2010/03/02 06:30:39
ORNII101_201002 143515850 2870317 2010/03/02 06:30:48
ORNII101_201003 146559550 2931191 2010/03/02 06:30:57
ORNII101_201004 0 2010/03/02 06:30:57Table 'O_RECEIVED_NOT_INVOICED_ITEMS' is COMPOSITE PARTITIONED by 'LEGAL_ENTITY_ID' & 'SNAPSHOT_DAY' and subpartitioned by 'RNII_ID'.
There are 227 partitions (Monthly) with 4 sub partitions in each of them.
Table is sized at 520 GB and there is no index on the table. Table is having DEGREE=8.
Query runs on first date of every month.
Looking forward to have tuning recommendations to reduce query elapsed time. Is there any advantage by creating any index (local ?) on this table?The parallel processing of the query is not helping (at least when executed from SQL*Plus) much.can you bit elaborate this please ?
Here is TKPROF report :
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.21 0 32 0 0
Fetch 234858 8.47 123.70 0 0 0 3522852
total 234860 8.48 123.93 0 32 0 3522852
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 153
Rows Row Source Operation
3522852 PX COORDINATOR (cr=32 pr=0 pw=0 time=119427010 us)
0 PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us)
0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND HASH :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
0 PX BLOCK ITERATOR PARTITION: 1 4 (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS FULL O_RECEIVED_NOT_INVOICED_ITEMS PARTITION: 197 200 (cr=0 pr=0 pw=0 time=0 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
reliable message 1 0.00 0.00
enq: KO - fast object checkpoint 1 0.00 0.00
PX Deq: Join ACK 10 0.00 0.00
os thread startup 8 0.02 0.18
PX Deq: Parse Reply 9 0.00 0.00
SQL*Net message to client 234858 0.00 0.10
PX Deq: Execute Reply 405 1.95 115.65
PX qref latch 3 0.00 0.00
SQL*Net message from client 234858 0.27 75.93
PX Deq: Signal ACK 11 0.00 0.00
latch: session allocation 2 0.00 0.00
enq: PS - contention 2 0.00 0.00
******************************************************************************** -
We have to inverstigate about a reporting solution where things are getting slow (may be material, database design, network matters).
I have red a lot in MSDN and some books about performance tuning on SQL Server 2008 R2 (or other) but frankly, I feel a little lost in all that stuff
I'am looking for practical steps in order to do the tuning. Someone had like a recipe for that : a success story...
My (brain storm) Methodology should follow these steps:
Resource bottlenecks: CPU, memory, and I/O bottlenecks
tempdb bottlenecks
A slow-running user query : Missing indexes, statistics,...
Use performance counters : there are many, can one give us the list of the most important
how to do fine tuning about SQL Server configuration
SSRS, SSIS configuration ?
And do the recommandations.
Thanks
"there is no Royal Road to Mathematics, in other words, that I have only a very small head and must live with it..."
Edsger W. DijkstraHello,
There is no clear defined step which can be categorized as step by step to performance tuning.Your first goal is to find out cause or drill down to factor causing slowness of SQL server it can be poorly written query ,missing indexes,outdated stats.RAM crunch
CPU crunch so on and so forth.
I generally refer to below doc for SQL server tuning
http://technet.microsoft.com/en-us/library/dd672789(v=sql.100).aspx
For SSIS tuning i refer below doc.
http://technet.microsoft.com/library/Cc966529#ECAA
http://msdn.microsoft.com/en-us/library/ms137622(v=sql.105).aspx
When I face issue i generally look at wait stats ,wait stats give you idea about on what resource query was waiting.
--By Jonathan KehayiasSELECT TOP 10
wait_type ,
max_wait_time_ms wait_time_ms ,
signal_wait_time_ms ,
wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
AS percent_total_waits ,
100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
AS percent_total_signal_waits ,
100.0 * ( wait_time_ms - signal_wait_time_ms )
/ SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0 -- remove zero wait_time
AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC
use below link to analyze wait stats
http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
HTH
PS: for reporting services you can post in SSRS forum
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers -
Query tuning : you can do it yourself
Hello,
This thread is not a question.
How tune my query ?
My query didn't use indexes why ?
I have indexes on table, stats are up-to-date why Oracle does a full scan on table ?
What are the hint which I can use ?
etc...
I would like try to answer to many such questions posted in this forum about query tuning.
And explain that tuning is not always complicated, is not always reserved to some consultants, is not always solved by hints usage, and not require to buy some books which would give some magic solutions.
By this thread, I would explain to people which have some query performance issues, that the solution is maybe here, in front of their eyes, inside the query itself. The solution may come from their own side, and that they can be happy to solve such question themself.
I'll develop here below a case from a real word situation encountered some time ago.At this point, remove this huge and nightmarish hint. We'll use it only if no other ways may found.
First, a look into the data model to see if the joins may be rewrite differently.
Original joins :
dw.AIRPORT_ROUTING_ID = ar.AIRPORT_ROUTING_ID and
dw.COUNTRY_ROUTING_ID = cor.COUNTRY_ROUTING_ID and
dw.REGION_ROUTING_ID = rr.REGION_ROUTING_ID and
dw.CITY_ROUTING_ID = cr.CITY_ROUTING_ID andAnd indeed, the join may be rewrite as below :
and dw.AIRPORT_ROUTING_ID = ar.AIRPORT_ROUTING_ID
and ar.CITY_ROUTING_ID = cr.CITY_ROUTING_ID
and cr.COUNTRY_ROUTING_ID = cor.COUNTRY_ROUTING_ID
and cor.REGION_ROUTING_ID = rr.REGION_ROUTING_IDNote the aliases were change here. Is it complicated to try to rewrite query like that ?
Secondly, we will try to see how avoid or, at least, workaround the all OR conditions. It would be well if we could merge all the FROM (bind variable :a) in one column, same for all TO (bind variable :b), unfortunately, the data model cannot be change (of course). Ok, we will try to work with a temporary table by combining all the possiblities between the two conditions.
create global temporary table REGION_ROUTING_TMP
on commit preserve rows
as
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP1 as REGION_TO
from REGION_ROUTING
where 1=2;And an index based on the two mains criteria of the query may help :
create index IDX_REGION_ROUTING_TMP on REGION_ROUTING_TMP(REGION_FROM,REGION_TO);Then we'll populate table :
insert into REGION_ROUTING_TMP
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP1 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP2 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP3 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP1 as REGION_FROM, REGION_STOP2 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP1 as REGION_FROM, REGION_STOP3 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP1 as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP2 as REGION_FROM, REGION_STOP3 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP2 as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP3 as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING;The insert take near 9 seconds, which is a reasonnable elapse time.
At this point, the query become :
Select
ap.AIRPORT_PAIR,
dw.DELIVERY_PERIOD,
dw.TOTAL_PAX As Demand,
od.GLOBAL_TOTAL_PAX as Total_OD_Demand,
dw.REPORTED_PAX As ReportedPax,
ap.AIRPORT_FROM,
ap.AIRPORT_TO,
ap.CITY_FROM,
ap.CITY_TO,
ap.COUNTRY_FROM_NAME,
ap.COUNTRY_TO_NAME,
ap.REGION_FROM_NAME,
ap.REGION_TO_NAME,
ar.AIRPORT_ROUTING,
cr.CITY_ROUTING,
cor.COUNTRY_ROUTING_NAMES,
rr.REGION_ROUTING_NAMES,
ar.NUMBER_OF_STOP,
dw.PERCENT_OF_TOTAL_PAX_VS_OD,
dw.AIRLINE1,
dw.AIRLINE2,
dw.AIRLINE3,
dw.AIRLINE4,
dw.NUMBER_OF_AIRLINE,
dw.AIRCRAFTCLASS_NAME,
dw.FARE
From
REGION_ROUTING_TMP rr, -- here we use now the temporary table instead of REGION_ROUTING table
DETAILED_FLIGHTS dw,
AIRPORT_PAIR ap,
AIRPORT_ROUTING ar,
CITY_ROUTING cr,
COUNTRY_ROUTING cor,
OD od
where
dw.DELIVERY_PERIOD in ('2006-09','2006-08','2006-07')
and dw.AIRPORT_PAIR_ID = ap.AIRPORT_PAIR_ID
and dw.OD_ID = od.OD_ID
and dw.AIRPORT_ROUTING_ID = ar.AIRPORT_ROUTING_ID
and ar.CITY_ROUTING_ID = cr.CITY_ROUTING_ID
and cr.COUNTRY_ROUTING_ID = cor.COUNTRY_ROUTING_ID
and cor.REGION_ROUTING_ID = rr.REGION_ROUTING_ID
and rr.REGION_FROM = '7' |
and rr.REGION_TO = '8' |-> these two lines replace all the OR conditions;And explain plan :
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 469 | 174K| 3462 | | |
| 1 | NESTED LOOPS | | 469 | 174K| 3462 | | |
| 2 | NESTED LOOPS | | 458 | 166K| 3004 | | |
| 3 | NESTED LOOPS | | 454 | 127K| 2096 | | |
| 4 | NESTED LOOPS | | 258 | 58308 | 548 | | |
| 5 | NESTED LOOPS | | 246 | 48216 | 56 | | |
| 6 | NESTED LOOPS | | 26 | 4420 | 4 | | |
| 7 | TABLE ACCESS BY INDEX ROWID | REGION_ROUTING_TMP | 1 | 123 |
|* 8 | INDEX RANGE SCAN | IDX_REGION_ROUTING_TMP | 1 | | 1 | |
| 9 | TABLE ACCESS BY INDEX ROWID | COUNTRY_ROUTING | 32 | 1504 | 2
|* 10 | INDEX RANGE SCAN | IX9_COUNTRY_ROUTING | 32 | | 1 | |
| 11 | TABLE ACCESS BY INDEX ROWID | CITY_ROUTING | 9 | 234 | 2 |
|* 12 | INDEX RANGE SCAN | IX9_CITY_ROUTING | 12 | | 1 |
| 13 | TABLE ACCESS BY INDEX ROWID | AIRPORT_ROUTING | 1 | 30 | 2
|* 14 | INDEX RANGE SCAN | IX10_AIRPORT_ROUTING | 1 | | 1 |
|* 15 | TABLE ACCESS BY GLOBAL INDEX ROWID| DETAILED_FLIGHTS | 2 | 122 |
|* 16 | INDEX RANGE SCAN | IX3_DETAILED_FLIGHTS | 9 | | 2 |
| 17 | TABLE ACCESS BY INDEX ROWID | AIRPORT_PAIR | 1 | 85 | 2 |
|* 18 | INDEX RANGE SCAN | IX1_AIRPORT_PAIR | 1 | | 1 | |
| 19 | TABLE ACCESS BY INDEX ROWID | OD | 1 | 10 | 1 | |
|* 20 | INDEX UNIQUE SCAN | PK_OD | 1 | | | | |
----------------------------------------------------------------------------------------------------Ouf, this sound like better, isn't it ? Was it complicated to arrive as such result ?
Ok, now launch the query and see the elapse time :
104103 rows selected.
Elapsed: 00:09:00.12
Statistics
0 recursive calls
0 db block gets
1214845 consistent gets
272481 physical reads
0 redo size
11164355 bytes sent via SQL*Net to client
257032 bytes received via SQL*Net from client
6942 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
104103 rows processedWoaw, developer is now very happy, less than 10 minutes instead of one hour... and without modify anything else in database and server settings, without add indexes, without add any hints...
Ok, now the problem is in the number of returned lines. Have you see the number of return client/server ? We'll now to try to reduce this one. Increasing the number of line returned by fetch :
set arraysize 5000
--run the query
104103 rows selected.
Elapsed: 00:02:25.49
Statistics
0 recursive calls
0 db block gets
1150893 consistent gets
271432 physical reads
0 redo size
11018641 bytes sent via SQL*Net to client
1013 bytes received via SQL*Net from client
22 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
104103 rows processedOk, the number of retunr client/server is now low, and elapse time is ok user. -
Friends and gurus...
OS: Linux
DB: 11gR2
Recently I have found myself trapped into many sql query tuning with and without bind variables and main aim of all tuning is to reduce total elapsed time displayed in AWR report.
I found myself run all over the places just to identify problem and then try to solve it..
with near to zero experience in query tuning I'm trying to learn this art and have below questions...
Q.
1. Identify problem: could somebody please list what all internal oracle tools available just to identify problem and what should be best approach?
like sqltrace, explain plan, tkprof etc... list goes on so wanting to know which to follow and when...
2. any idea how to get all details of steps listed in explain plan? since predicate information only list few steps where filter is used but some steps which takes long (hash join, nested loops) I don't know what caused it...
3. how to identify problems in queries with bind variable?
please note I don't have any 3rd party tool and all I work on is sqlplus session.
thanks,khallas301, beside SB's reference to the Performance and Tuning Guide I want to point out that use of the AWR requires purchase of the extra cost EM Diagnositc and potentially also the Performance Pack License.
You can use statspack if you do not have the EM liceses.
How you approach what to tune depends a bit on the envornment. If only a few processes are having issues then you can look into customer complaints and tune what people are complaigning about. On the other hand if the entire system is having issues then you might want to identify critical processes and start with them.
One approach would be to run sql trace on a critical process. Review the traces and tune the SQL statements you find having issues. Record the results and move on to the next critical process.
Another approach would be to query the dynamic performance views for SQL with high logical IO counts, determine what processes the SQL is coming from, and tune that SQL.
HTH -- Mark D Powell -- -
Hi
Below query is executing in 10 Secs in my TEST env .THis is taking more than 5 min in my Production env .Both having same execution plans
db is 10g -
How can i improve the performance in Prod for this . What are all the points i have to lookin in new Oracle 10g database
SELECT IND, COUNT(*) FROM Table1 WHERE IND IN ('A', 'G', 'C', 'E', 'M')
GROUP BY IND ORDER BY IND
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=23185 Card=5 Bytes
=20)
1 0 SORT (GROUP BY) (Cost=23185 Card=5 Bytes=20)
2 1 INDEX (FAST FULL SCAN) OF 'tab_pk_indx' (INDE
X (UNIQUE)) (Cost=22718 Card=3919918 Bytes=15679672)Hi Alish,
>>
Well, you have many options:
http://www.dba-oracle.com/art_sql_tune.htm
Optimize the server kernel - You must always tune your disk and network I/O subsystem (RAID, DASD bandwidth, network) to optimize the I/O time, network packet size and dispatching frequency.
Adjusting your optimizer statistics - You must always collect and store optimizer statistics to allow the optimizer to learn more about the distribution of your data to take more intelligent execution plans. Also, histograms can hypercharge SQL in cases of determining optimal table join order, and when making access decisions on skewed WHERE clause predicates.
Adjust optimizer parameters - Optimizer optimizer_mode, optimizer_index_caching, optimizer_index_cost_adj.
Optimize your instance - Your choice of db_block_size, db_cache_size, and OS parameters (db_file_multiblock_read_count, cpu_count, &c), can influence SQL performance.
Tune your SQL Access workload with physical indexes and materialized views - Just as the 10g SQLAccess advisor recommends missing indexes and missing materialized views, you should always optimize your SQL workload with indexes, especially function-based indexes, a Godsend for SQL tuning.
Hope this helps. . . .
Donald K. Burleson
Oracle Press author
Maybe you are looking for
-
Report: Create report for invoice details, shipping details and partner fn.
hi, i want to know the table used for Invoice Details, Shipping Details and Partner Function in SD. thanks in advance.
-
How To Delete A Old App From The Purchased Tab In Your App Store On You Apple Device.
Hi , i Need Help On Finding The Way To Delete An Old App Record Out Of Your iTunes Dowload Log Which Is Located In The App Store. I Know You used To Be Able To Delete The Record that You Downloaded The App, But If Forgot How. Does Any One Remember H
-
Can't install ODAC on Win 7 64 bit
Getting a Java(TM) 2 Platform Standard Edition binary has stopped working - a problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. Can anyone help ???
-
How to get UTF-8 Characters from HTML to Java?
Hi everyone, I'm trying to set up an application that will allow display and entry of international data from HTML forms via servlets. The problem is that I can't get the data back into a java string to apply to the DBMS. I have tried using UTF-8 and
-
Missing Aperture .Mac Galleries
I have four .Mac galleries published from Aperture 2.1 (and several more from iPhoto). They no longer appear in my projects, although if I go into preferences I can see them (and stop publishing them). I don't want to stop publishing, but want to add