We're in the process of migrating a customer from a SQL Server 2012 environment to 2019.
I've been trying to get the log shipping up and running as it was in the old environment but I keep coming up against errors.
The first error I get is in the restore job on the secondary server:
2020-02-25 16:04:04.77 Skipped log backup file. Secondary DB: 'DB_Name', File: 'E:\LogShipping\DB_Name_20200225154501.trn'
2020-02-25 16:04:04.77 Error: Could not log history/error message. Microsoft.SqlServer.Management.LogShipping)
2020-02-25 16:04:04.77 Error: Failed to convert parameter value from a SqlGuid to a String.(System.Data)
2020-02-25 16:04:04.77 Error: Object must implement IConvertible.(mscorlib)
If you google that, it leads you to a page suggesting the fix is to install cumulative update 2: https://support.microsoft.com/sq-al/help/4537869/fix-log-shipping-agent-is-not-able-to-log-history-and-error-informatio
I tried installing that but immediately started noticing an issue where when you open Job Activity Monitor, the list of jobs does not load and you get an error message including the text "Failed to retrieve data for this request". You also cannot do things like edit Log Shipping schedules for servers affected. Nothing will work until you restart SQL Server Agent on the affected server. If you check the job history, you can see that no scheduled tasks run during the time that SQL Server Agent is stalled. SQL Server Agent doesn't appear to crash completely which is a shame in a way, because it should re-start itself in that case.
Searching for this error leads you to a dba.stackexchange.com page describing the same issue with the only resolution being uninstalling CU2.
I tried uninstalling CU2 but am immediately back to the original error message.
This leads me to believe that Log Shipping is broken in SQL Server 2019.
Is anyone actually using it successfully?
Did you come across either of these issues and manage to resolve them?
Should I be looking at mirroring or replication instead in 2019, or is Log Shipping still an acceptable warm-standby solution?
