|
Hello everyone !!! My store procedure take 40-50 sec execution time can anyone refere me some solution to reduce it to 5-10 sec?? ////////////////////////////////////////////////////
////////////////////////////////////////////////////
(comments are locked)
|
|
I can't really tell what you're trying to achieve from a stored procedure given there is no description of it and no DDL, as Fatherjack pointed out. However, I can tell you that it is probably slow because you are doing data manipulation in a loop, rather than using a set based update. Out of interest - how long does this bit take to run? Thanks friends for u r quick reply. I am using the above store procedure for calculation monthly performance of the employees in a firm(which calculate their monthly presents, absent,weekoff,latecome,earlygo etc..) Yes Mr.Matt i hav used loop here because it is caculating the above information for the whole employees of a firm.
Apr 20 '10 at 06:53 AM
Pankaj
Let me know how long the insert into #muster bit takes - because if it is quick, then it is very likely that it is your loop that is slowing things down. You need to use set based statements that work on all the data at once, rather than using a row-by-agonising-row method.
Apr 20 '10 at 07:11 AM
Matt Whitfield ♦♦
Hi matt , the insert into #muster bit takes very less time. can u explain u r ideas with some more discriptive way.what should i hav to do instead of the loop??
Apr 20 '10 at 07:41 AM
Pankaj
Try reading this: http://www.simple-talk.com/sql/t-sql-programming/rbar--row-by-agonizing-row/ Basically you need to achieve your requirements without using while loops etc
Apr 20 '10 at 08:32 AM
Matt Whitfield ♦♦
I agree with Matt, this type of code is no better than Cursors, and SQL server has never been fast with cursors. You may get away with cursors in Oracle but not in SQL server.
Apr 20 '10 at 09:45 AM
Håkan Winther
(comments are locked)
|
|
I don't know what your data structure looks like, but if you want real performance, then you need to get away from this type of code:
If compcode is a varchar and @compcode is a varchar, then you only need to do this:
Otherwise, you're going to be getting calculations and best guesses by the optimizer instead of letting it use the parameters to guess at the best way to retrieve the data. Also, doing this with anything other than strings means you're forcing a data conversion which will prevent the optimizer from using indexes to retrieve your data. Editing to add in this after a bit more digging:
And there is one instance where you're converting dates to strings to compare to dates where you will lose performance and get table or index scans where you should get seeks (assuming you have good indexes in place) because of data type conversions. +1 - But one feels that the haystack is full of needles... :/
Apr 20 '10 at 08:33 AM
Matt Whitfield ♦♦
@Matt - that would be a needlestack then.
Apr 20 '10 at 09:16 AM
Fatherjack ♦♦
HAY - that's funny!
Apr 20 '10 at 09:51 AM
Blackhawk-17
That is a good one.
Apr 20 '10 at 10:23 AM
Grant Fritchey ♦♦
@Jack - LOL - 'trying to find some hay in a needlestack' does have a nice, and somewhat more sinister, ring to it :)
Apr 20 '10 at 10:27 AM
Matt Whitfield ♦♦
(comments are locked)
|


It is a lot easier to help people here when the question is concise and easily read. The question creation dialog has several facilities to help you layout your question. I have tried to apply some better formatting but I dont want to change it too much incase I change its meaning. Its also going to be tricky for people to comment when they dont have the DDL statements for the table your are referencing or any information about the amount of data etc. Anyway, I hope you get an answer that means your query runs in 5-10sec as you request.
@Fatherjack... Patience of a saint!
I'm sorry. I'm trying to help, but this is making my head hurt. Flat out, as Matt says below, you're cyclying through all your rows one at a time. That is absolutely the worst possible way to go about anything in the database. Second, since we're not in your head, it's hard to know what's going on with this. Documentation, an execution plan or two and some idea of what's happening would be necessary for us to really help.