Voice of the DBA

Author: way0utwest

  • What Differentiates Enterprise?

    Now THIS is Enterprise Edition.

    There seems to be regular disagreement from SQL Server professionals about what features are most important for future versions and which bugs should receive the highest priority. However one thing that many customers complain about is the lack of features in the Standard Edition (SE) that exist in the Enterprise (EE) or Data Center (DC) editions.

    In SQL Server 2000, it used to be that a customer had to buy Enterprise Edition (EE) to get clustering or log shipping. In SQL Server 2005 Standard Edition got clustering, but no partitioning or database snapshots. SQL Server 2008 and SQL Server 2008 R2 added new features, some of which are only available in EE and DC editions. In each case, as SQL Server evolves, some features get moved down to SE, while others do not. The distinctions between editions are arbitrarily made, with the idea that some features are “Enterprise and are used for large scale SQL Server installations. However there are also size limits on the editions that limit the number of instances, nodes in clusters, memory, processors, and more.

    Is that the best way to separate the editions of SQL Server? It seems that I rarely find many people that agree with the different mix of features and limits that are built into the different editions.  This Friday I wanted to get your opinion:

    What should differentiate Enterprise (or Data Center) edition from Standard edition?

    Do you think there should be a feature distinction? Or a hardware distinction? What would you change about the way things are done, or what makes the most sense to you, as a SQL Server customer.

    In my mind, I’d like to see SQL Server priced on scale, and not on features. I’d like to see all features in all editions above Express. However charge me by the core, or some formula of cores + RAM that might make licensing cheaper for those low end dual core systems we have now, maybe equal for 4-8 cores, and then scaling up as people move to more cores, and handle larger workloads.  Let me add licenses as I add hardware, and easily move those licenses around as I move my instances between physical servers.

    Licensing is always a controversial subject, and one that we rarely agree on. However I’m curious what people think about the plan that might seem the most fair to them.

    Steve Jones

    The Voice of the DBA Podcasts

  • Do You Need A Safe Word?

    Should we implement "safe words"?

    I read this Forbes piece on the hacker “Kayla”, which led me to this correspondence posted when she (or he) hacked HBGary Federal. The transcript of emails is rather amazing  and a little scary. She manages to get access to the servers through a clever bit of social engineering against a security specialist.

    The whole plot depends on access to a person’s email account, but that’s entirely possible. Imagine creating a distraction and then stealing a target’s smartphone. Done cleverly, a busy executive or IT worker might think they lost the phone and spend time trying to track it down. Meanwhile a hacker has access to their email, sending who knows what messages out.

    As system administrators, or anyone with privileged access to systems or data, should we assume that an email request from a person for a password reset, or an access request to additional privileges is genuine? My thought is that we might not want to “trust” these systems and instead, implement some other type of verification method along with this trusted access. Perhaps we ought to call the person and verify the request if we know their voice, or require them to present their request in person. At one place I worked, we used to require someone to personally come to the IT office unless we were sure we knew that person’s voice. That’s not a perfect solution, but it could help increase security.

    Maybe we need a safe word for each privileged account. It could be a word we request from the user when they ask, or maybe it is an uncommon word that has to be worked into the request to help verify the end user’s identity. Ideally we would just feed the message into some system that would authenticate it, rather than allowing a technician to manually verify the safe word from some store of words.

    Security is hard, but and none of my suggestions is perfect, but as there are more and more script kiddies, hackers, and social engineering professionals, perhaps a little paranoia is a good thing. Perhaps making it hard to gain addition access, especially privileged access, is a good idea.

    Steve Jones

    The Voice of the DBA Podcasts

  • 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.