It’s late in the day; 10 minutes before you are to leave to start your weekend and what happens…….a SQL Server failure has occurred. Your phone begins to ring off the hook, your boss and his boss are now at your desk standing over your shoulder inquiring as to what happened, the business unit is now emailing 100 times over saying they need into the system now. Has this situation ever happened to you? Well, I hope nothing ever does, but if it has join the club and if it hasn’t get ready cause it will.
I am very big on being pro-active instead of re-active to issues. I’d rather have a document in my hand that is a legitimate well thought through checklist to run down in critical situations so I’m not running around like a basket case that I’ve seen so many people do. One of the first things that I ask people when I get to a new place of employment is, “How is the teams documentation?” Nine times out of ten the response is “What documentation?”
If you don’t currently have a checklist, I strongly recommend one; if you do have a checklist then look for ways to improve the process.
Every DBA should have some mentor so to speak, someone who has been through the trenches before I’ll list several of ones I look up to here in a minute, but you can get so many good ideas from people in the SQL community. I strongly suggest taking advantage of every tool out there. I’m a huge Brent Ozar fan so I want to share his idea of a checklist with you….now I modeled mine after his but took some stuff out and added some stuff in that I believed fit my business need. The article if I’m not mistaken actually is presented by Kendra Little. You can access the article here
Some DBA’s that I really enjoy following are:
Recently, a SharePoint administrator came to the DBA team and asked for a backup to be restored on a certain day. Simple task right – it would have been had the backup he wanted not been corrupted. On to the second backup request, just give me a day earlier he says. Sure no problem only to find out that that backup is corrupted as well. Talk about looking like an idiot.
Business time constraints will not allow for executing the DBCC CheckDB command against the DB, backup the DB with the check sum option, then restore the backup with the verify only option. So; how do we get around this? Our DBA team has decided to take an approach that has not been done before here but I’m sure has been done somewhere.
After completing the space requirement assessment we have decided to spin up a VM. This will allow us to automate our process by taking the backup that was made and restoring it to the VM to ensure it is not corrupt. The automation piece will restore the backup; if failure occurs a notification will be sent to the team allowing us to know which backup could not be restored and then proceed on to the next backup.
The backup after being fully restored will then be removed prior to restoring the next one in line.
DBA’s are often times required to think outside the box; it is a tool that must be a necessity.
Don’t wait until there is a business need for a backup to find out you can’t do a restore. Be proactive about your backups and ensure that you are actively checking them.
I took the last month to step back and spend times with family and friends as the holidays of Thanksgiving and Christmas near. During that time I jotted down several topics I’d like to cover, and moving forward in the next few weeks I hope to share all of them. Look forward to getting all my thoughts, ideas, and ramblings out!
More to come……