SQL Server – Do I Need Service Packs for Security Patches?

service-packsql server

It's always been my belief that SQL Server needs to be updated to the latest service pack in a timely (and tested) manner to continue receiving security/bug patches.

I'm now partially responsible for a 2008 R2 DB that has not had any service packs installed. The external IT company mainly responsible for maintaining it has told me that they don't install service packs unless there is a specific business need, and that it would automatically recieve security patches any way. Is this the case, or do you need to keep up-to-date (once tested) with the latest service pack?

Best Answer

It's always been my belief that SQL Server needs to be updated to the latest service pack in a timely (and tested) manner to continue receiving security/bug patches.

You are correct. Some service packs will continue to have new CUs until their lifetime runs out.

... and that it would automatically recieve security patches any way.

They either didn't understand how this worked or flat out lied to you.

Is this the case, or do you need to keep up-to-date (once tested) with the latest service pack?

You'll need the latest SP + Patches. For example, since you're on RTM... you're missing quite a few different security patches because they weren't made for the RTM branch after it went out of support*.

*Note that the links above show the same security updates released for supported service packs at the time. However, RTM was not one of them.

Related Solutions

Sql-server – How to pull a list of applied service packs and cumulative updates from SQL Server 2008 R2

Cumulative updates are exactly that, cumulative. CU2 for example contains all of the fixes included in CU1. As such, the only SP or CU that matters is the last one to be applied which you can determine with:

SELECT @@VERSION

and Google or a reference list of SQL Server versions. SQLServerBuilds is the popular unofficial list, KB321185 is the official list.

I'm not aware of any way to obtain a complete list of all patches that have ever been applied to an instance. It's likely buried in the registry somewhere but I haven't fished for it.

SQL Server – Best Practices for Cumulative Updates

I am a big advocate of keeping up to the date with the most recent cumulative update, but only if your testing/QA cycle can ensure full and proper regression testing against it. Glenn Berry of SQLskills is also a proponent of this approach.

Microsoft's own recommendation is to only apply CUs that fix issues that affect you, though they have loosened that stance recently. The problem is that you may be affected by one or more of those issues and not know it, or you might be affected tomorrow even if it hasn't hit you yet. Are you going to go through and try to reproduce the issue behind every single fix in every single CU for your branch? Are you going to do this continuously to make sure you still aren't affected?

I'll be quite honest: I've never had an issue applying any CU to my instances. And in fact their CU release process has been a lot more reliable than the service pack release cycle, and in many cases (including most recently with SQL Server 2012 Service Pack 2), you don't want to apply the service pack until the first CU for that branch has been released anyway. In this case there is an interim hotfix to resolve the issue that wasn't fixed in time to make the Service Pack code, but that isn't always true.

Best Answer

Related Solutions

Sql-server – How to pull a list of applied service packs and cumulative updates from SQL Server 2008 R2

SQL Server – Best Practices for Cumulative Updates

Related Question