Adventures in SQL Server 2019: Microsoft updates the update that broke the update

I don't know why she swallowed the fly...

There was good news for administrators of Microsoft's SQL Server 2019 last night as Cumulative Update 8 emerged, fixing the borkage of its predecessor.

Things haven't been going well for the SQL Server 2019 servicing model: Cumulative Update 2 left the SQL Agent a bit unhappy (resulting in the company advising users to skip the patch if they were using the afflicted component). And most recently Cumulative Update 7 suffered from a "known issue" with database snapshots, which also affected that little-used command DBCC CHECKDB.

Cumulative Update 8 arrived with little fanfare and, like its predecessor, applies to both the Linux and Windows incarnations of Microsoft's database engine. Those who applied the previous borked update and have hit the server with the CREATE DATABASE ... AS SNAPSHOT OF syntax will need to recreate that snapshot before applying number 8.

Microsoft is naturally keen that administrators slap on its sticking plasters as soon possible, declaring that each contains all the fixes (but hopefully not the cock-ups) of those that have gone before and all "are certified to the same levels as Service Packs, and should be installed at the same level of confidence".

In the case of SQL Server 2019's Cumulative Updates, confidence levels may not be particularly high at this stage since two of the eight were subsequently subject to hurried "for the love of God, don't install this one!" warnings from the Windows giant.

This is a shame because the updates are generally packed full of handy fixes. A notable one in CU8 deals with a severe spinlock contention issue afflicting those running on high-end hardware with a high number of concurrent users.

However, despite Microsoft's insistence that customers should opt for "ongoing, proactive installation of CUs as they become available", anyone pondering the update of production systems would do well to consider the company's final bit of advice: "We recommend that you test SQL Server CUs before deploying to production environments."

This is in addition to hitting F5 a few times on the CU knowledgebase page just in case, you know, a big yellow box showing the equivalent of "Argh! It burns! It burns" turns up. ®


Similar topics


Send us news

Other stories you might like