SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Slow SP with date parameters solved.


Slow SP with date parameters solved.

Author
Message
Virgilio Licovali Bustos...
Virgilio Licovali Bustos Ramirez
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 18
Comments posted to this topic are about the item Slow SP with date parameters solved.
ahaliav
ahaliav
Forum Newbie
Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)

Group: General Forum Members
Points: 2 Visits: 10
.
r5d4
r5d4
SSChasing Mays
SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)SSChasing Mays (615 reputation)

Group: General Forum Members
Points: 615 Visits: 844
I don't understand the problem you are trying to solve.

Is it a parameterization issue?

Ditto previous comment i.e what sql version have you found this to be an issue on?

How large were your tables? Were they indexed? Did you look at the execution plan to analyse what was going on?
ahaliav
ahaliav
Forum Newbie
Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)

Group: General Forum Members
Points: 2 Visits: 10
I checked it on 1030484 rows and in my case it worked the same when I run it from direct query and from a SP
Carlo Romagnano
Carlo Romagnano
SSCertifiable
SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)SSCertifiable (7.3K reputation)

Group: General Forum Members
Points: 7335 Visits: 3395
Starting from sql2000 sp4 and sql2005, sql2008, the optimizer changed strategy to retrieve data when you specify parameters in the where clause. So, in this case "column1 between @from and @to" for the optimizer means "read all rows" and starts with a full scan table instead of using index. Another solution is using hints and force the use of index:
select * from tab with(index(idx_tab)) where column1 between @from and @to

I run on tuttopodismo
hillsl
hillsl
Old Hand
Old Hand (346 reputation)Old Hand (346 reputation)Old Hand (346 reputation)Old Hand (346 reputation)Old Hand (346 reputation)Old Hand (346 reputation)Old Hand (346 reputation)Old Hand (346 reputation)

Group: General Forum Members
Points: 346 Visits: 73
Not very scientific, but I found that the first time I ran, the result from the @tableparams was considerably faster when selecting approx 17,000 rows from 682,000, where there is no useful index.

(17234 row(s) affected)

SQL Server Execution Times:
CPU time = 2250 ms, elapsed time = 8095 ms.
-- this one was parameterised

(17234 row(s) affected)

SQL Server Execution Times:
CPU time = 515 ms, elapsed time = 1784 ms.
-- this using the table variable

Running exactly the same thing a second time the difference was greatly reduced.

(17234 row(s) affected)

SQL Server Execution Times:
CPU time = 343 ms, elapsed time = 958 ms.

(17234 row(s) affected)

SQL Server Execution Times:
CPU time = 314 ms, elapsed time = 264 ms.

Using a different table, the paraemterised query was quicker on the second run.
christopher.gray
christopher.gray
SSC-Enthusiastic
SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)

Group: General Forum Members
Points: 101 Visits: 203
I've run across this problem several times as well.
I try copying the parameters into local variables, then use the local variables in the WHERE clause.
That almost always fixes the problem.

The two result in very different execution plans, though I've never really understood why.
I'd love to hear what is going on behind the scenes.
arussell_10
arussell_10
SSC-Addicted
SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)SSC-Addicted (402 reputation)

Group: General Forum Members
Points: 402 Visits: 1331
It might be parameter sniffing. If you do what Christopher suggested this will resolve the issue with parameter sniffing. I think there are other ways to resolve the issue as well, but don't recall them right now. Just google parameter sniffing.
christopher.gray
christopher.gray
SSC-Enthusiastic
SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)SSC-Enthusiastic (101 reputation)

Group: General Forum Members
Points: 101 Visits: 203
On the subject of parameter sniffing, here's a good article that describes how that works (and best of all, how it can go wrong!)

http://www.sqlpointers.com/2006/11/parameter-sniffing-stored-procedures.html
brandonregister
brandonregister
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 67
I had this same problem. I simply copied the code in the SPROC and then dropped the object. Lastly, I recreated the SPROC and everything ran fine.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search