SQLServerUpdates.com
  • Home – Most Recent Updates
    • SQL Server 2019 Updates
    • SQL Server 2017 Updates
    • SQL Server 2016 Updates
    • SQL Server 2014 Updates
    • SQL Server 2012 Updates
    • SQL Server 2008 R2 Updates
    • SQL Server 2008 Updates
  • Download SQL Server
  • Subscribe to Updates
  • Contact Us
    • Frequently Asked Questions

Announcing SQL Server 2019 Cumulative Update 1

3 years ago
Brent Ozar
SQL Server 2019, Updates
5 Comments

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.

Brent Ozarhttp://sqlserverupdates.com
I make Microsoft SQL Server faster and more reliable. I love teaching, travel, and laughing.
Previous Post
New SQL Server 2017 CU18 and 2016 SP2 CU11
Next Post
Announcing SQL Server 2017 CU 19

5 Comments. Leave new

  • Rob
    January 8, 2020 10:23 am

    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 🙂

    Reply
  • Brent Leslie
    January 14, 2020 7:58 pm

    We are getting a Non-Yielding Scheduler error which CU1 claims to fix. Admittedly there could be many causes, but it’s pretty frustrating…

    Reply
  • Brian D
    January 29, 2020 11:35 am

    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.

    Reply
    • Brent Ozar
      January 29, 2020 11:37 am

      Brian – ouch! Did you open a support case with Microsoft?

      Reply
  • Jakub
    February 13, 2020 3:40 am

    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!

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Subscribe

Want to get an email when Microsoft publishes a new SP or CU for SQL Server? Subscribe here.

Recent Updates

  • SQL Server 2022 Gets Its 2nd Update in 2 Days February 16, 2023
  • SQL Server 2022 Gets Its First Update! Plus 2019, 2017, 2016, 2014 Updates February 14, 2023
  • Announcing SQL Server 2019 CU15 January 27, 2022
  • Announcing SQL Server 2019 CU13 and SSMS 18.10: Replication Improvements October 5, 2021
  • Announcing 2016 Service Pack 3 and 2017 CU26 September 15, 2021

© 2021 Brent Ozar Unlimited®. All Rights Reserved. Privacy Policy