标签：
在生产环境、我们会发现：
① 索引表空间 I/O 非常高
② "db file sequential read" 等待事件也比较高
这种迹象表明、整个数据库系统、索引的读写操作比较多、已经成为系统的主要瓶颈
一般的原因、大抵如下：
① 大量SQL均采用索引
② DML操作导致索引维护工作量暴增
③ 频繁DML导致很多索引碎片、增加I/O开销
④ 索引建立策略失误、走索引如同全表扫
如果、一张表字段30个、但索引竟有 50个！？
作为 DBA、你可能不了解业务逻辑、不敢删、也不知该删哪些、怎么办？
建议综合采用如下两种策略：
⑴ 根据原理去判断
这种情况肯定存在很多复合索引！依据复合索引的前缀性和可选性两大原理
分析这 50 个索引的具体字段的分布情况、自己做出合并、整合的判断
⑵ 利用 Oracle 索引监控特性
在典型业务周期开始之前、执行：
ora@node1> alter index <索引名> monitoring usage；
在典型业务周期结束之后、执行：
ora@node1> alter index <索引名> nomonitoring usage；
然后、查询：
ora@node1> select * from v$object_usage;
这样子、你就知道在这个典型周期之内、这个索引到底有木有用了
即便是这样了、可是、友情提示两下、上面的结论不一定正确、因为：
① 10g在收集统计信息时会导致索引被监控、这并非SQL语句产生、而在11g则不会出现这种情况了
② 外键索引不会因为主表的DML操作而被监控到、不要因为该索引没用而将它给删了
不过、这里、毕竟还会有个问题、对于一个复杂系统来说，索引的数量可能是庞大的
那么、我们该如何选择嫌疑对象、减少监控范围呢？
以下介绍两种方法：
① 利用 library cache 数据
在library cache中，存储了系统中游标的查询计划(并非全部，受library cache大小的限制)
通过视图v$sql_plan，我们可以查询到这些数据。利用这些数据，我们可以排除那些出现在查询计划中的索引：
② 利用 AWR 数据
10g以后，我们可以借助 AWR 分析哪些索引被使用到了
利用上述方法，过滤掉大部分肯定被使用的index后，再综合应用，选择可疑索引进行监控，找出并删除无用索引，为数据库减肥
频繁对索引字段进行 DML操作、会对索引造成大量碎片、从而极大影响索引的使用效率、并造成索引I/O的增加
那么如何进行索引碎片的分析和整理呢？
执行如下语句可监测索引的碎片情况：
analyze index <索引名> validate structure online;
select name,（del_lf_rows_len/lf_rows_len)*100 from index_stats;
其中、索引碎片率(%)=（del_lf_rows_len/lf_rows_len)*100
如果索引碎片率超过20%、则Oracle认为索引碎片已经非常严重
建议DBA编写一个检测所有索引碎片率的脚本、定期运行、保持对索引碎片率的监测
因为、进行索引碎片分析和整理是DBA日常维护的工作之一
Oracle 进行索引碎片的处理包括两种策略：
① 重建索引
alter index <索引名> rebuild;
② 压缩索引
alter index <索引名> coalesce；
不过、Rocky 建议大家采取定期索引重建的策略、例如可在每个周末或者每天夜晚对挥发表的索引进行在线重建
本文转自：http://blog.csdn.net/dba_waterbin/article/details/8805010
标签：
原文地址：http://www.cnblogs.com/nizuimeiabc1/p/4846815.html
