Voice of the DBA

Category: Editorial

  • A Nice Refund

    Why don't these kinds of mistakes happen to me?

    This editorial was originally published on Sept 12, 2006.

    How’d you like to be the DBA for a system thatmistakenly gives out $318 million? It probably wasn’t the database, but more likely the code for some application that caused this to occur in the IRS system, but it’s something that becomes more likely in SQL Server all the time.

    SQL Server 2005 is the first time that SQL Server can be easily used as a complete application development platform. With the addition of the CLR, the Service Broker, Database Mail, web services, and more, SQL Server 2005 could be your database server, application server, and only server, with no other software running.

    While application developers will likely write most of the code, including lots of the CLR functions, procedures, and other constructs, who do you think will be responsible for the system? That’s right, the DBA. You’ll be the first and last line of defense and the one that will likely shoulder a lot of the blame for issues. Fair or not, I expect that DBAs will become more likely the scapegoats for issues.

    This means that as a DBA, you really want to beef up your skills as well as clearly delineate lines of responsibility. You should be able to read the code behind assemblies you add to your server, as well as understand how the SQL Server subsystems fit into an application. But you also need to be sure that you let management know when you are overloaded, when you can’t review code, or when you are concerned about possible issues with code.

    I’ve felt for years that it was a matter of time before some computer professionals will need to become bonded because of their responsibilities. I’m not sure when or where this will start happening, but I wouldn’t be surprised if it starts with DBAs.

  • The DR Test Schedule

    You never know what disaster will strike.

    It’s hurricane season on the East Coast of the US right now, and after Hurricane Irene, I’m sure there are more than a few IT workers that are worried about their disaster recovery (DR) plans. Irene didn’t cause much damage, but it was a reminder that there are situations which are completely out of our control, but could easily end up causing us problems with our infrastructure.

    SQL Server gives us numerous ways to prepare for disasters with different technologies like database mirroring, log shipping and more. The new Always On features in Denali will give us even more options, and may be worth the cost of an upgrade. While DBAs seem to regularly practice backups and restores, recovering a full application often requires more than a SQL Server restore. This Friday, I wanted to ask how often you practice your recovery.

    How often do you perform a full DR test for an application?

    I think it’s very unlikely that you would lose all your servers at once. It’s possible, especially with an event like a hurricane, but it’s very unlikely that you would have to recover all your systems at once. However that doesn’t mean that you shouldn’t be prepared to recover a complete system. If new hardware arrived, could you rebuild your Windows hosts, your SQL Server instance and application or web servers? I’ve found out the hard way this isn’t as easy as it sounds.

    I used to perform a complete test of our one critical system once a year. We set aside a day, sending the IT staff needed to a secondary location with media, backups, and unformatted hardware to perform a test. If we couldn’t recovery the system in a day, we usually reviewed the issues and tried again in a month. Unfortunately, if we failed that test, we didn’t usually get another chance that year. Not exactly great disaster recovery planning.

    These days my part of the infrastructure, SQLServerCentral, lives on virtual servers. While I don’t have the responsibility for these servers, we do have images of them, as well as regular backups, and I suspect we could recover them fairly quickly. Maybe I should ask for a test someday soon….

    Steve Jones

    The Voice of the DBA Podcasts

  • An Awesome Job

    Life is awesome and if you can't see it, read this book.

    I recently watched The 3 As of Awesome with my daughter and loved it. It’s a short talk (17 min) from Neil Pasricha, the author of the 1000 awesome things blog. The talk goes through a roller coaster of emotions, at least for me, with a pleasant start, a sad middle, and a positive end. There’s some humor in it, and I highly recommend you watch it.

    When we finished, my daughter and I talked about what awesome thing had happened to each of us that day. She said that me giving her 5 extra minutes to play with a friend before we left was great. I told her the crazy, illegal, solo, 5 hit volleyball return I made at her practice that made everyone laugh was the highlight of my day. We challenged the rest of the family to find an awesome thing from that day, and everyone enjoyed it. Since then we’ve made it a point to regular ask what awesome thing happened to each other.

    The philosophy espoused in the talk is one I try to follow. I stop and appreciate the cool, little things in my life. A refill of my drink when I’m flying economy class makes me smile. I get a good feeling when I can stop and hold the door for someone behind me. I appreciate the health I have, and the fact I can run regularly. A good cup of coffee, the cat wanting to snuggle up when I’m typing in bed, or the chance to step away from my desk and give my wife a kiss during the day are awesome and amazing things in my life.

    Work isn’t always awesome, but I’d like to think that you find little things you can appreciate on a regular basis. Maybe it’s code you write that works. Maybe it’s the knowledge that you saved someone else time because of something you did. Maybe it’s that second monitor that lets the work flow a little smoother. Maybe it’s that burst of bandwidth that made a download smoother. Maybe it’s the comment someone made on SQLServerCentral or on Twitter that grew a smile on your face.

    We spend a lot of time at work, and it’s often work. I hope you enjoy your job overall, but even when it’s not the job for you, hopefully you can find and appreciate some little thing that occurs every week that shows the universe likes you.

    Steve Jones

    The Voice of the DBA Podcasts

  • How do you learn the advanced stuff?

    Advanced Study is hard, but worth it when you want to get better at something

    I was talking with someone recently about features in SQL Server and they mentioned that partitioning was something DBAs should know. It’s only available in the Enterprise and Data Center editions for production use, but my friend noted that it works in Developer edition and felt there was no excuse for a DBA not being familiar with a feature that’s been out since SQL Server 2005, nearly four versions removed from its introduction.

    I can understand that, but if you don’t have the ability to actually tune large data sets and see the impact of partitioning in a larger, production environment, it’s easy to dismiss this as a feature that doesn’t provide many benefits in a smaller situation. The same could be said for clustering, SSIS imports, or any number of features that aren’t often used. So how do you actually learn to get some experience with these features?

    The first thing you need to do is get a copy of SQL Server Developer Edition and install it as a virtual machine on your primary computer. I use VMWare, but you could use Virtual PC, Hyper-V, or VirtualBox as well. The important thing to do is have a sandbox to play in and a machine you can easily copy, clone, or destroy as needed. I would recommend a base install of Windows and SQL Server DE, and then copy that for a machine you can experiment with.

    One way to learn is duplicate the work that someone else has done. Make a copy of your virtual machine and then implement partitioning as described in an article. See if you can duplicate the way the author used the feature and get the same results. If you can’t, find out why, and if you can, experiment with the feature and try to improve the author’s implementation. The SQLServerCentral Stairway Series is a great way to do this in SSIS, SSRS, or other features that you may never have seen. Set aside an hour or two a week to learn some feature. After a month or two, you might be surprised what you’ve learned.

    The most important is to understand how a feature works and gain some experience in using it. You might not become an expert, but being able to talk about the feature, and explain how you might use it in a situation comes from practice. That ability  might get you the project or job that allows you to become an expert over time.

    Steve Jones

    The Voice of the DBA Podcasts