The first cumulative update for a brand new version of SQL Server is always chock full of interesting bug fixes. Sure, Microsoft tells you to test the new version during the community previews before it goes live publicly, but it’s not enough – the real tire kickers hit after RTM. So it’s nothing new to see really fun bug fixes in a CU1 – buckle up.
CU1 includes fixes for a lot of issues that also affected 2016 & 2017, and we’ve seen those before in other CUs, so I’m only going to focus on the 2019-only bugs here:
- Corruption occurs when Accelerated Database Recovery is disabled
- Error when you try to install 2019 on a low power CPU
- Detect corrupt statistics with CHECKDB’s extended_logical_checks
- SSIS package execution becomes slower (you may need to read this KB article a few times – I’m not saying that because it’s in-depth and detailed, but because it’s so damn short you’re going to think you’re missing something)
- Access violation if you access a temp table across sessions (I’m assuming this means global temp tables)
- Access violation for Memory-Optimized TempDB – also this one and this one and this one and this one and hey maybe you don’t wanna turn this feature on just quite yet
- Access violation when you query sys.dm_db_persisted_sku_features
- Assertion failure for full text indexes on computed LOB columns (wow, who does that? That’s kinda nifty)
- Worker stealing (which is a new good thing) stops working (that’s a bad thing) for encrypted databases
- Worker stealing (good thing) causes an access violation (bad thing) when it hits Resource Governor limits (wow, again, feature interoperability testing is really hard, and my hat is off to Microsoft)
- Data masking of user-defined functions may result in crashes
- New DMV for external authentication – and I bet you want to know what it is, but you know what, you’re not going to get it from this KB article, buddy. (Update after installing CU1: it’s sys.dm_external_authentication, and it has columns for use_identity, credential_id, and certificate_id.)
And lots more. Now, does this mean SQL Server 2019 is ready for its moment in the sun? In the past, you might have been one of those “don’t deploy until Service Pack 1 hits” people, but remember, there are no service packs anymore for SQL Server, so, uh, yeah. Got get ’em, tiger.
5 Comments. Leave new
I’m surprised they haven’t done anything about the hardcoded 1.5gb log truncation when In Memory tables exist.
That’s fun when you have a deliberately small db for something like session or a cache so have max log at 1gb.
Runs fine until you hit the log limit and then, well, the log is full but the errors don’t mention that!
Anyway, sorry, mini-rant over 🙂
We are getting a Non-Yielding Scheduler error which CU1 claims to fix. Admittedly there could be many causes, but it’s pretty frustrating…
We installed and then shortly thereafter removed CU1. ETL packages began to fail with undefined errors or just didn’t load at all. No amount of rebuilding/redeploying fiddling with security helped. Also some of the ETL’s with script components were dumped with the error indicating no binary found for component found. In SSDT most things would work or by running DTEXEC some of the jobs succeeded. So pretty erratic and random.
If this is how CU’s are fixing things then every CU will have to be QA’d before putting into production to make sure everything still functions correctly. This reminds me of the old days when SP’s would introduce nasty side effects. Since 2008 R2 things had been more stable and predictable until 2019.
Brian – ouch! Did you open a support case with Microsoft?
Hi. I have just enabled NVDIMM (DAX mode) log-cache feature in SQL 2016 and it works fine. I have made the same on SQL 2019. And what? On SQL 2019 this feature doesn`t work!