BizTalk Server 2004 Database Sizing Guidelines
Microsoft Corporation
August 2005
Applies to: Microsoft BizTalk Server 2004
Summary: This document describes sizing considerations for the Tracking (DTA) database in Microsoft BizTalk Server 2004. It explains how to use equations and message variables to determine how large the DTA database will become over a given period of time, and provides specific examples of how to apply the equations.
"Use Message Variables to Determine DTA Size" provides an overview of the entire process. "Track Message Bodies" explains how to account for the size of message bodies in calculations. The remaining topics provide specific instructions for calculating DTA size in different scenarios.
In BizTalk Server 2004, you can use a number of variables to determine how large the BizTalk Server Tracking (DTA) database will become over a given period of time. These variables are:
-
Number of pipelines used
-
Number of orchestrations involved
-
Number of events generated
-
Number of message properties tracked
-
Number of additional messages created
-
Estimated number of messages received in the specified timeframe
While the equation you use to estimate the size of the DTA database is straightforward, you must apply it to each incoming and outgoing message process that uses the BizTalk Server implementation. In other words, you will need to apply this equation for every distinct message scenario and then add up the results to obtain the final estimated database size. In this document we will look at two scenarios. The scenarios are:
-
Receiving a message, transforming the message, and then sending the resulting message
-
Receiving a message, running a business process using the message, and then sending the resulting message.
Both of these scenarios may be present in a BizTalk Server installation, and each scenario generates a different amount of tracking data. The total tracking data generated for the BizTalk Server installation is the sum of all the scenarios.
The following table shows some variables used in the equation.
Table 1 Examples of estimating the size of the DTA database
| Variable | Description |
|---|---|
|
Nserv |
Number of services (number of pipelines + number of orchestrations) |
|
Events |
Number of generated message events |
|
Properties |
Number of message properties tracked |
|
PropSize |
Size (in bytes) of the promoted property (field) |
|
CMsgs |
Number of additional messages created per incoming message |
|
Msgs |
Number of estimated incoming messages in a given time period |
|
MsgSize |
Message size |
|
MsgNum |
Number of messages tracked for each incoming message |
The equation is as follows:
[(Nserv * 252 bytes) + (Events * 182 bytes) + (Properties * CMsgs(40 bytes + PropSize)) * Msgs]/1024/1024 = Data size in MB
This equation calculates only the tracking data generated by the messages and does not include the tracking data generated for the Orchestration Debugger. You must apply this formula to each message process to estimate the size of the DTA database.
If you plan to track the message bodies in the DTA database, then you will also need to account for the size of these bodies in your calculation. Use the following equation:
[Msgs * MsgNum * MsgSize]/1024 = Data size in MB
The MsgNum variable is determined by turning on the tracking features at the port level or at the orchestration level using Microsoft BizTalk Server Health and Activity Tracking (HAT) or BizTalk Explorer. You must apply this formula to each message process as well.
In the following figure, a simple BizTalk Server message passes in and out of BizTalk Server without undergoing any message transformation.
Figure 1 Simple BizTalk Server message - no transformation

