Bizarre issue while using datetime variable instead of harcoded value

  • 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

  • .

  • 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)

    _____________________________________________
    "The only true wisdom is in knowing you know nothing"
    "O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!":-D
    (So many miracle inventions provided by MS to us...)

    How to post your question to get the best and quick help[/url]

  • What is the data type of the coldate column?

    Have you compared the execution plans for the two queries?

    John

  • 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 .. 🙂

  • 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

    _____________________________________________
    "The only true wisdom is in knowing you know nothing"
    "O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!":-D
    (So many miracle inventions provided by MS to us...)

    How to post your question to get the best and quick help[/url]

  • 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

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • 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.

  • 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

  • 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

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • richy post, had a great information, thanks for posting it

    ????? ????? ????? ??? ????? ??? ????

    ???? ?????? ????? ???????

    شركات نظافة بالرياض[/url] تخزين اثاث[/url] تنظيف فلل[/url] شركة تنظيف منازل[/url] شركات تنظيف بالرياض[/url]

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply