Brought to you by: http://www.biztalk360.com

Proactively monitor the health of your Microsoft BizTalk Server Environments

About the authorGreat experience in BizTalk administration. Awarded with the Microsoft Integration MVP 2013. Providing training and courses for BizTalk administrator’s worldwide. Great knowledge within performance and tuning of BizTalk. Also created a great way to perform health checks of BizTalk environments. Contributing to enhance productivity to other BizTalk administrators around the world with the blog www.biztalkadmin.com.

Document Version Author Reviewed By Release Date

V1.0 Tord Glad Nordahl Sandro PereiraSaravana KumarSteef-Jan WiggersAlexander ThueErik Thue

July 2013

ContentsAbout the author......................................................................................................................... 1Executive briefing....................................................................................................................... 4Purpose of this white paper.........................................................................................................4Limitations of this white paper....................................................................................................4Databases................................................................................................................................... 6

1.1 Sizes of databases..........................................................................................................61.1.1 BizTalkMsgBoxDb.....................................................................................................71.1.2 BizTalkDTADb...........................................................................................................71.1.3 Use tracking to keep statistics.................................................................................81.1.4 Table “DebugTrace”.................................................................................................81.1.5 Table “MessagesInOutEvents”.................................................................................81.1.6 Table “ServiceInstances”..........................................................................................8

1.2 SQL Agent jobs............................................................................................................... 91.3 SQL query times...........................................................................................................111.4 Database Growth and predefined size..........................................................................11

2 BizTalk Servers................................................................................................................... 122.1 Performance Counters..................................................................................................12

2.1.1 PAL......................................................................................................................... 152.2 Throttling...................................................................................................................... 162.3 Thresholds.................................................................................................................... 16

General...................................................................................................................................... 162.4 Event log....................................................................................................................... 172.5 Disk space.................................................................................................................... 17

2.5.1 SQL Servers............................................................................................................172.5.2 BizTalk Servers.......................................................................................................17

2.6 Performance optimizing................................................................................................18Why automatic monitoring isn’t enough...................................................................................18Guidelines................................................................................................................................. 18Conclusion................................................................................................................................. 18References................................................................................................................................ 19Thanks to.................................................................................................................................. 19

Executive briefingBizTalk is a powerful product when it comes to connecting and communicating between systems. Microsoft has over 12,000 clients that run BizTalk Server to connect and transfer data between their systems, including small tasks and larger operations. During the evolution of BizTalk Server, the system has gained a firm hold in companies and is often considered the heart of the entire business. Any unplanned downtime or data loss has a significant impact on the business that it supports; which can involve a monetary loss. Also, any potentials delays can cause critical systems in hospitals to impact the health and care of patients.

Like all large platforms, poor implementation decisions or poor maintenance and monitoring practices can cause bottlenecks in BizTalk Server. Potential problems can occur in a heartbeat or can evolve over time.

Purpose of this white paperThis white paper provides some guidance on how to be proactive and resolve, or avoid, potential problems before they occur. This white paper is dedicated to all types of BizTalk personnel, including architects, developers, and administrators. Most importantly, the goal is to help companies maintain healthy BizTalk environments by being proactive. Not all scenarios described may occur and some scenarios not discussed in this white paper can occur.

Due to the nature and importance of BizTalk Server, settings and best practices can differ from environment-to-environment depending on network, architecture design, versions, message flow, and resources. This white paper discusses the common setup and recommended values, preferably using percent values where possible.

