事务复制 Transaction and Command

事务复制使用 dbo.msrepl_transactions 和 dbo.MSrepl_commands 存储用于数据同步的Transaction和Command。在replication中，每个command只能更新（update，insert或delete）一条record；而在Publisher中，一个Trasaction能够更新Table Article的一条或多条Record，因此一个Transaction对应一个或多个command，只有当command全部执行成功，transaction才执行成功。

一, 事务和命令的存储

1，存储事务

在MSrepl_transactions中存储事务，字段xact_seqno 表示事务的序号，数据类型是 varbinary(16) ，值是递增的。

默认情况下，在Publisher database中提交的一个事务，只有一个xact_seqno，其值是10Bytes，只有当该事务中的所有commands都执行成功，该事务才算执行成功。如果事务被拆分成多个子事务，每个子事务都会有一个xact_seqno，由原有的xact_seqno加上子事务序号构成。

例如，事务：0x000B782E000057080006 被拆分成三个子事务，其子事务的序号是：

• 0x000B782E000057080006，占用10B
• 0x000B782E000057080006000000000001，占用16B
• 0x000B782E000057080006000000000002，占用16B

由于xact_seqno的数据类型是varbinary(16)，子事务序号：0x000B782E000057080006 和 0x000B782E000057080006000000000000 在逻辑上相同，表示第一个子事务，因此，在dbo.MSdistribution_history记录的xact_seqno都是 16Bytes的。

2，存储命令

在MSrepl_commands中存储命令，字段xact_seqno 表示命令关联的事务；在一个事务中，可能关联多个Command，字段 command_id 表示在事务中每个Command的ID值；字段 command 存储SQL Server的command，数据类型是varbinary(1024)；如果一个Command 不能存储在一个Command entry中，那么事务复制将其拆分成多个entry。如图，Command_ID依次增加，字段partial_command字段是1，hashkey的值都是3，表示这四个command是一个Command拆分的。

二，查看 msrepl_commands 中的SQL语句

使用 sp_browsereplcmds 能够解析comman的中语句，返回可读的文本。

sp_browsereplcmds Returns a result set in a readable version of the replicated commands stored in the distribution database。

sys.sp_browsereplcmds [ [ @xact_seqno_start = ] 'xact_seqno_start' ]
    [ , [ @xact_seqno_end = ] 'xact_seqno_end' ] 
    [ , [ @originator_id = ] 'originator_id' ]
    [ , [ @publisher_database_id = ] 'publisher_database_id' ]
    [ , [ @article_id = ] 'article_id' ]
    [ , [ @command_id= ] command_id ]
    [ , [ @agent_id = ] agent_id ]
    [ , [ @compatibility_level = ] compatibility_level ]

如果只是粗略地查看Transaction中的 command，可以使用如下脚本，得出的文本大概是：{CALL [sp_MSdel_dboDimUser] (?,?)}，实际上，这是在Subscriber DB中执行的SP，用于删除 dbo.DimUser表中的一条数据行。

SELECT CAST(SUBSTRING(command, 7, 8000) AS NVARCHAR(MAX)),
FROM dbo.msrepl_commands
WHERE xact_seqno = 0x0008E9340005C068003E;

三，Latency 问题一般是由于一个Transaction内包含的Command太多，导致Transaction从Publisher推送到distribution，再从distribution 推送到subscriber 的latency高。

Latency problems are often caused when series of transactions are trying to move a large batch of commands from the Publisher to the Distributor to the Subscribers. 

使用以下脚本查看Command的数量

select t.publisher_database_id, 
    t.xact_seqno, 
    min(t.entry_time) as EntryTime, 
    count(c.command_id) as CommandCount
FROM dbo.MSrepl_commands c with (nolock)
inner JOIN  dbo.msrepl_transactions t with (nolock)
      on t.publisher_database_id = c.publisher_database_id 
        and t.xact_seqno = c.xact_seqno
where c.publisher_database_id=2
GROUP BY t.publisher_database_id, t.xact_seqno
order by CommandCount desc

四，Transaction 和 Command 的cleanup

当Transaction 和 Command 已经被推送到Subscriber上之后，distribution 中的暂存的Transaction 和 Command 应该被purge，不然会导致distribution 过大，影响后续数据的推送。Replication 使用“Distribution clean up: distribution” Removes replicated transactions from the distribution database.

 

参考文档：

sp_browsereplcmds (Transact-SQL)

Determine Transactional Replication workload to help resolve data latency

 

转载于:https://www.cnblogs.com/ljhdo/p/5098809.html