sqlserver的监控和诊断（一次生产事故应急处理）

有些人经历这个过程可能比较短，但是多数人经历的都会比较长。一般数据库理论知识的积累可能会比较快，但是真正要从理论联系到实际工作，再从实际工作中反推理论，还真就是一个很漫长的过程。

任何数据库不达到一定的体量，很多问题就不会发生，那你也就难有机会去处理这些问题。一个DBA经历了大体量、大访问量数据库的磨练，处理了线上极其复杂的问题后，才能真正得到理论和实践的相结合，从而蜕变成一名合格而优秀的DBA。

不积跬步，无以至千里；不积小流，无以成江海。

就让我们从日常运维工作，开始慢慢了解SQLServer数据库。

线上故障

对于一个新手DBA来说，数据库在正常运行下，可能每天的主要任务就是做好备份，执行SQL，优化SQL等日常操作。但是如果突发了数据库的线上故障，却是最要命的。

本人在刚成为SQLServer DBA的时候并没有人带，完全是靠自己一步步走过来的。

先就一个线上故障的案例，来简单说说如何处理线上问题。

已经记不起当时自己是如何处理第一次线上故障的，就拿平时工作中比较常见的线上故障案例来做分析。

一次早上业务告警，访问非常卡。

登录相应的数据库服务器，内存和IO正常，数据库没死锁，没阻塞。CPU暴满。

从经验判断，引起CPU暴满的多数原因，应该是SQL导致的。

• 1.全表扫描的SQL。

• 2.数据倾斜导致的SQL的执行计划走偏。

• 3.无法通过索引来优化的复杂SQL。

解决问题

根据经验判断，是SQL导致的问题。

我们开始解决问题：

开启SQL Profiler监控。

主要抓消耗CPU资源的SQL语句。一般对业务比较繁忙的数据库系统CPU参数取值，大于4000。

经过监控发现一条SQL语句执行的非常频繁，而且消耗的CPU资源也很多。

我们再来看看这个SQL语句的执行计划：

大家可以发现，这个SQL语句在执行的时候 扫描表消耗了大量的逻辑读，所以消耗CPU是很厉害的，证明一定没有走条件索引。

我们对条件字段加上索引。

发现这个SQL的逻辑读大幅度下降。SQL执行效率也得到了大幅提升。

CPU消耗恢复正常，业务也恢复正常了。

剖析问题的核心关键点

大家可能会说，这个问题解决起来不是很简单吗？

对于一个资深DBA来说或许并不难，但是对于一个新手来说，尤其是第一次遇到这类问题的新手DBA来说，想要迅速定位和解决问题，其实并不容易。

因为线上故障发生很突然，而且业务和领导都会催促，你是在很大的压力之下来处理线上问题的，所以这个过程是需要有过硬的基本功和心理素质的。稍有不慎，一旦处理不当，可能会引起更大的生产事故，那就是灾难了。

以前遇到过一个DBA在添加windows cluster节点的时候，错误地勾选了“将所有符合条件的存储添加到群集”。

这导致了整个windows群集报错无法使用，引起了严重的生产事故。

这个错误我以前也犯过，还好当时是在半夜，而且不是重要的业务数据库，当时立即解决了。这位DBA当时很慌张，并且是业务时间，所以并没有第一时间想到办法去解决，最后虽然解决了，但是却影响了业务较长时间的使用。这位DBA也算是比较资深的DBA了，但是在面对突发的生产事故时，同样会慌不择路。

所以我想告诉各位DBA的同学们，无论你是新手还是资深，对于我们所管理的数据库系统都要有敬畏之心。尤其对于生产环境的操作，一定要小心小心再小心，因为任何一个生产操作，都可能会导致巨大的灾难。轻则影响业务使用，重则导致数据丢失。

对于任何不是很确定的操作，一定要在测试环境进行测试，而对于生产环境的操作，一定要有对可能会产生的问题的预判，并做好回退的准备。

而当生产事故一旦发生，我们要做的，无非就是冷静冷静再冷静。

1.一旦发生了生产事故，我们所要做的第一点，就是根据目前所有的监控，去判断此事故的严重性。

2.事故很严重，严重到影响业务使用，那第一要务就是尽快恢复业务。

• CPU暴满先从优化SQL着手。

• CPU正常但是磁盘访问很慢，多半是IO问题，可以考虑进行主备切换。

• 一般硬件问题可以进行主备切换，非硬件问题多半和SQL相关，进行SQL优化。后期再进行业务拆分和读写分离。并对可以归档的历史数据进行归档。

3.事故不是很严重，没有严重影响业务使用，那么可以先处理优先级高的问题，后面再处理这些问题。

写在最后

本文主要分享了我曾遇到的一次生产事故，应该如何来应对和处理，但是如果我们每次都是充当救火队员的角色，那对于成为一名称职和优秀的DBA来说，还是远远不够的。

其实对于SQLServer的日常运维来说，首先要做的，我觉得应该是防患于未然。

1.做好数据库监控，可以使用zabbix监控CPU、内存和磁盘IO等指标，使用Prometheus Grafana，实现可视化界面和SQLServer精细化指标监控和展示。

2.根据SQLServer不同的业务系统，进行数据库监控指标的告警和通知。

3.对于新上的和老的业务表，都要做好归档策略；对于无法归档的业务表，要尽早进行业务拆分、分库分表和读写分离。对于不能拆分和分库分表的业务大表，要尽早进行限制字段的增加。并对开发和业务方提出设计要求，严禁业务大表的不断增长。

4.良好的数据库设计才是最重要的。对于新上线的数据库表都要进行规范要求，不合理的设计一定要禁止上线。我们这里的数据库表上线，都必须有创建时间和更新时间字段，方便业务后期排查。对于大表的主键字段，都建议使用bigint。上线时候最好对索引也有预见，开发可以提出并建立合理的索引。

我觉得，一套完整的数据库监控系统，加上一份良好的数据库上线规范和数据库设计，其实就能把线上问题降低和防范一大半了。然后我们自己再深挖数据库理论，以及进行数据库优化，那完全可以避免绝大部分线上问题的发生（除去硬件故障）。

其实要说的还很多，但是限于篇幅，暂且就先说到这里。

做好SQLServer的日常运维只是第一步，要想在SQLServer上有所建树，我觉得还是需要深挖SQLServer的原理，毕竟原理通透才是我们DBA的立身之本，然后就是大量实战经验的积累了。相信这样深耕下去，你终会成为一名优秀的SQLServer DBA。

,