Voice of the DBA

Category: Editorial

  • Power Tools at Work

    This editorial was originally published on Jan 17, 2007. It is being republished as Steve is on vacation. 

    Now this could be fun. Just imagine your boss comes to your cube with an electric drill, a sledgehammer, and a circular saw. Oh, and don’t forget the safety glasses. You’ve got work to do.

    That’s what is happening in some IT shops as old data drives need to be destroyed with no hope of the data being recovered. I saw this article on data demolition and thought that might actually be a fun afternoon at work. Destroy some old data drives, ending their usefulness like the fax machine in “Office Space” 🙂

    Data security is becoming a bigger issue all the time in the corporate world. And as more companies store more and more data on disk, the issues with disposal must be dealt with by more and more IT groups.

    I guess you could hire a firm and get this before and after picture:

    Now this might be fun.

     

    but I’d think that defeats the purpose somehow. It’s the physical access outside your company that can be the problem. Going to a vendor specializing in destruction could be a problem since it gives criminals a single source (or a smaller source) or vendors they can bribe to get critical data. Better off letting different people in your company destroy the data at random intervals. That way no one can predict where and when the data will be destroyed.

    Plus it would be fun 🙂

  • Helpful Advice?

    hard drive
    Flicking power on and off is not recommended for these devices.

    This editorial was originally published on Feb 5, 2007 and is being re-run as Steve is on vacation.

    I have to be honest with you. It wasn’t me. This advice on DRwasn’t given to anyone by me. This post is from a blog entry last year before Tech Ed. I made a note of it, but it wasn’t until recently I got around to actually writing about it.

    I’m kind of surprised to see some of this advice being given to people. Some of these I don’t think are too bad, but would you do any of these on your production database?

    1. “Just run REPAIR_ALLOW_DATA_LOSS and you’ll be fine…”
    2. Just rebuild your transaction log using these steps…”
    3. “Just restore your database and carry on…”
    4. “Run CHECKALLOC, then CHECKDB, then CHECKTABLE on all your tables, then…”
    5. “Just flick the power switch on and off a few times on one of the drives…”

    Actually I’ve done #4 and #3 is something I’ve had to do before as well. I can appreciate the caution in the article about not finding the root cause, but I’ve had more problems than I’d like to think about where we couldn’t find a root cause in a reasonable time and decided to move on. And we never had the issue again. In the interests of getting the business going, there was a time where I explained everything, guesstimated the data loss, and we decided to just restore, lose the data, and have people re-enter it as quickly as possible.

    As for the other items, I don’t think I’d run REPAIR_ALLOW_DATA_LOSS without someone from CSS on the phone. And I don’t think I’ve ever even heard about anyone “rebuilding” a transaction log. That sounds like one of those urban myths where someone heard that someone said that they had a way to rebuild a log.<

    Flicking the power on your drives? I’m not sure what I’d even say to someone who suggested it.

  • What’s Your Title?

    What's your title?

    I was reading a very interesting post from L. Z. Granderson recently that is more of a political observation than anything, but in the piece he brought up a point that struck my interest. He finds that many people use a simple question when they are getting to know each other, and that the question might color the impressions of us that others hold. The question is

    “What do you do?”

    It’s fairly innocent, and it’s a nice icebreaker, and in fact I’ve used it at many conferences to try and get to know other people. I know that most people I meet at SQL Server events are technical, or work with SQL Server, but this allows me to better understand who they use the question. When people ask me who I am at conferences, I usually reply that I am the editor of SQLServerCentral, and explain the site if I need to. On my resume, I emphasize the “DBA” title, along with the “writer” label for me work with SQL Server.

    However when I’m away from work, I answer the question differently. People in Denver ask me what I do and I’m a “computer guy”, and if they query more because they’re technical, I say I’m a “database guy.” Pretty vanilla, pretty plain, but I find myself more often interested in talking about things other than work.

    The label you use matters when you’re looking for a job, or when you are presenting your professional brand to a potential employer, client, recruiter, or even your boss during a review. With that in mind, I wanted to ask you what title you use this Friday:

    What’s your job title?

    Let us know what it is, or what you think it should be. I’ve often joked at many companies that I was the “data janitor” since I was always cleaning up accidents and messes, but I typically have only worried about being classified as a “DBA” or maybe a “Senior DBA.” However with the proliferation of titles these days, and the buckets that many companies use to classify people, I usually go for a DBA job, but I’m willing to take the title that best fits for that company.

    Steve Jones

    The Voice of the DBA Podcasts

  • More SQL Injection

    If you can't prevent this in your application, you need to think about upgrading your skills.

    One milly-yon sites hit by a SQL Injection attack. That happened according to a headline I saw recently, with an attack similar to Lizamoon affecting seven figures worth of ASP.NET sites. How can this still be happening on large scales? I’d like to think that this was mostly at small sites that people had set up for themselves, but I’m sure some decent sized companies were involved in this.

    This isn’t good for your brand as a developer. If you don’t know what SQL Injection is, you shouldn’t be developing software. If you don’t know how to code to avoid it, you shouldn’t be hired by anyone to build software. If you can’t write a stored procedure around a query or built a parameterized call to a database engine, you need to learn how or find another career.

    It’s sad that years after we’ve had the SQL injection problem make headlines, and change the way many companies write software, we will have thousands of applications being used every day that are still vulnerable to this type of attack. There is a lot of old code out there, but it can’t remain. We are regularly adding new data to our systems, and new data to applications. There’s no excuse for companies not making a complete review of older code and updating it to avoid unvalidated input or passing through queries that could be hacked.

    Educate yourself, save these headlines for your boss, and ask that no new applications, including third party ones, be purchased if they haven’t updated the code to prevent SQL Injection attacks.

    Steve Jones

    The Voice of the DBA Podcasts