对于数据库圈来说，元旦似乎不大太平，关于事情是什么圈内大概也是知道的，我也从一些非常规渠道了解到了整件事情的来龙去脉，但是由于一些原因不能写（就看后面有没有正式点的通告吧）。但是通过这件事情，我还是想说一下，数据库除了本身健康运行以外，在其外围工具还需要做好哪些事情。

　　1 监控告警

　　这几乎是数据库工具中最重要的部分！以我实际工作经验来说，借助Oracle Enterprise Manager，可以实现对数据库、Exadata所有硬件组件的全面监控告警。

　　以告警为例，除了一般的CPU、内存使用率告警、数据库各类锁、等待告警和空间用量告警等，EM提供的告警甚至可以触达每个alert log中的异常信息（告警送达的同时告知绝大多数异常信息），这让数据库出现的绝大多数问题我都可以第一时间知晓，甚至很多时候我可以先于业务方得知问题发生并反馈。

　　除常规监控以外，EM提供的监控还可以可以实现：

• 　　通过实时ASH监控，可以通过查看数据库等待事件与对应SQL ID快速定位异常SQL，并及时反馈、解决

• 　　通过实时SQL监控，可以快速定位长时间运行SQL，避免长SQL、大事务带来的影响

• 　　通过实时锁监控，可以快速定位异常会话并处置

• 　　通过实时ADDM报告，可以快速判断数据库是否出现各类瓶颈

• 　　…

　　上面的监控能力归根结底其实想要突出的就是，监控平台本身需要有足够的能力能够帮助数据库管理者能够通过监控信息快速找到问题并处理，快是十分重要的！如果只是发现数据库出现问题，但是没法通过监控快速定位问题，还需要一点点去找各类日志来排查（尤其是分布式数据库节点组件多），那么处置问题必然会耗费更多的时间。

　　最后，能够实现对数据库的有效监控并实现有效告警，还需要数据库本身的支持，并且是一种对数据库极小影响的方式支持（比如底层接口），而不是通过定时在数据库跑一堆大SQL来实现监控，这样即不实时，而且这些监控需求也可能成为数据库消耗最多的SQL了，对数据库带来更多不稳定的因素。

　　2 逃逸机制

　　大家在维护一些数据库的过程中一定遇到过，数据库连接数异常且无法连接至数据库管理员用户进行修复操作的。对于数据库配置来说，很多数据库已经在常规业务连接数以外增加额外独立的管理员访问连接数可以避免这一情况发生。但然如果是因为操作系统配置或资源耗尽等导致无法连接数据库并执行相关操作怎么办？我认为有以下一些方法：

• 　　预防

　　：提前以现有硬件、操作系统、软件为基础，结合业务压力特性进行全面测试，制定合理的全局各部分的配置，在预留一定余量的基础上可以尽可能的避免实际上线后问题的出现。但依然要明确，这并不能完全避免特殊情况的发生。

• 　　手段

　　：在标准的连接至数据库通过命令行进行操作以外，在操作系统（或云底座）一定要有其他的应急操作手段，比如Oracle可以通过sysctl、PG可以通过pg_ctl来对数据库进行一些如启停实例、调整参数等操作，以求在紧急情况下能够处理问题。

• 　　高可用

　　：要说IT系统完全不会出问题，这几乎是不可能的，健壮性足够高的高可用架构（这里主要说的是跨集群高可用架构），在主用生产集群出现异常时，在紧急情况下甚至可以通过类似于failover的方式让备用集群接管生产，降低业务影响时间。

• 　　演练

　　：即便前面做的再好，各种故障处置、灾备切换的演练也是需要做好的，做这些的目的不仅仅是验证并完善数据库层面的操作流程，也为了验证生产业务程序、周边硬件等是否能正确应对数据库故障处置的相应场景，发现其中是否有需要完善的地方。避免真正需要的时候数据库或应用无法响应。

• 　　记录

　　：在生产中，所有的操作、隐患、处置过程等都需要详细的记录下来，并尽可能形成完整严谨的文档。

　　3 AI

　　接下来的一段话可能不那么好听：“现在的国产数据库和国外商业数据库之间还有不小的差距”，这个差距不只是数据库本身，也有前面说的外围工具，以及在这些基础之上经过实战检验的生产案例。但是现在又是一个比较好的时代，AI的快速发展使得我们可以借助AI少走不少弯路。

　　我们可以将数据库的相关信息，包括但不限于数据库本身的各类文档与案例、监控平台、IT架构及自己整理的内容等喂给AI进行学习，在帮助进行日常的监控、巡检等日常工作以外，也可以帮助进行负载预测、语句优化等工作。在有足够的高可用相关材料与实际故障处理案例的基础上，还可以结合AI搭建一套完整的高可用与故障诊断与编排平台，即可以在出现问题是结合监控与告警快速诊断问题并提供有效的操作建议（甚至可授权自动执行处置操作），也可以帮助模拟各种故障场景，协助进行日常演练操作。

　　但这也意味着数据库厂商需要更加开放，能够把一些可以称之为“底裤”的东西整理并公开出来，这可以让客户与广大数据库从业者更加深入的了解数据库，提前储备、积累一些故障案例；也可以根据不同的应用场景，使用更加合适的高可用架构，准备好相应合适的应急故障处理流程。有些数据库厂商在这方面做的很不错，不仅自己做了比较好的外围配套，也开放了很多资料。

　　当然我也理解那些生态封闭的数据库厂商，一方面是想把比如售后、交付之类的工作牢牢掌握在自己上手，稳定获得那部分收益；另一方面有些东西一旦给出去了就是把自己的弱点暴露出来，甚至可能会成为友商的攻击目标。但是我想说的，只有整个生态的繁荣，数据库才能有效发展，而且如果一些问题平时藏着掖着，在客户真实生产环境中爆发并造成严重后果的话，后果就不用我说了，艰难建立起来的信任也很可能一夜崩塌并波及出去。

　　总结

　　好好做数据库，也要好好做数据库的外围配套。