My current client is one of the retail giants in UK. During the Christmas period, their numbers of business transactions are always very heavy. So, all of their IT applications will face heavy load during October - December period. As part of preparing for that period, the peak readiness activity will start in their initial part of the business year which starts from February. I have been employed to prepare their integration services applications to handle their projected high business transactions during Christmas. Many ideas were discussed for the integration applications which uses BizTalk server. One of them is, empowering the existing BizTalk servers inventory with more servers for scalability and reliability. The scalability of the BizTalk Server databases can be achieved by adding multiple Messagebox databases. The reliability for the BizTalk Server databases can be achieved by using clustered server mechanism. In this post, I am going to discuss about using multiple Messagebox databases in a BizTalk Server group.
First, we will see when we need to use multiple MessageBox databases.
We use the multiple MessageBox databases, when we have
- More database transactions which increases the Messagebox database size and results in lesser performance. For example, when the number of messages to the MessageBox is more.
- Heavy message interactions which is database-intensive and results in lesser performance. For example, if the messages interact with the MessageBox are heavy in size.
The MessageBox database performs three main functionalities. They are:
- Evaluate subscriptions.
- Message publication.
- Save the message state.
So when we decide to add multiple MessageBox databases, our intention should be to distribute the functionalities to multiple databases/servers rather than sharing these functionalities with multiple databases/servers. We will see more detail of this in the following section.
When we add the first MessageBox database to the BizTalk processing servers using the Configuration Wizard, we need to make this MessageBox database as Master MessageBox database. Master MessageBox database is one of the MessageBox databases in your BizTalk Server group which holds the master subscription information, performs the subscription evaluation functionality of the MessageBox and routes the messages to the appropriate MessageBox databases for active message publication. Yes, Master MessageBox database doesn't perform the message publication. It only performs the "Evaluate subscriptions". This is done by disabling the new message publication in the Master MessageBox database.
![clip_image001[4]](http://lh6.ggpht.com/_ok7aDIm08kc/SSiatAbduRI/AAAAAAAAAR4/g1YecEu12nE/clip_image00144.gif)
Figure 1: Disabling new message publication for Master MessageBox Database.
A Master Messagebox database can receive two types of messages:
- A new activation message.
- An active instance's message/Correlation message.
Master MessageBox database with new activation message:
When the new activation message received by the Master MessageBox, after evaluating the subscription the Master MessageBox database distributes the activation message to the next available MessageBox database(secondary). When you have more than one secondary MessageBox database, Master MessageBox database uses it own build-in logic for load balancing the message for the publication with secondary MessageBox database.
![clip_image002[3]](http://lh3.ggpht.com/_ok7aDIm08kc/SSdfjsm5JBI/AAAAAAAAASA/NL7kYpdmLP0/clip_image00234.gif)
Note: Secondary MessageBox databases are the MessageBox databases which are other than Master MessageBox database in your BizTalk Server group. Though "Secondary" is not the official term, it is used to refer the non-Master MessageBox databases in the group.
Master MessageBox database with Correlation message:
When the correlation message is received by Master MessageBox database, it performs the lookup operation in the database for the secondary MessageBox databases that contains the state for the correlation message. And it distributes the message instance to the secondary Messagebox database which is waiting for this message. In this case, the Master MessageBox database doesn't perform round-robin pattern for message distribution. Rather it distributes to the specific secondary MessageBox database which is already expecting for this message from Master MessageBox database.
During dehydration, the Orchestration engine stores the in-memory representation of the Orchestration, its associated messages and state in the secondary MessageBox database which activated its instance.
Ok, we have decided to add multiple MessageBox databases in the BizTalk Server group. But how many is "multiple"? A minimum of 3 MessageBox databases (as recommended by Microsoft) for a BizTalk Server group. Out of these one should act as the Master MessageBox database (needs to disable the message publication on this MessageBox database) and other two should act as the secondary MessageBox databases. This recommendation is made because additional MessageBox databases incurs overhead by the Master MessageBox database for routing between the MessageBox databases. If you have only two MessageBox databases for a BizTalk Server group then most of the benefits gained by the additional MessageBox database is offset by the overhead consumed by the Master MessageBox for message routing. You have another option of using 2 MessageBox databases both performing the subscription evaluation and message publication with your own load balancing logic. In this case distributed transactional consistent with the MessageBoxes cannot be achieved, and hence this method should not be implemented.
So it is always
Master MessageBox database + n- Secondary MessageBox databases.
Another colleague of mine asked can we have multiple MessageBox databases in the same server. Yes, we can have this, but ensure that the existing database server has enough CPU and I/O resources and is bottlenecked only by the lock contention. In most of the enterprises situation this may not be the case. So by adding the secondary MessageBox database on the same physical server can cause server-intensive problems rather than solving the overhead problems involved in the high and heavy message transactions with the MessageBox database server. So it’s always advisable and better to use Messagebox databases in a separate server. For reliability use both the Master and Secondary MessageBox databases in the Clustered server environment.
![clip_image003[4]](http://lh3.ggpht.com/_ok7aDIm08kc/SSdflImnJDI/AAAAAAAAASI/4x9a3fF_2e8/clip_image00345.gif)
Since we have started our peak readiness activity much before the Christmas peak time, we had a sufficient time to test the new BizTalk Server group with multiple MessageBox databases in terms of performance and scalability. So thorough testing of your updated server infrastructure is vital in achieving the desired result.
