Heh... when a patient comes in with a bone sticking out of the skin, guess what's wrong. ;-)
I agree... too many people treat symptoms on SQL Server and, many times, they'll treat slow servers with new hardware without correctly identifying what the problem actually is. These same people are frequently grossly diappointed that their new wizz-bang server doesn't do much better than their old one did. Baselines don't help such people because they're not "doctors" and they sometimes just don't know what the symptom of a change compared to a baseline actually means. Worse than that, these same people are terrible "patients" because they don't want to take the necessary "medicine" especially when the correct treatment involves rewriting code.
So far as the question of how to define if the server is slow, it's kind of like defining the difference between a leak and flooding on a submarine. If you find it, it's a leak. If it finds you, it's flooding. :-P
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs