频道栏目
读书频道 > 数据库 > Oracle > 高并发Oracle数据库系统的架构与设计
2.5.4 废旧索引清理
2014-11-29 14:59:49     我来说两句
收藏   我要投稿
Foreword?推 荐 序 一文以载道 书以自娱侯松的新书付梓,嘱我为序,品读精华章节,览其前言,心有所感,遂言而记之。关于写作之因由,于作者来说,一直是最为重要的缘起。认真地写作一本好书,其中的坚持、勤  立即去当当网订购
索引这东西和表不一样,对于表来说往往可以很明确什么时候新建,什么时候下线。索引则不然,新建索引可以很明确,但在表没有下线的时候,我们往往会非常纠结索引是不是可以下线。如果将一个尚有业务使用的索引下线了,那将意味着一场灾难,由此而导致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很幸运的都没有跑,那很不幸的就又会出现索引误删的情况。为了减少以上情况的出现,我们可以这样改善:
选择数据库高峰期实施索引监控,以及尽可能使用较长的监控周期;
可以对特定时间段实施多次监控采样。
 
我们展开一下想象,是谁在使用索引?SQL语句嘛,而此方法是在SQL语句执行的末期进行监控,是一种被动的把关,故不为推荐,但可以作为一种辅助手段。那比较靠谱的做法是什么呢?当然是在SQL语句执行的初期就进行把关,或者说在SQL语句还没有执行的时候就进行把关,再结合索引监控进行前追后堵,基本上可以做到万无一失了。要达到这个目的,我们就需要:
先扫描程序代码,主动地去发现可能用到该索引的SQL语句;
同时通过Oracle 11g引进的SPA等工具进行必要SQL语句的抓取;
最后根据以上SQL语句进行性能影响分析(具体的方法之后的章节将会介绍)。
 
不要说这会带来多大的工作量,DBA的工作本身就不容易,对待索引新建和删除这样敏感的操作更加需要十二分的精神,尽可能地把工作做在前面,主动预防潜在的数据库问题,才不会出现本可以不出现的生产故障。
您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:2.5.3 如何重建索引
下一篇:Oracle内核技术揭密
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站