Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Slow SP with date parameters solved. Expand / Collapse
Author
Message
Posted Tuesday, April 27, 2010 7:39 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 25, 2014 7:01 AM
Points: 3, Visits: 15
Comments posted to this topic are about the item Slow SP with date parameters solved.
Post #911108
Posted Wednesday, April 28, 2010 12:46 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, July 17, 2011 6:08 AM
Points: 2, Visits: 10
.
Post #911645
Posted Wednesday, April 28, 2010 12:52 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Today @ 9:10 AM
Points: 267, Visits: 686
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?
Post #911649
Posted Wednesday, April 28, 2010 1:22 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, July 17, 2011 6:08 AM
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
Post #911666
Posted Wednesday, April 28, 2010 1:33 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 21, 2014 6:24 AM
Points: 2,451, Visits: 2,342
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
Post #911669
Posted Wednesday, April 28, 2010 4:33 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, June 18, 2014 5:04 AM
Points: 111, Visits: 59
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.
Post #911764
Posted Wednesday, April 28, 2010 7:58 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Today @ 6:47 AM
Points: 24, Visits: 120
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.
Post #911969
Posted Wednesday, April 28, 2010 8:18 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 1:52 PM
Points: 98, Visits: 1,191
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.
Post #911994
Posted Wednesday, April 28, 2010 8:32 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Today @ 6:47 AM
Points: 24, Visits: 120
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
Post #912021
Posted Monday, May 3, 2010 7:43 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, June 16, 2014 7:19 AM
Points: 1, Visits: 24
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.
Post #914683
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse