BizTalk 2009累积更新2安装问题

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

为了提供一些背景信息，我们的QA BizTalk server环境是运行在VMware下的六核AMD Opteron 2435上的Windows server 2003 R2标准SP2。BizTalk数据库位于BizTalk Server外部的SQL Server 2008框中。配置了多个BizTalk主机，每个主机的QA框上都有一个主机实例

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

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

还有其他人经历过这个问题吗？我能做些什么来修复它

提前谢谢

你试过了吗？可能积累了大量孤立实例

大多数数据库Msgbox、DTA等都可以使用与MsgboxViewer协同工作的工具来解决

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

是否尝试过？可能积累了大量孤立实例

大多数数据库Msgbox、DTA等都可以使用与MsgboxViewer协同工作的工具来解决

---

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

我会尝试一下并让您知道。很抱歉更新之间的延迟太长，但我需要抽出时间专门调查此问题。我能够使用MsgboxViewer识别启用跟踪的两个接收端口，所以我禁用了它们。然后，我可以使用BizTalk终止符查看msgboxdb中TrackingData_x_x表中有大量消息。我使用bts_CleanupMsgbox存储过程清空了msgboxdb表，重新启动了主机实例，现在一切都正常工作。谢谢你的建议！很高兴听你这么说。既然你提到了bts_CleanupMsgBox：你检查过你的SQL代理作业了吗？如果未配置DTA清除和归档BizTalkMsgBoxDb，则可能再次遇到问题。是的，所有SQL代理作业都已配置。有一段时间它们没有正确配置，所以我猜累积的邮件数量过多是该作业未启用的直接结果。我会尝试一下并让您知道。很抱歉，更新之间的延迟太长，但我需要抽出时间专门调查这个问题。我能够使用MsgboxViewer识别启用了跟踪功能的几个接收端口，所以我禁用了它们。然后，我可以使用BizTalk终止符查看msgboxdb中TrackingData_x_x表中有大量消息。我使用bts_CleanupMsgbox存储过程清空了msgboxdb表，重新启动了主机实例，现在一切都正常工作。谢谢你的建议！很高兴听你这么说。既然你提到了bts_CleanupMsgBox：你检查过你的SQL代理作业了吗？如果未配置DTA清除和归档BizTalkMsgBoxDb，则可能再次遇到问题。是的，所有SQL代理作业都已配置。有一段时间它们没有正确配置，所以我猜累积的消息数量过多是该作业未启用的直接结果。