V1.0

一、 目的

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

二、 适用范围

l 索引本身失效， 或者由于其他操作导致索引失效的情况

l 有索引unusable需要改为可用的情况

l 由于数据删除率过大， B-tree高度过高等导致的索引效率降低， 空间浪费的情况， 但是我们总是建议在需要的时候才去重建索引

l 移动索引至其他表空间的情况

l 无特殊说明，本手册只是针对常规B-tree索引，以及我们常用到的Local Partitioned Indexes和函数索引， 不涉及Bitmap类型和unique类型，临时表上的索引及其他复杂索引， 重建的方式为rebuild online。

三、 风险评估

l 没有指定重建索引tablespace name，导致建到了默认表空间，所在表空间不足，后续空间增长和维护困难。

l 所在表空间需要有重建后索引大小的空闲空间， 否者重建索引将会失败，需要预先加好空间。

l 若重建索引需要用到临时表空间，需确保临时表空间有重建后索引大小的空闲空间， 否者重建时的排序会失败。

l 为加快重建速度，并行重建索引完成后， 需要将索引的并行度重新改回1. 以免后来对该索引的使用开启不必要的并行。

l 重建索引时不设置nologging选项

l 重建索引时没有指定online， 结果阻塞表上的DML操作，影响应用， 但是在11G前，rebuild online 在开始和结束阶段还是会申请类型为4的TM锁，然后再做锁转化，如果当时有DML没有提交的的话， 还是会发生堵塞，所以在重建索引的时候，尽量避免并发的DML，设置online rebuild时， 在该表上将无法进行并行的DML操作。

l 在9i以及之前的版本，重建索引将不会自动收集统计信息，需要指定COMPUTE STATISTICS参数， 但是在收集索引统计信息的同时也会收集该列和表的统计信息。

l 分区索引重建时应该分别对每个分区进行重建， 在9i中加online选项的话默认会将分区索引的统计信息清除，可能引起执行计划出错。

l 移动lob的数据对象， 会自动将对lob对象所对应的lob类型的索引移动到同一个表空间， 需关注该表空间空余空间大小。

四、 操作流程

4.1准备工作

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

b) 准备重建索引脚本或命令，可用explain大致估算重建后索引需要占用的空间，检查目标表空间定义和剩余空间，检查临时表空间是否足够。

c) 检查数据库版本，确定重建索引的其他选项， 包括是否开启并行，是否收集统计信息等

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

4. 2执行过程

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

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

g) 索引重建过程中， 需要监控temp表空间的消耗，目标表空间的消耗， 以及通过v$session_longops 等其他视图查看重建的进度。

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

4.1.3验证方案

i) 常规检查：@dbcheck  @ind

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

k) 联系开发接口人进行应用检查，变更是否成功以应用测试结果为准。

l) 如果有修改统计信息， 需要检查统计信息。

五、 核心对象风险

1） 由于核心对象通常比较大， sql关联比较复杂，访问比较频繁， 重建index的变更很可能会超过十分钟，风险比较大，所以务必要在业务低峰期进行。

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

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

4） 在11G版本之前，重建索引前， 要确保索引所在表上的长事务sql已经结束。

5） 对核心大索引进行rebuild，可以在会话级加大db_file_multiblock_read_count以便加大单次读取的block的数量， 但是在linux上单次IO的上限是1M。

6） 查看索引的统计信息是否和表的统计信息相一致，再9i中，要注意到重建索引并收集索引统计信息会引起的表和索引列统计信息的改变。,

7） 需要考虑用于排序的临时表空间是否足够，如果可能会不够的话， 建议创建一个大的临时表空间用来重建索引，重建完索引后在drop掉该表空间。考虑索引所在的表空间是否足够， 是否预加空间。

六、 回退方案

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

1）若在rebuild过程中失败了，在目标表空间创建的是temporary 类型的segment， 系统会自动清理， 对原来的索引并没有影响， 但为了确保Smon已经被唤醒并清理完毕， 再一次的重建最好在一个小时之后在进行。

2）若rebuild index online 长时间没有响应，系统仍可控的话， 不要轻易尝试cancel ,试着找出阻塞的原因， 如果cancel 或kill后遇到数据字典不一致(Bug 3805539)， 如果不着急可以等待pmon自己去过清理， 如果着急的话， 可以尝试手动清理清理（10GR2后）

Logon as  sysdba

DECLARE

RetVal BOOLEAN;

OBJECT_ID BINARY_INTEGER;

WAIT_FOR_LOCK BINARY_INTEGER;

BEGIN

OBJECT_ID := 608365; 索引的OBJECT_ID

WAIT_FOR_LOCK := NULL;

RetVal := SYS.DBMS_REPAIR.ONLINE_INDEX_CLEAN ();

COMMIT;

END;

/

3）若rebuild index已经完全结束，则无法回滚到原先的索引， 对此引发的突发问题， 需要根据遇到的实际场景， 进行有效地决策。

七、 历史故障及教训

略