V1.0

一、 目的

明确删除索引操作的风险及标准流程，最大限度避免删除索引操作带来的故障。

二、 适用范围

l 由于新建了索引，冗余的索引可以删除的情况。

l 存在的索引没有在被使用或者并没有加快查询，浪费空间和降低DML效率的情况。

l 由于SQL走错执行计划，通过删除索引来调整执行计划的情况。

l 在IMP导入或者大数据量修订的时候，不允许先删除索引之后再重建的方式， 而是先设置索引不可用。

l 由于删除表所引起的索引删除不在此范围内。

l 无特殊说明，本手册只是针对常规B-tree索引，以及我们常用到的Local Partitioned Indexes和函数索引， 不涉及Bitmap类型和domain类型的索引及其他复杂索引。

l 在11G中， 如果不是为了节约空间的考虑， 可以选择将index设置成不可见，索引正常更新，但会被CBO忽略，观察三天没有问题的话再删除。

三、 风险评估

l 登陆错了schema，没有经过检查就删除，导致该schema下的同名的索引被删除。

l 试图删除没有在使用的索引前， 没有monitor一段时间， 结果发现该索引还是有在被使用的， 导致改sql走错执行计划。

l 试图删除关联强制唯一或主键的索引或者尝试删除local index的一个索引分区会报错。

l 如果索引正在被使用，尝试删除索引的话因为申请不到类型为6的TM锁，直接抛出resource busy的错误

l 在IMP等导入数据的时候删除索引， 因索引缺失引发的其他sql走错执行计划的风险。

l 索引删除后shared_pool中的与这个表相关的sql都会被aged out，必须重新分析,这个带来了潜在的风险。

l 尝试删除系统维护的Lob字段将会抛错， 只能对对应的lob字段进行操作

四、 操作流程

4.1准备工作

a) 首先要明确因何种原因删除索引，根据原因确定删除方案和时间，如果不是需要紧急处理的情况，删除索引应该安排在晚上十点后完成。

b) 准备删除索引脚本或命令，如果是删除不会被用到的索引，需要确保没有sql引用该索引， 我们通常的方式是：

1） monitoring index usage 至少一个星期， 以索引所在的schema然后查看V$OBJECT_USAGE

2） 通过查看dba_hist_sql_plan，v$segment_statistics ，idb的全文索引， AWR，报告等方式确认。

c) 删除索引前必须准备好回滚方案， copy出索引的完整定义放置变更单中， 以便能及时回滚， 并且备份索引的统计信息。

d) 删除索引操作属于一般变更或重大变更，在做之前必须在ITIL中提交相应的变更申请。

4. 2执行过程

e) 用应用账户登录数据库，SHOW USER检查是否连接到正确的schema。严禁使用sys、system等用户建表。

f) 执行删除索引脚本或命令。对于同步库， 则需根据删除原因判断是否在同步库也删除索引。

g) 查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至执行通过，最后退出当前登录。

4.1.3验证方案

h) 常规检查：@dbcheck  @ind

i) 整体的load

j) 查看关注的sql的执行计划，判断所关注的sql执行计划是否正确。

五、 核心对象风险

1） 由于核心对象通常比较大， sql关联比较复杂，访问比较频繁， 删除index的变更风险比较大，所以务必要在业务低峰期进行。

2） 对于核心对象的索引删除， 事先需要跟应用沟通一下，所制定的方案需要在同版本的测试库上做完整的测试，确认下的方案需要经过cab会议讨论，经过主管同意。

3） 在核心对象上删除索引，需要关注影响的范围是单个sql还是会影响其他sql，应该事前在SQL全文索引中，检查并整理出可能影响到的sql，如果删除后导致其他sql执行计划发生了意想不到的变化， 需要考虑后续方案或者回退方案。

六、 回退方案

删除索引的过程存在一定风险，重建后也可能会导致单条或多条sql改变执行计划，直接或间接影响到数据库和应用， 必须准备好回退方案。

1）因事先保存了索引创建的完整定义，回滚的第一选择是创建一个和原先一样的索引， 并且回滚统计信息。具体创建的方法参见《新建索引操作手册》

2）若按照原来的定义创建后问题还是没有解决，则无法回滚到原先的索引， 对此引发的突发问题， 需要根据遇到的实际场景， 进行有效地决策。

七、 历史故障及教训

暂无