通过

了解 DTA 跟踪性能行为

  • 项目

确定 DTA 跟踪 (MST) 的最大可持续吞吐量的主要因素是：

  • 系统所需的消息吞吐量，即按单位时间接收的消息数。

  • 正在跟踪每条消息的数据量。

  • 数据在被清除前在 BizTalkDTADb 数据库中存活多长时间，即数据保留时段。

  • 是否存档和清除 BizTalkDTADb 数据。 存档是可选的，但清除必须定期执行。

    所有这些因素都有一个共同点：DTA 接受和处理 (存档和清除) 数据的速度。

BizTalkDTADb 插入和处理速度如何影响您的系统

现在，让我们演练 测量最大可持续跟踪吞吐量中所述的跟踪数据路径，并评估 BizTalkDTADb 插入和处理速度对系统各个组件的影响。

从 trackingdata 表和 spool 表开始，我们可以假设，如果在将数据从这些表移到 BizTalkDTADb 数据库的进程中，将数据插入 BizTalkDTADb 数据库的速度无法与运行时将数据插入 trackingdata 表和 spool 表的速度至少相当，则 trackingdata 表和 spool 表将开始积压。 只要您知道将降低消息吞吐量以便最终消除积压，短期内上述情况不见得就是坏事。 但是，只要数据仍处于 spool 或 trackingdata 表中，就无法在 BizTalkDTADb 数据库中使用“组中心”页中的跟踪查询或任何其他工具对这些数据进行查询。 因此，它对解决问题没有作用。 因此，任何预期的积压期间都必须足够短，以便只要发生需要使用 BizTalkDTADb 数据进行调查的问题，仍可以及时地利用跟踪的信息予以解决。

从测试中，我们知道，不是将跟踪数据移动到 BizTalkDTADb 数据库的过程 (TDDS 和 TrackedMessages_Copy_BizTalkMsgBoxDb) ，而是决定积压工作是否会累积，而是 BizTalkDTADb 数据库接受输入的速度。 通常，这是受到 I/O 限制的 BizTalkDTADb 数据库的数据文件。 即，决定因素是 BizTalkDTADb 数据库数据文件所驻留的驱动器的速度，该速度将确定 DTA 的整体速度。

BizTalkDTADb 中的数据量如何影响 I/O 速度

与 I/O 速度相关的另一个关键因素是 BizTalkDTADb 数据库中的数据量：随着 BizTalkDTADb 数据库中跟踪的数据量增加，BizTalkDTADb 数据库的输入和处理速度会降低，因为插入新数据时需要排序的数据更多，这会影响每次插入所需的 I/O 量。

这就是为什么要考虑存档和清除操作，因为就是这些进程使得 BizTalkDTADb 数据库增长得过大，以致难以维护。 因此，基本思路就是：确保 BizTalkDTADb 数据库大小保持在较低的级别，其级别要低于不得不开始在 spool 表和 trackingdata 表中进行备份的级别。 但是，在 DTA 清除和存档 (BizTalkDTADb) SQL 作业中实现的清除和存档进程也要求来自 BizTalkDTADb 数据库服务器的资源（CPU、内存，尤其是 I/O），在度量与跟踪有关的 MST 时必须将此考虑在内。

另请参阅

度量最大可承受跟踪吞吐量
测量 DTA 跟踪的 MST 的测试方案
DTA 跟踪的 MST 的提示与技巧
跟踪数据库的大小调整准则