Voice of the DBA

Category: Editorial

  • 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

  • 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