Comments on: 2 Features of SQL Server You Should Avoid http://www.brentozar.com/archive/2010/03/2-features-of-sql-server-you-should-avoid/ Your technology pain-relief experts. Wed, 08 Feb 2012 16:37:59 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Brent Ozar http://www.brentozar.com/archive/2010/03/2-features-of-sql-server-you-should-avoid/comment-page-1/#comment-24023 Brent Ozar Thu, 04 Nov 2010 13:50:31 +0000 http://www.brentozar.com/?p=6853#comment-24023 Chris - just as you say you've never run into that problem, I can say that I've very frequently run into this problem. Just because it's always worked for you doesn't mean it's always worked. Best of luck, though! Chris – just as you say you’ve never run into that problem, I can say that I’ve very frequently run into this problem. Just because it’s always worked for you doesn’t mean it’s always worked. Best of luck, though!

]]> By: Chris Leonard http://www.brentozar.com/archive/2010/03/2-features-of-sql-server-you-should-avoid/comment-page-1/#comment-24022 Chris Leonard Thu, 04 Nov 2010 13:48:44 +0000 http://www.brentozar.com/?p=6853#comment-24022 None of your worst-case scenarios are inevitable - they are just things you would have to deal with if you implemented this strategy stupidly. For example, some places may have workflow division like that, and they would need to redress your concerns with good communication between teams, and you'd hope that the system DBAs could be taught to scan the T-SQL code base for index references before doing drops. That's easy, so your point is valid, but only to say that people need to do this right, not that people shouldn't do it. In our case (and other places I've worked - 7 jobs), we recognize that the application DBAs (the T-SQL developers) are the best experts for tuning and indexing decisions. Our system DBAs (which it sounds like you are referring to) could get fired if they did what you are suggesting without talking to us first. We run our own missing index / unused index reports, and before we drop an index we have a due-diligence checklist that goes beyond "it hasn't been used in 6 months" and also includes checks for hints. So, if you don't mind me saying so, you're presenting a straw man, and one that's very easily overcome. And if the proof is in the pudding? I've been working with SQL Server since 4.21a, and I think that the number of problems we've permanently solved with hints is probably over 100, and the number of problems we've introduced is 0. Not because we're smarter than everybody else, just because we replaced the FUD-y "never use hints" with the much wiser "use hints judiciously and safely." By the way, in my current job, I have 5 T-SQL developers reporting to me, and another 4 at least in our office, with probably 20 at another site. And I would say that about one-third to one-half of them understand how to use hints wisely and effectively. Not quite as "few and far between" as you might think? Cheers, Chris None of your worst-case scenarios are inevitable – they are just things you would have to deal with if you implemented this strategy stupidly.

For example, some places may have workflow division like that, and they would need to redress your concerns with good communication between teams, and you’d hope that the system DBAs could be taught to scan the T-SQL code base for index references before doing drops. That’s easy, so your point is valid, but only to say that people need to do this right, not that people shouldn’t do it.

In our case (and other places I’ve worked – 7 jobs), we recognize that the application DBAs (the T-SQL developers) are the best experts for tuning and indexing decisions. Our system DBAs (which it sounds like you are referring to) could get fired if they did what you are suggesting without talking to us first. We run our own missing index / unused index reports, and before we drop an index we have a due-diligence checklist that goes beyond “it hasn’t been used in 6 months” and also includes checks for hints.

So, if you don’t mind me saying so, you’re presenting a straw man, and one that’s very easily overcome. And if the proof is in the pudding? I’ve been working with SQL Server since 4.21a, and I think that the number of problems we’ve permanently solved with hints is probably over 100, and the number of problems we’ve introduced is 0. Not because we’re smarter than everybody else, just because we replaced the FUD-y “never use hints” with the much wiser “use hints judiciously and safely.”

By the way, in my current job, I have 5 T-SQL developers reporting to me, and another 4 at least in our office, with probably 20 at another site. And I would say that about one-third to one-half of them understand how to use hints wisely and effectively. Not quite as “few and far between” as you might think?

Cheers,
Chris

]]> By: Brent Ozar http://www.brentozar.com/archive/2010/03/2-features-of-sql-server-you-should-avoid/comment-page-1/#comment-24019 Brent Ozar Thu, 04 Nov 2010 10:28:06 +0000 http://www.brentozar.com/?p=6853#comment-24019 Chris - unfortunately, if you use index hints to produce stable and efficient plans, you won't be sleeping at all after you bring in a DBA. See, the DBA needs to build new indexes, consolidate existing ones, and remove the ones that aren't performing. If you hard-coded index names into hints, you'll be constantly revisiting that and rereleasing your code every time the DBA needs to tune indexes. It sounds great - right up until you learn that it doesn't, and by that point, you're in a world of hurt. (And sleeplessness.) Chris – unfortunately, if you use index hints to produce stable and efficient plans, you won’t be sleeping at all after you bring in a DBA. See, the DBA needs to build new indexes, consolidate existing ones, and remove the ones that aren’t performing. If you hard-coded index names into hints, you’ll be constantly revisiting that and rereleasing your code every time the DBA needs to tune indexes.

It sounds great – right up until you learn that it doesn’t, and by that point, you’re in a world of hurt. (And sleeplessness.)

]]> By: Chris Leonard http://www.brentozar.com/archive/2010/03/2-features-of-sql-server-you-should-avoid/comment-page-1/#comment-24017 Chris Leonard Thu, 04 Nov 2010 05:39:39 +0000 http://www.brentozar.com/?p=6853#comment-24017 Your point about the possibilities of better optimizations in future releases is true, BUT ... if you have to choose between using hints to produce stable and efficient plans versus hoping that a future version of SQL Server will fix the problem, which would you really choose? I'd rather be efficient (ie, nearly optimal) all the time and get to sleep at night rather than having to live with inconsistent performance for queries that waffle between plans when they recompile. And revisiting hinted stored procedures upon upgrade shouldn't be that monumental of a task if you don't use hints (or plans) too much. Your point about the possibilities of better optimizations in future releases is true, BUT …

if you have to choose between using hints to produce stable and efficient plans versus hoping that a future version of SQL Server will fix the problem, which would you really choose?

I’d rather be efficient (ie, nearly optimal) all the time and get to sleep at night rather than having to live with inconsistent performance for queries that waffle between plans when they recompile. And revisiting hinted stored procedures upon upgrade shouldn’t be that monumental of a task if you don’t use hints (or plans) too much.

]]>