问题现象:
1. 重建索引耗时400秒时,会产生大约3GB的日志,同时日志读取器报错“The process could not execute sp_replcmds on 'servername' ”。
这种情况连续出现了三次,重建索引耗时、日志大小、日志读取器报错并发概率为100%。
2. 重新组织索引耗时800秒,产生了大约9GB的日志,但日志读取代理并没有报错。
这种情况只连续出现了一次,重建索引耗时、日志大小、日志读取器没有报错并发概率为100%。
由于发生的次数比较少,目前并不能说明什么问题。
如果这两种现象有规律的出现,大胆假设以下:
重建索引长时间锁定了部分资源,造成日志读取器报错。由于日志读取器只读取COMMIT的事务,而且像重建索引这类事务也是不会读取的。重建索引能影响到复制发布说明是在日志读取器解析日志的时候出现的问题。这就产生一个新的问题,日志读取器什么时候解析日志?是在COMMIT之前?还是之后?
假设:
当重建索引或组织索引的事务完成后,日志读取器才开始解析日志。但这一逻辑和“重新组织索引耗时800秒,产生了大约9GB的日志,但日志读取代理并没有报错。”的现象相违背。重新组织索引产生了更多的日志,但日志读取器并没有报错,这应当说明解析工作是在COMMIT之前就开始了,可能是重建索引长时间锁定相关的资源,或则解析超时,从而造成解析工作失败。
复制日志读取代理参数:
ReadBatchSize:500
QueryTimeout:300
解决办法参考:
http://support.microsoft.com/kb/811030
为什么重建会出错,而组织不会出错?
应当是重建是作为一个事务运行,而组织是当作许多连续的小事务运行的。
处理方法:调整参数
ReadBatchSize:100
QueryTimeout:1000
结果:暂时没有出现这个ERROR message。