2.5.4 废旧索引清理

索引这东西和表不一样,对于表来说往往可以很明确什么时候新建,什么时候下线。索引则不然,新建索引可以很明确,但在表没有下线的时候,我们往往会非常纠结索引是不是可以下线。如果将一个尚有业务使用的索引下线了,那将意味着一场灾难,由此而导致DBA们都不敢删除索引,结果就成了一个表上的索引越来越多。

那如何解决这个问题呢?简单来说就是严进严出,不轻易新建更不轻易删除。如前面章节介绍的一样,新建的时候要做好性能影响分析,删除的时候更要严格做好性能影响分析。那废旧索引清理的时候需要如何来做性能分析呢?Oracle给了我们一个不错的选择,就是索引的使用情况监控(INDEX USAGE MONITOR)。

我们可以开启索引idx_alex_t05_id的使用监控,然后可以通过数据字段动态性能视图v$object_usage来进行查询监控情况,其中看到USED栏位显示该索引的使用状态为“NO”,那在此次监控期间内该索引未被使用到,可以考虑删除。示例如下所示:

SQL> alter index idx_alex_t05_id monitoring usage;
Index altered

SQL> select index_name, monitoring, used from v$object_usage;

INDEX_NAME                     MONITORING  USED
-------------------------- ----------- ----
IDX_ALEX_T05_ID               YES          NO

仔细思考一下,这个方法算不算很靠谱呢?当然不算,这仅是一种治标不治本的方法。如果监控期间本身就有性能问题,SQL的执行计划“跑偏”了,导致索引没有用到,此时若以此监控情况而删除了索引,那就是不理智的。或者说,在监控期间内,会使用到该索引的SQL很幸运的都没有跑,那很不幸的就又会出现索引误删的情况。为了减少以上情况的出现,我们可以如下改善:

q  选择数据库高峰期实施索引监控,以及尽可能使用较长的监控周期。

q  可以对特定时间段实施多次监控采样。

我们展开一下想象,是谁在使用索引?SQL语句嘛,而此方法是在SQL语句执行的末期进行监控,是一种被动的把关,故不为推荐,但可以作为一种辅助手段。那比较靠谱的做法是什么呢?当然是在SQL语句执行的初期就进行把关,或者说在SQL语句还没有执行的时候就进行把关,再结合索引监控进行前追后堵,基本上可以做到万无一失了。要达到这个目的,我们就需要:

q  先扫描程序代码,主动地去发现可能用到该索引的SQL语句;

q  同时通过Oracle 11g引进的SPA等工具进行必要SQL语句的抓取;

q  最后根据以上SQL语句进行性能影响分析(具体的方法之后的章节将会介绍)。

不要说这会带来多大的工作量,DBA的工作本身就不容易,对待索引新建和删除这样敏感的操作更加需要十二分的精神,尽可能地把工作做在前面,主动预防潜在的数据库问题,才不会出现本可以不出现的生产故障。

Trackback

no comment untill now

Add your comment now

切换到手机版