rebuild index ..
当我们对索引进行rebuild时,如果不加online选项,oracle则直接读取原索引的数据;当我们添加online选项时, oracle是直接扫描表中的数据,维护索引段数据的一致性就是从索引开始创建到索引创建完成这段时间的数据改变的同步 。 从索引开始rebuild online 的那一刻起,oracle会先创建一个SYS_JOURNAL_xxx的系统临时日志表,结构类似于物化视图日志表mlog$_表, 通过内部触发器, 记录了开始rebuild索引时表上所发生的改变的记录,当索引已经创建好之后, 新数据将直接写入索引,只需要把SYS_JOURNAL_xxx日志表中的改变维护到索引中即可 。
在rebulid index online 的时候走的是full table scan,这时候需要排序;在rebulid index 走的index ffs,而ffs搜索的顺序是根据 leaf block 的物理存储顺序相关 ,也需要排序 。在rebuild index时候还是需要用到 temp空间来排序的 。
-----------------------------------------------------
drop index , then create index again .
drop index 之后, index 重新建立相对 rebuild index 效果是否会更好 ? 在 index 碎片方面或其他性能方面 ?
如果一个table 有数据 2000 万笔, 在删除 1/3 的记录之后,需要重新建立index , 那么采用哪种方式更好 ?
当我们对索引进行rebuild时,如果不加online选项,oracle则直接读取原索引的数据;当我们添加online选项时, oracle是直接扫描表中的数据,维护索引段数据的一致性就是从索引开始创建到索引创建完成这段时间的数据改变的同步 。 从索引开始rebuild online 的那一刻起,oracle会先创建一个SYS_JOURNAL_xxx的系统临时日志表,结构类似于物化视图日志表mlog$_表, 通过内部触发器, 记录了开始rebuild索引时表上所发生的改变的记录,当索引已经创建好之后, 新数据将直接写入索引,只需要把SYS_JOURNAL_xxx日志表中的改变维护到索引中即可 。
在rebulid index online 的时候走的是full table scan,这时候需要排序;在rebulid index 走的index ffs,而ffs搜索的顺序是根据 leaf block 的物理存储顺序相关 ,也需要排序 。在rebuild index时候还是需要用到 temp空间来排序的 。
-----------------------------------------------------
drop index , then create index again .
drop index 之后, index 重新建立相对 rebuild index 效果是否会更好 ? 在 index 碎片方面或其他性能方面 ?
如果一个table 有数据 2000 万笔, 在删除 1/3 的记录之后,需要重新建立index , 那么采用哪种方式更好 ?
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/35489/viewspace-621567/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/35489/viewspace-621567/