Voice of the DBA

Author: way0utwest

  • Hacking Data

    I saw a note recently that researchers had successfully hacked a car using only an MP3 file on a CD. They were able to lock the doors and kill the engine in a car. That doesn’t necessarily sound too scary until you consider that the ability to kill any percentage of car engines during rush hour traffic could have catastrophic results.

    How much of an issue is this? I don’t know, but as long as there is some interpreter that has to decode digital data and render it as audio, video, or even text, there is the chance that additional code could be added to hack the system and allow someone to take control. When I think about all the ways that we get digital data these days, it is truly a scary thought that we could have these security holes.

    Think about it, MP3s could be sourced at a retailer like Amazon. Adding code to a popular MP3 song could infect millions of people that burn the MP3 to a CD, or connect their iPod to the stereo. The advent of HD radio could invite hackers to target broadcast centers and alter those files. Navigation systems and traffic data streams could potentially be carrying digital viruses that infect our systems.

    However that same idea could be extended in other ways. The more knowledge someone has about your internal systems, and the more they are connected, the more likely that just the addition of data to streams could have unexpected events. Suppose someone understood the complex relationships between various ordering and supply chain systems. Is there a chance that they could send in a sequence of orders that would disrupt your systems? Could someone inject data that somehow starts a chain reaction of workflows across your enterprise?

    It seems unlikely to me, but then again, 5 years ago I would never have considered an MP3 file might allow someone to gain control of a modern car. Security is a tough business, and there will always be new, creative, unbelievably exploits that are discovered. The best defense I can think of is to share information and never assume your systems are invulnerable to a new attack.

    Steve Jones

    The Voice of the DBA Podcasts

  • SQL Server Connections in a week

    I’m heading to SQL Server Connections next week, part of the DevConnections conference featuring a whole slew of technologies. Once again SQLServerCentral is sponsoring a track at the event, and I’m playing host and reporter.

    We’ve picked some great speakers, including Brian Kelley, Joe Webb, and Jonathan Kehayias to talk on security, locking/blocking, and extended events. We have Brad McGehee as well, talking trace and helping me host the party.

    This spring the event is back in Orlando, which is a great location and while I don’t mind the cold weather of Colorado, it is good to get down to Florida for some warm weather and cold drinks and talk some SQL Server

    Hopefully I’ll see a few of you down there. Look for me in the Hawaiian shirt and cowboy hat.

    There’s still time to register and you can save $200 with “DevCon1” as the registration code.

  • Test Before Deciding

    Do you extensively test?

    Will a new index improve the overall performance of your database server? Will adding another index slow down your insert or update performance? Can adding another file to tempdb make things run quicker?

    The answer to all of those questions is definitively “it depends.” That sounds contradictory, but it’s actually the answer that applies to all of your workloads. Your workload, on your version of SQL Server, on your hardware, with your data sets, will perform differently than the same version of SQL Server on the same hardware than my workload.

    What does that mean for DBAs and developers? It really means that you can’t easily make hard and fast decisions about many of the settings, configurations, and designs you use for performance are just guidelines. The best DBAs I know have lots of guidelines and rules of thumb that they use to begin their design or analysis of a database instance. However they are willing to make exceptions or changes to their “rules” if the situation warrants a change.

    How do they know when to change? They test.

    It’s that simple. Running tests, comparing the changes in performance, measuring the metrics that occur from implementing a particular feature allows a DBA to make an educated guess about whether or not any alteration of your code, your indexes, or your design will bring about improvement. However testing before you make the chance isn’t enough. Even after you have made a change, you need to continue to monitor, essentially “re-testing” in a live system, to determine if the system is still performing well.

    Just trusting that you are “sure” of what to do or not to do is a mistake. Set up tests, gather metrics, and make informed decisions to ensure you servers are operating at peak performance.

    Steve Jones

    The Voice of the DBA Podcasts

  • Looking at SOX

    What do you think of SOX?

    We republished an editorial recently that I wrote early on when the Sarbanes Oxley Act (SOX) was starting to become a part of daily life for IT people. SOX was really written to the rest of the business, requiring accountability from the executives in a corporation. However it seemed to quickly become a burden for many IT departments, with the interpretations of the act requiring additional documentation for all actions. There were often security changes required that interfered with the way in which many technology groups operated.

    The act was passed in 2002, nearly a decade ago. Now that it’s been a part of public corporate life, I wanted to ask the data professionals out there what they think of the act and its impact on their jobs. For this Friday’s poll:

    Does SOX impact your work?

    Is there an increased level of effort and work for you or is it just a part of your job now that you accept and are used to? I would think that after years of being subject to the regulation that most people would be used to it by now.

    I know when the act was first passed there was concern that our IT department would be understaffed for the documentation that was required. However we were an ISO 9001 certified organization, and we quickly realized that much of our work to maintain our ISO status could be re-used for SOX compliance as well.

    The biggest hurdle we faced was in implementing better separation for development and production groups to ensure that systems were accessed by the appropriate individuals. It seemed to me that this was a change for the better at my company, providing better security for us.

    Let us know this Friday how SOX, or even PCI/HIPAA impact your workload.

    Steve Jones

    The Voice of the DBA Podcasts