You reported it here in the comments, and over at SQLServerUpdates, and in this DBA.StackExchange.com question.
The official word is in: yep, SQL Server 2019 Cumulative Update 2 breaks Agent jobs on some servers, causing them not to run.
That official word is only in that linked post, though: there’s still no word in the official CU2 page about the bug, nor does the CU2 bug fix list even mention SQL Server Agent, so we were all pretty surprised that Agent would break when it wasn’t even supposedly changed in this CU.
For now, the official word is to uninstall CU2 if you’re experiencing the issue.
23 Comments. Leave new
[…] Breaking News: SQL Server 2019 CU2 Breaks Agent. (Brent Ozar) […]
I’ve found that scripting the jobs then deleting and recreating them prevents the issue recurring, at least it does on the 10 instances of SQL Server 2019 I’ve upgraded so far.
I asked MS about this, since we experienced that also.
They said that it MAY work as a temporary fix, but certain conditions may still lead the agent to fall into the faulty code path again.
Oh Dear™
I installed CU2 because log shipping doesn’t work properly on the vanilla install. CU2 was Microsoft’s fix for the issue. And now CU2 breaks the SQL server agent so …….. log shipping doesn’t work. Damned if I do and damned if I don’t.
I totally feel you, exact same issue here and saw your posting on StackExchange. Does anyone know when CU3 is planned to be published?
Microsoft told me it would be at the end of this month
Thanks a lot for your quick reply!
Its out as of today! https://support.microsoft.com/en-us/help/4538853/cumulative-update-3-for-sql-server-2019
Best, Kay
FYI, the bug introduced in CU2 with xp_sqlagent_enum_jobs is now understood and a fix will ship in CU3. Meanwhile, if you’re hitting this issue, revert back to CU1. We apologize for any inconvenience we may have caused.
Using LinkedServer or OPENDATASOURCE in a scalar udf raises “Select permission denied error”.
You must Alter function WITH INLINE = OFF or ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF; or set db compability level below 150.
Whoa, querying other SQL Servers inside a scalar user-defined function is a really, really bad idea in terms of performance. I’d strongly, strongly recommend against that.
There’s now a warning here not to install this update “if” you use SQL Server Agent: https://support.microsoft.com/en-us/help/4536075/cumulative-update-2-for-sql-server-2019
MS’s advice to me in the meantime was not to try and update agent jobs, or not to use Log Shipping!
Apparently CU3 should be out at the end of the month so we’re implementing an scheduled restart of the Agent service so that we can actually use Log Shipping until CU3 is out
In our case, it needed a Windows server (2019 ) reboot and SQLAgent worked again as it should
Although SQL Server 6.5 might just be out of support now, you’d have to roll back to the sweetness that was NT 4, so it won’t be all bad.
Okay, I’ve Googled to no avail, so I’ll bite. Was Microsoft SQL Workstation a misjudged rebranding of SQL Server that only lasted for the 6.5 release?
Why is the box so big?
Show me the box. WHAT’S IN THE BOX?!
Books! Lots and lots of books.
Makes me question the whole advice along the lines of “it’s now OK to install CU’s as soon as they’re released, they’re fully regression tested”!
No Service Packs since SQL 2017. Maybe the sensible thing to do is let the “other guy” install it first, then watch and wait….
New agent jobs are executing, but our Operators for Database Mail are not receiving any emails.
We are still having issues after installing the latest version: CU4 for SQL Server 2019
In our case, we are running on a Ubuntu 18.04.4 LTS installation.
After a complete Server reboot SQLAgent starts working as it should, but this is not a solution.
Does anyone else have a fix or also experience this problem after intalling the CU4 update?
Logging SQL Agent:
[382] Logon to server ‘(local),1433’ failed (JobManager)
[298] SQLServer Error: 258, TCP Provider: The wait operation timed out. [SQLSTATE 08001]
[165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00]
[298] SQLServer Error: 258, A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. [SQLSTATE 08001]
[382] Logon to server ‘(local),1433’ failed (JobManager)
For anyone who runs into the same problem we fixed this by adding the hostname (with and without domain) in the /etc/hosts files.
For more information see step 1 in the following link: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-sql-agent?view=sql-server-ver15
Lordy… MS keeps proving the old adage of “Change is inevitable… change for the better is not”.
BWAAA-HAAA!!! At least they’ve stopped breaking the no-long-supported versions! 😀
I know this is an older post but was reviewing the “hit parade” for 2020 and just wanted to say “Man! Thank you for what you do, Brent!”
How much $ is Microsoft sql workstation 6.5 big box New worth? Sealed in package. I found one at my local thrift store.