Replication 第三篇：Distribution Reader和Writer

在事务复制中，在发布服务器中执行了一个更新，例如：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

SQL Server复制系列4 – Transactional replication中如何跳过一个事务

发布订阅延迟故障排查案例：分发读进程延迟