Voice of the DBA

Tag: syndicated

  • BCPs – The Disaster Recovery Plan

    I came up with a short acronym for my Preparation for Disaster presentation: BCPs. It describes what I think you need to do in order to be prepared for issues with your database server. The initials stand for:

    • Backups
    • Checks
    • Practice and Preparation
    • Script and Schedule

    With a utility in SQL Server going by BCP, this ought to be easy to remember. I’ll describe what I mean below by each of these:

    Backups

    You need to make sure that you have backups. They are insurance for the issues that will befall you at some point. They are also required for restores, which do matter.

    You need a backup plan that meets the need for the particular system you are protecting. Not your entire infrastructure, but what’s appropriate for each system. Once size does not fit all here.

    Checks

    You can’t prevent corruption and it can occur at any time. The best you can do is detect it early, and fix it as soon as you can. Make sure you have checks in place that look for corruption.

    You also want checks for things that are out of the ordinary. Make sure you have some monitoring/base-lining set up so that you can proactively be aware of what a disaster might occur.

    Practice and Preparation

    All of the backups, checks, etc. in the world are useless if you don’t know how to apply them. Or if you don’t have the keys, passwords, account numbers, etc. Practice the skills you need to recover your systems, and make sure that you are prepared to do so in a variety of situations.

    Explaining to your CEO that you don’t have the keys for that TDE encrypted restore will make for a very, very bad day.

    Script and Schedule

    You must automate most of your job to be successful and efficient, and you ought to have lots of your DR insurance (backups/scripts) scheduled so that it get performed in a timely manner, and a regular manner. Humans forget things, and make mistakes constantly. You need to ensure that you are scripting your tasks (to speed up processes) and scheduling them (to ensure they occur regularly).

  • Speaking at the 2011 PASS Summit

    PASS_2011_SpeakingButton_180x180-blackI submitted three sessions to the 2011 Summit for consideration and I heard today that two of them were accepted, with the third being an alternate.

    It’s nice to be accepted, especially as there is always a lot of competition for people to speak and there are tons of submissions each year. I don’t know the total this year, but I’m sure it was over 500 for 160 or so slots.

    My two sessions are:

    Branding Yourself for a Dream Job -The Modern Resume – Everyone wants a dream job that they enjoy going to each week. However finding that job, and getting yourself hired can be hard for most people. Steve Jones will give you practical tips and suggestions in this session that show you how to better market yourself, how to get the attention of employers, and help improve the chances that the job you want will get offered to you. Learn about networking, blogging, writing, speaking , and more from Steve Jones, who has successfully used these techniques to find his dream job.

    (in the Professional Development Track, level 100)

    The Top Ten SQL Server Skills You Need – Come learn the ten most important skills that every accidental DBA, developer, or even manager should be able to do in SQL server. If you want to know where to start working with SQL server or which 10 things will get you through most of your days, some see Steve Jones show you how to accomplish these ten important tasks and explain why they are important. These ten skills represent the 80/20 rule in action; if you can do these ten things, you can successfully get through most of your days at work.

    (In Enterprise Database Administration and Deployment, level 100)

    No idea on which days they’ll be there, but come join me if you’re interested.

  • The 2012 Rally

    In case you hadn’t heard, the 2012 SQL Rally will be in Dallas. Andy Warren talks about the process for picking the city, and some of the challenges involved. There was supposed to be an open submission process and then votes from the community, but that didn’t work out. For the record, I completely understand the decision and would like to congratulate Sri, Tim, Sean, and the rest of the Dallas crew that put together a great application for their city. With the defending NBA champs in Dallas and the Rangers nearby, I’m looking forward to going to the Rally next year.

    Denver submitted an application, which I wasn’t a part of, but I was contacted by a group of people that wanted to get the Rally in Denver and we were looking to come  up with a way to market the city, get some votes, and get people excited.

    That’s done for now, but we won’t give up. Look for us to do some work and try to get the 2013 Rally in late spring, hopefully in time for a few of you to join us in some spring skiing.

  • T-SQL Tuesday #19 – Disaster Recovery

    TSQL2sDay150x150This month Allen Kinsel hosts T-SQL Tuesday #19 with a disaster recovery theme. This is the blog party idea started by Adam Machanic where everyone that participates writes on a single theme.

    If you want to host, contact Adam. If you want to participate, read Allen’s post and write your own post and link it in.

    What’s a Disaster

    It’s interesting that this is the theme since I already had two posts on DR scheduled this week and am working on modifying my “Preparation for Disaster” presentation for SQL in the City.

    It’s hurricane season for Allen on the Gulf, and while hurricanes give you advance notice when they are coming, you have to be prepared. I’ve lived on the East coast, and we always were worried about getting hit in Virginia Beach. We never did get hit, but that didn’t stop us from being prepared and sometimes even initiating some of our disaster protocols.

    As a side note, we had an office in High Point, NC, and it actually got hit by a hurricane, or the remnants of one and lost power. I was in a downtown hotel at the time and woke up without power.

    The thing is large disasters are rare. You have very little chance of your data center getting hit by a hurricane, a tsunami as Japan recently had, a tornado such as the Northeast have experienced this year,  They happen regularly, but the chance of them hitting your data center is low. The chance of you “losing” a data center is low. It just doesn’t happen that often, and the complete loss of a data center might mean you have bigger things to worry about.

    However there are plenty of disasters that you are likely to experience. It’s possible that you could have a fire in your data center that affects the database server. Not likely, but it could happen. It’s more likely that you could have one of these:

    • an operator spill coffee on your server
    • someone trips over a power cord or fiber cable and brings down your system
    • a memory chip go bad and get in memory corruption.
    • it’s possible power goes out for some reason, even with a UPS.
    • It’s highly likely that a drive will fail that contains data you need.

    These are the types of disasters that you really have to prepare for, since they are possible, and even likely.

    What’s more likely are the “Whoops” disasters as I like to call them. It’s very likely that someone will import the wrong file, update all prices instead of one, or even more likely, a developer or DBA will run the wrong code on the wrong server. The most likely disaster is probably this one:

    drwhoops

     

    If the DBA hits “Execute” here, it’s a disaster. Not a big one, but if this is a critical table in a critical system, you might have an even bigger reaction from manangement than if a hurricane hit.

    You have to prepare for disasters, but don’t get caught up in worrying about the data center being destroyed. Those disasters are rare. Most of your preparation, your practice, your checks, have to be focused on the more likely disasters, which are often smaller in scale and focused on your database.