Voice of the DBA

Tag: patching

  • Reasonable Timeframes

    Many of us hear about problems with various systems on a regular basis. We report them in Database Weekly far too often, and I’m sure a few of you have been informed (or found) bugs, nagging issues, even vulnerabilities in your systems.

    What’s a reasonable time to fix a system after an audit?

    It’s a simple question, but it’s not very simple to answer. After all, most of us don’t have a lot of slack development time built in to fix issues. Unless the issue is a broken application that doesn’t work, the items disclosed in an audit need to scheduled in among other work. After all, most of the time the audit finds something that no one is aware of, or no one has wanted to fix. This is work that no one really planned on completing.

    I ran across an interesting piece about the Employment Department for the state of Oregon hasn’t fixed a number of issues after an audit last year. While some strides have been made, there are still outstanding issues, the sum total of which it is estimated will take a decade to complete. That’s a long time, but in large systems, especially ones where the entire application cannot be rewritten because of resources, it’s not unusual. I’ve worked in a few places where we had large scale systems that we knew had issues, but we couldn’t easily re-design and implement fixes in any reasonable length of time. Often this was because of downstream dependencies, but certainly culture and management hadn’t made change a priority.

    I sympathize with those people dependent on mainframe systems. The power and reach of those systems, the poor documentation, not to mention the complex training required to change clients’ habits is huge. I would hope that the government groups using these large scale systems would work together to jointly proceed on development, with politicians also involved to help standardize the requirements across state lines (or countries’ borders) and simplify the software needed.

    However, no one ever makes software simpler, especially when it’s being designed.

    The Voice of the DBA Podcast

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

  • The Service Pack Fiasco

    I remember getting a Service Pack years ago that caused a blue screen of death on Windows 2000 servers when it was installed. In fact, a quick search shows that quite a few operating systems (and SQL Server 2005) have had issues with SP2 over the years. Perhaps we shouldn’t be waiting for the first service pack to upgrade, but upgrading and then skipping SP2 for various products.

    Microsoft has responded fairly well to problems with service packs by removing them quickly from their download sites and re-releasing them. This occurred recently for SQL Server 2014 SP1, where an issue was discovered with the SSIS Catalog. This is disconcerting to me, not because of the bugs, but because these mistakes and problems seem to lead Microsoft in the direction of abandoning Service Packs. The idea floated in the past, and still pushed by many people, is that the Cumulative Updates are good enough for patching SQL Server.

    That seems crazy to me. If we have problems with a service pack, wouldn’t we still have problems with a CU? Or is Microsoft hoping that the smaller group of people that are impacted with CU issues are good beta testers and limit the impact of issues to the community? I’m assuming the testing is similar for all patches, if not the same. However as we all know, testing can’t cover every possible scenario. Microsoft notes this as their latest documentation includes these quotes:

    I really prefer that a service pack is released every year for each product. It can contain all the CUs up to that point, with no additional patches, thought hopefully a bit more testing. It should be a line in the sand that helps administrators manage their systems to keep up with patching and reduce support requirements. I’d actually even suggest Microsoft require vendors that want to certify their products on SQL Server and use any logo, validate their software on an SP within four months of release. In most cases, there isn’t any work for vendors, merely the effort to re-run all their tests.

    We pay a large licensing cost for SQL Server, and the lifecycle support policy under which many of us purchased our software notes that we’ll get ten years of support and the term “service pack” is embedded throughout the SQL Server support pages. We should receive a service pack every year to provide continuing support for our platforms.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Final Service Packs

    There was an announcement recently that Service Pack 3 for SQL Server 2008 R2 was released. This is the final SP for that version and is mostly a rollup of all the previous cumulative updates (CU), though there are a couple additional items included.

    This is good news, and if you are running the “R2” version, I’d test this and install it. No more CUs will be released, though you’ll want this SP installed in case additional security patches are released during extended support. The last thing you’ll want is a crisis situation where you need to install a security patch based on SP3, and you haven’t tested this update.

    Earlier this year, Microsoft announced that we’d get one last SP for both SQL Server 2008 and 2008 R2. That was good news as many people are running these versions, and they haven’t installed all the previous CUs. I can understand this situation, and it would be good to bundle all the changes together in one final patch for companies that find the platform suits their needs. It’s also a fair request for customers that paid Microsoft for  a platform and should receive all patches developed during its lifecycle. Including a final patch that closes out support.

    I’m still waiting for an SP4 for SQL Server 2008 and I hope we get one soon. I’m not sure what the plans are for SQL Server 2012, 2014 and future releases, but I’d like to continue to see the bi-monthly CUs, an annual SP, and a final SP when each version transitions from mainstream to extended support.

    Steve Jones

    UPDATE: SQL Server 2008 SP4 was released just after this was written. It is available here: http://www.microsoft.com/en-us/download/details.aspx?id=44278

    The Voice of the DBA Podcast

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

  • MS14-044–Security Alert for SQL Server

    I just saw this, but you should be aware. There’s a potential Denial of Service/Elevation of Privilege bug in SQL Server. Here’s the bulletin:

    MS14-044

    There are QFE and GDR patches for versions since 2008, but you need to read carefully to determine which one to install on your systems.