确定 DTA 跟踪的最大可持续吞吐量（MST）的主要因素包括：
所需的消息吞吐量，即系统每个单位时间接收的消息。
每个消息被跟踪了多少数据。
在清除之前，数据在 BizTalkDTADb 数据库中生存多长时间，即数据保留时段。
BizTalkDTADb 数据是否已存档并清除。 存档是可选的，但必须定期执行清除。
所有这些因素都有一个共同点：DTA 可以接受和处理（存档和清除）数据的速度。
BizTalkDTADb 插入和处理速度如何影响系统
现在，让我们演练 测量最大可持续跟踪吞吐量中所述的跟踪数据路径，并评估 BizTalkDTADb 的插入和处理速度对系统各个组件的影响。
从 trackingdata 和 spool 表开始，我们可以设想，如果将数据从这些表移动到 BizTalkDTADb 数据库的进程无法以至少与运行时将数据插入 trackingdata 和 spool 表相同的速度将数据插入 BizTalkDTADb 数据库，那么 spool 和 trackingdata 表将开始积压。 这不一定是短期内坏事，只要你知道消息吞吐量会减少，以允许积压工作最终耗尽。 但是，只要数据仍然位于缓冲区或跟踪数据表格中，就无法在 BizTalkDTADb 数据库中通过Group Hub页面上的查询或任何其他工具进行查询。 因此，它不适用于问题解决。 因此，如果出现需要使用 BizTalkDTADb 数据调查的问题，任何预期的积压期必须足够短，以便跟踪的信息仍及时可用。
从测试结果来看，我们知道，决定是否会出现积压的因素不是将跟踪数据移动到 BizTalkDTADb 数据库（即 TDDS 和 TrackedMessages_Copy_BizTalkMsgBoxDb）的过程，而是 BizTalkDTADb 数据库接受输入的速度。 通常，它是受 I/O 绑定的 BizTalkDTADb 数据库的数据文件。 也就是说，BizTalkDTADb 数据库数据文件所在的驱动器速度将决定 DTA 总体速度。
BizTalkDTADb 中的数据量如何影响 I/O 速度
与 I/O 速度相关的另一个关键因素是 BizTalkDTADb 数据库中的数据量：随着 BizTalkDTADb 数据库中跟踪的数据量增加，BizTalkDTADb 数据库的输入和处理速度会降低，因为插入新数据时只需更多数据进行排序，这会影响每次插入所需的 I/O 量。
这是存档和清除开始起作用的地方，因为正是这些过程防止 BizTalkDTADb 数据库增长过大而难以管理。 基本思路是确保 BizTalkDTADb 数据库大小保持在后台处理表和跟踪数据表中开始备份的级别以下。 在 DTA 清除和存档（BizTalkDTADb）SQL 作业中实现的清除和存档过程同样需要占用 BizTalkDTADb 数据库服务器的资源（CPU、内存，尤其是 I/O）。在进行跟踪测量 MST 时，必须将这些因素予以考虑。
另请参阅
测量最大可持续跟踪吞吐量
用于衡量 DTA 跟踪的 MST 的测试场景
查找 DTA 跟踪 MST 的提示和技巧
跟踪数据库规模调整准则