Solved

Query Executing Slow- plz help

Posted on 2011-03-21
8
375 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
Optimizing Cloud Backup for Low Bandwidth

With cloud storage prices going down a growing number of SMBs start to use it for backup storage. Unfortunately, business data volume rarely fits the average Internet speed. This article provides an overview of main Internet speed challenges and reveals backup best practices.

 
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 500 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

Salesforce Made Easy to Use

On-screen guidance at the moment of need enables you & your employees to focus on the core, you can now boost your adoption rates swiftly and simply with one easy tool.

Question has a verified solution.

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

Suggested Solutions

In this article we will get to know that how can we recover deleted data if it happens accidently. We really can recover deleted rows if we know the time when data is deleted by using the transaction log.
A Stored Procedure in Microsoft SQL Server is a powerful feature that it can be used to execute the Data Manipulation Language (DML) or Data Definition Language (DDL). Depending on business requirements, a single Stored Procedure can return differe…
Using examples as well as descriptions, and references to Books Online, show the documentation available for datatypes, explain the available data types and show how data can be passed into and out of variables.
Viewers will learn how the fundamental information of how to create a table.

752 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