T-SQL Performance 1

  • SQL Kiwi (2/17/2012)


    Cliff Jones (2/17/2012)


    Interesting but I don't think I want my developers to discover the FORCESEEK hint.

    This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.

    Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is

    + 100

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • bitbucket-25253 (2/17/2012)


    SQL Kiwi (2/17/2012)


    Cliff Jones (2/17/2012)


    Interesting but I don't think I want my developers to discover the FORCESEEK hint.

    This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.

    Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is

    + 100

    I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.

  • DBA_Dom (2/17/2012)


    bitbucket-25253 (2/17/2012)


    SQL Kiwi (2/17/2012)


    Cliff Jones (2/17/2012)


    Interesting but I don't think I want my developers to discover the FORCESEEK hint.

    This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.

    Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is

    + 100

    I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.

    Actually I agree also, my post was a bit tongue in cheek. But with 50 developers sometimes bad practices get copied around like a virus before you have a chance to educate or remind. Code reviews would help if only we did them more than we currently do.

  • Cliff Jones (2/18/2012)


    DBA_Dom (2/17/2012)


    bitbucket-25253 (2/17/2012)


    SQL Kiwi (2/17/2012)


    Cliff Jones (2/17/2012)


    Interesting but I don't think I want my developers to discover the FORCESEEK hint.

    This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.

    Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is

    + 100

    I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.

    Actually I agree also, my post was a bit tongue in cheek. But with 50 developers sometimes bad practices get copied around like a virus before you have a chance to educate or remind. Code reviews would help if only we did them more than we currently do.

    I'm sure that making sure developers understand what features are available, where those features are most likely to be beneficial, what potential issues there are with these features, and how they should go about evaluating the pros and cons of using a feature in a situation where they are considering it is the only sensible way to go (this applies to any language, not just SQL dialects); if the time taken to educate developers about new features is sufficiently long that they may go and misuse them before the education happens, the thing to do is to fix the working system so that the education happens in a more timely fashion. Yes there need to be warnings about some features (but perhaps not as extreme as the labelling suggested in my earlier post 😀 - ) - in fact as DBA_Dom suggests developers have to be told that using hints to override the optimiser is a last resort, but a new query hint (which is what we have here) hardly needs new guidance since some query hints have been around for a long time and if the developers don't yet know that query hints are a last resort that little piece of education is more than a decade overdue so something is seriously wrong.

    Tom

  • L' Eomot Inversé (2/18/2012)


    Cliff Jones (2/18/2012)


    DBA_Dom (2/17/2012)


    bitbucket-25253 (2/17/2012)


    SQL Kiwi (2/17/2012)


    Cliff Jones (2/17/2012)


    Interesting but I don't think I want my developers to discover the FORCESEEK hint.

    This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.

    Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is

    + 100

    I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.

    Actually I agree also, my post was a bit tongue in cheek. But with 50 developers sometimes bad practices get copied around like a virus before you have a chance to educate or remind. Code reviews would help if only we did them more than we currently do.

    I'm sure that making sure developers understand what features are available, where those features are most likely to be beneficial, what potential issues there are with these features, and how they should go about evaluating the pros and cons of using a feature in a situation where they are considering it is the only sensible way to go (this applies to any language, not just SQL dialects); if the time taken to educate developers about new features is sufficiently long that they may go and misuse them before the education happens, the thing to do is to fix the working system so that the education happens in a more timely fashion. Yes there need to be warnings about some features (but perhaps not as extreme as the labelling suggested in my earlier post 😀 - ) - in fact as DBA_Dom suggests developers have to be told that using hints to override the optimiser is a last resort, but a new query hint (which is what we have here) hardly needs new guidance since some query hints have been around for a long time and if the developers don't yet know that query hints are a last resort that little piece of education is more than a decade overdue so something is seriously wrong.

    Yes, I think you hit the nail on the head. I work at a very fast paced and very successful software company and I don’t think anyone in our organization would use a Query Hint without checking with me to be sure it was appropriate. When you are dealing with a large development team sometimes that is the level at which you have to train. You can spend a lot of time training 50 dot net programmers how to write SQL but only a percentage will listen and only a percentage will remember everything. Would I spend 10 minutes of valuable training time to discuss the FORCESEEK Hint? No. Would I spend 30 minutes showing them why they shouldn’t try to out-guess the Optimizer with query hints? Yes. So it is easy to say give everyone all the details but sometimes it just not that simple.

  • A good question... Thank you.

  • Good question, though I answered wrong!:(

  • I heard a lot a word 'FORCESEEk' can anyone explain me what is this?

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • http://msdn.microsoft.com/en-us/library/bb510478%28v=sql.105%29.aspx

    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
  • Best question ..

    coz i like this topic 1+

    thanx:-)

    Neeraj Prasad Sharma
    Sql Server Tutorials

  • Got it right by logical thinking 😉

  • Hi,

    Could use the forceseek table hint.

    What do you think?

Viewing 12 posts - 46 through 57 (of 57 total)

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