Export (0) Print
Expand All
4 out of 4 rated this helpful - Rate this topic

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:

  1. Receiving a message, transforming the message, and then sending the resulting message
  2. 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

Aa475431.Local_1344986740_simple_bts_msg_new(en-US,BTS.10).gif

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
  • 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

Aa475431.Local_1955311327_biztalk_server_message_process_new(en-US,BTS.10).gif

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
  • 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

Aa475431.Local_-512423400_biztalk_server_message_orch_multiple_ports_new(en-US,BTS.10).gif

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

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

Aa475431.Local_579068356_sample_orchestration_new(en-US,BTS.10).gif

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.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.