By: Tim Ford | Comments | Related: More > Professional Development Career Planning
Problem
There is something to be said for taking a vacation. The rest and relaxation, seeing new places, being exposed to new and exciting things. The other side of the coin is being on-call, answering pages at 3:00 AM then driving around a strange location hunting for available Wi-Fi. Hmm, one of these things is not like the others. When you want a vacation it is usually expected that you can truly relax and let the rigors of the DBA grind slip out of your brain's cache. However that is not always easy. I'm taking a two week vacation and I've never turned the keys for the Evil DBA Laboratory (pronounced lah BOR uh tory like all madmen do) over to an outsider. In the past 10 years I've had Oracle DBAs that filled in as SQL DBAs and fellow staff that once saw Enterprise Manager or could spell and pronounce SQL Server for temporary backups "in case something happened." I've never walked away from my company for 2 weeks in order to let go completely. I needed to and I am.
So, what do you do when you're taking time off and need to plan for your environment to stay stable, secure, and running to the required standards? Well, if you wanted the first two, simply shut down the servers for two weeks. If you want all three then revoke all user access. If you can not do either of those then perhaps the list of items below will be of added value.
Solution
- Documentation: Whomever you turn the reigns over to should have a good understanding of what your environment looks like. This entails a good SQL Server Metadata Repository. I suggest providing your backup, be it an outside contractor, fellow internal DBA, or trusted and capable SQL professional with the following at a minimum.
- Server/Instance information
- Correlates SQL instance to physical server
- Server metadata
- O/S, physical location
- Domain
- IP address
- Instance metadata
- SQL Server version
- Edition of SQL Server
- Patch level
- Full Text Indexing on/off
- Collation
- PROD, DEV, TEST, BUILD status
- Clustering information
- Server metadata
- Correlates SQL instance to physical server
- Database Information
- Relationship to SQL instance
- Physical and logical file information
- Recovery Mode
- Backup schedule and requirements
- Disaster Recovery processes in place: replication, mirroring, or log shipping
- PROD, DEV, TEST, BUILD status
- Application Metadata
- Corresponding SQL instance and database name(s)
- Service Level Agreement (SLA) information as it relates to uptime requirements and support schedule
- Server/Instance information
- Daily Status Reports: Scheduled reports for DBA oversight scheduled to distribute to the individual providing support in your absence. I have a handful of reports I receive on a daily basis that tell me first thing in the morning what my environment looks like. These include a listing of any SQL Agent job that has failed in the past 24 hours, and a report that presents any database for which a full backup has not been run in the previous 24 hours. Granted I am also receiving notifications when certain very-important jobs or backups fail, but this gives me a single view "tick list" of all items that need to be reviewed immediately in the morning. It is important that your designated support person understands which of these items are critical and which can be ignored (for instance a backup that has not been run in 48 hours may be acceptable if it is for a training database that is only backed up once per week.) That level of detail should be available in the database or application metadata reports that I've mentioned previously. I also receive reports on any new databases created in the previous 24 hours so I can ensure backups are configured as well as sizing, recovery, security, and growth options are appropriate for the environment. The data for all of these reports are generated via SQL Server Integration Services (SSIS) and distributed via SQL Server Reporting Services (SSRS). You'll need to add the email account for your support individual to the listing of recipients for these reports.
- Security: Access to the Environment. I strongly recommend that you do not provide the sa account's password to the temporary DBA. Hopefully you're not using sa for any processes in your environment. I do recommend that you have an Active Directory group that is granted System Admin role rights on each of your SQL Server instances. This method will allow you to easily add the support person's login to the group and immediately have full DBA rights to your instances with minimal work on your part. After your return, these rights are revoked just as easily with the same minimal amount of effort and no residual loopholes in your security structure. This also affords rights to the physical SQL Servers via terminal services/RDP without having to grant local administrator rights to each server. In our environment of 80 servers that saves a great deal of work.
- Knowledge Transfer: Meet with the Temporary DBA. You can not simply rely on the written documentation you've provided for the environment. I strongly suggest going over such items as naming conventions, expectations for turnaround times for requests, how to use non-SQL applications such as any help desk software or logon processes if the individual is a contracted resource from outside of the company. If the resource does not have a confidentiality agreement on file at this time you should have one completed as well. Review high-availability architectures in place (clustering, replication, log shipping, and mirroring.) Be sure to go over all aspects of whom to contact in case of questions or concerns.
- Contact Information: Provide your contact information and outline the parameters for when or if you should be contacted.
- Intermittent Reviews: Forward reports to your PDA or make arrangements to otherwise receive this information. Reviewing the reports takes minutes. You may spot things the temporary DBA may miss. This small amount of time may save you hours or days of work upon your return.
- Let Go: Have a good time, you've worked hard and deserve it. On that note I am heading out on a sailing trip for two weeks. Hope nothing breaks!
Next Steps
- Review this tip on creating metadata reports:
- Have a great vacation!
About the author
Tim Ford is a Senior Database Administrator with MindBody.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
