BizTalk Server 数据库中存储的数据量可能会很快增长，具体取决于你设计 BizTalk Server 方案的方式，具体取决于 BizTalk Server 方案处理的消息数和大小，以及配置跟踪的方式。 通过在正常级别维护数据库大小，处理效率更高，系统中的数据量在任何给定时间都规范化。 这可提供高效且一致的性能。 通过自动执行此过程，可以减轻手动维护数据库的负担。
配置健康的环境
维护正常运行的 BizTalk Server 环境的策略在很大程度上取决于特定方案及其运行的硬件。 要监视的关键是 BizTalk 跟踪（BizTalkDTADb）数据库的增长率和大小。 跟踪数据库中的几个表占据了大部分的数据库大小，因此对运行时性能产生了显著的影响。
可以将同一方案配置为根据存在多少个跟踪点、使用了多少个不同的消息、消息大小以及所使用的消息正文跟踪级别生成完全不同的跟踪数据量。 以下是要监视的一些重要因素：
跟踪点数 - 例如管道、业务流程和端口
跟踪的消息属性数
每条传入消息对应的消息数量
消息大小
流量速率（平均和峰值）
消息正文跟踪配置
考虑自动存档和清除数据时，请考虑在跟踪数据库中保留多少实时数据。 需要根据您的环境适当地调整 DTA 清除和存档作业参数，以确保清除性能能够支持目标活跃数据量而不下降。
DTA 清除和存档作业可以在给定的时间间隔内清除一定的数据量。 作业的容量取决于正在运行的方案、当前数据库大小和硬件。 若要获得稳定的环境，必须在传入跟踪数据生成和清除之间保持平衡。 在测试环境中，可以通过改变数据的实时窗口和清除作业的频率来找到平衡点。 在均衡状态下，系统将提供可持续的吞吐量。 目标是在 BizTalk 跟踪数据库表大小导致持续的重大性能问题之前拥有足够的缓冲区。
性能限制
清除性能表现无法适应所有情况。 对于任何方案，可以生成越来越多的跟踪数据。 当跟踪数据以持续较慢的速度被清除时，跟踪数据库的大小会累积，从而进一步恶化清除性能。
在不可持续的负载条件下，邮件正文的复制也可能会变慢，并且 MessageBox 数据库中可能会积压。 在极端情况下，每日消息正文的复制和跟踪可能会导致存档中文件丢失，即使这些文件包含相关的实例信息。 通常，高负载周期与低负载周期交替，使作业能够在负载低期间赶上。
存档和清理 BizTalk 跟踪数据库应显著降低因持续裁剪数据库和压缩存储的跟踪数据而导致的不可持续负载状况的风险。 这些过程大大减少了手动干预的需求。