My new job is all about waiting. I need to understand more about what everyone is waiting for, specifically what their SQL statements are waiting for. I was reviewing some materials on waits and queues the other day and I started to have flashbacks memories of a previous job I once held.
At that job we would often be the last to know anything about a system that was being deployed. For example, we would not know if the nature of the application was more transaction based (OLTP) or more aligned with the nature of a data warehouse. Those two systems require a different set of tuning techniques. Ideally you would put your OLTP systems on one server and tune that server to perform based upon OLTP best practices, and put your data warehouse(s) on a different server. But if we are never to know the nature of the systems until well after they are deployed, what do we do as an administrator?
The answer is as plain as vanilla wafers: you prepare a standard build that is “good enough” for both and make adjustments as necessary depending on whoever is able to scream the loudest. Another way of looking at it is that your base build gets you 80% of where you need to be and you sit back, waiting for the phone to ring. Think of it as playing defense. Besides, if the users never complain about performance, then should you be concerned? Well, not if you have a lot of other servers to build and maintain, then you don’t really have time to go out of your way to fine tune everything under the Sun. You need to build yourself a “SQL Snuggie”, something that covers most of what is needed.
Ideally we would know more about the nature of the system and try to logically place it on the right instance. Often we were just told where the database would be placed, which didn’t make a whole lot of sense to us, but if we ever tried to voice a concern then we were always seen as being “difficult”. Of course that has never bothered me, I’ve always been the person that has been put into positions of being the difficult one and giving someone course corrections when necessary. But it does get tiring after a while, for everyone involved, especially if you are not involved in the development process until the very end.
It’s kinda like when we make dinner for our children and they get to the table and say “ugh, I don’t want to eat that”. No one wants to be derailed at the last possible minute, and no one likes to be told that after creating a meal that it is not going to be eaten by your ungrateful offspring it is not what someone really wanted to eat. Of course, to curtail this, you can just rotate between three or four meals that you know they will eat.
And that’s what you end up doing as a DBA as well. You have a handful of editions of SQL available, and you have a standard deployment or build process that you follow, and you make that available. And most of the time people accept what you have given them but every now and then someone says “hey, there’s a bone in my chicken salad” and you end up having to dig in and resolve the matter by making them a PB&J instead.
Brilliant! New uniform anyone? Every DBA should have a Snuggie Day for the office.
Well, Tom did say he was no longer wearing pants in the home office. Perhaps this is what he dons so when he gets close to the window the neighbors don’t point and laugh.