troubleshooting sql server Distribution（分发库优化）
表象
- 我们某个较核心项目的分发库【Distribution】 磁盘使用接近200G；
- 监控的阻塞源头中较频繁出现【分发清除: distribution】；
- 【分发清除: distribution】 job平均耗时11分钟以上；
- 从【distribution 】所在的独立E盘（ssd）磁盘队列以及活动时间%来看IO使用非常频繁；
系统版本相关信息如下
Microsoft SQL Server 2017 (RTM-CU14) (KB4484710) - 14.0.3076.1 (X64) Mar 12 2019 19:29:19 Copyright (C) 2017 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 Datacenter 6.3 <X64> (Build 9600: ) (Hypervisor)
库大小
表大小
阻塞情况
通过在线查看阻塞情况，常常会出现【分发清除: distribution】这个job；
查看该job历史执行记录，平均耗时11分钟以上；
日期 2020/2/26 7:45:00
日志 作业历史记录 (分发清除: distribution)
步骤 ID 1
服务器 ************
作业名称 分发清除: distribution
步骤名称 运行代理。
持续时间 00:11:43
SQL 严重性 0
SQL 消息 ID 21010
已通过电子邮件通知的操作员
已通过网络发送通知的操作员
已通过寻呼通知的操作员
重试次数 0
消息
已以用户 ************* 的身份执行。 从 MSrepl_commands 开始每毫秒删除 0 行 [SQLSTATE 01000] (消息 22121) 从 MSrepl_transactions 开始每毫秒删除 0 行 [SQLSTATE 01000] (消息 22121) 从 MSrepl_commands 开始每毫秒删除 0 行 [SQLSTATE 01000] (消息 22121) 从 MSrepl_transactions 开始每毫秒删除 0 行 [SQLSTATE 01000] (消息 22121) 在 670857 毫秒内删除了 1784 个由 5349 条语句组成的复制的事务(0 行/毫秒)。 [SQLSTATE 01000] (消息 21010). 该步骤成功。初步思路
- 检查分发、发布相关设置；
- distribution占用空间接近200G，可在维护窗口进行收缩或索引重建；
- 从现有的表象来看distribution所在E盘现阶段可能有IO瓶颈，如有必要可以收集一下perf；
处理步骤
1.查看分发服务器属性
因我们使用是SQL server 2017的版本，所以有【事务删除批大小】（默认5000），【命令删除批大小】（默认2000）的设置，如在2017以下的版本无界面设置就需手动在对应的发布库去调整存储过程【sp_MSdelete_publisherdb_trans】和【sp_MSdelete_dodelete】，可以使用sp_helptext 查看上述2个存储过程，然后分别把【sp_MSdelete_publisherdb_trans】代码中2000改成10000，【sp_MSdelete_dodelete】中5000改成10000；调整的原则是建议在原来参数的基础上10-100倍的调整；
2.查看各个发布属性
发布的订阅过期还是默认的永不过期设置，需调整成订阅过期 间隔120小时；
如发布比较多可以使用如下脚本查看
use distribution
set transaction isolation level read uncommitted
select distinct
srv.srvname publication_server
, a.publisher_db
, p.publication publication_name
, p.retention
, ss.srvname subscription_server
, s.subscriber_db
from MSArticles a
join MSpublications p on a.publication_id = p.publication_id
join MSsubscriptions s on p.publication_id = s.publication_id
join master..sysservers ss on s.subscriber_id = ss.srvid
join master..sysservers srv on srv.srvid = p.publisher_id
join MSdistribution_agents da on da.publisher_id = p.publisher_id
and da.subscriber_id = s.subscriber_id
ORDER BY p.retention 把过期时间调整为120小时之后的查询结果如下：
3.查看publication 的【immediate sync】等参数设置
exec sp_helppublication 把所有的发布的【immediate sync】 和 【allow_anonymous】 调整为0
EXEC sp_changepublication
@publication = '', -- put your publication name here
@property = 'allow_anonymous',
@value = 'false'
GO
EXEC sp_changepublication
@publication = '', -- put your publication name here
@property = 'immediate_sync',
@value = 'false'
GO 上述3个步骤做完，待【分发清除: distribution】job成功执行一次之后（本次执行时间因磁盘的性能时长不一，我们执行了大概1小时左右），查看distribution的表情况如下
发现表内的记录明显已减少；
查看磁盘使用情况如下：
磁盘空间大部分已是未使用，收缩【distribution】数据库之后；
重新查看【distribution 】的磁盘使用情况如下：
查看对应【分发清除: distribution】job的历史记录如下
执行时间已从之前的平均11分钟以上到现在的3秒；
这时4个不好的表象都已消失；
从上述的优化来看基本也可以排除磁盘硬件方面的问题；
总结
- 随着生产环境运行的越久，默认的分发、发布相关的配置参数会引起数据库出现性能瓶颈；