我们正在将客户从 SQL Server 2012 环境迁移到 2019。
我一直在尝试让日志像在旧环境中一样发送和运行，但我不断遇到错误。
我得到的第一个错误是在辅助服务器上的还原作业中：
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)
如果你用谷歌搜索，它会引导你到一个页面，建议修复是安装累积更新 2：https : //support.microsoft.com/sq-al/help/4537869/fix-log-shipping-agent-is-not -能够记录历史和错误信息
我尝试安装它，但立即开始注意到一个问题，当您打开作业活动监视器时，作业列表未加载，并且您收到一条错误消息，其中包含文本“无法检索此请求的数据”。您也无法为受影响的服务器执行诸如编辑日志传送计划之类的操作。在受影响的服务器上重新启动 SQL Server 代理之前，什么都不会起作用。如果检查作业历史记录，可以看到在 SQL Server 代理停止期间没有运行任何计划任务。SQL Server 代理似乎没有完全崩溃，这在某种程度上是一种耻辱，因为在这种情况下它应该重新启动。
搜索此错误会将您带到 dba.stackexchange.com 页面，该页面描述了相同的问题，唯一的解决方案是卸载 CU2。
我尝试卸载 CU2，但立即返回到原始错误消息。
这让我相信 SQL Server 2019 中的日志传送被破坏了。
真的有人成功使用过吗？
您是否遇到过这些问题中的任何一个并设法解决它们？
我应该在 2019 年考虑镜像还是复制，还是 Log Shipping 仍然是可接受的热备份解决方案？