Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 379
  • Last Modified:

Query Executing Slow- plz help

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
AnnaJames77
Asked:
AnnaJames77
1 Solution
 
Ephraim WangoyaCommented:

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
 
AnnaJames77Author Commented:
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
 
AnnaJames77Author Commented:
Anyone pls help
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
deightonCommented:
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
 
AnnaJames77Author Commented:
thanks for your reply. It is a view that i am  using. is there any other way to rewrite the query
0
 
BitsqueezerCommented:
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
 
James0628Commented:
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

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now