Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Query Executing Slow- plz help

Posted on 2011-03-21
8
Medium Priority
?
378 Views
Last Modified: 2012-05-11
The query of SSRS report takes long time .

select a.InvoiceID,a.CustomerCode,a.CustName,a.dimension,
a.dimension2_,a.dimension3_ ,
a.SALES_AMOUNT,a.COST_AMOUNT,a.GROSS_PROFIT,a.MARGIN_PER
from (
select InvoiceID,CustomerCode,CustName,dimension,dimension2_,dimension3_,
sum(LineAmountMST) SALES_AMOUNT,
SUM(linecostAmount) COST_AMOUNT,
sum(LineAmountMST- linecostAmount) GROSS_PROFIT,
case
when SUM(lineamountmst)=0 and sum(linecostamount)> 0 then -100
when SUM(lineamountmst)=0 and sum(linecostamount)< 0 then 100
when SUM(lineamountmst)=0 and sum(linecostamount)= 0 then 0
else
sum(LineAmountMST- linecostAmount)/sum(LineAmountMST)*100 END MARGIN_PER

FROM  salesdim

where invoicedate between @startdate and @enddate
and itembuyergroupid in (@itembuyergroupid)
and itemgroupid in (@itemgroupid)
and salesoriginid in (@salesoriginid)
and CustomerCode in (@Cust)
and dimension in (@Dept)
and dimension2_ in (@CC)
and dimension3_ in (@Purpose)

GROUP BY InvoiceID,CustomerCode,CustName,dimension,dimension2_,dimension3_)a
where a.MARGIN_PER between @marginFrom and @marginTo
order by a.MARGIN_PER desc
0
Comment
Question by:AnnaJames77
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
8 Comments
 
LVL 32

Expert Comment

by:Ephraim Wangoya
ID: 35186723

I don't see the reason why you need to select from a derived table in this case.
Why don't you just make it a simple select from salesdim table
0
 

Author Comment

by:AnnaJames77
ID: 35186726
Because i need to select only those records having percentage selected by user in parameter. Can you pls rewrite it for me if there is another way to improve performance.
0
 

Author Comment

by:AnnaJames77
ID: 35186945
Anyone pls help
0
Will your db performance match your db growth?

In Percona’s white paper “Performance at Scale: Keeping Your Database on Its Toes,” we take a high-level approach to what you need to think about when planning for database scalability.

 
LVL 18

Expert Comment

by:deighton
ID: 35188496
do you have indexes on the table?  

try creating a non-unique non clustered index on  all of the fields mentioned in
'
where invoicedate between @startdate and @enddate
and itembuyergroupid in (@itembuyergroupid)
and itemgroupid in (@itemgroupid)
and salesoriginid in (@salesoriginid)
and CustomerCode in (@Cust)
and dimension in (@Dept)
and dimension2_ in (@CC)
and dimension3_ in (@Purpose)'

in that order, if you haven't indexd the table already



0
 

Author Comment

by:AnnaJames77
ID: 35188699
thanks for your reply. It is a view that i am  using. is there any other way to rewrite the query
0
 
LVL 24

Accepted Solution

by:
Bitsqueezer earned 2000 total points
ID: 35196795
Hi,

you can also add indices to views, if the table definition allows it.

I'm not sure that this will really give a better performance, cannot try it without your environment. I tried to rewrite it as CTEs, that gives you the possibility to select the things in different steps.

The first step groups the data, calculates the sums and filters the data before grouping. The second step creates the additional column "MARGIN_PER" but don't need to use the SUM function so maybe works faster. Also the CASE WHEN was optimized to only calculate the things needed by using nested CASE WHENs. The third step grabs the complete data from step 2 and filters the "MARGIN_PER".

To see if it is really (if, then only a little bit) faster you need to use the client statistics and/or execution plan.

Question is, if the grouping of the first step really makes sense (depending on your data): As you included the InvoiceID which normally is a unique value you maybe get only one record for one invoice and in this case no sum or group would make sense. But as I said, depends on your data.

The other question is, if it makes sense to use the "IN" clause to filter the data in step 1. Normally this only makes sense if you provide more than one value inside the following brackets. If you use a variable you only get one value (more than one like "1,2,3" would not work, it would be used as one string value). So maybe it is faster if you change them (all) to a comparison which makes sense for you like "itemgroupid = @itemgroupid" and so on. I am not sure as I never tested it but I would guess this will also speed up your query, especially if you use indices on these columns. (In the table and/or the view).

Cheers,

Christian

WITH a AS
(SELECT InvoiceID, CustomerCode, CustName,
		dimension, dimension2_, dimension3_,
        SUM(LineAmountMST)  AS SALES_AMOUNT,
		SUM(linecostAmount) AS COST_AMOUNT,
		SUM(LineAmountMST - linecostAmount) AS GROSS_PROFIT
     FROM      salesdim
     WHERE (invoicedate BETWEEN @startdate AND @enddate) 
	   AND (itembuyergroupid IN (@itembuyergroupid))
	   AND (itemgroupid		 IN (@itemgroupid))
       AND (salesoriginid	 IN (@salesoriginid))
       AND (CustomerCode	 IN (@Cust))
       AND (dimension		 IN (@Dept))
       AND (dimension2_		 IN (@CC))
       AND (dimension3_		 IN (@Purpose))
     GROUP BY InvoiceID, CustomerCode, CustName, dimension, dimension2_, dimension3_
),
b AS
(SELECT InvoiceID, CustomerCode, CustName,
		dimension, dimension2_, dimension3_,
        SALES_AMOUNT, COST_AMOUNT, GROSS_PROFIT,
		CASE SALES_AMOUNT WHEN 0
		THEN
			 CASE WHEN COST_AMOUNT > 0 THEN -100
				  WHEN COST_AMOUNT < 0 THEN 100
				  WHEN COST_AMOUNT = 0 THEN 0
			 END
		ELSE GROSS_PROFIT / SALES_AMOUNT * 100
		END AS MARGIN_PER
     FROM a
)
SELECT * FROM b
WHERE (MARGIN_PER BETWEEN @marginFrom AND @marginTo)
ORDER BY MARGIN_PER DESC

Open in new window

0
 
LVL 35

Expert Comment

by:James0628
ID: 35197041
I don't know if this will actually affect the performance, but all of those SUM's in the inner query seem unnecessary.  All that you really need are SALES_AMOUNT and COST_AMOUNT.  You can use those to calculate GROSS_PROFIT and MARGIN_PER in the outer query.  The WHERE in the outer query would be a bit more complicated, since it would need to include the CASE to calculate the margin.  Still, it might be worth a try.  Whether or not it would actually affect the performance would depend on how clever the server is being when it sees those SUM's.  It just _looks_ kind of redundant seeing the same SUM's over and over in the inner query.

 James
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

For both online and offline retail, the cross-channel business is the most recent pattern in the B2C trade space.
Recently we ran in to an issue while running some SQL jobs where we were trying to process the cubes.  We got an error saying failure stating 'NT SERVICE\SQLSERVERAGENT does not have access to Analysis Services. So this is a way to automate that wit…
Viewers will learn how to use the SELECT statement in SQL to return specific rows and columns, with various degrees of sorting and limits in place.
Viewers will learn how to use the SELECT statement in SQL and will be exposed to the many uses the SELECT statement has.

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question