在事务复制中，在发布服务器中执行了一个更新，例如：update orders set col=? Where ?，该操作产生大量的数据更新操作，在Log Reader存储事务和命令时，把该更新操作分解成多条command，每一个command只更新一条record，这些command 位于同一个Transaction中。发布服务器执行命令的基本单元是一个事务，或者一个子事务。当一个事务包含的命令过多时，可以把一个事务拆分成多个子事务，使得每个子事务只包含特定数量的command。这样，分发服务器在把一个子事务准备就绪后，就可以执行该子事务中的命令，循环该过程，最终把整个事务中完成。
在事务复制中，事务的顺序必须得到保证。事务在订阅者和发布者中的执行顺序是相同的，换句话说，订阅者接收事务的顺序和发布者执行事务的顺序是一致的。
Distribution Agent包含两个子进程，Reader和Writer。 Reader负责从distribution 数据库中读取数据，Writer负责将reader读取的数据写入到订阅数据库。Reader是通过 sys.sp_MSget_repl_commands 来读取Distribution数据库中挂起（pending）的命令和事务（读取Msrepl_transactions表和Msrepl_Commands表），并把读取到的数据存储到内部队列中。Writer从队列中顺序获取命令，通过执行以sp_MSupd…, sp_MSins…, sp_MSdel…为前缀的存储过程，把队列中的命令依次写入到subscriber，换句话说，把数据更新的命令在订阅服务器中重新执行一遍。
CREATE PROCEDURE sys.sp_MSget_repl_commands
@agent_id int,
@last_xact_seqno varbinary(16),
@get_count tinyint = 0, -- 0 = no count, 1 = cmd and tran (legacy), 2 = cmd only
@compatibility_level int = 7000000,
@subdb_version int = 0,
@read_query_size int = -1
对Reader进行调优
案例：在Distribution Agent同步数据时，发现Subscriber中有很多Session处于 ASYNC_NETWORK_IO等待状态，该Session正在执行的sp是：sys.sp_MSget_repl_commands，正在执行的语句如下，这条查询用于返回Distribution Agent读取的Commands。
select rc.xact_seqno, rc.partial_command, rc.type,
rc.command_id, rc.command, rc.hashkey,
-- extra columns for the PeerToPeer resultset
-- originator_id, srvname, dbname, originator_publication_id, originator_db_version, originator_lsn
NULL, NULL, NULL, NULL, NULL, NULL, rc.article_id
from MSrepl_commands rc with (nolock, INDEX(ucMSrepl_commands))
inner join dbo.MSsubscriptions s with (INDEX(ucMSsubscriptions))
-- At end, we use the FASTFIRSTROW option which tends to force
-- a nested inner loop join driven from MSrepl_commands
ON (rc.article_id = s.article_id)
where s.agent_id = @agent_id and
rc.publisher_database_id = @publisher_database_id and
rc.xact_seqno > @last_xact_seqno and
rc.xact_seqno <= @max_xact_seqno and
(rc.type & @snapshot_bit) <> @snapshot_bit and
(rc.type & ~@snapshot_bit) not in ( 37, 38 )
and (@compatibility_level >= 9000000
or (rc.type & ~@postcmd_bit) not in (47))
order by rc.xact_seqno, rc.command_id asc
OPTION (FAST 1)
说明该Session返回的数据集太大，导致Writer不能及时读取Command，使得分发的时延增加。
1，查看正在分发的事务
通过SQL Server Profile抓取当前正在执行的SQL命令，从抓取的大量语句中发现，sp_MSget_repl_commands 一般只会用到前四个参数，第三个和第四个参数的值是固定不变的，分别是0和10000000。
exec sp_MSget_repl_commands 74,0x0008ECE200307E10014C00000000,0,10000000
2，Distribution Agent 读取的Commnd数量
sys.sp_MSget_repl_commands 返回的Result Set的大小跟变量 @max_xact_seqno 有关
rc.xact_seqno > @last_xact_seqno and rc.xact_seqno <= @max_xact_seqno
对变量 @max_xact_seqno 的赋值，是由 @read_query_size 参数控制的，在调用该sp时，其值是默认值-1。
下面代码表示 将 dbo.MSrepl_commands 最大的 xact_seqno 赋值给变量@max_xact_seqno，那么Distribution Agent 每次都会读取所有的Command。
--Note4: The max_xact_seqno is calculated based on the @read_query_size parameter -
-- this parameter limit the number of commands retrieved by this call.
if(@read_query_size <= 0)
begin
select @max_xact_seqno = max(xact_seqno) from MSrepl_commands with (READPAST)
where
publisher_database_id = @publisher_database_id and
command_id = 1 and
type <> -2147483611
end
else ....
3，是否可以修改参数 @read_query_size的值
明确为@read_query_size传递一个参数值，而不是使用默认值 -1，可以解决这个问题，但是该sp是系统存储过程，不能直接修改，而Distribution Agent profile中也没有参数能够控制Reader读取的Command数量。
┬_┬
遇到这种情况，就需要换种角度来思考，长时间出现ASYNC_NETWORK_IO，根本原因是一个Trasaction中包含的Command过多，而数据更新的速度跟不上。如果在源头把一个事务拆分成多个子事务，每个子事务可以很快地执行完成。
如果Log Reader将大事务拆分成多个小的Transaction写入到Distribution中，那么Distribution Reader很快地把commands读取，写入到in-memory queue中，进而 Distribution Writer很快把 Queued Commands 写入到Subscriber中，完成数据的一次同步。只要Distribution Reader的读取速度能够跟上Log Reader写入的速度，而Distribution Writer的写入速度也能跟上Distribution Reader的读取速度，这样Distribution Latency 就会很小。
参考文档：
Performance Tuning SQL Server Transactional Replication – Part 1