BizTalk 2009 累积更新 2 安装问题答案

【问题标题】：BizTalk 2009 Cumulative Update 2 installation problemsBizTalk 2009 累积更新 2 安装问题
【发布时间】：2011-07-19 14:22:15
【问题描述】：

早在四月份，我就在我们的开发环境中安装了 BizTalk 2009 CU 2 修补程序。所有本地（开发人员机器）安装都成功并且没有问题。但是，我们的 QA 服务器安装存在一些我们似乎无法解决的问题。

为了提供一些背景知识，我们的 QA BizTalk 服务器环境是 Windows Server 2003 R2 Standard SP2，运行在 VMware 下的六核 AMD Opteron 2435 上。 BizTalk 数据库位于 BizTalk 服务器外部的 SQL Server 2008 盒子上。配置了多个 BizTalk 主机，每个主机在 QA 框上都有一个主机实例。

安装此修补程序后我们遇到的问题是，我们的跟踪主机实例在大约 5 分钟内使服务器 CPU 使用率达到 100%，然后主机实例关闭。主机实例将在一分钟后自行重启，然后将 CPU 再次峰值 100% 持续 5 分钟，无限期地重复该循环。正如您可以想象的那样，当处理器处于峰值时，服务器上无法运行其他任何东西。

我们尝试使用不同的名称删除并重新创建跟踪主机实例，但问题仍然存在。我们尝试第二次安装修补程序无济于事。唯一可行的解决方案是关闭主机实例，使其无法运行。

还有其他人遇到过这个问题吗？我能做些什么来解决它？

提前致谢！

【问题讨论】：

标签： biztalk biztalk-2009 biztalk-deployment

【解决方案1】：

您尝试过MsgboxViewer 吗？可能积累了大量的孤立实例。

大多数数据库（Msgbox、DTA 等）都可以使用 BizTalk Terminator 解决，它与 MsgboxViewer 协同工作。

您是否修改了此主机实例上的任何高级（性能）设置？

【讨论】：

我会试一试，然后告诉你。
抱歉，更新之间的延迟很长，但我需要抽出时间专门调查此问题。
我可以使用 MsgboxViewer 来识别几个启用了跟踪的接收端口，所以我禁用了它们。然后，我能够使用 BizTalk Terminator 查看 msgboxdb 的 TrackingData_x_x 表中存在大量消息。我使用“bts_CleanupMsgbox”存储过程来清空 msgboxdb 表，重新启动主机实例，现在一切似乎都在正常工作。感谢您的建议！
很高兴听到它对你有用。既然你提到了bts_CleanupMsgBox：你检查过你的 SQL 代理作业吗？如果您没有配置“DTA 清除和存档 (BizTalkMsgBoxDb)”，您可能会再次遇到麻烦。
是的，现在所有 SQL 代理作业都已配置。有一段时间他们没有正确配置，所以我猜测积累的过多消息是该作业未启用的直接结果。