Voice of the DBA

Category: Editorial

  • Testing in Production

    The recent Apple keynote announcing the iPhone 6 was very heavily watched. At least, I think it was heavily viewed because I had trouble connecting, numerous pauses and regular stuttering of the video. Despite the fact that the stream was limited to Apple operating systems (iOS/OSX), it appeared that many other people had trouble watching based on the tweets I saw. On top of the scale issues, there were also different language translations overlaid in the audio and crashes of the Safari browser. Overall, the live event was a disappointment to me, though it hasn’t stopped me from upgrading my iPhone.

    The numerous problems that occurred had me wondering if any system wide testing was previously conducted. Was it possible that Apple was actually having their full scale, end to end system test in production? During the live event? I guess it’s possible, though it would be  imprudent and foolish to do so. With all the effort and expense that goes into the “Apple show”, how could a complete system test not be managed?

    Certainly a one time event like a product launch can be hard to simulate. The scale alone is difficult to predict, but certainly there are things that can be simulated. The actual people and applications can be used to record, encode, broadcast, etc. As closely as possible to the conditions of the live event, with the same size, type, and configuration of equipment should be used. The same people who will operate it should participate. We know this as technologists, and most of us would perform testing like this if we could.

    I know that resources are often constrained, and time is precious. However we need to perform some testing prior to production if we are to have confidence that everything will work during a deployment of new bits. The best way to do this is to deploy often, to a variety of environments in the same way we will to production. Execute a variety of tests each time that ensure the application functions as expected. If we find problems, we shouldn’t fix them in that environment. We should start over, fixing the issue in development, and deploying the changes again through test, pre-production, and any other environments we have. Be repeating the process over and over, we can build confidence that our production environment will work as we expect. 

    I hope Apple did this, though the end result has me feeling a bit skeptical.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.9MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • Automate Yourself to a Coffee Break

    I’ve worked as a production DBA in a few companies, and in those positions, I’ve always worked to make my position one of “insurance,” with me able to respond when things go wrong. My goal has been to understand, improve, and enable an environment that runs smoothly, which allows me to take leisurely coffee breaks and not hurried (and harried) sips of coffee as I walk from the coffee pot back to my desk.

    There was a good article published recently about the mindset of a DBA and how automation is an important part of your job. If there’s something you can easily automate, then it’s probably something you should automate. There are plenty of tasks that are easy to script into jobs, set alerts for, or have the system perform some action when they occur. If the system is performing that work, then you have time to deal with other, higher value tasks.

    What are those higher value tasks? Well, what things do people complain about, but you never get the time to work on? Perhaps tuning queries? Maybe practicing your skills for a disaster? Finding time to analyze the performance of systems and plan for the future? There’s probably no shortage of things that you wish you had time to deal with because there is no shortage of busy work you’re assigned.

    Do yourself a favor. Look for places to introduce automation through T-SQL scripts, Powershell commandlets, alerts, and more. Practice writing some small program to manage a task for you. It might seem like it will take longer than doing the work, and it will. However the next few times you’re asked to complete the same task, it should take you much, much less time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.8MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Watson Freemium

    I’ve been intrigued by the Watson project from IBM. It was quite a coup to see the platform win on Jeopardy. That’s an amazing accomplishment for machine learning, though it does seem like the investment and effort to set up the platform and experiment with it was more than most people could afford.

    However this week I saw an announcement that IBM has introduced a freemium version of Watson, aimed at people looking to work with analytics. This product allows users to upload some data and ask natural language questions, which Watson will answer.
    I have no idea how this will work, but I like the model they’ve taken. We can upload limited data and experiment with it. If it works well, we can subscribe, pa some money and upload more data and get more complex analysis. As an IT person, I think this is great. End users can play with it, and I don’t have to mess with a proof of concept. If it works, I can get involved, help automate ETL, query structure, tuning etc.
    It’s a changing way of working with analytics, and one I welcome. To me, as business people play with technologies like this, they become more savvy and willing to invest in technology. And as they demand more, they create more opportunities for IT people to help them, not less.
    Steve Jones

  • No Compelling Reason

    When I’m talking to people working with SQL Server, many of them are quite pleased with the platform. It solves their issues and problems. While they always wants changes and improvements, not to mention bug fixes, overall most people seem happy with their particular version. However, there’s no shortage of things that are slightly broken in SQL Server, and while I appreciate the Cumulative Updates every other month, I’d like to see even more work done fixing code.

    The development of SQL Server has accelerated in the last decade. After the five year span from SQL Server 2000 to 2005, we’ve seen new versions coming just over every 24 months, and I expect that to continue in the future. This rapid release cycle means that many of us end up supporting 3, 4, or more versions of the platform at any one time.

    We often install the latest version for new instances, often because that’s the only version we can buy at any time. However we don’t seem to upgrade older instances quickly. This week I’m wondering why.

    What are the reasons that prevent you from migrating those 2005/2008/2012 instances to 2014?

    Are there technical reasons you don’t upgrade? Is it cost-related? Or is there no compelling reason to adopt the newest features and enhancements to the platform? I suspect a combination of these reasons for many of you, though I also feel the platform is very mature, and has been for many versions. The applications I run, primarily SQLServerCentral, don’t really benefit from any of the features in later versions.

    Let us know this week, and I’m especially interested in knowing if there are technical reasons any of you can’t upgrade.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.