Voice of the DBA

Category: Editorial

  • Servicing SQL Server in the Future

    Service Packs have become the way that many of us patch the various Microsoft products we use. Many administrators find patching to be time consuming and difficult to justify, even for security patches, and as a result, often wait for a Service Pack before they inform clients and schedule testing. Most people used to always wait for Service Pack 1 before installing a new version of a server product, but I don’t think that’s necessary anymore. The quality of Microsoft server products has gone up quite a bit in the last 5 years.

    However, I don’t like the way that the servicing, or patching, of products has evolved. For SQL Server, we get patches every other month, known as Cumulative Updates. Exchange Server has also moved to this format, though it seems many of the other server products (Windows Server, Sharepoint, System Center, etc) still release Service Packs. A few years ago it was rumored that Microsoft would not release Service Pack 3 for SQL Server 2005. A number of us voted on this patch and it was eventually released.

    The strategy announced at that time was that SQL Server would receive a service pack 6 months after the RTM release and thereafter annual service packs until support expired for the product. In between, Cumulative Updates would be released. That seemed to be the case for a few years, but once again Microsoft seems to have quietly decided not to move forward with Service Packs. We’ve been getting cumulative updates, but no service packs in over a year and a half. The last SPs we have are SP1 for 2012 (Nov 2012), SP2 for 2008 R2 (July 2012), and SP3 for 2008 (Oct 2011).

    If you’re like to express your opinion, take a moment and vote for these items:

    It just takes a moment to click on them, and I’d also ask that you pass along the URL (or this editorial) to friends that work with SQL Server.

    Personally I’d also like to see a solid strategy moving forward that includes annual service packs, especially with a 2 year release cycle. I know some of my fellow MVPs and writers like the CU strategy and wish more people would adopt it, but I don’t agree. It’s time consuming to test and prepare for updates, and as long as this paragraph appears on CU pages, I do not think we should recommend CUs to DBAs.

    “This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. The updates in this package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2012 service pack that contains the hotfixes in this package.”

    To me that shows even Microsoft doesn’t completely want to stand behind their cumulative updates.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Mevio . 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. Support this great duo at www.everydayjones.com.

  • Management at Scale

    Would you like to manage 20,000 databases by yourself? What about 20,000 instances? It’s not quite the same thing, but Facebook recently announced that each of their data center operations staff manages 20,000 servers. That’s an impressive number, and it comes about because of lots of standardization, specialized design, and lots of automation.

    If you watch the video, you’ll see that a lot of effort in the Facebook data centers is being paid to gathering and analyzing information. They seem to truly understand that having data about not only their systems, but their processes, is valuable. Maybe more importantly, they understand how to modify the way they work based on data to improve their efficiencies.

    We should do the same thing as DBAs. Perhaps even as developers. We should be monitoring our workflow and looking for ways to improve our effectiveness. We should take advantage of the tools that let us manage systems at larger scales. PBM, third party tools for monitoring and alerting, BIML or SSIS patterns and practices, and more. There are a variety of ways in which we can work more efficiently.

    I thought the best quote in the article was this one: The emphasis on automation is not because Facebook is interested in unmanned data centers, or having robots operate facilities. It’s because Facebook values its workers”. The next quote is “We want to hang onto our talent,” she said. “The way you do that is to give them the opportunity to work on high-value tasks.”

    Those are powerful quotes, and I wish that was how more businesses viewed their workers. To be fair, most workers haven’t proven themselves to be willing to tackle and want the “high value tasks”. All too often I find there are too many workers that want to get their job done, without providing more value than they cost. If they did, perhaps we’d have many more companies that would value their employees, and they could manage systems at something closer to Facebook’s scale rather than the much lower numbers I’ve seen in my career.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and Mevio . 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. Support this great duo at www.everydayjones.com.

  • Common Checks

    One of the things that I recommend to DBAs is that as they write code to solve problems, they write some sort of check to catch future potential occurrences of the issue. For example, I worked with a product years ago that had an identity column as an int, but this product scanned thousands of our systems every 5 minutes, logging each scan. We found that after 8-12 months, we’d run out of identity ranges.

    While we considered changing to a bigint, this was a third party product and they did not want to allow us to alter the schema. Since there were only a few million rows in the table at any one time, we decided to write a check that would alert us when the table came close to running out of integer values. A DBA could then easily reseed the identity property to prevent issues.

    Across my career I’ve found many other instances where we could write checks to find issues before users were impacted. At SQLServerCentral we have checks looking for discrepancies in points awarded, in incorrect status values, and more. These often don’t impact the users of the site, but they are alerts that let administrators know about potential problems before they become issues.

    This week I’m wondering:

    What types of common issues have you found that could be valuable as checks for other DBAs?

    Perhaps looking for delays in replication or Service Broker? Jobs that never stop or never execute for some reason? Memory or space alerts? Do you look for localsystem as a service account? Let us know what checks you’ve written, or which ones you wish were available for you to download and use on your systems.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and Mevio . 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. Support this great duo at www.everydayjones.com.

  • Too Much Choice

    As this piece shows, more information can be bad. As drivers get more choices, options, and opportunities to interact with information, they may not be driving as well as they otherwise might. Restaurants and retailers have seen something similar. Too much information either prevents decisions or slows the process. I know when I go to a restaurant that has too large a menu, I often find myself taking a long time to decide on an item.

    I think this can certainly be a problem for our clients in technology, as we discuss specifications and requirements with them. If we allow clients too many choices, and too many options, it can be hard for them to make a decision, much less understand the implications of their choices. As software professionals, we need to give clients two or three options, but recommend one and explain in a fairly simple manner what the advantages and disadvantages of each solution are.

    Too much choice can also be a problem for us in technology. If we have too many architectural options, we can debate entirely too long. If we have too many requirements, we may be unable to get work done if we can’t focus or distill them all down. If we have too many concerns, we may not find an effective solution because we’re looking for a perfect one. The latter is a situation I find all too often with developers that want a perfect, 100% solution when a 90% one will work fine because the edge cases so rarely occur.

    The exceptions to this, both in my restaurant experience, and in research, are when the person already knows what they want, or they have some preconceived idea. That can be good for us in technology, as we can move quickly when we have some idea of what is needed. However this is a double edged sword as it can lead us to work with tunnel vision, not thinking about the alternatives or possibilities we may face.

    In general I think more information is better than less, but we can’t let the abundance paralyze us from moving forward and accomplishing work.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and Mevio . 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. Support this great duo at www.everydayjones.com.