Voice of the DBA

Author: way0utwest

  • The Career Path

    Which career path would you like?

    Most people seem to wander through their careers, taking any job that comes their way. Others have a tight focus, often with a larger goal of ending up as the owner of a company or perhaps the CIO of one.

    However for the technical person, someone that wants to remain employed for a long time, but doesn’t want to oversee others, there isn’t a clear path. So many DBAs, developers, and other people have no interest in moving into management, but they still would like to progress in some fashion to other jobs.

    This Friday I wanted to ask what that progression might be like if you had no restrictions from HR and could design your own set of jobs:

    What would you like your technical career path to look like?

    I am wondering if you think there ought to be some way to advance to a senior person, maybe with multiple levels after your title. Perhaps some of you would like to move into an architect position or even be seen as some technical fellow after some amount of time.

    Think about the way that a technical career might advance, without going into management, and let us know in which direction you wish you could move.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Woes of Cloud Computing

    Cloud computing: sunshine or rain?

    Many people have been skeptical about the move to cloud computing, especially in the database world. There are valid reasons to worry about security, legal issues, and more. I certainly think that using cloud services requires some planning and careful examination of the impact to your environment, but I also think that many companies will want to make the move, so it pays to learn more about cloud computing and be prepared with realistic, rational concerns from the database perspective.

    Anthony Skipper of ServiceMesh gave a presentation on some of the problems and lessons learned from moving to cloud computing. It was picked up in an Information Week piece that summarizes some of the areas that can cause problems for your company. The list of issues is a good one, and worth reading through.

    There are a couple of items in the list that I thought were very interesting for data professionals. The first was the fact that companies need to ensure that they implement policy from the beginning for how cloud services will be used. I think this will always be a point of contention between IT and the clients, and this isn’t an excuse to lock down clients or limit their options. Instead it ought to be a place where IT looks to be informed, help with guidance, and respond more quickly to client requests. IT cannot be the stumbling block in the cloud, or it will get left behind.

    The other thing? This quote: Have the ability to bring things back internally or to another provider at any point. That’s a great point. The cloud isn’t the ultimate answer, and you ought to have a backup plan, which should include the ability to move your services back to your own data center.

    Steve Jones

    The Voice of the DBA Podcasts

  • #1 Skill Needed – Backups

    This series of blog posts are related to my presentation, The Top Ten Skills You Need, which is scheduled for a few deliveries in 2011.

    1. Backups

    The first skill that you really need is the ability to back up a database. No matter what else you can do, or others will do, if you have backups, you can recover from issues.

    The is the first thing you should do with a new database. Make a backup if there isn’t one, and create a new schedule. Even if you haven’t added any objects or data, just setup a backup schedule. It’s easy to put off, and forget. I can’t tell you how many times I’ve run into a developer or DBA that is looking to recover a database and doesn’t have backups.

    Backups are insurance. Just like you have Geico, or Aviva, or any other insruance company in case of situations like this:

    Car Accident

    You never know when this will happen, so you have to be prepared. In the database world, part of your preparation is having a backup.

    Even if you don’t know how to do a restore, make sure you have a backup. You can always find someone to help you with a restore, but another person can’t help you with a restore without a backup file.

    Learn how to use the Backup T-SQL command.

  • A Really Bad Day

    I was out of town for work one day, literally on the other side of the country, in a car bound for the remote office when my cell phone rang. I had flown into LaGuardia Airport in New York City and needed to drive to Connecticut, to an office just outside of Hartford. The company was paying, and it was more convenient for me to fly into NYC and then take a chartered car to CT.

    I glance at caller ID and it’s a client of mine back in Boulder, CO who I do some occasional SQL Server work for. I answer, thinking that he needs help with some SQL command and I can score some brownie points here without charging him.

    “Steve, I have a problem”

    The words that anyone in technology is loath to hear. Even if you’re being paid by the hour, clients that cause issues are often going to be more trouble than the payment is sometimes worth. I much prefer to hear “Steve, we’d like to do x. How can we do that?”

    I ask him to tell me what’s wrong and he said that RAID card was throwing errors on the development server, so he performed a SQL Server backup, copied the backup to a file server and then replaced the RAID card, rebuilding the array. When he went to restore the server, he got an error.

    I am the backup and restore champ, at least of my little world. “Read me the error, “ I say, confident I can solve this for him before we arrive at the office..

    “The media set has 2 media families but only one are provided”

    Uh, oh, I’m thinking, and not because of the poor grammar. This is not good and I’m not going to be able to fix this. Breaking bad news to a client is never fun, even if it’s not your fault. I’ve lost a couple because they were so upset they let me go at some bad news. That’s actually OK with me because if they can’t tell the difference, they are likely to leave me when I least expect it anyway and I’d rather know sooner than later.

    I explain that he must have used two backup files and he needs to add the second one in there. The guy is insistent that he didn’t pick two files when he made the backup and he copied the right one off. He even included the date in the filename (like I showed him) and reads it back to me.

    I know what’s happened. He’s made an inadvertent striped backup, and since the RAID array was blown away, he’s likely lost the other file. I try to keep from laughing as I explain patiently what happened. He’s upset, then he’s confused, then he’s unhappy. I can picture the sad panda face on him from 2,000 miles away as he realizes that he’s not getting this restore to work. The driver must hear it in my voice as well since he’s smirking in the rear view mirror.

    To add misery here, he wasn’t copying backups off this development server to save space on the file servers. He’s lost a few weeks of work now, and he has to break the news to the developers, who likely don’t have backups of their own.

    I sign off, not sure what to do as I get to my destination. It’s a good example of why SQL Server still needs a DBA, or someone with decent DBA skills. Despite the ease with which you can get many things done, not understanding why you do them cause big problems.