2

Back in April, I installed the BizTalk 2009 CU 2 hotfix in our development environment. All local (developer machine) installations were successful and have no problems. However, our QA server installation is having some problems that we cannot seem to rectify.

To provide some background, our QA BizTalk server environment is Windows Server 2003 R2 Standard SP2 running on a six-core AMD Opteron 2435 under VMware. The BizTalk databases are housed on a SQL Server 2008 box external to the BizTalk server. There are several BizTalk hosts configured, each with a single host instance on the QA box.

The problem we're having after the installation of the hotfix is our tracking host instance spikes the server CPU usage to 100% for about 5 minutes, then the host instance shuts down. The host instance will restart itself after a minute, then spike the CPU to 100% again for 5 minutes, repeating the cycle indefinitely. As you can imagine, nothing else can run on the server while the processor is spiking.

We tried deleting and recreating the tracking host instance with a different name but the issue persists. We tried installing the hotfix a second time to no avail. The only solution that works is shutting down the host instance so it can't run.

Has anyone else experienced this issue? What can I do to fix it?

Thanks in advance!

dramatix01
  • 65
  • 7

1 Answers1

0

Did you give MsgboxViewer a try? Maybe a huge amount of orphaned instances accumulated.

Most database (Msgbox, DTA, etc.) can be solved using BizTalk Terminator which works hand in hand with MsgboxViewer.

Did you modify any advanced (performance) settings on this host instance?

Filburt
  • 17,626
  • 12
  • 64
  • 115
  • I'll give these a shot and let you know. – dramatix01 Jul 20 '11 at 21:01
  • Sorry for the very long delay between updates, but I needed to find the time to dedicate to investigating this issue. – dramatix01 Aug 19 '11 at 21:18
  • I was able to use MsgboxViewer to identify a couple of receive ports that had tracking enabled, so I disabled them. I was then able the use BizTalk Terminator to see that there were a large number of messages stuck in the TrackingData_x_x tables in the msgboxdb. I used the "bts_CleanupMsgbox" stored proc to empty the msgboxdb tables, restarted the host instance, and everything seems to be working as it should now. Thanks for the suggestions! – dramatix01 Aug 19 '11 at 21:23
  • Nice to hear it did work out for you. Since you mention `bts_CleanupMsgBox`: Did you check your SQL Agent Jobs? If you didn't configure "DTA Purge and Archive (BizTalkMsgBoxDb)" you could run into trouble again. – Filburt Aug 22 '11 at 08:27
  • Yes, all the SQL agent jobs are configured now. There was a time that they weren't configured properly, so I'm guessing that the excessive number of messages that accumulated were a direct result of that job not being enabled. – dramatix01 Sep 27 '11 at 18:11