Recently, I’ve seen on a production environment that we don’t have any information about the Tracked Services Instances since a couple of week. Sometimes on this platform, we’ve got an error 7001 which description is :
BizTalk host BiztalkServerApplication throttled because DatabaseSize exceeded the configured throttling limit
After some research, we’ve seen that beyond a certain threshold, database size throttling will be applied. This threshold is the “Message count in database” setting. By default, this threshold is configured at 50 000 and our platform was not processed a lot of message, so we thought our problem was elsewhere.
Here is the process, the message box contains all the message processed in BizTalk and a SQL Job (TrackedMessages_Copy_BizTalkMsgBoxDb) is responsible to copy the message processed to the BizTalkDTA (Data Tracking) database. This allows the user to query the database without deals with the perf of the MessageBox (ie: BizTalk).
We’ve seen in the history of this job and all seems to be done (no error). The description of this job is the following :
Copies the message bodies of tracked messages from the BizTalkMsgBoxDb database to the Tracking (BizTalkDTADb) database.
Ok but the tracking is composed of tracking data like property , start, end, type of message etc…
All this data (of the message) are transferred to the DTA using TDDS and the Tracking Host defined in BizTalk.A query on the TrackedData table give us a huge result of 550 000 lines while this table have to be close to 0.
SELECT COUNT(*) FROM [BizTalkMsgBoxDb].[dbo].[TrackingData]
Indeed, the tracked host did not realize his job. And the TrackedMessages_Copy_BizTalkMsgVoxDb job purge this data only when the data were transfered.
So I realize that the Tracking host could have a problem. And I realize the following operations :
- Create a new host (BizTalkServerTracking) with the property : Allow Host Tracking to true
- Remove the property : Allow Host Tracking of the previous responsible host (BizTalkServerApplication) (in this order because
- one instance must have this property to true.
- Create a new host instance for the BizTalkServerTracking Host.
- Start the previous Host Instance.
After this, the number of message has decreased in the TrackingData table and the informations were available on the BizTalk Administration Console.
EDIT : This problem seems to be present on the platform migrated previously from BizTalk 2009 to 2010 where the BizTalk engine and the SQL Server are installed on separated server.
Pingback: Biztalk Tracking data not visible « Ravindar, Biztalk Developer and Administrator