When the database administrator turns in her notice, what questions should you ask her in her last couple of weeks?

I’m assuming, of course, that it was a friendly departure and you’ve got the full two weeks to have good conversations.

Or maybe the DBA is about to go on vacation, and you need to quickly get up to speed about things that might break while they’re gone.

One of my clients’ DBAs turned in their resignation, so I was presented with this very task. I haven’t done it in a while, so I asked Twitter, and here’s what I got:

@BrentO overview of topology, security model, key contacts, hotspot servers, script library walk over, sqlpowerdoc all servers, …

— Johan Bijnens (@alzdba) January 13, 2014

@BrentO Any SA Passwords for which systems. Any processes using HIS(or her) credentials. Systems list, location of any documentation.

— ?? Will ©? (@SirWill) January 13, 2014

http://twitter.com/BrightByNature/status/422792839345364992

@BrentO 1) PWs and Backup Info 2) any custom scripts/sprocs written defined 3) documentation (if any) 4) contacts for any vendors used 5)

— Ryan McKnight (@Accidental_DBA_) January 13, 2014

I kind of expected answers like that – a lay of the land, and Buck Woody’s runbook is a good example – but there were so many good creative ideas:

@BrentO anything that's non standard and why it's like that. There's usually a good reason but the new person won't know that.

— Kent (@kentchenery) January 13, 2014

@BrentO info about each, anything special (i.e. need patch XXXXX for perf on this server). #sqlhelp

— Allan Hirt (@SQLHA) January 13, 2014

When you look at someone else’s server, it’s so easy to think, “This guy couldn’t have known what he was doing – nobody should ever set this trace flag or this database option or use this cumulative update.” Maybe not, though – maybe it’s critical to making the application work.

@BrentO Walk through of custom scripts/code that the company uses, i.e. roll-your-own index maintenance.

— Mike Fal (@Mike_Fal) January 13, 2014

How many of us left little snippets of code around that ended up becoming mission-critical? Often we don’t have source code control on these, either.

http://twitter.com/BBassic/status/422793906175344640

Does the company even have one?

@BrentO Another one (maybe not as crucial) when was the last time the backups were verified (IE: restored).

— John Morehouse (@SqlrUs) January 13, 2014

Have you tested a restore lately?

@BrentO "What's the current monitoring solution?" <- breaks out into SLA conversations, What's the most frequently encountered issue etc.

— John Sansom (@SqlBrit) January 13, 2014

And a followup – are you getting value out of it, or have you just set up email rules to bozo-bin all of the monitoring emails? It helps to know what to expect when the emails start coming your way.

@SqlBrit @BrentO Yep, "what buttons do you manually push every day?"

— Chuck Rummel (@crummel4) January 13, 2014

Wow – that’s a fantastic answer. Often we just didn’t have the time to automate all of our problems, and we know that the flux capacitor will leak if we don’t clean it out weekly. Followed up with:

@BrentO a list of all the things they wanted to do but never got a chance to, due to being in constant firefighting mode. (aka time bombs)

— Chuck Rummel (@crummel4) January 13, 2014

Now might be a good time to get that project approved.

@BrentO A list of who contacted them the most and why, so you can learn undocumented hot spots of trouble. It may not all be in emails.

— Chuck Rummel (@crummel4) January 13, 2014

Being a DBA takes soft skills. Getting this inside info on the squeaky wheels helps me prepare for the incoming support requests. Which brings me to:

@BrentO "Who are your biggest customers?", "What are you current challenges/pain points?" #sqlhelp

— John Sansom (@SqlBrit) January 13, 2014

And I’d follow that up with, “Why are you leaving?” Sometimes that helps reveal some of the biggest land mines.