Voice of the DBA

Category: Editorial

  • The Chance of Failure

    I’ve always worked on the notion that my hardware rarely fails, and while I protect it with backups RAID, etc., I don’t expect failures. That seems to be how most of the RDBMSes are structured, with this idea that things will work well and we have protection mechanisms when they don’t.

    Contrast that with the way Google viewa the world. To them,failure is inevitable at scale, as noted by  Jeremiah Peschaka in The Promise and Failure of Federated Data. At large scales of deployment, Google and other companies assume that there will be a percentage of failures and they have to account for them. This is the same type of accounting that restaurants use (spoilage) and retailers (shrinkage) use for allow for some amount of loss.

    In technology, we account for potential failures with RAID, with HA or DR technologies, and hopefully with substantial testing to ensure that we have properly accounted for potential failures. However it seems that most technology people account for failure as a possibility and not a probability. Many people seem to assume that a serious disaster is not likely in their career.

    I think that a catastrophic, we lost the whole data center, event is unlikely for most of us. As Hurricane Katrina and the recent earthquake in Japan have shown, that is possible. However it’s unlikely for most locations, which is a good thing.

    Failures are inevitable and whether it’s a disk corruption, a server crash, or a building power failure, we have to assume we will experience one and plan for the event. We also have to expect hardware will fail, which means regular checks and monitoring to detect these failures as soon as possible.

    Hope for the best, but plan for the worst.

    Steve Jones

    The Voice of the DBA Podcasts

  • 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