Sql-server – SQL Server Version – are hotfixes for previous versions implied

sql server

tl;dr: If I identify an SQL Server as having build X, and find out that X implies hotfix Y, does it also imply that all hotfixes listed for versions below X are installed? Or that only the hotfix for build X is installed?

I found the following list of Microsoft SQL Server version numbers and their meaning in terms of service packs, hotfixes, product versions, etc.:

SQL Server Version Database @ sqlsecurity.com

My question is best illustrated with an example, an excerpt from that list:

2005 RTM+Q915793        9.00.1502  <-- interested in this
2005 RTM+Q910416        9.00.1500
2005 RTM+Q932557        9.00.1406

In the above list, if I find out that the SQL Server I am connected to is version 1502, does this imply that:

only hot-fix Q915793 is installed?
or that all of hot-fixes Q915793, Q910416 and Q932557 are installed?

ie. does the build imply that all previous hotfixes are installed?

Follow-up bonus question: Is this a fixed pattern for all the versions, or are there exceptions to the rule?

Best Answer

All hotfixes are cumulative unless otherwise stated.

Random pick, http://support.microsoft.com/?Kbid=971409

Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2005 fix release. Microsoft recommends that you consider applying the most recent fix release that contains this hotfix.

The "otherwise stated" is like these examples where you have some dependencies (sorry. bit old, for SQL Server 2000 and SP4). http://support.microsoft.com/?Kbid=941203 and http://support.microsoft.com/kb/959420

Related Solutions

Sql-server – Which SQL Server product does version 622 represent

622 is an internal intermediate version, never released. How come you have an 622 version DB? The explanation is simple actually: an aborted upgrade. Look at the sequence Aaron posted:

Converting database 'x' from version 611 to the current version 655. 
Database 'x' running the upgrade step from version 611 to version 621. 
Database 'x' running the upgrade step from version 621 to version 622. 
Database 'x' running the upgrade step from version 622 to version 625.

If the last step above crashes, your database is a version 622 now (each step commits). This version can only be attached to a SQL Server 2008 (or newer) to continue and finish the upgrade. It seems to me you had a SQL Server 2005 DB (v. 611) you attached to a SQL Server 2008 or higher, it started to upgrade but the upgrade failed at step 622->625 and now you're trying to attach it back to the SQL 2005 instance. It can't be re-attached, your only chance is to try to move forward. If the upgrade continue to fail, you will have to start again from an original SQL 2005 database (a copy of the files, a backup...).

Why would a database upgrade fail? Same reason any operation can fail: CTRL-C, power outage, corrupted original database, hardware problems, bugs in the product. Knowing what the upgrade step 622-625 does, my moneys are on a corrupted source DB. Recovering from a failed upgrade is a bit more tricky. As usual, having a good, tested, backup and restore strategy pays off.

SQL Server – Are Version Numbers Inclusive with Hotfixes?

Unless you have access to the log files for every cumulative update install, the only thing you would know is #3:

Hotfix 9.00.3182 has definitely been applied, there simply isn't enough information available to determine if the other 2 have been applied or not.

Cumulative updates are, well, cumulative. So are the builds within a CU branch. So 9.00.3182 will contain the fixes from 3179, 3178, 3165, 3122, 3068, etc. Microsoft used to release certain critical fixes individually, but now they have almost completely stopped doing that, opting for a ~60 day Cumulative Update delivery model (security fixes excepted).

The challenge comes when you pass a service pack boundary. There are cases where a fix is released in a cumulative update right before a service pack is released. The service pack code path was frozen at least 60 days earlier (since SPs go through more rigorous testing/regression etc). So, the service pack - even though released later - is missing fixes that won't be in that branch until the first cumulative update for that service pack. This is why you will often see a CU released out of band, almost immediately after a service pack is released.

Then, of course, there is the situation where multiple branches are being maintained, and multiple CUs come out for the lower service pack. There will be fixes there which weren't even known issues when the newer service pack was released.

This means that in many cases a newer build (say, 2005 SP4, 9.00.5000) is missing fixes from cumulative updates for SP3 (say, CU15, which was released several months after SP4). All of those fixes are usually also available in subsequent CUs for the later service pack, but just looking at version number alone wouldn't really tell you that unless you knew which fixes you are trying cross-reference. You'd need a database for that, not a numeric/string compare.

You're kind of playing with fire here, anyway. You're running SQL Server 2005, and not even on the most recent service pack. Unless you have gone through extended support, you are completely on your own. In fact 2008 and 2008 R2 both hit end of mainstream support in about 60 days.

My philosophy is to always be on the absolute latest service pack for any version I am running, and unless there is something prohibitive, always be on the latest CU for that service pack as well. So, rather than worry about whether the fixes for 3179 or 3178 were installed independently, I'd focus more on getting onto a more modern build (SP4 + MS12-070, putting you at 9.00.5324), or a more modern version (and one that isn't about to sunset).

Best Answer

Related Solutions

Sql-server – Which SQL Server product does version 622 represent

SQL Server – Are Version Numbers Inclusive with Hotfixes?

Related Question