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.

Today I want to talk to you about two small optimizations often forgotten but with performance implications. Some of these implications may be noticed more in the early days of our BizTalk environment when the databases are small or almost empty and often need to increase, others can have impact later when databases are large and the percentage increase is also too large.

By default BizTalk Server databases are defined with small files size and with the parameter “Autogrowth” set to:

• Increase by 1 MB for database file
• And by 10% for log file

There’s a great post from Jeroen Hendriks: Checking database autogrowth settings where it is explained howwe can check allBizTalk Server database settings using an SQL query and also Database file size - data collection so that we can recommend the right values.

One of the responsibilities of a BizTalk admin is to ensure that BizTalk performs according to business requirements. One of the aspects that can impact performance is hyper-threading. Hyper-threading is a technology that makes the server appear to have more processor cores than it actually has. It seems logical that more cores will give the server a better performance. However, it is not as simple as it seems. Some applications suffer from performance loss when hyper-threading is enabled. BizTalk Server is among the applications which encounter performance loss from hyper-threading. The Microsoft document “General Guidelines for Improving Operating System Performance” states that the overall performance will decrease when hyper-threading is enabled. This is because of the self-tuning algorithms within BizTalk (for more information see: http://msdn.microsoft.com/en-us/library/ee377075.aspx).

I had a discussion with some of the other bloggers (Sandro Pereira, Lex Hegt, Steef-Jan Wiggers and Tord Glad Nordahl) on this website about initial file sizes for BizTalk databases. This discussion was based on the following article:

http://www.biztalkadminsblogging.com/index.php/item/66-checking-database-autogrowth-settings

Yesterday I was performing a Health Check at a client. One of the checks is looking at the database autogrowth settings. In the operations guide Microsoft states the following about the BizTalk database autogrowth settings:

Pre-allocate space for BizTalk Server databases and define auto-growth settings for BizTalk Server databases to a fixed value instead of a percentage value

If you give the host instance where your file adapter is running under modify rights on a file location that a receive port is using that port will fail to start. You will see the following error in your log:

Depending on whether your BizTalk environment is multiple-server or stand-alone environment, you can use domain users or local users. If you have a multiple-server configuration, then you must use domain groups and domain accounts. BizTalk Server supports local groups and user accounts only in single-server (standalone) configuration. In this example I will talk about a multiple computer configuration. For more information about which groups are necessary in BizTalk and how to create them, follow this link: http://msdn.microsoft.com/en-us/library/aa577661.aspx

I recently published an article on TechNet Wiki explaining how to install Microsoft BizTalk Server 2010 on a basic multi-server. However, when I was analyzing my BizTalk environment with BizTalk Server Best Practice Analyser tool, has appeared a warning that caught my attention:

Privilege Attribute Certificate (PAC) Signature Validation is Enabled on Server BTS2010LAB01.
On server BTS2010LAB01, Privilege Attribute Certificate (PAC) signature is enabled, which may cause some user-authentication delay

And led me to go deeper in trying to see what was causing this strange issue and I found a number of TCP settings that needs to be done (or is recommended) which can also prevent from occurring general network errors on BizTalk Server Environments.