Download Proactivity in BizTalk Server - Center

Proactively monitor
the health of your
Microsoft BizTalk
Server Environments
Brought to you by:
http://www.biztalk360.com
About the author
Great 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 Pereira
Saravana Kumar
Steef-Jan Wiggers
Alexander Thue
Erik Thue
July 2013
Contents
About the author.............................................................................................................................................. 1
Executive briefing ............................................................................................................................................. 3
Purpose of this white paper ............................................................................................................................ 3
Limitations of this white paper ........................................................................................................................ 3
Databases ......................................................................................................................................................... 4
1.1
2
Sizes of databases ............................................................................................................................. 5
1.1.1
BizTalkMsgBoxDb......................................................................................................................... 5
1.1.2
BizTalkDTADb ............................................................................................................................... 6
1.1.3
Use tracking to keep statistics .................................................................................................. 6
1.1.4
Table “DebugTrace” .................................................................................................................. 7
1.1.5
Table “MessagesInOutEvents” .................................................................................................. 8
1.1.6
Table “ServiceInstances”........................................................................................................... 9
1.2
SQL Agent jobs ................................................................................................................................... 9
1.3
SQL query times ............................................................................................................................... 11
1.4
Database Growth and predefined size ....................................................................................... 11
BizTalk Servers ........................................................................................................................................... 12
2.1
Performance Counters ................................................................................................................... 12
2.1.1
PAL .............................................................................................................................................. 15
2.2
Throttling ............................................................................................................................................ 16
2.3
Thresholds.......................................................................................................................................... 16
General ............................................................................................................................................................ 17
2.4
Event log ........................................................................................................................................... 17
2.5
Disk space ......................................................................................................................................... 17
2.5.1
SQL Servers ................................................................................................................................ 17
2.5.2
BizTalk Servers ............................................................................................................................ 17
2.6
Performance optimizing ................................................................................................................. 18
Why automatic monitoring isn’t enough .................................................................................................... 18
Guidelines ........................................................................................................................................................ 18
Conclusion....................................................................................................................................................... 18
References ...................................................................................................................................................... 19
Thanks to .......................................................................................................................................................... 19
Executive briefing
BizTalk 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 paper
This 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 paper
This 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:
Microsoft System Center Operation Manager is one of the recommended tools for monitoring your
Microsoft infrastructure, including BizTalk.
1
F IGURE 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.
Databases
This section contains information about the most common databases used by BizTalk.
1.1 Sizes of databases
SQL 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.
F IGURE 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.1 BizTalkMsgBoxDb
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” tables
The 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 debatching, 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” tables
The 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.2 BizTalkDTADb
The 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.3 Use tracking to keep statistics
One 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.
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.
2
If you add custom pipelines, verify that tracking is enabled for instances and in / out events. See
Figure 3:
F IGURE 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.4 Table “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.5 Table “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:
F IGURE 4
1.1.6 Table “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.2 SQL Agent jobs
BizTalk 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.
CleanupBTFExpiredEntries
Job_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_DeadProce
sses_Cleanup_BizTalkMsg
BoxDb
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_M
If execution time
Removes messages that are no longer
anageRefCountLog_BizT
alkMsgBoxDb
is double the
normal execution
time.
referenced by the Message Box. This job also
starts the
MessageBox_Message_ManageRefCountLog_Bi
zTalkMsgBoxDb job.
MessageBox_Parts_Clean
up_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_UpdateStat
s_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_OperateOnIn
stances_OnMaster_BizTal
kMsgBoxDb
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_Bi
zTalkMsgBoxDb
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_Cleanu
p_BizTalkRuleEngineDb
If execution time
is double the
normal execution
Purges outdated audit data from the Rule
Engine database every 90 days. Every third day,
it purges old history data (deploy/undeploy
time.
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.3 SQL query times
Locks 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.4 Database Growth and predefined size
As 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 Servers
2.1 Performance Counters
The 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
Displays information gathered from the BizTalk
Message Agent, including information about
thresholds, instances, throttling states, duration,
message statistics, and so on.
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
duration
Message delivery throttling user
3
Read more about Performance Monitor at http://technet.microsoft.com/library/cc749249.aspx.
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)
Displays the general counters in the Message
Box; including the Spool table size, tracking
data, and information about the cleanup jobs
and their workflow.
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
BizTalk: Message Box: Host counters
Host queue – Instance state msg refs –
length
Host queue – length
Host queue – number of instances
Host queue – suspended messages –
Displays information about hosts, their number
of instances, and lengths in the Message Box.
length
BizTalk: TDDS
Batches being processed
Batches committed
Displays information about tracking and the
movement of tracking data.
Events being processed
Events committed
Records being processed
Records committed
Total batches
Total events
Total failed batches
Total failed events
Total records
BizTalk:Messaging
Active Receive Location
Active Receive Threads
Displays information about active artifacts,
documents processed, and batching details.
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
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.
F IGURE 5: USING REPORT VIEW, THE DATA GATHERED IS MORE USER -FRIENDLY .
2.1.1 PAL
F IGURE 6: T HIS 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.2 Throttling
Throttling states can be overwhelming when you are trying to be proactive 5 . 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.3 Thresholds
When 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.
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.
4
General
This 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.4 Event log
The 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.5 Disk space
There 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.1 SQL Servers
Depending 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.2 BizTalk Servers
BizTalk 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.6 Performance optimizing
There 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 enough
BizTalk 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.
Guidelines
Creation 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.
Conclusion
Being 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.
References
Performance Counters: http://msdn.microsoft.com/library/aa578394.aspx
BizTalk Throttling: http://msdn.microsoft.com/library/aa559893.aspx
Performance 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 to
Thanks to the following people for reviewing this white paper:
MVP Steef-Jan Wiggers – Motion 10, Netherlands
MVP Saravana Kumar – BizTalk360, Founder
MVP Sandro Pereira – DevScope, Portugal
Alexander Thue – Bouvet AS, Norway
Erik Thue – Bouvet AS, Norway
Mandi Ohlinger – Microsoft, USA