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了或者故障了，可能本机的程序/脚本就没法运行了，又怎么监控呢？

 

最后

基于上面的监控列表，还须要将监测工做自动化，并在发现问题时告警。