This white paper is not a substitute for monitoring tools like SCOM1 (System Center Operation Manger), BizTalk360, or any other monitoring solutions (http://social.technet.microsoft.com/wiki/contents/articles/5364.biztalk-monitoring-tools.aspx). The goal of the white paper is to provide more information about proactivity in BizTalk.

Limitations of this white paperThis white paper covers message flow proactivity; specifically when the message is picked-up and then delivered to the end system. The following diagram highlights the areas that contain information for proactivity:

1 Microsoft System Center Operation Manager is one of the recommended tools for monitoring your Microsoft infrastructure, including BizTalk.

FIGURE 1

As shown in Figure 1, this white paper contains information regarding the BizTalk environment; it does not include details on how to resolve system errors external to BizTalk. Nor does it include detailed information about elements that can occur; all is kept at a high level. All findings may require more investigation.

Services, applications, the BizTalk Server platform, infrastructure, operating system, and server hardware are discussed. These topics include a guideline so you can expand and build this white paper around your solution.

There are known errors when using BizTalk. These errors are not described in detail but using the methods described in this white paper, you have the resources and knowledge to monitor and check for errors. Any errors seen should be investigated and resolved.

DatabasesThis section contains information about the most common databases used by BizTalk.

1.1Sizes of databasesSQL Server is the driving force behind the BizTalk Server platform. As a result, you must be aware of the database sizes. It is recommended to have at least 15% free disk space. The closer data is saved to the inside of the spindle on the disk, the slower the performance. BizTalk creates numerous disk I\O requests. When global tracking, artifact tracking, and orchestration debugging events are enabled, the communication with the databases increases drastically.

FIGURE 2

As shown in Figure 2, communications for one message instance can be tremendous. When the message is received, the Receive port communicates with the SQL database. The orchestration debugger logs “Orchestration Start and End”, “Shape Start and End”, and “Messages In Out” events. These events provide much of the communication. The Tracking host is also responsible for moving this data to the Tracking database (BizTalkDTADb) and the BAM database (BAMPrimaryImport). To be proactive, it’s important to always make sure that there is enough disk space on the SQL server disks.

If you get close to the inside of the spindle on the disk, BizTalk performance decreases and the databases can continue to grow; which can create a work stoppage. Therefore, it is important to have full control of disk usage and available storage.

1.1.1BizTalkMsgBoxDb The BizTalkMsgBoxDb is the BizTalk Message Box database (also referred to as the hub). The Message Box database transfers and holds all information that goes through BizTalk. The BizTalk Server engine also uses the Message Box database for routing, queuing, instance

management, and various other tasks. To maintain your environment and be proactive, there are several tables to know.

1.1.1.1 The “Spool”, “Parts”, and “Fragments” tablesThe Spool, Parts, and Fragments tables reference all messages that flow through BizTalk; all messages are in these tables at least once. As a recommendation, keep these tables as small as possible to prevent a massive increase of messages in your environment. If you are using de-batching, a message spawns more than once. It is important to make sure that these tables do not grow too large. As more data is stored while increasing the table and database sizes, queries take longer to execute and transaction performance decreases. If the Spool table doubles in size, it can impact latency. In this situation, investigate the issue as there may be a problem with the message flow. In some cases, a slight peak can result in a throttling state and decrease performance.

1.1.1.2 The “TrackingData_x_x” tablesThe TrackingData_x_x tables (where x indicates a number) store tracking information. These tables provide temporary storage while waiting for the Tracking host to move the data:

TrackingData_0_x (where x indicates a number from 0-3): If you are using BAM, temporarily stores BAM tracking events before being moved to the BAM database (BAMPrimaryImport).

TrackingData_1_x (where x indicates a number from 0-3): Temporarily stores tracking events before being moved to the Tracking database (BizTalkDTADb).

If these tables grow, it can indicate a problem with the Tracking host.

As a best practice, there should be one Tracking host per Message Box, including one Tracking host in redundancy. In some large environments, more than two Tracking hosts may be needed to transfer the data to BAM and the Tracking database (BizTalkDTADb). The general rule is if the table size increases more than it decreases for 5 minutes, there is a problem in your environment.

1.1.2BizTalkDTADbThe BizTalkDTADb database is the storage for all tracking for BizTalk (not BAM). This database contains information about the history of your transactions and instances. The database keeps information until it is purged by the DTA Purge and Archive SQL Agent job. Normal setup is 15 days for soft delete and 30 days for hard delete. However these number differ for all companies so only store data for the time you need.

1.1.3Use tracking to keep statisticsOne of the most important tasks of the Tracking database is that it provides a good overview of instances that have processed through your environment. As long as global tracking2 is enabled, you store information of instances and in / out events. This data is valuable to be proactive; it gives you a great overview over the message flow on a daily basis. In addition to providing the number of messages processed through BizTalk, it also gives you information on the best day and time to perform scheduled maintenance.

2 Global tracking is referred to as group-level tracking in the BizTalk Server 2010 administration console. Versions prior to BizTalk Server 2010 have this setting set in the BizTalkMgmtDb database.

If you add custom pipelines, verify that tracking is enabled for instances and in / out events. See Figure 3:

FIGURE 3

By adding information of In and Out events, including instances in, graphs demonstrate how the message count increases and how they increase over time. It gives a clear overview and highlights when and if BizTalk should be scaled out or scaled down. It is also a good way to determine if a specific application has stopped or is no longer in use.

1.1.4Table “DebugTrace”The DebugTrace table in the BizTalkDTADb database contains all information for the Orchestration debugger to work. The DebugTrace table stores information about when an orchestration starts and stops, when shapes start and end, and when messages are sent and received within an orchestration. These tracked events are often referred to as artifact tracking and enabling them is not recommended in a production environment. The DebugTrace table can significantly grow and cause the well-known chain reaction. A large Tracking database slows the Tracking host; which is a sign of difficulty in moving data from the Message Box to the Tracking database. As a result, the Message Box size increases and causes delays for other applications.

When an application is exported from Visual Studio, orchestration tracking is enabled by default. To disable tracking, open the orchestration Properties and click Tracking to view the Tracking options.

1.1.5Table “MessagesInOutEvents”When Global Tracking is enabled, it stores any In and Out events in this table, including communication between other orchestrations within the environment. This table also contains information of when messages are received, the message size, and the message origin. This information is a great way to monitor and follow the addition of transactions in your environment.

If you want to disable global tracking, open the BizTalk Administration console and modify the group Settings. See Figure 4:

FIGURE 4

1.1.6Table “ServiceInstances”The Service Instances table contains information of all instances in your environment. It stores details of when the message came in and published outside of BizTalk. This information is a great way to find problematic applications that hold files too long or run complex orchestrations or maps. This table also grows according to the message flow in the environment. Monitor this table to confirm you do not reach any thresholds; which can affect other applications in the environment.

1.2SQL Agent jobsBizTalk Server 2010 includes 13 SQL Agent jobs that are responsible for making sure BizTalk is performing as expected. The SQL Agent jobs execute at different durations; however, you should pay attention to these jobs as they can indicate potential problems. The default times can differ on different servers.

SQL Agent Job Warning level Description

Backup BizTalk Server If execution time is double the normal execution time.

This job takes the transactional backup of your BizTalk databases and any third-party databases that have been added (the databases may not be on the same instance). Depending on the size of your databases, the average run time can be different. However, when the job takes a long time to finish, it may indicate problems with your databases or that the database sizes are too large. In this scenario, any values that are more than double the average suggest some abnormality that needs investigation.

CleanupBTFExpiredEntriesJob_BizTalkMgmtDb

If execution time is double the normal execution time.

Deletes expired BizTalk framework from the Management database (BizTalkMgmtDb). It also automates the archiving and purging of tracked messages to the Tracking database. The goal is to maintain a healthy system and to keep the tracking data archived for future use.

If the run time exceeds double the average time, it may indicate a problem and needs investigation.

MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb

If execution time is double the normal execution time.

Detects when a host instance has stopped responding. Release the work from the host instance so another host instance can take over. If the job hangs, it may stop data that is

locked on an unavailable host instance.

MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb

If execution time is double the normal execution time.

Removes messages that are no longer referenced by the Message Box. This job also starts the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job.

MessageBox_Parts_Cleanup_BizTalkMsgBoxDb

If execution time is double the normal execution time.

Removes all message parts that are no longer referenced by a message. If run time exceeds twice the time of a regular job run, it should be investigated and monitored.

MessageBox_UpdateStats_BizTalkMsgBoxDb

If execution time is double the normal execution time

Updates statistics for the Message Box database. Updating the statistics is important to maintain the stability in BizTalk. However if the job runs too long, it can cause issues in your BizTalk environment.

Monitor BizTalk Server This job has no impact on BizTalk Performance and therefore has no gain to monitor the timeframe for this specific job. The results can state problems in your environment and any failures should be investigated.

This SQL Agent Job is new to BizTalk 2010. It scans for any errors on the BizTalk SQL Server, like orphaned instances. It does not solve any issues and it has nothing to do with the cleaning and performance of your environment. Monitoring the time this job takes to run has no proactive gains.

Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb

If execution time is double the normal execution time.

Used if there are multiple Message Box databases. The job asynchronously performs operational actions. If this job takes too long, it can indicate some issues with the different Message Box databases. Any time delays should be investigated and resolved.

PurgeSubscriptionsJob_BizTalkMsgBoxDb

If execution time is double the normal execution time.

Purges unused subscription predicates from the Message Box. Build-ups of unused subscriptions in the Message Box can indicate some errors in your environment and should be investigated. Any errors should be resolved immediately.

Rules_Database_Cleanup_BizTalkRuleEngineDb

If execution time is double the normal execution time.

Purges outdated audit data from the Rule Engine database every 90 days. Every third day, it purges old history data (deploy/undeploy notifications) from the Rule Engine database. Build-ups in this database can slow down the response time of the Business Rules Engine (BRE) and cause delays in your BizTalk environment.

TrackedMessages_Copy_BizTalkMsgBoxDb

If running time has any abnormal time the normal running time of this job.

Copies message bodies of the tracked messages from the Message Box (BizTalkMsgBoxDb) to the Tracking database (BizTalkDTADb). One of the more important jobs; message flow is fast, and files build up and consume space quickly. Issues with this job should be resolved immediately.

DTA Purge and Archive If execution time is double the normal execution time.

The DTA Purge and Archive job purges and archives all tracking data in the Tracking database. If this job takes a long time to run, there is an issue. A table or the Tracking database may be too large and cause the job to execute slowly. This can also affect your entire BizTalk environment by causing a chain reaction. The tracking data in the Message Box (BizTalkMsgBoxDb) is not moved to the Tracking database (BizTalkDTADb). As a result, the tables in the Message Box continue to grow; which can cause delays and possibly work stoppage.

1.3SQL query timesLocks in the database can cause difficult scenarios in your environment. It is important to maintain and confirm that the SQL query execution times are within the designated time. SQL Profiler is the best tool to monitor traffic and queries to the SQL Server. SQL Profiler is available under “Performance Tools”. There are also SQL Server-specific counters in the performance counter log that indicate if there are locks.

1.4Database Growth and predefined sizeAs a recommendation, set Auto Growth on the databases’ data and log files to a fixed megabyte (MB) value. This value should be based on the size of your environment and number of messages going through your BizTalk environment. Fast growing disks can indicate a problem and need investigation. Five gigabytes (GB) is considered the normal size of a

Message Box database. A sudden increase by one gigabyte can indicate that something is wrong. Also, predefining the size of the database to the normal size can increase performance. Predefining the database is done by altering the Files settings in the database properties.

2 BizTalk Servers2.1Performance CountersThe BizTalk performance counters provide a lot of live information about your environment. There are many counters dedicated to BizTalk that provide statistical details and possible errors. Errors can be deadlocks, memory problems, or even a throttling state. The following table lists the main performance counters. The performance counters are viewable in Performance Monitor. These counters can be added to your view or written to a data collector set based on your requirements3. Open Performance Monitor by running perfmon.exe, available in the Start menu or the Run option.

Name Subcounter Description

BizTalk: Message Agent Active Instance Count

Database sessions

Database session threshold

Database size

High database session

High database size

High in-process message count

High message delivery rate

High message publishing rate

High Process memory

High System memory

High thread count

In-process message count

In-process message count threshold

Message delivery delay (milliseconds)

Message delivery incoming rate

Message delivery outgoing rate

Message delivery throttling state

Message delivery throttling state

Displays information gathered from the BizTalk Message Agent, including information about thresholds, instances, throttling states, duration, message statistics, and so on.

3 Read more about Performance Monitor at http://technet.microsoft.com/library/cc749249.aspx.

duration

Message delivery throttling user override

Message publishing delay (milliseconds)

Message publishing incoming rate

Message publishing outgoing rate

Message publishing throttling state

Message publishing throttling state duration

Message publishing throttling user override

Physical memory usage (megabytes)

Process memory usage (megabytes)

Service Class ID

Thread count

Thread count threshold

Total batches omitted

Total message delivered

Total messages published

BizTalk: Message Box: General counters

Instances (total number)

MsgBox Dead processes cleanup (purge job)

MsgBox Msg Cleanup (purge job)

MsgBox Parts Cleanup (purge job)

MsgBox Purge Subscriptions job (purge job)

Spool size

Tracked msg body (purge job)

Tracking data size

Tracking spool cleanup

Displays the general counters in the Message Box; including the Spool table size, tracking data, and information about the cleanup jobs and their workflow.

BizTalk: Message Box: Host counters

Host queue – Instance state msg refs – length

Host queue – length

Host queue – number of instances

Displays information about hosts, their number of instances, and lengths in the Message Box.

Host queue – suspended messages – length

BizTalk: TDDS Batches being processed

Batches committed

Events being processed

Events committed

Records being processed

Records committed

Total batches

Total events

Total failed batches

Total failed events

Total records

Displays information about tracking and the movement of tracking data.

BizTalk:Messaging Active Receive Location

Active Receive Threads

Active Send Messages

Active Send Threads

Documents processed (per second)

Documents received (per second)

Documents resubmitted (per second)

Documents suspended

Documents transmitted/batch

ID Process

Pending Receive Batches

Pending transmitted messages

Request/response timeouts

Throttled receive batches

Displays information about active artifacts, documents processed, and batching details.

BizTalk:<adapterName>_Receive / Send adapter

Bytes Received

Bytes Received per second

Deleted retries

Lock failures

Lock failures per second

Message received

Messages received per second

Time to build batch

Displays hosts details regarding send and receive adapters used in your environment.

FIGURE 5: USING REPORT VIEW, THE DATA GATHERED IS MORE USER-FRIENDLY.

2.1.1PAL

FIGURE 6: THIS IMAGE IS THE STARTUP VIEW FOR PAL. CREATED BY CLINT HUFFMAN, MICROSOFT.

PAL4 (Performance Analysis of Logs) is a powerful Windows PowerShell tool. This CodePlex tool is free to download (http://pal.codeplex.com) and free to use. When PAL parses the results collected from the performance counters, there are some questions to answer correctly to return helpful and valid results.

To maintain a proactive environment, it is important to have routines when validating resource usage and the general health of hardware and software. Using Performance Monitor, create a log that runs for a week. Then, use PAL to parse the output. This output provides the general health of your computers.

PAL should not run on any BizTalk production machines since it requires a large amount of memory. Any computer can run the logs, including a non-BizTalk computer.

By using PAL, you have the following benefits:

Consolidated Guidance, central repository of guidance gathered from multiple sources Log File Data Access Layer, using Microsoft Log Parser Analyze More Data Points, data broken down in smaller slices and analyzed individually Dynamically Changing Thresholds, learning environment asking questions Reusable (Open source), code is open source Extensibility of Thresholds, add, edit, or delete thresholds

2.2ThrottlingThrottling states can be overwhelming when you are trying to be proactive5. Throttling is a condition that occurs in BizTalk to prevent a complete disaster. It simply slows down anything affected by the throttling states. Some of the most common throttling conditions occur when the incoming rate exceeds the outgoing rate, or when the Message Box database is too large. Throttling conditions should always be monitored and actions should be taken when it occurs. In some cases, a throttling condition may not interfere with the message flow. For example, throttling can occur for one minute. This can build up and so you need to be aware. Use tools like PAL and Performance Monitor to monitor throttling conditions. If the throttling state exceeds the duration thresholds, the applications that run in the host and the environment should be investigated and reviewed.

2.3ThresholdsWhen BizTalk is installed, the default threshold settings are set; which are sufficient for most applications. The default settings do not provide high throughput or low latency, but in between. If an application is using high memory and continues to use more memory, increasing the Memory Usage counters may be appropriate. Reviewing the application should also be considered to confirm the development was done using best practices and that there are no unnecessary memory allocations.

4 PAL (Performance Analysis of Logs) is a third-party tool located on Codeplex and is originally created by Clint Huffman, Microsoft’s’ tuning expert. (pal.codeplex.com)5 You can read more about throttling in BizTalk at http://msdn.microsoft.com/library/aa559893.aspx.

GeneralThis section covers the general tasks that apply to the BizTalk and SQL servers. Some of these tasks do not affect both platforms but it is important to be aware and to monitor.

2.4Event logThe event log is on the BizTalk and SQL Servers. It logs events, errors, and warnings in your environment. A large amount of information is provided; however not all issues generate errors, warnings, or informational messages in the event log. There are several known bugs that should be resolved or specially controlled and monitored. Errors that show problems with your environment should be investigated and resolved, or logged as a non-critical error.

2.5Disk spaceThere are many different ways BizTalk and SQL disks are split up; one of the most common is high available shares. Even these shares can be slow. There are many types of disks. Depending on the monetary resources spent on storage, the disk speeds vary. Some of the disks used by BizTalk do not require fast speeds, like backup disks; though it is recommended. However there are a few elements that needs and should always have fast disks due to the high disk read and write load.

2.5.1SQL ServersDepending on how BizTalk is used, there are many databases in SQL Server. If BAM is used, there is a set of dedicated databases for BAM. If Business Rule Engine (BRE) is used, there is a database for BRE. Let’s assume there is a standard BizTalk setup without BAM, BRE, or any other additions. The four databases used are BizTalkMgmtDb, BizTalkDTADb, BizTalkMsgBoxDb, and SSODB. These databases perform different actions; however only two of them are known to create numerous disk reads and writes. The BizTalkDTADb is responsible for tracking data and the BizTalkMsgBoxDb is responsible for messages that are processing by BizTalk. Both databases have a set of log and data files. These four locations (two logs and two data locations) should have their own high available, fast speed disks. You can monitor the disk delay on these disks by using Performance Monitor and PAL. If the disks are physical and regular HDD disks, there should always be at least 20% free disk space. The closer to the inside of the spindle, the less it performs. All HDD should be defragged at least once a month.

2.5.2BizTalk ServersBizTalk also requires a lot of disk I\O. The system disk should only be used by BizTalk and the operating system. Pagefile and temp folders should be moved to a dedicated fast running disk. If the BizTalk servers are virtual, you can move the disks to high-speed and available disks. If the BizTalk Servers are physical, make sure both disks are fast disks6. Always monitor the disk I\O using PAL. You can monitor the disk delay on these disks by using Performance Monitor and PAL. If the disks are physical and regular HDD drives, there should be at least 20% free disk space. The closer to the inside of the spindle, the slower the disk performs. All HDD should be defragged at least once a month.

6 Fast disks are referenced several times, and fast disks are measured in the disk read and write speeds.

2.6Performance optimizingThere are several ways to increase performance in your environment. It is recommended to consider all measures. For example, consider real-time scanning by antivirus, number of allowed network connections, network-related issues with TCP ports, receiveTimeout and thread usage with the WCF-SQL, WCF-Oracle, and WCF-Custom adapters, and so on. All should be monitored and maximum values should be updated according to the usage by your environment.

Why automatic monitoring isn’t enoughBizTalk and most companies utilize transactional queries. As a result, monitoring results can very daily, weekly, and so on. This behavior may not cause any problems in your environment. Many different aspects of being proactive can be enhanced by using different monitoring tools, like Microsoft SCOM and BizTalk360. The only way to have complete control of your environment is to read the logs and view the counters. There are no tools that can compete with the manual monitoring and all other aspects that involve being proactive.

GuidelinesCreation of guidelines enhances the usability and supportability of your environment. Add rules for when and why applications can be suspended. This behavior gives an extra advantage during unforeseen problems or failures, like external networks that crash, firewalls that are reset, DNS servers that crash, and so on. When these unforeseen issues occur, the established guidelines help administrators handle these situations to prevent the environment from failing. When handling errors and thresholds, the steps mentioned in this white paper should ensure that you maintain a healthy and proactive BizTalk environment.

ConclusionBeing proactive is more than checking logs and setting up the environment correctly. It also includes making sure that the limits are set appropriately, including the thresholds for hosts, TCP ports, allowed connections to a server or file share, and so on. Create good routines to measure the logs. Create a weekly schedule and understand the impact and the scenarios that can occur in your environment. Note that all environments act differently and the resources on one computer may behave differently on another computer. Split workloads between servers and ensure that the disks can handle the messages processed in your environment. SQL Agents jobs should be monitored and measured. Event logs should be read and understood. Performance logs should be collected and reviewed.

Though these steps can take extra time, it provides you with a better understanding of how BizTalk works and ensuring that BizTalk runs smoothly. BizTalk grows fast. Most companies have one or multiple critical applications used by the business where downtime can cause financial loss. Having a stable and proactive environment is valuable for most companies.

ReferencesPerformance Counters: http://msdn.microsoft.com/library/aa578394.aspxBizTalk Throttling: http://msdn.microsoft.com/library/aa559893.aspxPerformance Analysis of Logs: http://pal.codeplex.com Performance Monitor: http://technet.microsoft.com/library/cc749249.aspx Troubleshooting databases: http://msdn.microsoft.com/library/ee308858%28v=bts.10%29.aspx

Thanks toThanks to the following people for reviewing this white paper:MVP Steef-Jan Wiggers – Motion 10, Netherlands MVP Saravana Kumar – BizTalk360, FounderMVP Sandro Pereira – DevScope, PortugalAlexander Thue – Bouvet AS, NorwayErik Thue – Bouvet AS, NorwayMandi Ohlinger – Microsoft, USA