正文
0. SQL Server监控清单
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
数据库服务器的监控可大致分为两类：
(1) 状态监控：数据库服务器有没有在健康地运行？
(2) 性能监控：健康运行的同时，有没有性能问题？可不可以更快些？
一. 服务器
1. 状态监控
(1) 服务器是否可访问？
(2) 数据库服务是否启用？
(3) 操作系统事件日志中的错误或告警
(4) 磁盘可用空间
2. 性能监控
(1) IO压力
(2) 内存使用
(3) CPU使用
(4) 网络带宽占用
这1，2，3，4是按照容易出现瓶颈的顺序排列的，由于磁盘的读写速度限制，通常IO是最容易出现瓶颈的地方，我们所做的很多优化，也都是针对IO的，比如：索引优化，读写分离等等。
二. 数据库
1. 状态监控
(1) 数据库可否打开 (数据库状态)
(2) SQL Server/SQL Server Agent错误日志中的错误或告警
(3) 数据库/文件组可用空间
(4) SQL Agent 作业运行状态
(5) 数据库备份有没有成功
(6) 数据库还原测试的结果
(7) 数据库一致性检查的结果 (DBCC CHECKDB)
以下几条状态监控，通常需要和系统平均值/基线值比较才有意义，否则没有告警的标准。
(8) 连接数、请求数、事务数、线程数
(9) 数据库/文件/表的大小
(10) 表使用、行数
2. 性能监控
(1) 有没有长时间运行的查询 (一般指没有被任何请求阻塞，效率很差的查询)
(2) 有没有被阻塞的查询 (可能单独运行很快，但和别的请求一起，由于有锁等待，耗时很长)
(3) 有没有死锁 (开发人员/用户口中说的”死锁” 通常是阻塞/等待，数据库死锁通常很少让用户感觉到等待，一般是请求被中断，因为被kill掉了)
(4) 有没有等待 (一般指各种资源的等待，等待和阻塞的交集就是锁等待)
以下几条性能监控，通常在性能优化时作为参考，或者如：索引碎片整理/统计信息更新，直接设置为后台维护作业，并不直接告警。
(5) 有没有缺失的/未被使用的/效率不高的索引，以及索引碎片
(6) 有没有过期的统计信息
(7) 有没有数据库文件的争用 (比如：日志文件，tempdb争用)
(8) 有没有消耗CPU较大、IO读写较多的查询 (通常IO消耗大的，也就是内存消耗大的查询)
三. 其他
(1). 如果有部署高可用的策略，会有镜像、复制、日志传送、集群状态的监控；
(2). 某些业务数据有严格的一致性要求，业务数据的校验，最好也做在监控的告警里面；
(3). 对于数据库/实例的选项、参数设置，链接服务器等对象的可用性，通常在每年/每季度的health check里检查过就可以了，如果不放心，当然也可以放到监控的告警中来。
四. 如何部署监控？
1. 不要选择依赖性的脚本/命令
以监视服务是否启动为例，脚本如下：
(1) SQL扩展存储过程
--参数1: QueryState 检查服务状态/ Start启动服务/ Stop停掉服务
--参数2: 服务名
exec master.dbo.xp_servicecontrol 'QueryState', 'MSSQLServer'
exec master.dbo.xp_servicecontrol 'QueryState', 'SQLServerAgent'
exec master.dbo.xp_servicecontrol 'QueryState', 'SQLBrowser'
exec master.dbo.xp_servicecontrol 'QueryState', 'NetLogon'EXEC xp_servicecontrol N'Stop', N'SQLServerAGENT'
EXEC xp_servicecontrol N'Start',N'SQLServerAGENT'
(2) SQL调用操作系统命令
if OBJECT_ID('tempdb..#tmp_started_services') is not null
drop table #tmp_started_services
create table #tmp_started_services (started_services varchar(255))insert into #tmp_started_services(started_services)
exec master..xp_cmdshell 'net start' select *
from #tmp_started_services
where LTRIM(RTRIM(started_services)) like 'SQL%'
如果SQL Server没启动，这些脚本根本就跑不了，又怎么监控呢？
也许，又会有这么一个思路，服务器正常时，发出邮件通知，如果没有收到邮件就说明服务器不正常了，可如果有很多服务器时，怎么知道谁没发邮件呢？
2. 部署在专门的一台/多台监控机上
服务器状态监控，不管使用第三方工具，还是使用自定义脚本，都建议部署在专门的监控机上，远程监视目标机器。
因为：如果服务器DOWN了或者故障了，可能本机的程序/脚本就无法运行了，又怎么监控呢？
最后
基于上面的监控列表，还需要将监测工作自动化，并在发现问题时告警。
