Separating Database Servers from BizTalk Servers

One powerful option for increasing the performance of a BizTalk installation is to use dedicated SQL Server machines, separate from the BizTalk Server machines. To design a multiple-server configuration, you need to understand how BizTalk Server uses databases and how the document-processing workload is distributed among those databases.

Databases Used by BizTalk Server

Four types of databases are used by BizTalk Server, with differing degrees of 1-to-N or M-to-N relationship allowed between database instances and BizTalk Server instances:

• Messaging Management database (default name InterchangeBTM)— Defines all BizTalk Messaging objects for a BizTalk server group. Must be shared by all BizTalk servers in the same group. (Server groups are explained in next section of this chapter.)

• Shared Queue database (default name InterchangeSQ)— Persists all received documents until successfully processed. Contains Scheduled, Work, Retry, and Suspended queues for a BizTalk server group. Shared by all BizTalk servers in the same group.

• Document Tracking database (default name InterchangeDTA)— Contains copies of incoming and outgoing documents along with selected data fields and time stamps for tracking document flow. Also shared by all BizTalk servers in the same group.

• Orchestration Persistence database (default name XLANG)— Used to store state data for BizTalk Orchestration schedules (which may need to run for days or weeks before completing). This can be a separate database for each individual BizTalk server or can be shared among servers in any combination.

Recommended Division of Database Workload

For low-volume BizTalk Server installations (or for a development system), it is permissible to host BizTalk Server and all the SQL Server databases on a single machine. However, the recommended configuration for a production BizTalk installation includes at least three server machines: one BizTalk Server machine and two SQL Server machines. (Web services and mail services for HTTP [Hypertext Transfer Protocol] and SMTP [Simple Mail Transfer Protocol] document transport generally should be hosted on additional separate machines.)

The reason for two separate SQL Server machines is that the Shared Queue database is heavily read and written by the BizTalk servers. All documents received are written to the Shared Queue database, and all documents to be processed are read from there. Similarly, full copies of both received and sent documents are written to the Document Tracking database. To avoid the database services competing with each other for resources, or competing with BizTalk services, each of these two databases should be located on its own separate SQL Server machine.

The performance requirements for the other two BizTalk Server databases are not so stringent. The Messaging Management database is written to only during development or administration (creating or deploying Messaging objects, defining BizTalk server groups, and configuring individual BizTalk servers). During operations, Messaging Management information is cached on individual servers and is read from the database only to refresh the cache (every 50 seconds by default). Because the Messaging Management database is written so infrequently—and therefore does not often write to its transaction log—it can be conveniently hosted on the same machine that hosts the Document Tracking database.

Depending on the number, complexity, and duration of your BizTalk Orchestration schedules, the Orchestration Persistence database will experience a low to moderate amount of database traffic. Unlike the other three BizTalk database types, this database can be configured separately for each individual BizTalk server. It makes the most sense initially to host the Orchestration Persistence database on the same machine as the Shared Queue database and to use the same database for all BizTalk servers in the server group. If you expect a large workload, or if performance evaluation reveals the need (see “Monitoring BizTalk Server for Performance” later in this chapter), you can install additional SQL Server machine(s) to host Orchestration Persistence.