October 16, 2012 at 3:34 am
Hi, I am facing a bizarre issue while testing a query, When i test with hardcoded date value, the query runs in 2 mins (tables used in joins are huge)
, but when i assign the date in a variable and use, it took more than 20 mins and then i cancelled the query.
Sample query
SELECT *
FROM table1 A
,table2 B
,table3 C
,table4 D
WHERE A.col1= B.col1
AND C.col1=D.col2
AND C.col1=A.col1
AND D.col3 LIKE '%test%'
AND D.coldate> '10/12/2012'
above one takes 2 min and below one more than 20 mins
declare @dt datetime
set @dt ='10/12/2012'
SELECT *
FROM table1 A
,table2 B
,table3 C
,table4 D
WHERE A.col1= B.col1
AND C.col1=D.col2
AND C.col1=A.col1
AND D.col3 LIKE '%test%'
AND D.coldate > @dt
Could any one help me out of this.
Any suggestions would be appreciated
Thanks
October 16, 2012 at 3:38 am
.
October 16, 2012 at 4:09 am
Is it just a query behaviour or you see it only when wrapped into stored procedure?
Does look like parameter sniffing to me...
Also, it's a bad practice to use strings for datetime in non-ISO format. Always use YYYYMMDD (or YYYY-MM-DD)
October 16, 2012 at 4:12 am
What is the data type of the coldate column?
Have you compared the execution plans for the two queries?
John
October 16, 2012 at 4:40 am
datatype of coldate is datetime,
there is no difference in the execution plan of both queries.
Thanks Eugene Elutin for that date format practice .. old habits hard to change .. 🙂
October 16, 2012 at 4:48 am
jeyis (10/16/2012)
datatype of coldate is datetime,there is no difference in the execution plan of both queries.
Thanks Eugene Elutin for that date format practice .. old habits hard to change .. 🙂
Is it just a query or stored procedure?
Also, why you are not using proper JOINS? That is even worse than not using dates in ISO format...
Can you try this:
DECLARE @dt DATETIME
SET @dt ='20121210'
SELECT *
FROM table1 A
JOIN table2 B ON B.col1 = A.col1
JOIN table3 C ON C.col1 = A.col1
JOIN table4 D ON D.col2 = C.col1
WHERE D.col3 LIKE '%test%'
AND D.coldate > @dt
October 16, 2012 at 5:03 am
Definitely looks like parameter sniffing (or more correctly, the lack thereof)
http://sqlinthewild.co.za/index.php/2008/02/25/parameter-sniffing-pt-2/
Can you post execution plans please?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 16, 2012 at 5:03 am
Thanks again for the reply,
I am testing it as query now, eventually i'll have to put this part into a stored procedure
I agree with you Join practice and the comma separated is really outdated. But even after trying with that it doesn't give the desired output.
October 16, 2012 at 5:14 am
Hi Gail Shaw, The server which i refer to is sql 2000. i don't find an option to save execution plan. Let me read the article about parameter sniffing which you provided. Thanks for your reply
October 16, 2012 at 5:18 am
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/ Shows how to save the plan on SQL 2000.
p.s. Please post SQL 2000 questions in the SQL 2000 forums in future. In the SQL 2008 forums we'll assume you're running SQL 2008.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 15, 2013 at 12:19 am
richy post, had a great information, thanks for posting it
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply