question

Mark avatar image
Mark asked

The Gestalt of Performance? Just curious...

Using SQL-2000, I have seen cases where I have had performance problems with a SP, isolated the query that caused the issue, then run the query by itself and the performance was fine. It was only when the query was run in the context of the SP was there a problem. My apologies for not having a specific query to show you. Unfortunately, I can't show that. I can tell you it was a complex query with multiple joins and a where clause with an "IN" or an inner join involved. (Both methods were tried there.) I'm mainly hoping someone else has experienced this and knows why it happens.
sql-server-2000stored-proceduresperformance
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Grant Fritchey avatar image
Grant Fritchey answered
Parameter sniffing is usually the cause of something like this. When you run the query as just a query, all the parameters are local, so SQL Server can look at them, sniff them, and determine an execution plan based on the values. As soon as you put parameters in a stored procedure, SQL Server assumes an unknown value in the parameter, correctly, and creates a different execution plan. In most cases, this works well. In some cases it doesn't. Then you get into using the common work-arounds, like setting the procedure parameters to local parameters inside the query after initiating the local parameter with a known value. This is basically the same as using the OPTIMIZE FOR query hint in SQL Server 2005/2008.
4 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks Grant (+1), I remember reading about this behavior before, but didn't think to apply it to this situation. Interesting, I'll look into that more. Could this also apply to later versions of SQL too then?
0 Likes 0 ·
Yes, but you get a lot more ways to fix the issue. Just remember, most of the time, parameter sniffing is a good thing. Just not all the time.
0 Likes 0 ·
I see that Gail Shaw wrote some informative articles on parameter sniffing: http://sqlinthewild.co.za/index.php/2007/11/27/parameter-sniffing/ So far, she has the best articles I've been able to find on them.
0 Likes 0 ·
Gail's articles are all good.
0 Likes 0 ·
Håkan Winther avatar image
Håkan Winther answered
Do you have any conditional statements in your procedure? Do you alter any of the input paramaters? If you do, the optimizer give you an incorrect execution plan. The statement below may cause an incorrect execution plan. create proc spTest @id int as select @id=id from someTable where someCol = someValue SELECT * FROM someOtherTable WHERE someOtherCol=@id You can compare the execution plans to see if there is any differences. How many joins are involved? More than 4 joins in SQL server 2000 will cause the optimizer to give up, but that doesn't explain why the code works when you run the code outside the procedure. Do you execute all the code from the procedure? I have seen cases when the compilation of the procedure took 20 seconds, but the execution of the statements took less than a second. It was caused by some complex statements and some "constants". When I replaced the constants with the values the compilation was also less then a second. I will try to add some pseudo code for you to consíder. CREATE PROC spTest2 AS declare @x int, @y --"constant" SET @x=10 SET @y=20 SELECT * from table1 t1 INNER JOIN table2 t2 ON t1.x=t2.x INNER JOIN table3 t3 ON t2.z=t3.z WHERE t2.y IN (@x, @y) --replaced this with values and it worked Personally I think it was really strange, but the procedure was recompiled for every execution.
2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@Hakan, sorry but none of those apply. The SP itself was fairly simple.
0 Likes 0 ·
OK, since you've edited your answer, maybe some of those conditions apply. I didn't know that more that 4 joins in SQL 2000 would make the optimizer give up for example. (+1)
0 Likes 0 ·
Scot Hauder avatar image
Scot Hauder answered
Another culprit is the ARITHABORT setting which may be set differently for the stored proc and your SSMS session. [more here][1] [1]: http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance.aspx
1 comment
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks Scot, I didn't know about the ARITHABORT setting.
0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.