Breaking News: SQL Server 2019 CU2 Breaks Agent.

That's it, I'm rolling back to SQL Server 6.5

That’s it, I’m rolling back to SQL Server 6.5

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.

Previous Post
Updated First Responder Kit and Consultant Toolkit for February 2020
Next Post
SQL ConstantCare® Population Report: Winter 2020

21 Comments. Leave new

  • […] Breaking News: SQL Server 2019 CU2 Breaks Agent. (Brent Ozar) […]

    Reply
  • Chris Howarth
    March 2, 2020 7:12 am

    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.

    Reply
    • Brian Jensen
      March 9, 2020 4:26 am

      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.

      Reply
  • Oh Dear™

    Reply
  • 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.

    Reply
  • 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.

    Reply
  • 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.

    Reply
    • 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.

      Reply
  • 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

    Reply
  • In our case, it needed a Windows server (2019 ) reboot and SQLAgent worked again as it should

    Reply
  • 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.

    Reply
  • 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?!

    Reply
  • 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….

    Reply
  • New agent jobs are executing, but our Operators for Database Mail are not receiving any emails.

    Reply
  • 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)

    Reply
  • 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

    Reply

Leave a 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.

Menu
{"cart_token":"","hash":"","cart_data":""}