事务复制会话 (一)

[アーティクル]
08/18/2011

当对事务复制性能问题进行故障排除时，我们可以将数据流分为四段同步的会话，测试每段会话的性能，将有助于确认应该从哪里开始瓶颈调查。

1) 日志读取器（LogReader）的读者线程通过存储过程sp_replcmds（xp_replcmds的包装）读取事务日志，它会扫描被标记为复制事务的日志，跳过非复制的事务。

2) 日志读取器的写者线程使用sp_MSadd_replcmds，将排队事务从读者线程写到分发数据库。

3) 分发的读者线程执行sp_MSget_repl_commands，从分发数据库获得未处理的命令并存储到内部队列。

4) 分发的写者线程通过以sp_MSupd、sp_MSins、sp_MSdel开头的几个参数化的存储过程，将行的变更应用到订阅方的每个项目，从而将队列中的命令写到订阅服务器。

5) 日志读取器和分发服务器也会执行一个“历史”线程，将总结数据写到分发数据库的系统表MSlogreader_history和MSdistribution_history中。

接下来我将分五个部分来讨论事务复制会话:

1. 性能故障排除工具

2. 日志读取器读者线程延迟

3. 日志读取器写者线程延迟

4. 分发代理读者线程延迟

5. 分发代理写者线程延迟

一、性能故障排除工具

SQL Server事件探查器（SQL Profiler）：查看事务复制会话的信息有多种方法。与所有连接到SQL Server的应用程序一样，复制组件执行的每条命令都可以被事件探查器跟踪抓取。跟踪信息可以被存储或查询，从而找到运行时间较长的语句。

跟踪信息中的“应用名称”举例：

- - - REPLICATION MONITOR —— Management Studio的用户界面
    - REPL-LOGREADER-#-DatabaseName-#——日志读取器代理向分发表记录变更的写者线程
    - ServerName\Instance-DatabaseName-PubName-Subscriber——来自分发代理的读者线程，用于找出哪些命令/事务要复制到订阅方
    - REPLCATION
      LOGREAD HISTORY——日志读取器代理用来记录历史的写者线程
    - REPLICATION
      DISTRIBUTION HISTORY——分发代理用于记录历史的写者线程

复制存储过程调用举例：

· 分发活动

- - SP_MSGET_REPL_COMMANDS
  - SP_MSHELP_DISTRIBUTION_AGENTID
  - SP_MSGET_SUBSCRIPTION_GUID

· 日志读取器活动

- - SP_MSADD_REPLCMDS
  - SP_MSADD_LOGREADER_HISTORY
  - SP_REPLCMDS
  - SP_MSPUB_ADJUST_IDENTITY
  - EXEC SP_MSGET_LAST_TRANSACTION @PUBLISHER_ID = {##}, @PUBLISHER_DB = {STRN}, @FOR_TRUNCATE = {BS}
  - SP_REPLDONE
  - EXEC SP_REPLCOUNTERS {STRN}

· 订阅服务器活动

- - SP_MSins%
  - SP_MSupd%
  - SP_MSdel%

活动监视器（Activity Monitor）：SQL Server Management Studio活动监视器、SQL 2005的性能仪表盘（Performance Dashboard）、SQL 2008的性能数据仓库（Performance Database Warehouse）、以及系统存储过程，可以帮助查找阻塞、磁盘瓶颈和导致高IO和高CPU的语句。为了识别复制组件，我们可以查找日志读取器或分发代理作业连接到SQL Server的程序名。查找复制作业的列表，可运行下面的语句：

SELECT name, description, enabled from MSDB..sysjobs

WHERE category_id>10 and category_id<20

跟踪令牌（Tracer Tokens）：使用复制监视器中的跟踪令牌功能，可以得到复制性能的概览。该功能提供了“发布服务器到分发服务器”以及“分发服务器到订阅服务器”的等待时间值。要使用该功能，开启复制监视器。在My Publishers表中，选择想要测试的发布。在右边的面板，选择Tracer Tokens标签，并点击“Insert Tracer Token”按钮。下面将会出现一个订阅方列表，可获得“发布服务器到分发服务器”和“分发服务器到订阅服务器”的值。

该方法仅对实时复制有用。如果拓扑是晚3天的，那将不会看到跟踪令牌按时到订阅方，所以，你只能看到日志读取器在时间上是否落后。这其实还是很有用的信息，尤其是在当订阅方只晚了五分钟，你可以看到令牌全程传递的情况。

如果看到“发布服务器到分发服务器”的时间很长，就要集中于日志读取器性能的问题排除。如果日志读取器性能很好，但“分发服务器到订阅服务器”的值很大，那么说明，事务从被发布数据库的事务日志到分发数据库的过程很快，但是从分发数据库到订阅数据库很慢。分发代理应当作为瓶颈调查的关键。

下面的链接提供了估计延迟时间的示例代码：

· https://www.replicationanswers.com/TracerTokens.asp

· https://blogs.mssqltips.com/blogs/chadboyd/archive/2007/10/24/monitoring-replication-latency-automatically-using-tracer-tokens-sp-replchecklatency-allpubs.aspx

· https://www.microsoft.com/technet/prodtechnol/sql/2005/p2ptranrepl.mspx

性能监视器（Performance Monitor）：我们也可以使用Windows性能监视器来跟踪复制日志读取器的 “LogReader:Delivery Latency” 计数器或者复制分发的“Dist:Delivery Latency”计数器。不过，Windows性能监视器的复制计数器值仅在日志读取器或分发代理完成一个过程阶段并记录了性能状态之后才会更新。所以即使有一个包含上百万行的事务在处理，计数器的值也将显示为0 commands/sec及0 transactions/sec

次の方法で共有

事务复制会话 (一)

その他のリソース