Voice of the DBA

Category: Editorial

  • Is SQL Server Mature?

    When I asked recently what compelling reasons there are, or aren’t, for upgrading SQL Server, it seems cost was the issue for most people. I can understand that, especially as licensing for VMs has made it an expensive endeavor to upgrade their systems. Many, many companies have started to revisit their policies regarding upgrades and seriously evaluate the decision to undertake a version change. While I’m not sure if many companies are starting to look at keeping all instances of SQL Server for ten years, I know many are looking to keep their noncritical systems on the existing versions as long as possible.

    As I read through the posts on my piece, I found this great quote from one of the commenter: “I’m a great believer in “If it ain’t broke, don’t fix it” and so if a system is running acceptably for it’s purpose, I’ll leave it alone.” To a large extent, that’s how I’ve viewed systems. If things are working, it becomes hard to justify an upgrade. In fact, I had a client that was running a SQL Server v6.5 instance in 2005, a full ten years after that version was released. Why? Mostly because the database backed a card key system that worked. While the database wasn’t supported, neither was the card key system, and since an upgrade would have been close to $100,000, it wasn’t worth performing. We did upgrade to a virtual server to remove hardware dependencies, but otherwise left the system alone.

    That brings me to this week’s question, which is one that I’ve asked myself for years: Is SQL Server mature?

    If a version of SQL Server can handle the load placed on it, is there any good reason to upgrade. I suspect that for many applications, the base features of SQL Server are good enough. If these features have performed well for a number of versions, then why change? While I like the changes in T-SQL, especially error handling, I’m not sure those changes are worth paying tens of thousands of dollars for. I’m not sure the improvements are really justified for many applications, and I’m not sure many developers can even find the time to implement them.

    More and more I think that key to continued adoption and growth of SQL Server is licensing by scale, not edition, and not by feature. Just like Azure, let me pay for the cores and RAM I need, and let me easily grow that as needed.

    Steve Jones

    The Voice of the DBA Podcast

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

     

  • The Value of Data

    How valuable is your data? It’s a good question, and certainly the type of data your organization has along with the business in which you are engaged will make your data more or less valuable. More and more we find the differentiation between companies is in the way they collect, manage, and use the data available to them. So much in business is based on guesses, but more and more the guesses have some basis in data. We are starting to see those who make decisions in business feel some need to justify or support their choices with data.

    Is data the new oil? Oil was arguably the most important commodity of the twentieth century (and perhaps still is). The SQLRockstar wrote a piece with that same title, with the idea that knowing more about how valuable data can be will make you more successful in business. The post is based on the review of Predictive Analytics: The Power to Predict Who Will Click, Buy, Lie, and talks about some of the challenges of using data to make decisions.

    I certainly believe in the power of data, and that more data often gives us more insight into how the world works, as well as allowing us to draw some inferences about the future. Not necessarily better insight, but certainly more. I do think that computer extrapolation of patterns to the future is vastly overrated as most of our algorithms are far too simple, using too little data and discounting the increasing effects of small variables as scale increases. In short, I don’t think we’re anywhere close to a Foundation-like computer that can help us predict the success of new products, much less the future of a country.

    However I think that using analytics to make small decisions, and help guide our directions is important. We will still need humans that apply their internal supercomputers to interpret data, and continue to evolve the algorithms, and I hope that more and more of you are gaining deeper industry insight in your particular field. After all, many of us data professionals will be needed to help guide analysts in gathering, transforming, interpreting, and displaying data in ways that allows us to make decisions with more confidence.

    Steve Jones

    The Voice of the DBA Podcast

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

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