Of course, it isn't true, not by a long way but it did make me wonder. Is the simplicity of SQL Server also one of it's downfalls?
It is of course wonderfully easy to use. Microsoft's user interface is second nature to most if not all of us and yes there are wizards, lots and lots of wizards. Installing SQL Server is that easy that anyone could do it, really. You want a new database? Easy, right click over there, select new and done. Brilliant, isn't it?
You see the problem I have is that anyone can do it. I am sure that everyone reading this has had to fix a SQL Server at some point and all of its default settings are intact, left completely unaltered. You also know the specific one's that I am talking about here because these are the one's that can cause you all kinds of pain (and we'd change them)! Parallelism, maximum memory, tempdb, autogrowth etc etc. I haven't even mentioned maintenance yet!
For the non database person all of that simply doesn't matter. They've got their instance. The application is connecting wonderfully, queries are running beautifully and all is fantastic.
It's just that it isn't...
Sure in the beginning things are great but after a while strange things start to happen. Those queries start to run a heck of a lot slower than before. The OS comes under pressure, the CPU usage has gone through the roof and what the heck is a CXPACKET wait...is it the network?!?!
The person who set it all up is not to blame. We are all familiar with the term "accidental DBA" but what about the seriously reluctant one? They didn't ask for this and now they are doing all kinds of weird and wonderful things to rectify a problem they probably don't even understand.
This is an all too common scenario and it might be in part because the role is often misunderstood (seriously, we don't just look at graphs all day!). But the way I see it, the main reason is that there are often seemingly easier alternatives to bringing in a DBA to handle everything. And you know why? Because they believe SQL is simple, and anyone can do it. Right?
We know better.
For the non database person all of that simply doesn't matter. They've got their instance. The application is connecting wonderfully, queries are running beautifully and all is fantastic.
It's just that it isn't...
Sure in the beginning things are great but after a while strange things start to happen. Those queries start to run a heck of a lot slower than before. The OS comes under pressure, the CPU usage has gone through the roof and what the heck is a CXPACKET wait...is it the network?!?!
The person who set it all up is not to blame. We are all familiar with the term "accidental DBA" but what about the seriously reluctant one? They didn't ask for this and now they are doing all kinds of weird and wonderful things to rectify a problem they probably don't even understand.
This is an all too common scenario and it might be in part because the role is often misunderstood (seriously, we don't just look at graphs all day!). But the way I see it, the main reason is that there are often seemingly easier alternatives to bringing in a DBA to handle everything. And you know why? Because they believe SQL is simple, and anyone can do it. Right?
We know better.
No comments:
Post a Comment