我们有一个用于BizTalk的VM和一个用于SQL后端的单独VM。我们使用Veeam进行备份，基本上开始了VM的快照。在SQL VM上完成此快照时，应用程序服务器上的BizTalk服务将失败。通常它们会自动重启，但有时需要手动干预才能启动服务。下面的错误记录在BizTalk服务器上。
是否存在允许BizTalk服务在快照过程中保持运行的超时设置或配置更改？
发生错误，需要BizTalk服务终止。最常见的原因如下： 1）意外的内存不足错误。 要么 2）无法连接或失去与其中一个BizTalk数据库的连接。 该服务将在1分钟内关闭并自动重启。如果有问题的数据库仍然不可用，则此循环将重复。
错误消息：[DBNETLIB] [ConnectionRead（recv（））。]常规网络错误。检查您的网络文档。 错误来源：
BizTalk主机名：BizTalkServerApplication Windows服务名称：BTSSvc $ BizTalkServerApplication
答案 0 :(得分：2)
我们遇到了与BizTalk 2009和BizTalk 2013相同的情况和错误，每个都设置了两个App服务器和一个SQL DB服务器。
当我们的VMware在应用程序服务器上执行快照备份的最后一步时，它会冻结应用程序服务器大约10秒钟，从而阻止它接收数据包。在SQL Server 2008和2012上，它默认情况下每隔30秒（30,000 ms）向客户端发送保持活动数据包。如果SQL服务器无法从App服务器收到响应，它将发送保持活动请求的1次重试（默认设置）1秒（1,000毫秒）。如果SQL仍然没有收到响应，它将终止连接，这将导致App服务器上的BizTalk主机重置，在我们的例子中，当我们的德国制造的ERP系统在此期间将其EDI文档发送到BizTalk时重置期间，传输将失败。
我们通过在DB和App服务器上运行NetMon来等待下一条错误消息，从而解决了这个问题。经过检查，我们看到五个SQL保持活动数据包相隔1秒发送到App服务器，同时在应用服务器上收到的数据包完全没有。最初猜测，人们可能会认为他们只是丢弃网络数据包＆＃34;，这种情况很少发生。然后我们将相关性与VM快照的时间相关联，现在确认每次快照完成每天，应用服务器冻结。
作为一种短期到中期的解决方法，我们通过添加注册表值TcpMaxDataRetransmissions并将其设置为30（因此在30秒之前），在声明连接失效（默认为5）之前提高了SQL尝试的重试次数。 SQL声明客户端没有响应）。这暂时掩盖了我们的问题，并由您自行决定使用。
我们还在查看基于代理的VM快照版本，这可能会缓解冻结服务器的状况。
答案 1 :(得分：1)
是否存在允许BizTalk服务在快照过程中保持运行的超时设置或配置更改？
不是我知道，但您可能需要位于BizTalk安装目录中的 btsntsvc.exe.config 文件中的Google配置选项。
通过BizTalk传递的所有邮件都写入BizTalkMsgBoxDb，如果您正在运行跟踪，BAM等，则涉及其他数据库。唯一可以缓存“东西”并处理数据库中断的服务是企业单点登录（ESSO）服务。因此，BizTalk需要与数据库服务器的持久连接才能保持“正常”状态，因此您的主机实例（BizTalkServerApplication）正在停止 - 如果数据库不在那里，它将无法处理消息。
我想补充一点，你的备份方法可能不受微软的支持，我还会建议你认真考虑在备份过程中使数据库服务器脱机的方法是否可行？
BizTalk为其内置于产品中的各种数据库提供了非常强大的备份解决方案，我建议您查看使用此支持的方法。
如果您确实需要拍摄数据库系统的快照 - 比如每晚一次 - 您可能需要考虑停止BizTalk主机实例，执行快照，然后通过某些脚本任务重新启动主机实例。
您可能还需要考虑检查累积更新中包含的BizTalk Server版本是否有任何可能有助于解决问题的修补程序。