A community of more than 1,600,000 database professionals and growing

There are plenty of reasons not to upgrade your SQL Servers to a new version. Perhaps you know the system is working and don't want to disrupt activity. Often we don't want to take a chance that some change in functionality causes us issues. In many cases, the new functionality might not be used in your current system, and you don't see the ROI for the cost of upgrades. Costs certainly are a concern as SQL Server has gotten more expensive across time. In all these cases, it makes sense to stay on your current version. Software Assurance might negate the upgrade cost in money, or even give you a reason to upgrade, but it doesn't prevent any of the other time and resource costs.

Patches don't cost money, however, and they are included in your cost. While I am nervous about applying patches right away, I do want to apply them at some point. If for no other reason, I do want to ensure I'm going to get into a position where I have to apply a patch to fix something or get support in an emergency and not have done any testing. I am more nervous now after the recent Windows Fall Update issues, and definitely want to let others test patches for a month or two before I apply them. Thanks to those of you that patch early and report issues.

The exceptions I make here about avoiding patches are for older versions of SQL Server. If I've got systems that are out of mainstream support, I want them patched. At that point, only security patches are coming and if I get those, I need to apply them, which means I need to be sure all other patches are in place.

Apparently many of you think like me, but not enough of you. I ran across a post from Erik Darling looking at a cross section of their customers, who I'd like to think are slightly more on the ball than everyone else, but perhaps not. In any case, lots of SQL Server 2008 and SQL Server 2012 systems haven't been patched, with R2 and 2014 not far behind. While I know some vendors make patching difficult for SQL Server DBAs, we ought to be pressuring them more and more, and even asking our management to do the same.

We ought to be patching systems on a regular basis. That's a part of the software life cycle and until we find ways to write bulletproof software, we're going to be patching. Microsoft is in the same situation as most of us, which is why they deliver patches regularly for SQL Server. They need to patch their Azure databases and ensure they are prepared for security issues.

Make a plan to test these patches on your systems and start implementing it. None of us wants to be caught in a situation where we have to apply a security patch to an older server next week and we have no plan for how to test the application. Perhaps even worse, none of us wants to have a data breach because we were afraid to apply a security patch *because* we didn't have a test plan.

Join the debate, and respond to today's editorial on the forums

The transactions/sec counter does NOT count SELECT statements run in autocommit mode: that is, statements that do not have an explicit transaction wrapped around them (BEGIN TRAN .... COMMIT, etc.)

Oddly enough, this isn't true for modifications. If you run an update statement in autocommit mode, for example, it will be reflected in the counter.

» Discuss this question and answer on the forums