One of the SQL jobs created during the configuration of BizTalk is the DTA purge and archive job. This job purges tracking data from the tracking database (BizTalkDTADb). By default it also archives this data to disk. To do this the job calls the stored procedure dtasp_BackupAndPurgeTrackingDatabase.

However, most of my customers do not use the archived data and just remove it periodically.

Some time ago I wrote a blogpost on how to enforce your tracking strategy:

http://www.biztalkadminsblogging.com/index.php/item/84-enforce-your-tracking-strategy-with-a-powershell-script

I did this because one of my customers had a tracking strategy stating that by default all tracking in the production environment should be disabled. The problem was that it was difficult to enforce this strategy. New applications were put into production with tracking enabled or tracking was enabled for troubleshooting reasons never to be disabled again. The only method they had to enforce this strategy was to manually check the tracking settings. Since they have a lot of artifacts this took about an hour of clicking (and was extremely boring).

The is a new version of this script. You can find it here:

http://www.biztalkadminsblogging.com/index.php/item/99-new-version-enforce-your-tracking-strategy-with-a-powershell-script

One of my customers has a tracking strategy stating that by default all tracking in the production environment should be disabled. The problem is that it is difficult to enforce this strategy. New applications were put into production with tracking enabled or tracking was enabled for troubleshooting reasons never to be disabled again. The only method they had to enforce this strategy was to manually check the tracking settings. Since they have a lot of artifact this took about an hour of clicking (and was extremely boring).

Here are some best practices tips on the usage of tracking for Biztalk:

• Determine the information you need to track during planning : You should decide during the planning stages which information you need to track, so that after you deploy the project you can set the tracking options and limit the amount of tracked data to give you only the information you need.
• Do not track all messages: We recommend that you not track all messages, because each time a message is touched, BizTalk Server makes another copy. You can instead narrow the scope by tracking only a specific port. This helps to maximize the performance of your system and to keep the databases uncluttered.
• Set tracking on send ports and receive ports instead of on a pipeline: If you set tracking options on pipelines, you will also set the tracking options globally for every port that uses the pipeline. This in turn may result in far more data being tracked than you intend, which will slow system performance. Instead, you can set tracking options on send ports and receive ports.
• Take into account various factors when you size the BizTalk Tracking database:
  • When sizing the BizTalk Tracking database, account for SQL Server factors, such as index size, by adding a contingency multiplier to your calculations.
  • When determining the size of messages in the BizTalk Tracking database, add the average size of the message context to the message size if it is significant compared to the message size.
  • To limit the size of messages in the BizTalk Tracking database, limit the number of properties that you promote. You should only use promoted properties if you need them for routing purposes, otherwise use distinguished fields.
  • If the orchestration Shape start and end option is enabled, take into account that a start and stop event for each shape in each orchestration instance is saved in the BizTalk Tracking database.

Also some additional best practices tips for message and instance data tracking can be found on http://technet.microsoft.com/en-us/library/aa559344.aspx