Hundreds of thousands of years of humans roaming the earth.
Countless scientific discoveries. The wheel. The light bulb. Handerpants.
It’s all led up to this exact moment: SQL Server 2016 SP2 Cumulative Update 12. If, like me, you like SQL Server to keep running, then you’ll probably want to pay attention:
- SQL Server can shut down when you hit the max number of sessions
- SQL Server can shut down due to lock conflicts during error message processing
- “SQL Server crashes frequently” when you check a clustered columnstore index for corruption
- AGs may have “interruption” – I’m guessing that means the AG stops replicating, but it’s not clear from the KB article. This particular article wins this CU’s prize for The Vaguest And Most Dangerous Article. Congratulations!
- Stack dumps when transaction replication has a heavy workload on the publication database
- Stack dumps when you query persisted computed columns
- Stack dumps when you run a batch mode query with multiple joins (that’s columnstore indexes in 2016)
- Scalar functions run slower than they did on SQL Server 2008 R2
- Non-yielding scheduler when the primary AG replica runs low on memory
- AG may think there’s a missing log block when the database isn’t very active
- AG automatic seeding may fail
- AGs with persistent log buffers: “all of the secondaries in the AG become unavailable”
- Change tracking auto cleanup causes access violations and stack dumps
- Access violations when Extended Events tries to capture query text on busy servers
- Error when stored proc in database A pulls data from database B while being audited in database C
- Stack dumps when you alter database-scoped configurations
- Incorrect statistics histograms when they’re updated in parallel – which also means that after you apply this CU, you should probably update your statistics.
There’s also a new feature: the default system health Extended Events session can store way more data now, AND you can edit how much it holds!
Lots of good stuff in there. All of human evolution has been poised for this moment. Now is your time to shine: go get ’em.
4 Comments. Leave new
I get Stack Dumps after installing CU12. Is anyone experiencing the same issue? I’m still figuring out which line of code forces this to happen. Uninstalled CU12 and our code run without problems.
* BEGIN STACK DUMP:
* Location: tmpilb.cpp:3462
* Expression: fNoReaderWriterConflict
Error: 17066, Severity: 16, State: 1.
SQL Server Assertion: File: , line=3462 Failed Assertion = ‘fNoReaderWriterConflict’.
When you get a stack dump, open a support case with Microsoft right away. They can analyze the dump to tell you what’s causing it.
Don’t waste time or play around here: these are serious business. You might be dealing with corruption, or you may be dealing with a bug that causes corruption.
Thanks, Brent! Will do like you say.
fyi: after this CU the hyperlinks for SSRS are case-sensitive. Regression from an earlier bug. Confirmed by Microsoft support, will be fixed in the next CU. Which is still not out…