
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.
9 Comments. Leave new
I would think these would also be excelent questions to ask when you start a job. Or for that matter they would make a good yearly review at an existing job.
Wow, this is familiar. Back in 2009 I got a SQL DBA job and found a useful looking website called brentozar.com thanks to google. One quick email to Brent asking for advice as to what information to gather about the existing db estate when starting a new job resulted in a blog post too. Now I’m leaving my current role and am being asked lots of these questions by my co-workers. The circle of (work) life…..
HA! Wow, funny!
Great post sir, very much appreciated. As I’m the leaving DBA myself, I’m glad to be able to gather some tips (“what’s non-standard?” being a favorite) to help during the three weeks transition.
“Why are you leaving?”
This would be my very first question.
Apart from revealing some of the technical landmines, it may also reveal other issues, that if resolved, may well mean your DBA doesn’t leave.
Ask a DBA to document / refine old documents for following things.
1. Servers / Databases list
2. DR Plan
3. Service Accounts details (along with the passwords).
4. All SQL Jobs / Maintenance job details.
5. Regular system monitoring and counters detail.
6. Topology of the critical / complex system like high availability, replication etc.
7. Other team member / tasks details with he is dealing on daily basis.
8. Reports and reporting tools
9. Up coming scheduled tasks (may be scheduled downtime) for he / she is responsible.
10. Get critical email thread details.
11. If any third party tools are actively in use, get details including support details.
12. If there is any project specific tool / team / utility / hardware / software / support etc. detail.