Voice of the DBA

Category: Editorial

  • You Don’t Know Enough

    Always be learning

    We always expect developers to test their own code and be sure that it works as expected before they release it for anyone else to use. However we should be aware that developers won’t think of all the edge cases that might break their code, so a good software process includes another group (QA) that tests the software separately, and hopefully also reviews the code as well.

    Why do we do this? It’s because you can’t be sure that just because code passes your own tests that it is well written. You can only be sure that it passes the various tests you have designed, which is likely a subset of all possible tests it ought to pass.

    Bruce Schneier wrote a piece that talks about this from the security perspective. If a system fails initial testing, we know there’s a problem. However if it passes those tests, we still don’t know it’s secure. There still might be other vulnerabilities, perhaps even obvious ones. Only through exhaustive testing and review of the code, can we gain any sense of confidence in the security of a system. Even then we would still want to include some monitoring of the system as vulnerabilities might be discovered at a later time.

    Each of us has some limited amount of knowledge about the technology we work with, but there is one common thing we all share: we can all learn more.  Those limitations of our knowledge carry over to the code we write, and mean that we won’t necessarily completely test our code to cover all possibilities.  We might not even remember to test for some things as our work gets more complicated.

    We need to work with others to ensure enough code coverage and have some level of confidence in the quality of our work. Today’s systems are just too complex for one person to completely understand. Once you accept that and learn to work in a team, critiquing the code of others and accepting criticisms from them on your work, you will find the quality of your software will rise.

    Steve Jones

    The Voice of the DBA Podcasts

  • How to Fix Connect

    Microsoft Connect is the place to submit feedback

    The Connect system is the main way that all of us can feed back information on SQL Server to Microsoft . You can use this system to submit a bug or a suggestion, and your submission will go to the SQL Server development team so that they can respond. There is the ability to comment on other people’s posts, view workarounds that Microsoft or another user have posted, and vote a suggestion up or down. A great example that’s one of the most voted on items is the Create or Replace idea.

    Recently a large number of Connect items were closed, including a few that I had submitted. Based on all the Twitter comments, it seems that most of these items were closed and marked as “Won’t Fix”, which I assume means these will not be fixed for SQL 11.

    That’s good and bad. Having watched the Connect Feed for SQL Server, I’m surprised by some of the suggestions that I see come through. While I can appreciate someone wanting to know when SQL 11 “Denali” will be released, I’m not sure it’s worth a Connect submission. Or this brilliant duplicate indexes note. I feel bad for the people that triage these requests since these not-very-well-thought-out submissions create ill will and waste time. How would you like to get these type of suggestions for your software? My guess is most of these suggestions ought to be closed and this was a good thing.

    But it’s also discouraging for those of us that submit feedback and don’t necessarily get a good response on why our feedback doesn’t make sense, especially when you have dozens of people voting for the idea.

    For a long time I really liked the SQLWish email address where one could send ideas to Microsoft. That was discontinued in favor of Connect, which I think is a good idea. However I think Connect has a scale problem and doesn’t necessarily work as well for “ideas” as it does for bugs.

    I’m not sure how we can fix it, but one thing I’d like to see is a ranking of the top xx items that could be considered for the next version. Feed that back to the community and let us give you opinions on whether or not those items are still important. I know we can’t necessarily drive development, but I do think that SQL Server can evolve into a product that we are more likely to upgrade if our feedback is visibly and obviously considered.

    Steve Jones

    The Voice of the DBA Podcasts

  • Improving SQLServerCentral

    A better database for SQLServerCentral: BigTable

    We have some big changes coming to SQLServerCentral over the next few months. In response to a large number of comments about the performance of the site, we are looking to implement some sweeping changes that will drastically improve performance, and make the site much more interesting.

    We send out nearly a million newsletters a day, which places a substantial load on our system. Our hardware upgrade last year improved the performance, but as we continue to grow, we are stressing the hardware. When we add in the global reach of our forums, we have once again begun to noticed a slowdown on the systems.

    Fortunately we have a solution. One of the distinguished engineers at Red Gate has a brother that works for Google and they have agreed to help us out. We received a license to implement the BigTable technology at SQLServerCentral and will be moving our primary database systems to this NoSQL storage. This will allow us to scale out effectively with a large number of small, single socket, dual core servers, each of which will handle a portion of our load.

    In addition we have decided to also scale out our articles using the cloud. With a combination of the BigTable technology and GoogleDocs, we will be moving all our publications to the cloud, enabling you to get access to our content with the power of the Google network. We will have analytics built in and the OpenID framework will authenticate you with a Google ID.

    Of course, this is all a big joke give that today is April Fools day in the US. We like Google’s technology, but we *love* SQL Server and have no desire to move off that platform for any other. Now if we could get Resource Governor in our Standard Edition, all would be great.

    Enjoy your day and hopefully you liked this editorial.

    Steve Jones

    The Voice of the DBA Podcasts

  • 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