我们知道，事务复制是将数据从发布服务器传到分发服务器然后复制到订阅服务器的过程 - 数据流几乎是实时地进行这些步骤。当有问题产生而造成流程中断，就会出现数据复制延迟。我们经常碰到的难题和关键是定位到哪一步是整个延迟的原因。从SQL2005开始支持的
我们知道，事务复制是将数据从发布传到分发然后复制到订阅服务器的过程 - 数据流几乎是实时地进行这些步骤。当有问题产生而造成流程中断，就会出现数据复制延迟。我们经常碰到的难题和关键是定位到哪一步是整个延迟的原因。从sql2005开始支持的跟踪令牌功能，可以帮助我们轻松确定延迟问题是出现在1）从发布服务器到分发服务器，还是2）从分发服务器到订阅服务器。
跟踪令牌
跟踪令牌是一种特殊的时间戳事务，可以从复制监视器或运行T-SQL语句插入，它会被写到发布的事务日志中并被日志读取代理获取。之后被分发代理读取并写到订阅服务器。每一步的时间戳都被记录到分发的跟踪表中并显示在复制监视器或通过T-SQL语句获得。见下图：
在SQL Server Management Studio中，右击Replication（复制），然后选择Launch Replication Monitor（启动复制监视器）。
在复制监视器中，选择事务复制发布，然后打开Tracer Tokens页面。点击Insert Tracer插入新令牌。在插入跟踪令牌之后，复制监视器显示“Pending…”。
当日志读取代理获取令牌后，它会在分发数据库的Mstracer_token系统表中记录时间 – 通过计算插入令牌和日志读取代理获得令牌的时间差，来获得Publisher到Distributor的时间；然后分发代理获取令牌和并在分发数据库的Mstracer_history系统表中记录写入订阅方的时间 - 通过计算日志读取代理获得令牌和分发代理获取令牌并写入订阅方的时间差，来获得Distributor到Subscriber的时间。
跟踪令牌示例
在这个示例中，延迟大约持续了6秒，其中订阅方的写入只有1-2秒，但跟踪令牌却用了5秒将它们从发布服务器复制到分发服务器。因而，此示例中的事务延迟的关键显然应从日志读取代理开始而非分发代理。
再来看另一个例子，令牌复制到分发服务器用了3秒，但是到订阅服务器#1用了1秒，到订阅服务器#2用了4秒。尽管日志读取代理不像想象中那么快，但改进到订阅服务器#2的延迟将可以减少至少一半的整体延迟。
