Instead of working, I blog.

It's almost never fun to lose a DBA, but it's a fact of life. People leave jobs, and sometimes jobs leave people. This is another reason why it's really important to not tax your DBAs too heavily. If you've got 2 DBAs and they're both working like dogs, what happens when you lose one? I'll tell you what happens... deadlines start to slip, backups start failing and don't get looked into, maint starts getting behind, security gets relaxed, etc. You want your DBA to have time to do his job and be able to pick up some slack when you lose someone. And it could be quite a while before you get a replacement. Good DBAs are really hard to find and you don't want someone to just warm the seat.
I talked about this recently in my IW blog. Of course, this really only goes for production DBAs, right? I mean, you can work your devs as much as you want. They'll never get a call in the middle of the night because the server's down or because a package failed. So again, DBAs are insurance policies. We're kinda like a clustered server. You don't use the inactive node. It just sits there waiting for something to happen to the primary node. It seems a terrible waste and managers hate spending that money for a box that just sits there. And while DBAs aren't quite that useless, we really should be used in the right way. So it really is just like a multi-node cluster. You never run the primaries at full capacity because one day something will happen and one box will have to take on its workload and one of the downed nodes. So if they're all running at 100%, they can't failover and resume work. So you run them at 50%... give or take, right?

So again, let your prod people do their prod jobs and don't put them on too many actual projects. Afterall, that's what prod means.

And yeah, we're losing our other DBA so I'm all alone now. We'll see how it turns out.