Sql tuning query running slow -2
oracle : 10g
os : linux
SELECT *
FROM (SELECT elance_paginated_data.*, ROWNUM elance_current_row_number
FROM (SELECT elance_original_data.*
FROM (SELECT /*+first_rows ordered use_nl(cont) use_nl(conthub) use_nl(sps) */
cont.ID AS workorderid,
cont.status_id AS statusid,
cont.code AS workordercode,
cont.NAME AS workordertitle,
cont.description AS workorderdescription,
cont.start_dt AS startdate,
cont.end_dt AS enddate,
cont.termination_dt AS terminationdate,
cont.user_id AS hiring_manager_user_id,
cont.org_id AS org_id,
conthub.user_id AS contractorid,
-- cand.last_name AS last_name,
cand.last_name
|| ', '
|| cand.first_name AS candidatename,
cand.became_userid AS became_userid,
su.display_name AS hiring_manager_name,
ord.cat_id AS cat_id, ord.ID AS order_id,
ord.code AS order_code,
ord.NAME AS order_name,
ord.version_number AS version_number
FROM spm_contracts cont,
spm_contracts_hub conthub,
spm_candidates cand,
spm_users su,
spm_pmt_sched_hub spsh,
spm_payment_schedule sps,
spm_contracts ord
WHERE cont.owner_id = 4000 /* Change for GE env. : changed value from 100 to 4000 */
AND cont.contract_type_id = 323
AND cont.status_id IN (8705, 8709, 8708, 8702)
AND EXISTS (
SELECT 1
FROM spm_user_folder_details ufd
WHERE ufd.contract_id = cont.ID
AND ufd.user_id IN (
SELECT ru.role_id
FROM spm_role_users ru,
spm_roles r
WHERE ru.user_id = 29 /* Change for GE env. : changed value from 257698 to 29 */
AND ru.role_id = r.ID
AND r.type_of =
'ROLE_GROUP_TYPE'
UNION ALL
SELECT 29 /* Change for GE env. : changed value from 257698 to 29 */
FROM DUAL))
AND NOT EXISTS (
SELECT /*+ use_nl(pcr) */ 1
FROM spm_contract_pcr pcr,
spm_contracts ord2
WHERE pcr.contract_id_child = ord.ID
AND pcr.contract_id_parent = ord2.ID
AND ord2.status_id = 2612
AND pcr.type_of_relation IN
('CONTR_NEW_VERSION',
'CONTRACTOR_REENGAGED'
AND cont.ID = conthub.contract_id
AND conthub.type_of = 'CANDIDATE'
AND conthub.candidate_id = cand.ID
AND cont.user_id = su.ID
AND cont.ID = spsh.contract_id
AND spsh.pmt_sched_id = sps.ID
AND sps.contract_id = ord.ID
ORDER BY workorderid DESC) elance_original_data) elance_paginated_data
WHERE ROWNUM <= 31)
WHERE elance_current_row_number >= 1
call count cpu elapsed disk query current rows
Parse 1 0.60 0.57 1 148 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 4 12.70 21.37 3459 481585 0 31
total 6 13.30 21.94 3460 481733 0 31
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 21 (TLADM01)
Rows Row Source Operation
31 VIEW (cr=481585 pr=3459 pw=0 time=21365544 us)
31 COUNT STOPKEY (cr=481585 pr=3459 pw=0 time=21365480 us)
31 FILTER (cr=481585 pr=3459 pw=0 time=21365455 us)
31 VIEW (cr=481491 pr=3459 pw=0 time=21366696 us)
31 SORT ORDER BY (cr=481491 pr=3459 pw=0 time=21366310 us)
32745 NESTED LOOPS (cr=481491 pr=3459 pw=0 time=19266638 us)
32745 NESTED LOOPS (cr=415999 pr=3459 pw=0 time=18415173 us)
32745 HASH JOIN (cr=350507 pr=2907 pw=0 time=16695622 us)
32745 HASH JOIN (cr=349756 pr=2823 pw=0 time=16056095 us)
32745 HASH JOIN (cr=349581 pr=2780 pw=0 time=16950617 us)
32745 TABLE ACCESS BY INDEX ROWID SPM_CONTRACTS_HUB (cr=347407 pr=610 pw=0 time=8351793 us)
65491 NESTED LOOPS (cr=332023 pr=338 pw=0 time=105243492 us)
32745 NESTED LOOPS (cr=299202 pr=298 pw=0 time=6616161 us)
149239 VIEW VW_SQ_2 (cr=724 pr=53 pw=0 time=1118731 us)
149239 HASH UNIQUE (cr=724 pr=53 pw=0 time=969487 us)
197161 NESTED LOOPS (cr=724 pr=53 pw=0 time=394854 us)
9 VIEW VW_NSO_1 (cr=100 pr=0 pw=0 time=1288 us)
9 UNION-ALL (cr=100 pr=0 pw=0 time=1269 us)
8 NESTED LOOPS (cr=100 pr=0 pw=0 time=1133 us)
97 INDEX RANGE SCAN ROLE_TYPE_NDX (cr=1 pr=0 pw=0 time=514 us)(object id 30685)
8 INDEX UNIQUE SCAN ROLE_USERS_PK (cr=99 pr=0 pw=0 time=1140 us)(object id 30691)
1 FAST DUAL (cr=0 pr=0 pw=0 time=4 us)
197161 INDEX RANGE SCAN UFD_CONTRACT_FK_I (cr=624 pr=53 pw=0 time=197643 us)(object id 30848)
32745 TABLE ACCESS BY INDEX ROWID SPM_CONTRACTS (cr=298478 pr=245 pw=0 time=7787761 us)
149238 INDEX UNIQUE SCAN CONTRACTS_PK (cr=149240 pr=59 pw=0 time=2627776 us)(object id 30085)
32745 INDEX RANGE SCAN CONT_HUB_CONTRACT_FK_I (cr=32821 pr=40 pw=0 time=1129934 us)(object id 30106)
44590 TABLE ACCESS FULL SPM_CANDIDATES (cr=2174 pr=2170 pw=0 time=695935 us)
35864 INDEX FAST FULL SCAN SPM_USERS_SNZ1_IDX (cr=175 pr=43 pw=0 time=49486 us)(object id 30832)
44547 INDEX FAST FULL SCAN PMT_SCHED_HUB_IDX_1 (cr=751 pr=84 pw=0 time=101490 us)(object id 30474)
32745 TABLE ACCESS BY INDEX ROWID SPM_PAYMENT_SCHEDULE (cr=65492 pr=552 pw=0 time=3084181 us)
32745 INDEX UNIQUE SCAN PMT_SCHED_PK (cr=32747 pr=34 pw=0 time=512373 us)(object id 30427)
32745 TABLE ACCESS BY INDEX ROWID SPM_CONTRACTS (cr=65492 pr=0 pw=0 time=820633 us)
32745 INDEX UNIQUE SCAN CONTRACTS_PK (cr=32747 pr=0 pw=0 time=344850 us)(object id 30085)
0 NESTED LOOPS (cr=94 pr=0 pw=0 time=3048 us)
8 TABLE ACCESS BY INDEX ROWID SPM_CONTRACT_PCR (cr=70 pr=0 pw=0 time=2354 us)
8 INDEX RANGE SCAN CONTRACT_PCR_CHILD_FK_I (cr=62 pr=0 pw=0 time=1915 us)(object id 30116)
0 TABLE ACCESS BY INDEX ROWID SPM_CONTRACTS (cr=24 pr=0 pw=0 time=583 us)
8 INDEX UNIQUE SCAN CONTRACTS_PK (cr=16 pr=0 pw=0 time=328 us)(object id 30085)
Rows Execution Plan
0 SELECT STATEMENT MODE: HINT: FIRST_ROWS
31 VIEW
31 COUNT (STOPKEY)
31 FILTER
31 VIEW
31 SORT (ORDER BY)
32745 NESTED LOOPS
32745 NESTED LOOPS
32745 HASH JOIN
32745 HASH JOIN
32745 HASH JOIN
32745 TABLE ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'SPM_CONTRACTS_HUB' (TABLE)
65491 NESTED LOOPS
32745 NESTED LOOPS
149239 VIEW OF 'VW_SQ_2' (VIEW)
149239 HASH (UNIQUE)
197161 NESTED LOOPS
9 VIEW OF 'VW_NSO_1' (VIEW)
9 UNION-ALL
8 NESTED LOOPS
97 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'ROLE_TYPE_NDX' (INDEX)
8 INDEX MODE: ANALYZED
(UNIQUE SCAN) OF 'ROLE_USERS_PK' (INDEX
(UNIQUE))
1 FAST DUAL
197161 INDEX MODE: ANALYZED (RANGE
SCAN) OF 'UFD_CONTRACT_FK_I' (INDEX)
32745 TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'SPM_CONTRACTS' (TABLE)
149238 INDEX MODE: ANALYZED (UNIQUE SCAN)
OF 'CONTRACTS_PK' (INDEX (UNIQUE))
32745 INDEX MODE: ANALYZED (RANGE SCAN) OF
'CONT_HUB_CONTRACT_FK_I' (INDEX)
44590 TABLE ACCESS MODE: ANALYZED (FULL) OF
'SPM_CANDIDATES' (TABLE)
35864 INDEX MODE: ANALYZED (FAST FULL SCAN) OF
'SPM_USERS_SNZ1_IDX' (INDEX)
44547 INDEX MODE: ANALYZED (FAST FULL SCAN) OF
'PMT_SCHED_HUB_IDX_1' (INDEX)
32745 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'SPM_PAYMENT_SCHEDULE' (TABLE)
32745 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PMT_SCHED_PK' (INDEX (UNIQUE))
32745 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'SPM_CONTRACTS' (TABLE)
32745 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'CONTRACTS_PK' (INDEX (UNIQUE))
0 NESTED LOOPS
8 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'SPM_CONTRACT_PCR' (TABLE)
8 INDEX MODE: ANALYZED (RANGE SCAN) OF
'CONTRACT_PCR_CHILD_FK_I' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'SPM_CONTRACTS' (TABLE)
8 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'CONTRACTS_PK'
(INDEX (UNIQUE))output of tkprof attached
Hi Tom,
just a very basic hint:
Are the statistics computed on your schema? It definetely helps the optimizer choose the right path to access the data.
With up-to-date statistics, I did not experience major performance problem, while using the standard (java) search method.
Regards
Daniel
Similar Messages
-
Query runs slower when using variables & faster when using hard coded value
Hi,
My query runs slower when i use variables but it runs faster when i use hard coded values. Why it is behaving like this ?
My query is in cursor definition in a procedure. Procedure runs faster when using hard coded valus and slower when using variables.
Can anybody help me out there?
Thanks in advance.Hi,
Thanks for ur reply.
here is my code with Variables:
Procedure populateCountryTrafficDetails(pWeekStartDate IN Date , pCountry IN d_geography.country_code%TYPE) is
startdate date;
AR_OrgId number(10);
Cursor cTraffic is
Select
l.actual_date, nvl(o.city||o.zipcode,'Undefined') Site,
g.country_code,d.customer_name, d.customer_number,t.contrno bcn,
nvl(r.dest_level3,'Undefined'),
Decode(p.Product_code,'820','821','821','821','801') Product_Code ,
Decode(p.Product_code,'820','Colt Voice Connect','821','Colt Voice Connect','Colt Voice Line') DProduct,
sum(f.duration),
sum(f.debamount_eur)
from d_calendar_date l,
d_geography g,
d_customer d, d_contract t, d_subscriber s,
d_retail_dest r, d_product p,
CPS_ORDER_DETAILS o,
f_retail_revenue f
where
l.date_key = f.call_date_key and
g.geography_key = f.geography_key and
r.dest_key = f.dest_key and
p.product_key = f.product_key and
--c.customer_key = f.customer_key and
d.customer_key = f.customer_key and
t.contract_key = f.contract_key and
s.SUBSCRIBER_KEY = f.SUBSCRIBER_KEY and
o.org_id(+) = AR_OrgId and
g.country_code = pCountry and
l.actual_date >= startdate and
l.actual_date <= (startdate + 90) and
o.cli(+) = s.area_subno and
p.product_code in ('800','801','802','804','820','821')
group by
l.actual_date,
o.city||o.zipcode, g.country_code,d.customer_name, d.customer_number,t.contrno,r.dest_level3, p.product_code;
Type CountryTabType is Table of country_traffic_details.Country%Type index by BINARY_INTEGER;
Type CallDateTabType is Table of country_traffic_details.CALL_DATE%Type index by BINARY_INTEGER;
Type CustomerNameTabType is Table of Country_traffic_details.Customer_name%Type index by BINARY_INTEGER;
Type CustomerNumberTabType is Table of Country_traffic_details.Customer_number%Type index by BINARY_INTEGER;
Type BcnTabType is Table of Country_traffic_details.Bcn%Type index by BINARY_INTEGER;
Type DestinationTypeTabType is Table of Country_traffic_details.DESTINATION_TYPE%Type index by BINARY_INTEGER;
Type ProductCodeTabType is Table of Country_traffic_details.Product_Code%Type index by BINARY_INTEGER;
Type ProductTabType is Table of Country_traffic_details.Product%Type index by BINARY_INTEGER;
Type DurationTabType is Table of Country_traffic_details.Duration%Type index by BINARY_INTEGER;
Type DebamounteurTabType is Table of Country_traffic_details.DEBAMOUNTEUR%Type index by BINARY_INTEGER;
Type SiteTabType is Table of Country_traffic_details.Site%Type index by BINARY_INTEGER;
CountryArr CountryTabType;
CallDateArr CallDateTabType;
Customer_NameArr CustomerNameTabType;
CustomerNumberArr CustomerNumberTabType;
BCNArr BCNTabType;
DESTINATION_TYPEArr DESTINATIONTYPETabType;
PRODUCT_CODEArr PRODUCTCODETabType;
PRODUCTArr PRODUCTTabType;
DurationArr DurationTabType;
DebamounteurArr DebamounteurTabType;
SiteArr SiteTabType;
Begin
startdate := (trunc(pWeekStartDate) + 6) - 90;
Exe_Pos := 1;
Execute Immediate 'Truncate table country_traffic_details';
dropIndexes('country_traffic_details');
Exe_Pos := 2;
/* Set org ID's as per AR */
case (pCountry)
when 'FR' then AR_OrgId := 81;
when 'AT' then AR_OrgId := 125;
when 'CH' then AR_OrgId := 126;
when 'DE' then AR_OrgId := 127;
when 'ES' then AR_OrgId := 123;
when 'IT' then AR_OrgId := 122;
when 'PT' then AR_OrgId := 124;
when 'BE' then AR_OrgId := 132;
when 'IE' then AR_OrgId := 128;
when 'DK' then AR_OrgId := 133;
when 'NL' then AR_OrgId := 129;
when 'SE' then AR_OrgId := 130;
when 'UK' then AR_OrgId := 131;
else raise_application_error (-20003, 'No such Country Code Exists.');
end case;
Exe_Pos := 3;
dbms_output.put_line('3: '||to_char(sysdate, 'HH24:MI:SS'));
populateOrderDetails(AR_OrgId);
dbms_output.put_line('4: '||to_char(sysdate, 'HH24:MI:SS'));
Exe_Pos := 4;
Open cTraffic;
Loop
Exe_Pos := 5;
CallDateArr.delete;
FETCH cTraffic BULK COLLECT
INTO CallDateArr, SiteArr, CountryArr, Customer_NameArr,CustomerNumberArr,
BCNArr,DESTINATION_TYPEArr,PRODUCT_CODEArr, PRODUCTArr, DurationArr, DebamounteurArr LIMIT arraySize;
EXIT WHEN CallDateArr.first IS NULL;
Exe_pos := 6;
FORALL i IN 1..callDateArr.last
insert into country_traffic_details
values(CallDateArr(i), CountryArr(i), Customer_NameArr(i),CustomerNumberArr(i),
BCNArr(i),DESTINATION_TYPEArr(i),PRODUCT_CODEArr(i), PRODUCTArr(i), DurationArr(i),
DebamounteurArr(i), SiteArr(i));
Exe_pos := 7;
dbms_output.put_line('7: '||to_char(sysdate, 'HH24:MI:SS'));
EXIT WHEN ctraffic%NOTFOUND;
END LOOP;
commit;
Exe_Pos := 8;
commit;
dbms_output.put_line('8: '||to_char(sysdate, 'HH24:MI:SS'));
lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_CUSTNO ON country_traffic_details (CUSTOMER_NUMBER)';
execDDl(lSql);
lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_BCN ON country_traffic_details (BCN)';
execDDl(lSql);
lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_PRODCD ON country_traffic_details (PRODUCT_CODE)';
execDDl(lSql);
lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_SITE ON country_traffic_details (SITE)';
execDDl(lSql);
lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_DESTYP ON country_traffic_details (DESTINATION_TYPE)';
execDDl(lSql);
Exe_Pos:= 9;
dbms_output.put_line('9: '||to_char(sysdate, 'HH24:MI:SS'));
Exception
When Others then
raise_application_error(-20003, 'Error in populateCountryTrafficDetails at Position: '||Exe_Pos||' The Error is '||SQLERRM);
End populateCountryTrafficDetails;
In the above procedure if i substitute the values with hard coded values i.e. AR_orgid = 123 & pcountry = 'Austria' then it runs faster.
Please let me know why it is so ?
Thanks in advance. -
Query of query - running slower on 64 bit CF than 32 bit CF
Greetings...
I am seeing behavior where pages that use query-of-query run slower on 64-bit Coldfusion 9.01 than on 32-bit Coldfusion 9.01.
My server specs are : dual processer virtual machine, 4 GIG ram, Windows 2008 Datacenter Server r2 64-bit, Coldfusion 9.01. Note that the coldfusion is literally "straight out of the box", and is using all default settings - the only thing I configured in CF is a single datasource.
The script I am using to benchmark this runs a query that returns 20,000 rows with fields id, firstname, lastname, email, city, datecreated. I then loop through all 20,000 records, and for each record, I do a query-of-query (on the same master query) to find any other record where the lastname matches that of the record I'm currently on. Note that I'm only interested in using this process for comparative benchmarking purposes, and I know that the process could be written more efficiently.
Here are my observed execution times for both 64-bit and 32-bit Coldfusion (in seconds) on the same machine.
64 bit CF 9.01: 63,49,52,52,52,48,50,49,54 (avg=52 seconds)
32 bit CF 9.01: 47,45,43,43,45,41,44,42,46 (avg=44 seconds)
It appears from this that 64-bit CF performs worse than 32-bit CF when doing query-of-query operations. Has anyone made similar observations, and is there any way I can tune the environment to improve 64 bit performance?
Thanks for any help you can provide!
By the way, here's the code that is generating these results:
<!--- Allrecs query returns 20000 rows --->
<CFQUERY NAME="ALLRECS" DATASOURCE="MyDsn">
SELECT * FROM MyTBL
</CFQUERY>
<CFLOOP QUERY="ALLRECS">
<CFQUERY NAME="SAMELASTNAME" DBTYPE="QUERY">
SELECT * FROM ALLRECS
WHERE LN=<CFQUERYPARAM VALUE="#ALLRECS.LN#" CFSQLTYPE="CF_SQL_VARCHAR">
AND ID<><CFQUERYPARAM VALUE="#AllRecs.ID#" CFSQLTYPE="CF_SQL_INTEGER">
</CFQUERY>
<CFIF SameLastName.RecordCount GT 20>
#AllRecs.LN#, #AllRecs.FN# : #SameLastName.RecordCount# other records with same lastname<BR>
</CFIF>
</CFLOOP>BoBear2681 wrote:
..follow-up: ..Thanks for the follow-up. I'll be interested to hear the progress (or otherwise, as the case may be).
As an aside. I got sick of trying to deal with Clip because it could only handle very small Clip sizes. AFAIR it was 1 second of 44.1 KHz stereo. From that point, I developed BigClip.
Unfortunately BigClip as it stands is even less able to fulfil your functional requirement than Clip, in that only one BigClip can be playing at a time. Further, it can be blocked by other sound applications (e.g. VLC Media Player, Flash in a web page..) or vice-versa. -
SQL tuning for extremely slow query
Hi,
We have a requirement to display sales data by month. The sales data should be summed based on groups. The whole query is dynamically generated so the WHERE clause as well as the GROUP BY columns will be dynamically generated. Please find below the query which has been dynamically generated. The query is extremely slow and is not returning any data even after several minutes.
Please can anyone suggest possible ways of tuning this query? We are evaluating the option of using Materialied Views with Fast Refresh but the number of tables involved in this query runs into several hundreds and creating log in each table would be tedious.
Regards,
Balu
SELECT trantype, cmp, fyr, nam, cno, loc, or#, prd, siz, dat, ter, reg, gra,
mjr, mrk, fiscdat, GROUP_ID, class_id, group_name, class_name,
cmp_sreg, channel, bt_dsc, SUM (CASE fpr
WHEN 1
THEN amt
ELSE 0
END) AS a1,
SUM (CASE fpr
WHEN 2
THEN amt
ELSE 0
END) AS a2, SUM (CASE fpr
WHEN 3
THEN amt
ELSE 0
END) AS a3,
SUM (CASE fpr
WHEN 4
THEN amt
ELSE 0
END) AS a4, SUM (CASE fpr
WHEN 5
THEN amt
ELSE 0
END) AS a5,
SUM (CASE fpr
WHEN 6
THEN amt
ELSE 0
END) AS a6, SUM (CASE fpr
WHEN 7
THEN amt
ELSE 0
END) AS a7,
SUM (CASE fpr
WHEN 8
THEN amt
ELSE 0
END) AS a8, SUM (CASE fpr
WHEN 9
THEN amt
ELSE 0
END) AS a9,
SUM (CASE fpr
WHEN 10
THEN amt
ELSE 0
END) AS a10, SUM (CASE fpr
WHEN 11
THEN amt
ELSE 0
END) AS a11,
SUM (CASE fpr
WHEN 12
THEN amt
ELSE 0
END) AS a12, SUM (CASE fpr
WHEN 1
THEN qty
ELSE 0
END) AS q1,
SUM (CASE fpr
WHEN 2
THEN qty
ELSE 0
END) AS q2, SUM (CASE fpr
WHEN 3
THEN qty
ELSE 0
END) AS q3,
SUM (CASE fpr
WHEN 4
THEN qty
ELSE 0
END) AS q4, SUM (CASE fpr
WHEN 5
THEN qty
ELSE 0
END) AS q5,
SUM (CASE fpr
WHEN 6
THEN qty
ELSE 0
END) AS q6, SUM (CASE fpr
WHEN 7
THEN qty
ELSE 0
END) AS q7,
SUM (CASE fpr
WHEN 8
THEN qty
ELSE 0
END) AS q8, SUM (CASE fpr
WHEN 9
THEN qty
ELSE 0
END) AS q9,
SUM (CASE fpr
WHEN 10
THEN qty
ELSE 0
END) AS q10, SUM (CASE fpr
WHEN 11
THEN qty
ELSE 0
END) AS q11,
SUM (CASE fpr
WHEN 12
THEN qty
ELSE 0
END) AS q12,
SUM (CASE fpr
WHEN 1
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm1,
SUM (CASE fpr
WHEN 2
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm2,
SUM (CASE fpr
WHEN 3
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm3,
SUM (CASE fpr
WHEN 4
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm4,
SUM (CASE fpr
WHEN 5
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm5,
SUM (CASE fpr
WHEN 6
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm6,
SUM (CASE fpr
WHEN 7
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm7,
SUM (CASE fpr
WHEN 8
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm8,
SUM (CASE fpr
WHEN 9
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm9,
SUM (CASE fpr
WHEN 10
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm10,
SUM (CASE fpr
WHEN 11
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm11,
SUM (CASE fpr
WHEN 12
THEN (amt - (((frt + mrt + csc)) * qty))
ELSE 0
END
) AS cm12,
SUM (CASE fpr
WHEN 0
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml0,
SUM (CASE fpr
WHEN 1
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml1,
SUM (CASE fpr
WHEN 2
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml2,
SUM (CASE fpr
WHEN 3
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml3,
SUM (CASE fpr
WHEN 4
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml4,
SUM (CASE fpr
WHEN 5
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml5,
SUM (CASE fpr
WHEN 6
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml6,
SUM (CASE fpr
WHEN 7
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml7,
SUM (CASE fpr
WHEN 8
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml8,
SUM (CASE fpr
WHEN 9
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml9,
SUM (CASE fpr
WHEN 10
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml10,
SUM (CASE fpr
WHEN 11
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml11,
SUM (CASE fpr
WHEN 12
THEN (amt - (((lrt + frt + mrt + csc)) * qty))
ELSE 0
END
) AS cml12,
SUM (amt) AS a, SUM (qty) AS q,
SUM ((amt - (((frt + mrt + csc)) * qty))) AS cm,
SUM ((amt - (((lrt + frt + mrt + csc)) * qty))) AS cml
FROM (SELECT ruec_a.seq, ruec_a.trantype, ruec_a.cmp, ruec_a.fyr,
ruec_a.fpr, ruec_a.csc, ruec_a.lrt, ruec_a.mrt, ruec_a.frt,
ruec_a.typ, ruec_a.nam, ruec_a.cno, ruec_a.loc, ruec_a.or#,
ruec_a.prd, ruec_a.bulk_item_no, ruec_a.siz, ruec_a.dat,
NVL (ruec_a.qty, 0) qty, ruec_a.amt, ruec_a.ter, ruec_a.reg,
ruec_a.gra, ruec_a.mjr, ruec_a.mrk, ruec_a.fiscdat,
ruec_a.group_name, ruec_a.class_name, ruec_a.GROUP_ID,
ruec_a.cur, ruec_a.conversion_rate, ruec_a.grpnum,
ruec_a.rgnshi, ruec_a.mktshi, ruec_a.slmshi, ruec_a.mjrshi,
ruec_a.cmpid, ruec_a.chnshi, ruec_a.srgshi, ruec_a.sh_sreg,
ruec_a.cmp_sreg, ruec_a.channel, ruec_a.srgcmp,
ruec_a.biz_typ, ruec_a.bt_dsc, amt / NVL (qty, 1) qty$,
NVL ((amt - ((qty * csc) + (qty * frt) + (qty * mrt))),
0) cm,
NVL ((amt - (((frt + mrt + csc)) * qty)) / NVL (qty, 1),
0
) cm$,
NVL (( (( amt
- ( (qty * csc)
+ (qty * frt)
+ (qty * mrt * 100)
+ (qty * lrt)
/ 100
0
) gp,
((CASE amt
WHEN 0
THEN 0
ELSE NVL (( ( amt
- ( (qty * csc)
+ (qty * frt)
+ (qty * mrt * 100)
+ (qty * lrt)
/ amt
0
END
) pm,
ruec_a.customer_trx_id, ruec_a.customer_trx_line_id,
ruec_a.inventory_item_id, ruec_a.item_id, line_id, header_id,
ruec_a.customer_id, ruec_a.site_use_id, ruec_a.class_id
FROM (SELECT xxsrg.line_number seq, xxsrg.trantype,
xxsrg.co_code cmp, xxsrg.period_year fyr,
xxsrg.period_num fpr, csc_invcur * conv_rate csc,
lrt_invcur * conv_rate lrt,
mrt_invcur * conv_rate mrt,
xxsrg.frt_invcur * conv_rate frt,
xxsrg.inv_class typ, xxsrg.site_name nam,
xxsrg.customer_number cno, xxsrg.site_number loc,
xxsrg.ct_reference "OR#", xxsrg.item_no prd,
xxsrg.bulk_item_no, xxsrg.container_type siz,
xxsrg.trx_date dat, qty,
xxsrg.amt_invcur * conv_rate amt,
xxsrg.sales_territory_name ter,
xxsrg.sales_region_name reg,
xxsrg.customer_group_name gra,
xxsrg.major_market_name mjr,
xxsrg.minor_market_name mrk, xxsrg.trx_date fiscdat,
xxsrg.group_name group_name,
xxsrg.class_name class_name,
NVL (xxsrg.GROUP_ID, 0) GROUP_ID, xxsrg.inv_cur cur,
conv_rate conversion_rate,
xxsrg.customer_group_code grpnum,
xxsrg.sales_region_code rgnshi,
xxsrg.minor_market_id mktshi,
xxsrg.salesrep_id slmshi,
xxsrg.major_market_id mjrshi,
xxsrg.organization_id cmpid,
xxsrg.sales_channel_code chnshi, xxsrg.ssr_id srgshi,
xxsrg.ssr_name sh_sreg, xxsrg.psr_name cmp_sreg,
xxsrg.sales_channel_code channel,
xxsrg.psr_id srgcmp, xxsrg.biz_typ,
xxsrg.biz_typ_dsc bt_dsc, xxsrg.customer_trx_id,
xxsrg.customer_trx_line_id, xxsrg.inventory_item_id,
xxsrg.item_id, xxsrg.line_id, xxsrg.customer_id,
xxsrg.site_use_id, 0 class_id, 0 header_id
FROM (SELECT xxsrg.*,
CASE
WHEN 'CAD' = xxsrg.inv_cur
THEN 1
ELSE xxaoc_int_srg_util.get_dly_rate
(xxsrg.inv_cur,
'CAD',
xxsrg.trx_date
END conv_rate,
CASE
WHEN 'KG' = 'LB'
THEN xxsrg.qty_lbs
ELSE xxsrg.qty_kgs
END qty
FROM apps.xxaoc_bs_srg_details_vw xxsrg) xxsrg) ruec_a
WHERE (fiscdat >= '01-APR-06' AND fiscdat <= '01-APR-09')
AND (prd LIKE '%H864%')
AND grpnum IN (274, 275)
AND class_id IN (54)
AND GROUP_ID IN (10)
AND mjrshi IN ('4')
AND mktshi IN ('21')
AND rgnshi IN ('ER')
AND slmshi IN (10045)
AND cmpid IN (462)) ruec_a
GROUP BY trantype,
cmp,
fyr,
nam,
cno,
loc,
or#,
prd,
siz,
dat,
ter,
reg,
gra,
mjr,
mrk,
fiscdat,
GROUP_ID,
class_id,
group_name,
class_name,
GROUP_ID,
class_id,
chnshi,
srgshi,
sh_sreg,
cmp_sreg,
channel,
srgcmp,
biz_typ,
bt_dscThe database version is 10.2.0.3.0. Explain Plan is provided below please:
Plan
SELECT STATEMENT CHOOSECost: 435 Bytes: 10,402 Cardinality: 1
182 SORT GROUP BY Cost: 435 Bytes: 10,402 Cardinality: 1
181 VIEW SRG. Cost: 409 Bytes: 10,402 Cardinality: 1
180 FILTER
166 NESTED LOOPS Cost: 399 Bytes: 10,736 Cardinality: 1
163 NESTED LOOPS OUTER Cost: 396 Bytes: 10,693 Cardinality: 1
160 HASH JOIN OUTER Cost: 393 Bytes: 10,646 Cardinality: 1
117 HASH JOIN Cost: 299 Bytes: 10,636 Cardinality: 1
32 HASH JOIN Cost: 240 Bytes: 299 Cardinality: 1
27 FILTER
26 NESTED LOOPS OUTER Cost: 22 Bytes: 3,060 Cardinality: 12
23 HASH JOIN OUTER Cost: 19 Bytes: 232 Cardinality: 1
18 NESTED LOOPS OUTER Cost: 12 Bytes: 216 Cardinality: 1
15 VIEW VIEW APPS.XXAOC_RA_CUST_TRX_LINES_VW Cost: 9 Bytes: 147 Cardinality: 1
14 FILTER
10 FILTER
9 NESTED LOOPS Cost: 5 Bytes: 195 Cardinality: 1
6 NESTED LOOPS Cost: 4 Bytes: 171 Cardinality: 1
4 NESTED LOOPS Cost: 4 Bytes: 163 Cardinality: 1
1 TABLE ACCESS FULL TABLE AR.RA_CUSTOMER_TRX_LINES_ALL Cost: 3 Bytes: 34 Cardinality: 1
3 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 129 Cardinality: 1
2 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cardinality: 1
5 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_BATCH_SOURCES_U2 Bytes: 8 Cardinality: 1
8 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUST_TRX_TYPES_ALL Cost: 1 Bytes: 24 Cardinality: 1
7 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUST_TRX_TYPES_U1 Cardinality: 1
13 COUNT STOPKEY
12 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_SYSTEM_ITEMS_B Cost: 4 Bytes: 22 Cardinality: 1
11 INDEX RANGE SCAN INDEX (UNIQUE) INV.MTL_SYSTEM_ITEMS_B_U1 Cost: 3 Cardinality: 1
17 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 3 Bytes: 69 Cardinality: 1
16 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 2 Cardinality: 1
22 VIEW VIEW APPS.CM_CLDR_HDR_VL Cost: 6 Bytes: 1,632 Cardinality: 102
21 NESTED LOOPS Cost: 6 Bytes: 2,346 Cardinality: 102
19 TABLE ACCESS FULL TABLE GMF.CM_CLDR_HDR_B Cost: 6 Bytes: 1,632 Cardinality: 102
20 INDEX RANGE SCAN INDEX GMF.CM_CLDR_HDR_TL_PK Bytes: 7 Cardinality: 1
25 TABLE ACCESS BY INDEX ROWID TABLE GMF.CM_CLDR_DTL Cost: 3 Bytes: 276 Cardinality: 12
24 INDEX RANGE SCAN INDEX (UNIQUE) GMF.CM_CLDR_DTL_PK Cost: 1 Cardinality: 12
31 VIEW VIEW APPS.XXAOC_IC_ITEM_MST_VW Cost: 217 Bytes: 82,632 Cardinality: 1,878
30 NESTED LOOPS Cost: 217 Bytes: 61,974 Cardinality: 1,878
28 TABLE ACCESS FULL TABLE GMI.IC_ITEM_MST_B Cost: 217 Bytes: 46,950 Cardinality: 1,878
29 INDEX UNIQUE SCAN INDEX (UNIQUE) GMI.IC_ITEM_MST_TL_PK Bytes: 8 Cardinality: 1
116 VIEW VIEW APPS.XXAOC_BS_CUST_SITE_VW Cost: 58 Bytes: 10,337 Cardinality: 1
115 SORT ORDER BY Cost: 58 Bytes: 1,149 Cardinality: 1
114 FILTER
113 NESTED LOOPS OUTER Cost: 33 Bytes: 1,149 Cardinality: 1
110 FILTER
109 NESTED LOOPS OUTER Cost: 31 Bytes: 1,130 Cardinality: 1
106 NESTED LOOPS OUTER Cost: 30 Bytes: 1,111 Cardinality: 1
104 NESTED LOOPS OUTER Cost: 29 Bytes: 1,088 Cardinality: 1
101 NESTED LOOPS Cost: 29 Bytes: 1,041 Cardinality: 1
99 NESTED LOOPS OUTER Cost: 29 Bytes: 1,037 Cardinality: 1
97 NESTED LOOPS Cost: 28 Bytes: 1,001 Cardinality: 1
94 NESTED LOOPS Cost: 27 Bytes: 910 Cardinality: 1
92 NESTED LOOPS Cost: 26 Bytes: 902 Cardinality: 1
89 NESTED LOOPS Cost: 25 Bytes: 796 Cardinality: 1
86 NESTED LOOPS Cost: 24 Bytes: 773 Cardinality: 1
83 NESTED LOOPS OUTER Cost: 23 Bytes: 678 Cardinality: 1
81 NESTED LOOPS Cost: 23 Bytes: 675 Cardinality: 1
78 NESTED LOOPS OUTER Cost: 22 Bytes: 666 Cardinality: 1
76 NESTED LOOPS OUTER Cost: 22 Bytes: 662 Cardinality: 1
70 NESTED LOOPS OUTER Cost: 22 Bytes: 649 Cardinality: 1
64 NESTED LOOPS OUTER Cost: 22 Bytes: 636 Cardinality: 1
54 NESTED LOOPS OUTER Cost: 21 Bytes: 609 Cardinality: 1
52 NESTED LOOPS OUTER Cost: 20 Bytes: 573 Cardinality: 1
50 NESTED LOOPS OUTER Cost: 18 Bytes: 515 Cardinality: 1
47 NESTED LOOPS OUTER Cost: 17 Bytes: 457 Cardinality: 1
45 NESTED LOOPS OUTER Cost: 15 Bytes: 421 Cardinality: 1
43 NESTED LOOPS Cost: 13 Bytes: 385 Cardinality: 1
40 NESTED LOOPS Cost: 12 Bytes: 290 Cardinality: 1
37 NESTED LOOPS OUTER Cost: 11 Bytes: 237 Cardinality: 1
35 HASH JOIN Cost: 10 Bytes: 143 Cardinality: 1
33 TABLE ACCESS FULL TABLE AR.RA_TERRITORIES Cost: 3 Bytes: 34 Cardinality: 1
34 TABLE ACCESS FULL TABLE AR.HZ_CUST_SITE_USES_ALL Cost: 6 Bytes: 11,336 Cardinality: 104
36 INDEX RANGE SCAN INDEX (UNIQUE) JTF.JTF_RS_SALESREPS_U1 Cost: 1 Cardinality: 11
39 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCT_SITES_ALL Cost: 1 Bytes: 53 Cardinality: 1
38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCT_SITES_U1 Cardinality: 1
42 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 95 Cardinality: 1
41 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cardinality: 1
44 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 2 Bytes: 36 Cardinality: 1
46 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 2 Bytes: 36 Cardinality: 1
49 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 1 Bytes: 58 Cardinality: 1
48 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 1 Cardinality: 1
51 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 1 Cardinality: 1
53 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 1 Bytes: 36 Cardinality: 1
63 VIEW PUSHED PREDICATE VIEW APPS.RA_SALESREPS Cost: 1 Bytes: 27 Cardinality: 1
62 NESTED LOOPS Cost: 4 Bytes: 59 Cardinality: 1
59 NESTED LOOPS Cost: 3 Bytes: 22 Cardinality: 1
56 TABLE ACCESS BY INDEX ROWID TABLE JTF.JTF_RS_SALESREPS Cost: 2 Bytes: 11 Cardinality: 1
55 INDEX RANGE SCAN INDEX (UNIQUE) JTF.JTF_RS_SALESREPS_U1 Cost: 1 Cardinality: 1
58 TABLE ACCESS BY INDEX ROWID TABLE JTF.JTF_RS_RESOURCE_EXTNS Cost: 1 Bytes: 11 Cardinality: 1
57 INDEX UNIQUE SCAN INDEX (UNIQUE) JTF.JTF_RS_RESOURCE_EXTNS_U1 Cardinality: 1
61 INLIST ITERATOR
60 INDEX UNIQUE SCAN INDEX (UNIQUE) JTF.JTF_RS_EXTNS_U1 Cardinality: 1
69 VIEW PUSHED PREDICATE VIEW APPS.OE_PRICE_LISTS_115_VL Bytes: 13 Cardinality: 1
68 NESTED LOOPS Cost: 1 Bytes: 62 Cardinality: 1
66 TABLE ACCESS BY INDEX ROWID TABLE QP.QP_LIST_HEADERS_B Cost: 1 Bytes: 45 Cardinality: 1
65 INDEX UNIQUE SCAN INDEX (UNIQUE) QP.QP_LIST_HEADERS_B_PK Cardinality: 1
67 INDEX UNIQUE SCAN INDEX (UNIQUE) QP.QP_LIST_HEADERS_TL_PK Bytes: 17 Cardinality: 1
75 VIEW PUSHED PREDICATE VIEW APPS.OE_ORDER_TYPES_115 Bytes: 13 Cardinality: 1
74 NESTED LOOPS Cost: 1 Bytes: 43 Cardinality: 1
72 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_TRANSACTION_TYPES_ALL Cost: 1 Bytes: 26 Cardinality: 1
71 INDEX UNIQUE SCAN INDEX (UNIQUE) ONT.OE_TRANSACTION_TYPES_ALL_U1 Cardinality: 1
73 INDEX UNIQUE SCAN INDEX (UNIQUE) ONT.OE_TRANSACTION_TYPES_TL_U1 Bytes: 17 Cardinality: 1
77 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_ORGANIZATION_UNITS_PK Bytes: 4 Cardinality: 1
80 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUSTOMER_PROFILES Cost: 1 Bytes: 9 Cardinality: 1
79 INDEX RANGE SCAN INDEX AR.HZ_CUSTOMER_PROFILES_N1 Cardinality: 1
82 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_PROFILE_CLASSES_U1 Bytes: 3 Cardinality: 1
85 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 95 Cardinality: 1
84 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cardinality: 1
88 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTY_SITES Cost: 1 Bytes: 23 Cardinality: 1
87 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTY_SITES_U1 Cardinality: 1
91 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_LOCATIONS Cost: 1 Bytes: 106 Cardinality: 1
90 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_LOCATIONS_U1 Cardinality: 1
93 INDEX RANGE SCAN INDEX AR.HZ_LOC_ASSIGNMENTS_N1 Cost: 1 Bytes: 8 Cardinality: 1
96 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 91 Cardinality: 1
95 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cardinality: 1
98 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 1 Bytes: 36 Cardinality: 1
100 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Bytes: 4 Cardinality: 1
103 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CONTACT_PREFERENCES Bytes: 47 Cardinality: 1
102 INDEX RANGE SCAN INDEX AR.HZ_CONTACT_PREFERENCES_N1 Cardinality: 1
105 INDEX RANGE SCAN INDEX AR.HZ_CONTACT_POINTS_N6 Cost: 1 Bytes: 23 Cardinality: 1
108 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_ORGANIZATION_PROFILES Cost: 1 Bytes: 19 Cardinality: 1
107 INDEX RANGE SCAN INDEX AR.HZ_ORGANIZATION_PROFILES_N1 Cardinality: 1
112 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PERSON_PROFILES Cost: 2 Bytes: 19 Cardinality: 1
111 INDEX RANGE SCAN INDEX AR.HZ_PERSON_PROFILES_N1 Cost: 1 Cardinality: 1
159 VIEW VIEW APPS.XXAOC_SALES_REGION_VW Cost: 94 Bytes: 40 Cardinality: 4
158 SORT ORDER BY Cost: 94 Bytes: 2,736 Cardinality: 4
157 VIEW VIEW APPS.XXAOC_CT_KFF_VW Cost: 69 Bytes: 2,736 Cardinality: 4
156 SORT ORDER BY Cost: 69 Bytes: 800 Cardinality: 4
155 CONCATENATION
127 MERGE JOIN CARTESIAN Cost: 11 Bytes: 200 Cardinality: 1
123 NESTED LOOPS Cost: 5 Bytes: 82 Cardinality: 1
120 NESTED LOOPS Cost: 4 Bytes: 54 Cardinality: 1
118 TABLE ACCESS FULL TABLE APPLSYS.FND_ID_FLEX_SEGMENTS Cost: 4 Bytes: 28 Cardinality: 1
119 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_ID_FLEX_SEGMENTS_TL_U1 Bytes: 26 Cardinality: 1
122 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUE_SETS Cost: 1 Bytes: 28 Cardinality: 1
121 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_FLEX_VALUE_SETS_U1 Cardinality: 1
126 BUFFER SORT Cost: 10 Bytes: 2,714 Cardinality: 23
125 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 6 Bytes: 2,714 Cardinality: 23
124 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 2 Cardinality: 23
136 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 6 Bytes: 2,714 Cardinality: 23
135 NESTED LOOPS Cost: 11 Bytes: 200 Cardinality: 1
133 NESTED LOOPS Cost: 5 Bytes: 82 Cardinality: 1
130 NESTED LOOPS Cost: 4 Bytes: 54 Cardinality: 1
128 TABLE ACCESS FULL TABLE APPLSYS.FND_ID_FLEX_SEGMENTS Cost: 4 Bytes: 28 Cardinality: 1
-
Query running slow after 1000 rows in oracle
Hi.
I have one query which is fetching miln of rows.. the query runs very fast till 1000 to 1500 records after that it run very slow. Can you please help ,what could be the reason?
Thanks831269 wrote:
I have one query which is fetching miln of rows.. Why are you fetching that many rows? What is your client code going to do with a million rows? And why do you expect this to be fast? A million rows worth of I/O has to be done by Oracle (that will likely be mostly from disk and not buffer cache). That million rows has to be copied from the Oracle's SGA to client memory. If your client is PL/SQL code, that will be copied into the PGA. If your client is external, then that copy has to happen across platform boundaries and the network too.
Then your code churns away on processing a million rows... doing what exactly? That "+what+" will need to be done once per row, for a million times. If it takes 10ms per row, that means almost 3h of client processing time.
Fetching that many rows..? Often a design and coding mistake. Always an exception to the rule. Will never be "fast".
And scalability and performance need to be addressed by re-examining the requirements, optimising the design that necessitates fetching that many rows, and using techniques such as parallel processing and thread safe code design. -
I have a search query that uses the substr function to fetch some records.The query runs fine when executing SQL*PLUS or any other client like PL/SQL Developer. The same query is dead slow in Forms interface.
Can anyone suggest?Both the query use the substr function. Here is the query. only highlighted IF condition evaluates to true.
V_SEARCH VARCHAR2(255);
BEGIN
--- SET MOBILENO
IF :CONTROL.MOBILENO IS NOT NULL AND LENGTH(:CONTROL.MOBILENO) <= 7 THEN
IF :CONTROL.QRY_MOBILENO = 'P' THEN
V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) = '||''''||:CONTROL.MOBILENO||'''';
ELSIF :CONTROL.QRY_MOBILENO = 'S' THEN
V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) LIKE '||''''||:CONTROL.MOBILENO||'%''';
ELSIF :CONTROL.QRY_MOBILENO = 'E' THEN
V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) LIKE '||'''%'||:CONTROL.MOBILENO||'''';
ELSIF :CONTROL.QRY_MOBILENO = 'C' THEN
V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) LIKE '||'''%'||:CONTROL.MOBILENO||'%''';
END IF;
ELSIF :CONTROL.MOBILENO IS NOT NULL AND LENGTH(:CONTROL.MOBILENO) <= 11 THEN
IF :CONTROL.QRY_MOBILENO = 'P' THEN
V_SEARCH := V_SEARCH||' AND MOBILENO = '||''''||:CONTROL.MOBILENO||'''';
ELSIF :CONTROL.QRY_MOBILENO = 'S' THEN
V_SEARCH := V_SEARCH||' AND MOBILENO LIKE '||''''||:CONTROL.MOBILENO||'%''';
ELSIF :CONTROL.QRY_MOBILENO = 'E' THEN
V_SEARCH := V_SEARCH||' AND MOBILENO LIKE '||'''%'||:CONTROL.MOBILENO||'''';
ELSIF :CONTROL.QRY_MOBILENO = 'C' THEN
V_SEARCH := V_SEARCH||' AND MOBILENO LIKE '||'''%'||:CONTROL.MOBILENO||'%''';
END IF;
END IF;
--NDC
IF :CONTROL.NDC IS NOT NULL THEN
V_SEARCH := V_SEARCH||' AND SUBSTR(MOBILENO,1,4) = '||''''||:CONTROL.NDC||'''';
END IF;
--Number Type
IF :CONTROL.number_type IS NOT NULL THEN
V_SEARCH := V_SEARCH||' AND number_type = '||''''||:CONTROL.number_type||'''';
END IF;
--Status
IF :CONTROL.status IS NOT NULL THEN
V_SEARCH := V_SEARCH||' AND status = '||''''||substr(:CONTROL.status,1,1)||'''';
END IF;
--CITY
IF :CONTROL.CITY IS NOT NULL THEN
V_SEARCH := V_SEARCH||' AND LOC_NAME = '||''''||:CONTROL.CITY||'''';
END IF;
--REGION
IF :CONTROL.REGION IS NOT NULL THEN
V_SEARCH := V_SEARCH||' AND COMM_REGION = '||''''||:CONTROL.REGION||'''';
END IF;
--RECYCLE FLAG
IF :CONTROL.RECYCLE_FLAG <> 'A' THEN
V_SEARCH := V_SEARCH||' AND RECYCLE_FLAG = '||''''||:CONTROL.RECYCLE_FLAG||'''';
END IF;
--EXECUTE QUERY
V_SEARCH := SUBSTR(V_SEARCH,5);
GO_BLOCK('NO_INVENTORY');
SET_BLOCK_PROPERTY('NO_INVENTORY',ONETIME_WHERE,V_SEARCH);
EXECUTE_QUERY;
END; -
Below query is running slow is there any other way to write the query which will enhance the performance.
select ld.cst_fle_seq,
tf.date_pro,
lj.case_num ,
ca.reference,
rr.rej_txt
from
load_judg lj,
rej_rea rr ,
pl_case ca,
tp_files tf ,
tp tp
where rr.rej_code(+) = ld.rej_code
and ca.case_num (+)=lj.case_num
and tp.seq =tf.seq
and lj.cred_code(+) =tp.cst_code
and tp.format =9
and valid=''Y''
and tf.fle_name like ''%F%''
and lj.rej_code is not null
and trunc(date_pro)=trunc(sysdate)
Thanks in advance
JhaHere is the explan plan of the query
- SELECT STATEMENT Optimizer=CHOOSE (Cost=16 Card=1 Bytes=225)
-NESTED LOOPS (Cost=16 Card=1 Bytes=225)
-NESTED LOOPS (OUTER) (Cost=15 Card=1 Bytes=192)
- HASH JOIN (Cost=14 Card=1 Bytes=147)
- MERGE JOIN (CARTESIAN) (Cost=9 Card=4 Bytes=432)
-TABLE ACCESS (FULL) OF LOAD_JUDGMENTS (Cost=1 Card=1 Bytes=69)
- SORT (JOIN)
-TABLE ACCESS (FULL) OF TAPE_FILES
-TABLE ACCESS (FULL) OF TAPES (Cost=4 Card=418 Bytes=16302)
-TABLE ACCESS (BY ROWID) OF REJECT_REASONS
-INDEX (UNIQUE SCAN) OF REJ_PK (UNIQUE)
-TABLE ACCESS (BY ROWID) OF CASES
-INDEX (UNIQUE SCAN) OF CASE_PK (UNIQUE)
sorry, as I have checked the tables and its not a cartesian.
Thanks
Jha -
Query Running Slow due to nvl.
I have a Cursor Based query written as a Procedure.when i invoke that procedure,I found that two condition statements are the ones which is making my query run very slow.
Since this has been handled with NVL statements query is running very slow.Currently query takes more than one hour to execute.if i comment these two statements and run the query,it takes ony 20 secs to complete.
Those two statements are
'and rbsa.batch_source_id = nvl(p_source_type_id, rbsa.batch_source_id)'
'and rsa.salesrep_id between nvl(p_from_salesrep_id, rsa.salesrep_id) and nvl(p_to_salesrep_id, rsa.salesrep_id)'
Is there any other alternative to replace these two statements by other means.
Thanks in Advance...Dear Friend,
Please try to replace nvl(p_source_type_id, rbsa.batch_source_id) with decode(p_source_type_id,NULL,rbsa.batch_source_id,p_source_type_id)
It will speedup your query.
Regards
Ahamed Rafeeque Cherkala -
Sql query runs slower from the application
Hi,
We are using oracle 9ias on AIX box.The jdk version used: 1.3.1 . From the j2ee application when we perfom a search, the sql query takes for ever to return the results. I know that we are waiting on the database because I can see the query working when I look at TOAD.But if i run the same query on the database server itself, it returns the results in less than a sec. Could you guys throw some light on how we could troubleshoot this problem. Thanks.When the results have to travel over the network, it is slow, and when they don't, it is fast.
That is what you are saying, correct?
So your approach should be to not bring so much data over the network. Don't select columns you don't need, and don't select rows you don't need. -
Hi
i have a query when i run it for the first time it returs result in 30 mins after few mins (say 2 m ins) if i run the same query it fetches result in 3 mins) can any one hel me to tune the issu
when i saw AWR report i showed too many disk I/o and sql messege to client wait events
DB: Oracle 10g
O/S: Unix
DB cahce size :1GB
help PleaePLAN_TABLE_OUTPUT
Plan hash value: 3961783764
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 390 | 361 (2)| 00:00:05 |
| 1 | SORT GROUP BY | | 2 | 390 | 361 (2)| 00:00:05 |
| 2 | VIEW | | 2 | 390 | 360 (1)| 00:00:05 |
| 3 | UNION-ALL | | | | | |
| 4 | NESTED LOOPS | | 1 | 297 | 344 (1)| 00:00:05 |
|* 5 | HASH JOIN | | 1 | 231 | 343 (1)| 00:00:05 |
| 6 | TABLE ACCESS FULL | TRAN_VH_INV_SS_PART | 3634 | 72680 | 213 (0)| 00:00:03 |
|* 7 | HASH JOIN | | 1799 | 370K| 129 (2)| 00:00:02 |
| 8 | TABLE ACCESS FULL | MAST_MF_NAME | 4 | 84 | 5 (0)| 00:00:01 |
|* 9 | HASH JOIN | | 1799 | 333K| 123 (1)| 00:00:02 |
|* 10 | HASH JOIN | | 1552 | 209K| 120 (1)| 00:00:02 |
|* 11 | TABLE ACCESS FULL | HIST_VH_INV_SS_PART | 1188 | 62964 | 115 (0)| 00:00:02 |
| 12 | NESTED LOOPS | | 24566 | 2039K| 4 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID| MAST_YM_YARD | 1 | 29 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | MAST_YM_YARD_01 | 1 | | 0 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID| TRAN_VH_INV_SUB_SERVICE | 24566 | 1343K| 3 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | TRAN_VH_INV_SUB_SERVICE_02 | 1 | | 2 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | TRAN_VH_INV | 3863 | 196K| 3 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | TRAN_VH_INV_02 | 1 | | 2 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | TRAN_VH_INV_WORKSHEET | 1 | 66 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | TRAN_VH_INV_WORKSHEET_01 | 1 | | 0 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 1 | 297 | 16 (0)| 00:00:01 |
| 22 | NESTED LOOPS | | 1 | 277 | 14 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 224 | 10 (0)| 00:00:01 |
| 24 | NESTED LOOPS | | 1 | 203 | 9 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 151 | 7 (0)| 00:00:01 |
| 26 | NESTED LOOPS | | 1 | 85 | 5 (0)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID| MAST_YM_YARD | 1 | 29 | 1 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | MAST_YM_YARD_01 | 1 | | 0 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID| TRAN_VH_SHP_SUB_SERVICE | 1 | 56 | 4 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | TRAN_VH_SHP_SUB_SERVICE_02 | 1 | | 3 (0)| 00:00:01 |
|* 31 | TABLE ACCESS BY INDEX ROWID | TRAN_VH_SHP_WORKSHEET | 1 | 66 | 2 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | TRAN_VH_SHP_WORKSHEET_01 | 1 | | 1 (0)| 00:00:01 |
|* 33 | TABLE ACCESS BY INDEX ROWID | TRAN_VH_SHP | 1 | 52 | 2 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | TRAN_VH_SHP_01 | 1 | | 1 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | MAST_MF_NAME | 1 | 21 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | MAST_MF_NAME_01 | 1 | | 0 (0)| 00:00:01 |
|* 37 | TABLE ACCESS BY INDEX ROWID | HIST_VH_SHP_SS_PART | 1 | 53 | 4 (0)| 00:00:01 |
|* 38 | INDEX RANGE SCAN | HIST_VH_SHP_SS_PART_01 | 5 | | 2 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | TRAN_VH_SHP_SS_PART | 1 | 20 | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | TRAN_VH_SHP_SS_PART_01 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
5 - access("C"."SUB_SERVICE_SEQ_NUM"="H"."SUB_SERVICE_SEQ_NUM" AND
"C"."PDI_PART_ORDER_NUM"="H"."PDI_PART_ORDER_NUM" AND
"C"."SUB_SERVICE_PART_SEQ_NUM"="H"."SUB_SERVICE_PART_SEQ_NUM")
7 - access("D"."MFG_CODE"="E"."MFG_CODE")
9 - access("D"."YARD_CODE"="A"."YARD_CODE" AND "D"."VIN_NUM"="B"."VIN_NUM" AND
"B"."TERMINAL_SEQ_NO"="D"."TERMINAL_SEQ_NO" AND "B"."YARD_CODE"="D"."YARD_CODE")
10 - access("B"."SUB_SERVICE_SEQ_NUM"="C"."SUB_SERVICE_SEQ_NUM")
11 - filter("C"."PART_FRANCHISE">=U' ' AND TRUNC(INTERNAL_FUNCTION("C"."ACTUAL_ISSUE_DATE_TIME"))<>TO_DAT
E(' 0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
AND "C"."PART_FRANCHISE"<=U'~')
14 - access("A"."TERMINAL_SEQ_NO"=1 AND "A"."YARD_CODE"=U'1')
16 - access("B"."TERMINAL_SEQ_NO"=1 AND "B"."YARD_CODE"=U'1')
18 - access("D"."TERMINAL_SEQ_NO"=1 AND "D"."YARD_CODE"=U'1')
19 - filter("G"."YARD_CODE"=U'1' AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<>TO_DATE('
0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "G"."TERMINAL_SEQ_NO"=1 AND
(TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))>=TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00',
'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<TO_DATE(' 2010-06-01
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE('
2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE(
2010-06-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))<=TO_DAT
E
(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') OR
TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))=TO_DATE(' 0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
OR TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))>=TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00',
'syyyy-mm-dd hh24:mi:ss')) AND "G"."VIN_NUM"="D"."VIN_NUM")
20 - access("G"."WORKSHEET_NUM"="B"."WORKSHEET_NUM")
28 - access("A"."TERMINAL_SEQ_NO"=1 AND "A"."YARD_CODE"=U'1')
30 - access("B"."TERMINAL_SEQ_NO"=1 AND "B"."YARD_CODE"=U'1')
31 - filter("G"."YARD_CODE"=U'1' AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<>TO_DATE('
0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "G"."TERMINAL_SEQ_NO"=1)
32 - access("G"."WORKSHEET_NUM"="B"."WORKSHEET_NUM")
33 - filter("D"."YARD_CODE"=U'1' AND "D"."TERMINAL_SEQ_NO"=1)
34 - access("G"."VIN_NUM"="D"."VIN_NUM")
filter("D"."VIN_NUM"="B"."VIN_NUM")
36 - access("D"."MFG_CODE"="E"."MFG_CODE")
37 - filter("C"."PART_FRANCHISE">=U' ' AND TRUNC(INTERNAL_FUNCTION("C"."ACTUAL_ISSUE_DATE_TIME"))<>TO_DAT
E(' 0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
AND "C"."PART_FRANCHISE"<=U'~' AND (TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))>=TO_DATE(' 2010-06-01
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<=TO_DATE('
2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<TO_DATE
' 2010-06-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
(TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
OR TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00',
'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))=TO_DATE(' 0001-01-01 00:00:00',
'syyyy-mm-dd hh24:mi:ss')) OR TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))>=TO_DATE(' 2010-06-01
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE('
2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
38 - access("B"."SUB_SERVICE_SEQ_NUM"="C"."SUB_SERVICE_SEQ_NUM")
39 - filter("C"."PDI_PART_ORDER_NUM"="H"."PDI_PART_ORDER_NUM")
40 - access("C"."SUB_SERVICE_SEQ_NUM"="H"."SUB_SERVICE_SEQ_NUM" AND
PLAN_TABLE_OUTPUT
"C"."SUB_SERVICE_PART_SEQ_NUM"="H"."SUB_SERVICE_PART_SEQ_NUM")
Note
- SQL profile "SYS_SQLPROF_014aab7522964001" used for this statementEdited by: user629451 on Sep 22, 2010 12:23 AM
Edited by: user629451 on Sep 22, 2010 12:25 AM -
Help on SQL Query Running slow -
Explain plan -
Explain plan for select is here:
Execution Plan
| Id | Operation | Name | Rows |
Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 4589K|
5497M| 352K (1)|
| 1 | NESTED LOOPS OUTER | | 4589K|
5497M| 352K (1)|
| 2 | NESTED LOOPS OUTER | | 4589K|
5409M| 214K (1)|
| 3 | NESTED LOOPS | | 4589K|
5322M| 168K (1)|
| 4 | TABLE ACCESS FULL | SERVICE_REQUEST | 4634K|
1423M| 75254 (2)|
| 5 | TABLE ACCESS BY INDEX ROWID| S_SRV_REQ | 1 |
894 | 1 (0)|
|* 6 | INDEX UNIQUE SCAN | S_SRV_REQ_P1 | 1 |
| 1 (0)|
| 7 | TABLE ACCESS BY INDEX ROWID | S_SRV_REGN | 1 |
20 | 1 (0)|
|* 8 | INDEX UNIQUE SCAN | S_SRV_REGN_P1 | 1 |
| 1 (0)|
| 9 | TABLE ACCESS BY INDEX ROWID | S_SRV_REQ_X | 1 |
20 | 1 (0)|
|* 10 | INDEX RANGE SCAN | S_SRV_REQ_X_U1 | 1 |
| 1 (0)|
Predicate Information (identified by operation id):
6 - access("S"."ROW_ID"="SR"."SERVICE_REQUEST_ROW_ID")
8 - access("S"."SRV_REGN_ID"="R"."ROW_ID"(+))
10 - access("SRX"."PAR_ROW_ID"(+)="S"."ROW_ID")
SQL> set autotrace off
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> show parameter opt
NAME TYPE VALUE
filesystemio_options string asynch
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 1
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
plsql_optimize_level integer 2Thanks for the information. As the query is taking huge time to execute I am not able to get the trace of the query. Please suggest for any performance improvements based on the available explain plan details.
Query -
SELECT /*+ FIRST_ROWS */
s.row_id service_request_row_id,
s.sr_num service_req_id,
s.prdint_id product_id,
s.x_comp_prd_id component_id,
s.cst_ou_id account_id,
s.cst_con_id contact_id,
s.par_sr_id parent_service_request_row_id,
s.agree_id entitlement_id,
s.asset_id asset_id,
s.x_locality locality,
s.resolution_cd problem_classification,
s.x_res_text resolution,
s.post_mortem_rvw_by front_line_owner_id,
s.owner_emp_id resolution_owner_id,
s.bu_id resolution_group_id,
s.owner_ou_id front_line_workgroup_id,
s.created_by created_by_id,
sr.created_by_workgroup created_by_workgroup,
s.target_con_id secondary_contact_id,
s.created time_opened,
s.x_srvc_restored time_service_restored,
s.act_close_dt time_closed,
s.last_upd last_updated,
s.x_last_eservice_upd last_eservice_update,
s.x_sr_pref_comms_chnl preferred_comms_channel,
s.sr_area TYPE,
s.sr_sub_area sub_type,
s.sr_stat_id status,
s.sr_sub_stat_id sub_status,
s.sr_title abstract,
s.desc_text description,
s.exp_close_dt response_time,
s.x_likely_resolution_time likely_resolution_time,
s.x_proactive proactive_type,
s.x_market_sector market_sector,
s.x_light_sr light_sr,
s.x_esrvc_flg eservice,
s.sr_sev_cd severity,
s.x_urgency_copy priority,
s.x_impact impact,
s.x_sr_category CATEGORY,
s.x_generic_identifier generic_id,
sr.interface_name interface_name,
s.x_referral_target referral_target,
s.rtng_dlr_id referral_account_id,
s.x_data_country data_country,
s.x_data_exchange data_exchange,
s.x_dc_loc data_centre_location,
s.x_data_type data_type,
s.x_data_source data_source,
s.x_db_queried database_queried,
s.x_data_item data_item,
s.x_sr_class_type classification_type,
s.x_sr_class_sub_type classification_sub_type,
s.x_resolver_grp ds_resolver_group,
s.x_sys_subsys system_sub_system,
s.x_assembly assembly_sub_assembly,
s.x_prob_start_time problem_start_time,
s.x_prob_stop_time problem_stop_time,
s.x_del_infrastructure delivery_infrastructure,
s.x_network_srvc network_service,
s.x_telco_name telco_name,
s.x_circuit_type circuit_type,
s.x_extra_telco_info additional_circuit_telco_info,
s.x_security_type security_type,
s.resolution_cd resolution_code,
s.x_secondary_cntct secondary_contact,
s.sr_os operating_system,
s.ou_addr_id service_address_id,
s.x_external_srvc external_service,
s.x_system ops_ref_system,
s.x_sub_system ops_ref_sub_system,
s.x_symptom symptom,
s.x_asset_subcomponent asset_subcomponent,
s.x_solution_flg save_solution,
s.x_trgt_rstrd_time target_restoration_time,
s.x_second_level second_level,
r.NAME service_region,
s.x_spec_instrs special_instructions,
s.x_ext_ticket_refno external_ticket_ref_no,
sr.original_priority original_priority,
sr.original_severity original_severity,
sr.originating_comm_type originating_comm_type,
sr.fline_owner_timezone_offset fline_owner_timezone_offset,
sr.res_owner_timezone_offset res_owner_timezone_offset,
sr.fixed_by_workgroup fixed_by_workgroup ,
sr.fixed_by_owner_id fixed_by_owner_id,
sr.resolved_by_workgroup resolved_by_workgroup,
sr.channel channel,
s.x_orig_commit time_of_1st_entitled_response,
sr.time_of_1st_assignment time_of_1st_assignment,
sr.time_of_1st_call_back time_of_1st_call_back,
sr.time_of_resolution time_of_resolution,
sr.time_of_iface_assignment time_of_iface_assignment,
sr.time_to_1st_entitled_resp_24x7 time_to_1st_entitled_resp_24x7 ,
sr.time_to_1st_assignment_24x7 time_to_1st_assignment_24x7 ,
sr.time_to_1st_assign_24x7_excl time_to_1st_assign_24x7_excl,
sr.TIME_TO_1ST_INFOACT_CONTACT TIME_TO_1ST_INFOACT_CONTACT,
sr.TIME_TO_1ST_ENHAACT_CONTACT TIME_TO_1ST_ENHAACT_CONTACT,
sr.time_to_1st_call_back_24x7 time_to_1st_call_back_24x7 ,
sr.time_to_1st_call_bck_24x7_excl time_to_1st_call_bck_24x7_excl,
sr.time_to_service_rest_24x7 time_to_service_rest_24x7 ,
sr.time_to_service_rest_24x7_excl time_to_service_rest_24x7_excl ,
sr.time_to_serv_rest_24x7_excl1 time_to_serv_rest_24x7_excl1,
sr.time_to_serv_rest_24x7_excl2 time_to_serv_rest_24x7_excl2,
sr.time_to_resolution_24x7 time_to_resolution_24x7 ,
sr.time_to_closure_24x7 time_to_closure_24x7 ,
sr.time_to_closure_24x7_excl time_to_closure_24x7_excl,
sr.time_to_iface_assignment_24x7 time_to_iface_assignment_24x7,
sr.time_to_1st_entitled_resp_24x5 time_to_1st_entitled_resp_24x5 ,
sr.time_to_1st_assignment_24x5 time_to_1st_assignment_24x5 ,
sr.time_to_1st_call_back_24x5 time_to_1st_call_back_24x5 ,
sr.time_to_service_rest_24x5 time_to_service_rest_24x5 ,
sr.time_to_resolution_24x5 time_to_resolution_24x5 ,
sr.time_to_closure_24x5 time_to_closure_24x5 ,
sr.rsh_duration_type rsh_duration_type ,
sr.time_to_1st_entitled_resp_rsh time_to_1st_entitled_resp_rsh ,
sr.time_to_1st_assignment_rsh time_to_1st_assignment_rsh ,
sr.time_to_1st_call_back_rsh time_to_1st_call_back_rsh ,
sr.time_to_service_rest_rsh time_to_service_rest_rsh ,
sr.time_to_resolution_rsh time_to_resolution_rsh ,
sr.time_to_closure_rsh time_to_closure_rsh ,
sr.resolved_within_same_day resolved_within_same_day,
sr.resolved_in_one_go resolved_in_one_go,
sr.resolved_within_crmc resolved_within_crmc,
sr.resolved_with_site_visit resolved_with_site_visit,
sr.involved_field_services involved_field_services,
sr.involved_data_centre involved_data_centre,
sr.involved_rdh involved_rdh,
sr.involved_account_team involved_account_team,
sr.latest_parked_status latest_parked_status,
sr.num_front_line_owner_changes num_front_line_owner_changes,
sr.fs_time_of_1st_fs_activity,
sr.fs_time_of_1st_dispatch,
sr.fs_time_of_1st_fs_response,
sr.fs_time_of_flo_reassign,
sr.fs_time_to_1st_fs_activity_rsh,
sr.fs_time_to_1st_dispatch_rsh,
sr.fs_time_to_1st_fs_response_rsh,
sr.fs_time_to_flo_reassign_rsh,
sr.number_activities,
sr.number_open_activities,
s.x_prd_version product_version,
s.x_prd_srvc_info product_service_details,
s.x_urgency notify_level,
srx.attrib_47 concat_sr_attrib
FROM crmrep_rep.crm_s_srv_regn r, crmrep_rep.crm_s_srv_req s, crmrep_rep.SERVICE_REQUEST sr ,crmrep_rep.CRM_S_SRV_REQ_X srx
WHERE
s.row_id = sr.service_request_row_id
and s.srv_regn_id = r.row_id(+)
AND srx.par_row_id(+) = s.row_id;
Explain Plan
The script for view creation is attached.
Explain plan for select is here:
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 4589K| 5497M| 352K (1)|
| 1 | NESTED LOOPS OUTER | | 4589K| 5497M| 352K (1)|
| 2 | NESTED LOOPS OUTER | | 4589K| 5409M| 214K (1)|
| 3 | NESTED LOOPS | | 4589K| 5322M| 168K (1)|
| 4 | TABLE ACCESS FULL | SERVICE_REQUEST | 4634K| 1423M| 75254 (2)|
| 5 | TABLE ACCESS BY INDEX ROWID| S_SRV_REQ | 1 | 894 | 1 (0)|
|* 6 | INDEX UNIQUE SCAN | S_SRV_REQ_P1 | 1 | | 1 (0)|
| 7 | TABLE ACCESS BY INDEX ROWID | S_SRV_REGN | 1 | 20 | 1 (0)|
|* 8 | INDEX UNIQUE SCAN | S_SRV_REGN_P1 | 1 | | 1 (0)|
| 9 | TABLE ACCESS BY INDEX ROWID | S_SRV_REQ_X | 1 | 20 | 1 (0)|
|* 10 | INDEX RANGE SCAN | S_SRV_REQ_X_U1 | 1 | | 1 (0)|
Predicate Information (identified by operation id):
6 - access("S"."ROW_ID"="SR"."SERVICE_REQUEST_ROW_ID")
8 - access("S"."SRV_REGN_ID"="R"."ROW_ID"(+))
10 - access("SRX"."PAR_ROW_ID"(+)="S"."ROW_ID")
Note
- 'PLAN_TABLE' is old version
Version Information
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
Optimizer parameters
filesystemio_options string asynch
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 1
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
plsql_optimize_level integer 2
Cursor values
NAME TYPE VALUE
cursor_sharing string EXACT
cursor_space_for_time boolean FALSE
open_cursors integer 1500
session_cached_cursors integer 200
Block Details
db_block_buffers integer 0
db_block_checking string FALSE
db_block_checksum string TRUE
db_block_size integer 8192
db_file_multiblock_read_count integer 8
Thanks in advance. -
UCCX 5 SQL Dbase Query Issues - Slow Returns
For several months it seemed to me that our UCCX 5 system was beginning to have trouble. At first it appeared as a problem with our wallboard system being unable to display the real-time data properly. I had deduced that queries to the db_cra database were taking 4 - 5 minutes to return data.
At first I called on the vendor for our wallboard, but they were unable to help stating that it was a UCCX database issue - and I agreed. I then went to Cisco TAC and fed them all my information and asked them for help. They also were unable to help figure out what was happening, but they could see that the SQL queries that used to take 2 seconds were now taking several minutes. Since the wallboard system queried the database every 10 seconds, it was over-taxing the database.
This began to cause little anomalies in things like call-distribution, dropped calls, slow to no Historical reports returns, and this ultimately began to cause failovers to our backup node. I could not go a day without a failover and I had to reboot the servers almost every night.
I felt there was no solution and was afraid we needed to replace our system.
After talking to all the engineers around the world, my solution came from our very own SQL administrator. Within 5 minutes he was able to resolve all our issues.
The root of our problem was that the indexing of the db_cra database was extremely fragmented.
He wrote a SQL sript that he had me run against the database and he told me that this would correct any indexing issues.
It worked like a charm.
The system stopped behaving poorly immediately. This resolved many of our problems that I had been living with for a long time. It made the Admin page work so much faster, call distribution issues halted, the wallboard is running faster than ever with real-time data, and the list goes on. This resolved so many smaller issues that I cannot even list them all.
I would advise anyone using a SQL database, whether it be a Cisco product or not, to always keep their database 'defragmented'.
My SQL admin also setup the script to run automatically, on a schedule to keep our database running like a Ferrari. It has been sweet ever since.
KEEP YOUR INDEXES CLEAN AND YOU WILL REAP HAPPINESS!I was equally shocked that there was no escalation, as was my boss and my Cisco rep. They let me go with no resolution and hung-up the phone leaving me with instructions to have some-one else take a look at the database. It was very unexpected, especially considering how close they were to the point when we were trouble-shooting.
The TAC SR # 611904619 - IPCC Database Not Returning Query Data.
With this resolution, it also raised to my mind the issue of Informix. We are using CUCM 6.1.2 and are concerned about the same issue happening there and we would like to determine if this can happen there also, and if there is a re-indexing tool available for Informix. -
Query running slow in one node
Hi All,
We are running 4-node Oracle 10g RAC (linux 64-bit). The query is running fast in one node, but the same query is running very slow in the other node. And sometimes, we see pin S wait on X wait event in top 5 events.
Has anyone faced this kind of situation before ?
Thanks,
KumarHi,
Execute your query on node where query is running very slow. Get SID and execute query above to see what is event of waiting.
exec dbms_application_info.set_client_info('@sw2')
-- file sw2.sql
col event format a25 heading "Wait Event" trunc
col state format a15 heading "Wait State" trunc
col siw format 99999 heading "Waited So|Far (ms)"
col wt format 9999999 heading "Time Waited|(ms)"
select event,
state,
seconds_in_wait siw,
wait_time wt
from v$session_wait
where sid = &sid
order by event;
exec dbms_application_info.set_client_info('@sw1');
-- file sw1.sql
set linesize 30000
set pagesize 200
col sid format 9999 heading "SID"
col username format a10 heading "USERNAME"
col osuser format a20 heading "OSUSER"
col event format a25 heading "Wait Event" trunc
col state format a15 heading "Wait State" trunc
col siw format 99999 heading "Waited So|Far (ms)"
col wt format 9999999 heading "Time Waited|(ms)"
col sw1 format 9999999 heading "File"
col sw2 format 9999999 heading "Block"
col Objeto format a50
select sw.event,
sw.p1,
sw.p2,
sw.p3,
sw.state,
s.sid,
S.osuser,
s.username,
nvl(s.program, s.module),
sw.seconds_in_wait siw,
sw.wait_time wt
from gv$session_wait sw,
gv$session s
WHERE sw.sid = s.sid
and sw.EVENT NOT LIKE 'SQL%'
and username is not NULL
and s.inst_id = sw.inst_id
and sw.event not like 'PX%'
order by 1, 6, 7;Regards,
Levi Pereira -
SDO_ANYINTERACT query runs slower with numerous iterations
hi all,
I have some PL/SQL code within a loop that take longer and longer to run as it iterates through the loop.
I have identified the problem function below. It seems that the SDO_ANYINTERACT takes longer and longer to execute the more it is called.
I have found a bug on metalink 7003151 with indicates a potential memory leak issue. Could this be a cause? I know that this function runs as expected using Oracle Express. The issue is on a development server which has been patched to 10.2.0.4.
FUNCTION SEARCHFORFEATURE(sTABLE VARCHAR2,gGEOM MDSYS.SDO_GEOMETRY, nSEARCH NUMBER) RETURN VARCHAR2 IS
TYPE typNIMSREF IS TABLE OF VARCHAR2(10);
vNIMSREF TYPNIMSREF;
sSQL VARCHAR2(500);
BEGIN
sSQL := 'SELECT NIMSREF FROM ' || sTABLE || ' S WHERE SDO_ANYINTERACT(S.GEOLOC, :gGEOM) = 'TRUE';
EXECUTE IMMEDIATE sSQL BULK COLLECT INTO vNIMSref USING gGEOM;
IF vNIMSREF.COUNT = 1 THEN
RETURN vNIMSREF(1);
ELSIF vNIMSREF.COUNT > 1 THEN
RETURN '-1';
ELSE
RETURN '-2';
END IF;
EXCEPTION -- exception-handling part starts here
WHEN OTHERS THEN
dbms_output.put_line(SQLERRM);
dbms_output.put_line(sSQL);
END SEARCHFORFEATURE;
Thanks in advance
DanielI have run the query in SQLPLUS. As a single call performance is as expected. I ahve included the XPLAN. I have also tried using SDO_RELATE and SDO_INSIDE but it still slows down after a number if interations. I have looked at bug 7003151 but there are not available patches for a window 32bit OS.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3399 | 331K| 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| WATER_NODES | 3399 | 331K| 3 (0)| 00:00:01 |
|* 2 | DOMAIN INDEX | WATER_NODES_SDX | | | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("MDSYS"."SDO_ANYINTERACT"("S"."GEOLOC","MDSYS"."SDO_GEOMETRY"(2003,82086,
NULL,"SDO_ELEM_INFO_ARRAY"(1,1003,4),"SDO_ORDINATE_ARRAY"(123455.9,123456,123456.1,1234
56,123456,123456.1)))='TRUE') -
Spatial query runs slow on view
Hello,
I have two tables and one of them has geometry column. I created view to join those two tables based on id column which has been indexed for both tables.
t1(
id number(9),
name varchar2(20)
t2(
id number(9),
geom MDSYS.SDO_GEOMETRY
CREATE VIEW v1 (
id,
name,
geom
) AS
SELECT /*+ FIRST_ROWS */ t1.id, t1.name, t2.geom
FROM t1,t2
WHERE t1.id = t2.id
When I query the view with following statement it runs very slow (there are more then 1 million rows in t2 table)
SELECT * FROM v1
WHERE mdsys.sdo_filter(geom, [a rectangle],'querytype=window') = 'TRUE';
but
SELECT /*+ FIRST_ROWS */ t1.id, t1.name,t2.geom
FROM t1,t2
WHERE t1.id=t2.id
and mdsys.sdo_filter(geom, [a rectangle],'querytype=window') = 'TRUE';
returns almost instantly. Can some one tell me what is wrong with the "create view" statement?
ThanksThank you for your reply. Here are the plans. The view looks for the spatial index first.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 21 | 756 | 10 (60)|
| 1 | NESTED LOOPS | | 21 | 756 | 10 (60)|
| 2 | TABLE ACCESS BY INDEX ROWID| T2 | 5269 | 123K| 3 (0)|
| 3 | DOMAIN INDEX | T2_SDX | | | |
| 4 | TABLE ACCESS BY INDEX ROWID| T1 | | | |
| 5 | INDEX RANGE SCAN | T1_ID_IDX | 1 | | 0 (0)|
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 21 | 756 | 99 (3)|
| 1 | TABLE ACCESS BY INDEX ROWID | T2 | 1 | 24 | 99 (3)|
| 2 | NESTED LOOPS | | 21 | 756 | 99 (3)|
| 3 | TABLE ACCESS FULL | T1 | 21 | 252 | 2 (0)|
| 4 | BITMAP CONVERSION TO ROWIDS | | | | |
| 5 | BITMAP AND | | | | |
| 6 | BITMAP CONVERSION FROM ROWIDS| | | | |
| 7 | INDEX RANGE SCAN | T2_ID_IDX | 1 | | 2 (0)|
| 8 | BITMAP CONVERSION FROM ROWIDS| | | | |
| 9 | SORT ORDER BY | | | | |
| 10 | DOMAIN INDEX | T2_SDX | 1 | | |
-----------------------------------------------------------------------------------------------------
Maybe you are looking for
-
Hot Sync problems with Windows Vista using a Tungsten E2
Need Help solving a hot sync problem. Have a Tungsten E2, about a year old. Use Windows Vista OS. Can not sync to desktop. It worked fine for awhile then stopped sync'ing. Have reinstalled Palm Software, Have downloaded Palm 6.2. Have deleted all 3rd
-
I just finished installing this on our build machine only to discover that there is, apparently, no command line interface that I can use in my build scripts to automatically convert robohelp input files to html files. I've searched and searched and
-
Hi Can anyone help me with the exact syntax to create temp table in Oracle 8i in Stored Proc. Eg. CREATE PROCEDURE MROSiteNoVendors @IDCustomer INT AS SELECT DISTINCT s.IDCustomer, SiteName, Address , AddressII, City, State, Zip, s.IDSite INTO #TempT
-
Sometimes HTML source is being shown instead of rendering it
Sometimes my webpage shows the html source instead of rendering. If i refresh the page it shows my page correctly. My html tags are correct and i have added meta tag 'meta http-equiv="content-type" content="text/html; charset=utf-8"' on the page head
-
Can you replace existing images in Captivate 7 the way you can when using InDesign?
Can you replace existing images in Captivate 7 the way you can when using InDesign? I need to replace some images but wondering if I'll need to reformat, resize, rename for the Advanced Action, etc.