数据库日检是一个对于DBA来说又爱又恨的工作，恨的是每天面对相同的数据，重复性的劳动，但是又不得不做，有时候做一年日检也没有啥收获；爱的是，有时候日检确实能够帮助我们发现一些严重的威胁，如果不做日检，后果不堪设想。

(相关资料图)

想把日检做好其实不易，很多DBA干了一辈子数据库运维，也没掌握好日检的技巧。我见过很多企业的日检脚本，检查项很丰富的很多，但是做的比较到位的不多。日检需要技术积累，更需要与时俱进。从别的企业抄一个日检脚本来做自己的日检，没有自己的运维经验积累，没有针对自己的业务特点和业务场景，那么做出来的日检也是一项例行工作而已，并不能对我们的运维工作有任何帮助。

对于金融、证券、运营商、互联网企业来说，日检是发现系统中存在比较急迫的隐患的一种最常用的技术手段。而中长期的问题发现往往可以通过优化和月度/季度巡检来实现。如果我们的日检报告里发现的问题都不是当前比较紧迫需要解决的问题，而都是一些中长期优化的问题，那么这个日检的路子就走错了。日检的检查项应该是日常监控不容易发现，但是一旦出现又比较容易很快触发问题的项目，或者是一些和系统安全有关的问题。系统安全有关的问题往往不会立即触发故障，但是一旦安全问题被入侵者利用，后果十分严重，一些中了勒索病毒的系统就是因为弱密码等问题导致的，这些问题潜伏期很长，也往往容易被忽视。昨天我发了一个关于勒索病毒防范的文章，一个朋友在留言区留言说他们刚挫败了一起勒索病毒。在做灾备演练时重启备库发现了勒索病毒，幸亏主库还没有重启，因此主库数据数据还没被加密，从而躲过了一劫。

其实一般企业都有数据库日检的需求，但是往往因为成本过高而无法真正开展日检工作。因此在D-SMART中我们设计了一个专门的自动化日检功能，每天下半夜（默认是3点钟），任务调度器会针对每个数据库实例发起一个日检任务。这个任务会对前一天数据库运行的指标进行一次分析，并对一些重点问题进行分析。

虽然日检是个很简单的业务，不过日检工具要做好也不容易。数据库日检功能刚刚上线的时候，用户就吐槽说用起来不方便。当时我们的日检结果清单里没有异常日检项这一列，当用户看到日检结果里有扣分的时候，必须点击报告详情去查看。用户一下子接入了大几十个多个数据库，一个个这么看下来很累。于是我们改进了一下，把异常日检项直接在第一页显示出来，如果太多，鼠标移过去就能看全了。

后来日检功能变成了用户每天都必须使用的功能了，他们也大量的把系统接入D-SMART。随着接入数量的增加，新问题又出现了。他们接入了近1000个实例的时候，觉得这么看日检结果还是太麻烦了。于是日检汇总报告又出现了。

日检汇总报告可以让他们每天只打开一份报告，就可以看清楚自己负责的所有数据库的日检情况，从而避免了翻几十页去查看日检结果的繁琐工作。运维自动化的目的就是这样，通过工具体验的改善，让人用更少的时间，完成更多的工作。

不过问题还没结束，使用一段时间后，客户发现有些日检项告警，并不一定能够马上去解决。我们和他们讨论是不是从日检里拿掉，放到月检里去。他们又觉得这些检查十分必要，如果一个月做一次恐怕会来不及，还是在日检里做比较好。只是希望在报告里有所区分，把新发型问题和老问题做个区分，让人一目了然的就能看到某个问题是今天发现的新问题就可以了。这么改造完了，确实日检报告好用多了。

可能讲到这里，有些朋友有点不耐烦了，说了半天，数据库日检到底要做点啥啊？实际上日检因人而异，因各个企业的特点而异。比如在二十年前，存储空间是个奢侈品，因此每天检查是否存在可能无法扩展的SEGMENT是一个重点，而在目前的数据库版本，以及存储容量条件下，这个检查就不一定需要了。在D-SMART中，日检模板是可以根据用户的需求去做调整的。也可以自己定制日检的检查项。

D-SMART社区版的日检模板无法自定义，不过我们也提供了十分丰富的日检项。大家有兴趣的话可以去“DBAIOPS社区”下载一个免费的D-SMART社区版，体验一下数据库日检的功能。

只要日检变得很方便了，任何用户都可以做数据库日检，而日检工作带来的提升是显而易见的。不过从我们对日检的理解来看，数据库日检不仅仅是一项工作，更是一种能力。如果无法低成本，快捷，高效，准确的进行日检，那么日检只能是一个讨厌的，烦人的，没有效率的，没有必要的工作。而一旦我们把工具化，便捷化，实用化做到位了，那么这个能力对数据库运维来说，是受益无穷的。