Before you apply the formula in the previous section, you will need to gather some facts about this scenario. In this example, we use the following:
-
The message size is 5K.
-
No properties will be promoted.
-
The number of messages you receive in a year is 3.5 million.
-
Tracking is turned on for all events. There are four events in this scenario. The events are:
-
Receipt of message M0
-
Output of message M1 from the receive port
-
Receipt of message M1 by the transmit pipeline
-
Output of message M2 by the send pipeline
-
Receipt of message M0
-
Two additional messages are created in this scenario. Message M0 is the incoming message and is therefore not created by BizTalk Server. Message M1 is the output message from the receive port and M2 is the output from the transmit port. M1 and M2 are created by BizTalk Server.
Applying this information to the formula gives the following:
[(2*252 bytes) + (4*182 bytes) + (0*2(40 bytes + 0) * 3,500,000]/1024/1024 [(504 + 728 + 0) * 3,500,000]/1024/1024 = 4112.24 MB ~ 4.02 GB per year
Messages with a single promoted property
Let's take another look at this example and add one additional fact to the scenario. You want to promote a single field, approximately 10 bytes in size, from the original message. The maximum size of a promoted field is 256 characters, or approximately 256 bytes (512 bytes if the characters are Unicode).
With this additional fact, the equation now appears as follows:
[(2*252 bytes) + (4*182 bytes) + (1*2(40 bytes + 10 bytes) * 3,500,000]/1024/1024 [(504 + 728 + 100) * 3,500,000]/1024/1024 = 4446.03 MB ~ 4.34 GB per year
If you wanted to promote an additional field that is 10 bytes in size, the equation would be:
[(2*252 bytes) + (4*182 bytes) + ((1*2(40 bytes + 10 bytes) + (1*2(40 bytes + 10 bytes)) * 3,500,000]/1024/1024 [(504 + 728 + 200) * 3,500,000]/1024/1024 = 4779.82 MB ~ 4.67 GB per year
As you can see, if you promote a single 10-byte property in this scenario, it will add an additional 333.79 MB ~ 0.33 GB per year to the size of the DTA database.
Promoting two 10-byte properties will add an additional 667.58 MB ~ 0.65 GB of additional space per year to the size of the DTA database.
Messages with message body tracking activated
In this example, let's also assume that you are planning on activating message body tracking. You will need to add the second equation for message tracking, shown in the previous section. The equation will look like the following for this example:
[3,500,000 * 3 * 5KB]/1024 = 51269.5 MB ~ 50.1 GB per year
By adding the results of the two equations, you can estimate that the DTA database will grow approximately 54.44 GB to 54.77 GB per year.
Let's look at an example that includes an orchestration. The following figure displays the entire business process. In this scenario, a message comes into BizTalk Server, is sent through an orchestration, is changed within the orchestration, and is then sent out through a send port.
Figure 2 The BizTalk Server message process

Here are some of the facts concerning this scenario:
-
The message size is 5K.
-
You are not promoting any properties.
-
The number of messages you receive in a year is 3.5 million.
-
Tracking is turned on for all events. There are six events in this scenario:
-
Receipt of message M0
-
Output of message M1 from the receive port
-
Receipt of message M1 by the orchestration
-
Output of message M2 from the orchestration
-
Receipt of message M2 by the send port
-
Output of message M3 by the send pipeline
-
Receipt of message M0
-
Three additional messages are created in this scenario. Message M0 is the incoming message and is therefore not created by BizTalk Server. Message M1 is the output message from the receive port, M2 is the output message from the orchestration, and M3 is the output message from the transmit port.
Applying this information to the formula gives the following result:
[(3*252 bytes) + (6*182 bytes) + (0*0(40 bytes + 0) * 3,500,000]/1024/1024 [(756 + 1092 + 0) * 3,500,000]/1024/1024 = 6168.37 MB ~ 6.02 GB per year
Messages in orchestrations with a single promoted property
Now let's promote a single field in this scenario, as in the earlier example. The promoted property is approximately 10 bytes in size. The equation now looks like this:
[(3*252 bytes) + (6*182 bytes) + (1*3(40 bytes + 10 bytes) * 3,500,000]/1024/1024 [(756 + 1092 + 150) * 3,500,000]/1024/1024 = 6669.04 MB ~ 6.51 GB per year
If you need to promote an additional property that is 20 bytes in size, the formula now looks like this:
[(3*252 bytes) + (6*182 bytes) + ((1*3(40 bytes + 10 bytes) + (1*3(40 bytes + 20 bytes)) * 3,500,000]/1024/1024 [(756 + 1092 + 330) * 3,500,000]/1024/1024 = 7269.86 MB ~ 7.1 GB per year
Messages in orchestrations with message body tracking activated
If you want to accommodate message tracking, the result from calculating the additional space needed is identical to the result in the earlier scenario, or 50.1 GB per year.
In the following figure, you have a message that proceeds through an orchestration, is changed within the orchestration, and is then sent out to several different send ports through a distribution list.
Figure 3 BizTalk Server message that proceeds through an orchestration and is sent out to several different ports

Here are some of the facts concerning this scenario:
-
The message size is 5K.
-
You are not promoting any properties.
-
The number of messages you receive in a year is 3.5 million.
-
Tracking is turned on for all events. There are five events in this scenario:
-
Receipt of message M0
-
Output of message M1 from the receive port
-
Output of message M3 by the send port
-
Output of message M4 by the send port
-
Output of message M5 by the send port
-
Receipt of message M0
Applying this information to the equation gives the following:
[(5*252 bytes) + (10*182 bytes) + (0*0(40 bytes + 0) * 3,500,000]/1024/1024 [(1260 + 1820 + 0) * 3,500,000]/1024/1024 = 10280.61 MB ~ 10.04 GB per year
Messages in an orchestration that are sent out to a distribution list with a single promoted property
In this example, let's promote a single property, approximately 10 bytes in size, as in an earlier scenario. The equation now looks like this:
[(5*252 bytes) + (10*182 bytes) + (1*5(40 bytes + 10 bytes) * 3,500,000]/1024/1024 [(1260 + 1820 + 250) * 3,500,000]/1024/1024 = 11115.07 MB ~ 10.85 GB per year
If you promote an additional property that is 20 bytes in size the equation now looks like this:
[(5*252 bytes) + (10*182 bytes) + ((1*5(40 bytes + 10 bytes) + (1*5(40 bytes + 20 bytes)) * 3,500,000]/1024/1024 [(1260 + 1820 + 550) * 3,500,000]/1024/1024 = 12116.43 MB ~ 11.8 GB per year
Messages in an orchestration that are sent out to a distribution list with message body tracking activated
If you want to accommodate message tracking, the equation will look like the following for this example:
[3,500,000 * 5 * 5KB]/1024 = 85449.2 MB ~ 83.45 GB per year
If you had all three message scenarios present in a Microsoft BizTalk Server 2004 implementation, you would need to add together all of the scenario results to determine the size of the DTA database.
The following table combines the data from the preceding examples.
Table 2 Examples of three message scenarios
| Scenario | Space required, per year, in GB |
|---|---|
|
Simple messages |
4.67 |
|
Messages in orchestrations |
7.1 |
|
Messages in orchestrations sent out to distribution lists |
11.8 |
|
Total |
23.57 |
In addition, if you turn on message body tracking for all three scenarios, you would get the results shown in the following table.
Table 3 Examples with message body tracking for three scenarios
| Scenario | Space required, per year, in GB |
|---|---|
|
Simple messages |
50.1 |
|
Messages in orchestrations |
50.1 |
|
Messages in orchestrations sent out to distribution lists |
83.45 |
|
Total |
183.65 |
This would give you a grand total of 207.22 GB per year growth on the DTA database. This figure does not include any contingency. If you decided to add a contingency of 10 percent to this total, as is recommended, then you should plan on the DTA database growing 227.94 GB per year.
There are other items, such as the shapes used within an orchestration, that also affect the size of the BizTalk Server DTA database.
If the orchestration debugger option is turned on, which it is by default, the status of each shape in the orchestration is saved to the DTA database.
The formula to determine the size needed to track shape status is:
[(# of object shapes + 1) + (# of scopes + 1)] * 2 * 100 bytes
For example, in the following figure, you would use the following formula to determine the DTA size:
((8 + 1) * 2 * 100 bytes = 1800 bytes
Figure 4 Sample orchestration

If you assume that this orchestration processes 3.5 million messages, the additional space needed to track this orchestration would be:
1800 bytes * 3,500,000/1024/1024 = 6008.15 MB ~ 5.87 GB.
You will need to account for each orchestration that has the orchestration debugger set to "on" to get an approximate size for the DTA database.