SQLSERVER复制优化之一《改变包大小》
SQLSERVER 复制 优化 之一 《 改变 包 大小 》 自从搭了 复制 之后以为可以安枕无忧了,谁不知问题接踵而来 这次遇到的问题是 丢包 ,不知道情况的读者可以先看一下我之前写的一篇《SQLSERVER监控 复制 并使用数据库邮件功能发告警邮件》 因为机房C和机房A不
SQLSERVER复制优化之一《改变包大小》
自从搭了复制之后以为可以安枕无忧了,谁不知问题接踵而来
这次遇到的问题是丢包,不知道情况的读者可以先看一下我之前写的一篇《SQLSERVER监控复制并使用数据库邮件功能发告警邮件》
因为机房C和机房A不在一个局域网,网络状况不是太好
分发积压的命令经常处于20W+条,复制并没有报错,每次传递的事务都是少于30个,正常来讲SQLSERVER默认每次会传输100个事务
后来测试了一下网络情况
从分发服务器ping一下订阅服务器,ping 4096Byte大小的包,ping100次,因为分发默认传输的包大小是4096Byte,中间偶尔会超时
ping 订阅服务器ip -l 4096 -n 100
参数l是指包的大小, 参数n是指ping的次数,不加 -l 参数的话默认ping的包大小为32Byte
100个包有21个丢包
ping 订阅服务器ip -l 1024 -n 100
100个包有5个丢包
后来又继续ping 512Byte 、256Byte、128Byte大小的包,发现越小的包,丢包率就越低
从当前的网络测试情况来看,需要调整一下分发代理的包大小,在分发代理配置文件里有一个参数 -PacketSize packet_size
这个参数是设置分发代理发送到订阅服务器的包大小的。
环境:发布和分发都在同一台机器
设置
我们将分发代理的包大小设置1024Byte,那么怎么设置呢?
有两种方法:
方法一:修改分发agent 的作业
(1)打开分发代理作业
(2)转到步骤
(3)双击“运行代理”,然后添加参数 -PacketSize 1024 ,点击确定,退出作业属性
(4)停止分发代理作业
(5)开始分发代理作业
这样设置过后,分发代理就会以新的参数运行
但是代理配置文件是看不出来当前分发代理的运行参数的,还是显示4096Byte
方法二:新建一个代理配置文件,然后直接修改参数
(1)默认的代理配置文件是修改不了的
(2)新建一个代理配置文件
(3)选择默认代理配置文件(新代理的默认值)
(4)输入配置文件名:testprofile,把“仅显示此配置文件的参数”的勾去掉,修改-PacketSize参数为1024,然后点击确定
(5)勾选testprofile,然后点击确定
(6)跟分发作业一样,点击“停止分发代理”,然后点击“启动分发代理”,使设置生效
验证
那么我怎么知道究竟当前分发代理是否使用1024Byte大小的包来传送呢?
这时候可以借助Microsoft Process Monitor 3.10这个工具
在发布端使用这个工具来监测一下
复制分发代理
复制分发代理是一个可执行文件,它能将快照(对于快照复制和事务复制)和保存在分发数据库表中的事务(对于事务复制)移动到订阅服务器上的目标表中。
若要启动分发代理,请从命令提示符下执行 distrib.exe
打开任务管理器,查看分发代理进程的进程ID(PID),然后打开Microsoft Process Monitor 3.10,设置筛选条件
使用process monitor来监控分发代理传输的包大小
看一下length,最大的包也不会超过1024,说明设置生效了
未分发命令降下来了
注意:
当你的服务器中当前多个数据库是做了复制的,一个数据库只有一个logread进程,多个数据库就对应多个logread进程
分发代理也是,一个数据库可以有多个分发代理,每个分发代理对应他们各自的进程(distrib进程)
所以一定要看清楚,你当前查看的distrib进程是不是你刚才设置的那个分发代理
总结
这篇文章只是阐述了复制的过程当中出现问题的其中一个原因,当然还有很多原因,例如 发布库的日志文件VLF太多等等。。。
在分析的时候一定要多个角度分析,不能死磕一个方面,因为复制涉及到的方面比较多
有可能是发布端的问题,有可能是分发端的问题,也有可能是订阅端的问题
感谢菠萝兄的热心帮助o(∩_∩)o
如有不对的地方,欢迎大家拍砖o(∩_∩)o