1.    失效索引管理

数据库DBA经常碰到这样的困惑，怎么一上班数据库性能就变得这么差，服务器的CPU、IO使用率噌噌地往上涨。如果告警及时、值班在线、处理得当，那大事化小，否则又是一次生产事故，被领导叫去思想教育是难免，搞不好还得罚款。分析事故原因，昨天晚上业务进行数据库对象维护，维护过程中表上的索引失效了，但维护完成后没有没有检查并rebuild索引。晚上业务量很小，功能测试没问题，但是上班后，并发量一上来，本来应该走索引的核心SQL，变成了走全表扫描，然后就变成个灾难。

在ankole数据库运维平台中失效索引管理模块，定期检查数据库中是否有新的索引、索引分区失效。如果发现了数据库有索引失效，运维平台将自动向数据库的业务负责人发送出现索引或索引分区失效的告警短信。

业务负责人接收到告警短信后，就可以通过自助服务中的“失效索引管理”页面进行检查、确认，在“失效索引管理”页面上有索引的失效时间，如果是后期追查，可以根据这个时间点去追查当时的维护过程，避免同类事情的发生。

有些数据库可能以前就存在相当多的失效索引，在ankole运维平台上进行维护是否需要全部rebuild好？这就是个仁者见仁，智者见智的事情。有些维护人员认为，这些失效索引不影响数据库性能无需关注，但从管理上来讲，数据库存在失效索引就不是个合理的事情，因为不知道这些索引什么时侯要被用，如果觉得不重要，不如把索引删除掉，还可以减少空间占用，节省保贵的存储资源。但DBA又不清楚业务的运行规则，所以这些不符合要求的历史遗留问题，一直得不到解决。

Ankole运维平台提供了失效索引基线功能，新增加的运维数据库如果一开始就发现了失效索引，但是无法确认是否需要rebuild或删除时，则把这些索引或索引分区加入失效索引基线中，这些失效索引不会告警。随着数据库的运行，如果业务在后面的维护过程中将这些失效索引rebuild或者drop，则将从运维平台的失效索引基线中删除这些恢复的信息。所以，慢慢地整个失效索引基线将越来越小。Ankole数据库运维平台将所有数据库的失效索引进行慢慢自愈。

2.    AWR TopSQL分析

有些业务维护的小伙伴责任心是比较强的，在完成本职工作后，会来问问DBA，我们的系统有啥可以优化的内容，有啥TopSQL需要看看，或者是当数据库系统负载比较大时，业务维护小伙伴又会过来问一下，是哪些SQL执行得比较慢，比较耗资源需要关注。以前DBA总是出一下AWR报告，然后告诉业务的维护人员，需要关注那些TopSQL的内容，随着这些交互的变多，DBA的时间又不够用了。

在ankole数据库运维平台中提供了AWR TopSQL分析功能，通过选中数据库就可以直观地看到哪些SQL的耗费比较高。

通过左边的桑基图就可以很直观地看到，哪个SQL的耗费比较大。在左边是时间序列，右边是耗费较高的SQL，线条越粗，表明SQL的耗费越高，这些SQL就需要业务维护人员去关注和分析。

在AWR TopSQL分析页面中提供按“执行时间”、“逻辑读”、“CPU”三个维度进行分析，在页面中可以显示SQL文本、执行计划、执行次数历史、平均每次执行时间历史等。

3.    总结

在ankole数据库运维平台中提供了很多帮助业务自行分析、解决问题的自助服务功能，有些是以短信告警的方式在提供帮助。随着ankole数据库运维平台的深入开发，各种需求纷至沓来，ankole数据库运维平台将把这些需求分析与实现，在DBA照顾不过来时，帮助业务可以自行分析、解决问题，节省DBA的宝贵时间。