That might sound a bit ominous but really, its the exact opposite. I’m going to use my situation as the basis for explaining exactly what I mean. I decided a few weeks ago that I was ready for a new job opportunity with new challenges and to continue my growth as a DBA. But before we get to that point, let me give you a bit of background info on where I’m currently working.
I’m currently the sole DBA at a small publishing company and most of the time my job entails more than just the usual DBA tasks. At times, I’m the project manager, the database architect, the system admin, the change control specialist, and then I also do some standard DBA stuff too…you know on the side 😉 Now while many of you probably won’t be in the situation where you’re the sole DBA, you may be in the situation where you are the DBA with most of the knowledge about how your systems are built and how certain processes work. So hopefully you can relate to many of the things I’m describing in this article.
With the back story out of the way, I can discuss what prompted me to write this. I’ve seen many articles around the net describing the first days as a DBA (Help! It’s my first day as a DBA!). And there’s valuable info for newer DBAs coming in trying to get adjusted quickly. But I was also thinking, “why wouldn’t the last DBA make it better for the next guy to come in and hit the ground running?” Instead of spending weeks trying to play catch up and learn everything, wouldn’t it be better if the next guy doesn’t have it so rough?
So let’s start with the three main things I think would be important to accomplish in the last days as a DBA:
Sure we’re all suppose to document everything as we’re implementing it. But how often does that REALLY happen?? With management breathing down our necks and giving tougher deadlines all the time, usually documentation is the first thing to be eliminated. And it will help everyone involved to have some kind of documents in place when questions are posed later on. This is actually even more important once you’ve decided to leave your current position and for that next guy/girl taking your place. However, I know I won’t have enough time to document EVERYTHING that I’ve done in my time as DBA. So here’s the most important things I decided to document regarding:
- List of passwords– particularly the sa passwords on all your servers but also any user accounts that are not AD accounts
- Backup strategy – if the next DBA (or even sys admin) comes aboard, they can review this and check to make sure backups are still occurring as expected.
- Processes currently in place for high availability – which H/A type of process is being used, what resources are allocated to this and why was this H/A method chosen?
Tuning and Optimization
There’s a good chance that your successor won’t be hired before you leave. I know thats exactly what’s happening to me and you really have no idea when the next DBA will be hired (or if they’ll even hire another DBA). By getting all your databases running the best they can, you’ll be making sure that the organization can run for a short time without a DBA. And you’ll prevent one of those frantic calls from your previous employer begging you to help them while they still haven’t decided to even hire your replacement. And you should really be doing tuning and optimizing periodically anyway. I usually to do it approximately every quarter but maybe the next person won’t know how to really do some performance tuning like you do. So doing one last optimization should be a good idea and here’s the list of things I’m doing before I leave:
- DBCC Commands – The obvious ones are DBCC CHECKDB and DBCC SHOWCONTIG. Both will help you find errors and also for the next step in this list about fragmentation of your databases
- Defrag/Rebuild indexes – After you run the SHOWCONTIG, you’ll know which indexes need to be rebuilt or defragged. Make sure you know which indexes need to be accessed live so you don’t drop them and just defrag.
- Sizing of files – Yes SQL Server will automatically grow files for you if you have the option set. But you shouldn’t rely on this ability and by sizing the files appropriately, you make sure there’s no problems for some time until the next DBA gets acclimated.
- Profiler & DTA – I actually just did this a few days ago. I spent some time during the busiest point of the day for our websites and did some profile traces. Then after loading those saved traces into DTA, it gave me the suggestions to create some stats and indexes. Just make sure you do some testing before implementing the suggestions.
- Review all logs – Seems like a simple thing to do but can be overlooked when you’re trying to get everything else cleaned up and getting ready to leave. Just make sure there are no big errors and if possible, include anything that is worthwhile in your documentation.
Complete Outstanding Projects
And no I’m not talking about some large scale project that would be impossible to finish before you leave. All of us have those little projects that we work on but are not high priority and often go unfinished. These are the projects I’m talking about. It’s better for the company you’re leaving because they may not have someone in mind to take your place for a while. It’s better for that next DBA because they don’t have to try and figure out where you were at and what still needed to be finished. And it’ll help you to give you that sense of completion when you leave. And when management comes to you just days before your last day, you can tell them the “state of the union” about what has been just completed and what is still outstanding.
I’m sure there could be plenty of other topics that would be important but I felt like these were the easier to accomplish and gives the best opportunity for the next DBA to succeed and the organization to stay afloat while they look for that person to replace you.
I’m hoping to update this regularly with any of my SQL Server-related thoughts, views, ideas, etc. I’m open to taking suggestions about topics if there’s something you’re interested in. Most of what I’ll be writing will be with the DBA in mind with some developer-based thinking thrown in from time to time. Hope you enjoy and come back often!