I haven’t been blogging as much recently as I’d like and I’m trying to get back into it. One excellent way to do that is to join in on TSQL Tuesday. It’s our monthly blog party where someone hosts and comes up with an idea and the rest of us blog about it. In this particular case that someone is Steve Jones (blog|twitter), who incidentally is also who you need to talk to if you want to be a host.
This month the topic we are blogging about is Upgrade Strategies. Or, how do we look at SQL Server upgrades. In my case I want to talk about the absolute hardest part of any upgrade at my company.
I should point out that I work for a large company with a lot of moving parts. Over the course of my tenure here I’ve helped to support hundreds to thousands of SQL Server instances. And at least for us, the technical part of an upgrade isn’t too bad. Where we almost always run into problems is Who do we contact?
Development staff
The development staff is necessary to help with timing, testing, and because we always do side-by-side upgrades there are always configuration changes that will need to be made. And last but not least they let us know who the users are.
Users
We frequently get at least some of the users involved for testing because they are the ones that actually use the applications and can tell far better than most if they are still working correctly. Also they are the final word as to when we can do the upgrade. Believe it or not, not all applications can have an outage over the weekend. We have some applications where the best time to shut them down is during the work day.
Now, in a small company this is easy. Your entire company may be involved any any upgrades. In a big company though you might have one or two developers, or a dozen teams of developers that are working with each database. Then you get some databases that are replicated either wholly, or in pieces across multiple instances.
In the end, figuring out who needs to be contacted is a multi part process. We start with a list of who we contacted last time. In other words document, document, document! Then we pull a list of service accounts that have access to the databases and see who is listed as an owner, and then we start tracking down anyone who’s accessed the databases over the last 30-90 days. Hopefully wherever you are this isn’t quite as difficult, but no matter what, that list of who’s going to be involved in the upgrade is always a good place to start.