SQL Server Best Practices – Do YOU Practice?
I’ve been talking with a growing number of people who, because of budget pressures, time pressures and the whole "do more with less" thing have taken to deploying best practices in a reactionary way. Rather than putting things in place to, for example, protect the systems in advance of any issues, the updates are put in place in response to issues. Clearly this is a bad idea. But I have to say, it’s a tough discussion to have. "You shouldn’t do that." "Yeah? No kidding. But I have to prioritize things on an absolute level now – just don’t physically have the time to do all that *should* be done, when what *must* be done is taking 150% of my time."
True enough.
What I’ve been doing in the vWorkshop and the DBA School class stuff (this isn’t to promote them – stick with me just a ‘sec here) is to try to bring things back down to earth. Bring things back to a plan of how you can shave off some proactive stuff and get it done. I think if you have a plan, you can show iterative steps forward, your systems are better for it and you can make some headway. I’m trying to work up what amount to roadmaps for doing this and it’s not easy, that’s for sure. I get the pressure. We feel it too. We have a massive server move breathing down our necks and at the same time, our normal work must get done, let alone new site launches and… well, you get the idea that I get the idea.
To say that we just have to do it isn’t good enough. I’ve found myself building to-do lists around things that can be grouped. For example, if we’re going to be adding a new database to the mix, clearly we have to check maintenance on that db. Great. What I’ve been working toward is saying "hey, while we’re in there, let’s check the job system for overlapping jobs." It gets the job done and takes one additional step in the right direction.
Other things I have on the plan include "move the database, check and automated the index defragmentation for that db on the new server." Another is "add user to this system, and check for DBO ownership permissions and role/group membership on the database we’re working with."
It’s not perfect, but if you look at the "must-do" list and figure out what other items need to be done that are in the same mindset, at least you’re taking steps. Don’t just give up.
The bad side of people dropping the proactive stuff and doing only what’s required comes when only part of a fix is applied or updated. We address the one, specific, targeted issue to fix the problem. Never mind that there are 10 other variants out there to be considered. Never mind that those will be issues soon too – we’ll just deal with those later.
Be sure you work feverishly to not get stuck in this trap – take the extra steps and hide them in other work.
Do you do this? Do you approach it differently? Don’t write and tell me you have 5 DBAs per server. I don’t want to hear it and may get emotional. 🙂
Drop me a note, let me know how you approach this.
Featured Article(s)
ITIL implementation for Oracle Part 2
ITIL, Database, Oracle, Process, Incident,problem,configuration, change, Release Management