Oracle 重建索引的必要性

      索引重建是一个争论不休被不断热烈讨论的议题。当然Oracle官方也有自己的观点,我们很多DBA也是遵循这一准则来重建索引,那就是Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引。近来Oracle也提出了一些与之相反的观点,就是强烈建议不要定期重建索引。本文是参考了1525787.1并进行相应描述。

1、重建索引的理由     a、Oracle的B树索引随着时间的推移变得不平衡(误解)     b、索引碎片在不断增加     c、索引不断增加,删除的空间没有重复使用     d、索引 clustering factor (集群因子)不同步,可以通过重建修复(误解)

2、重建索引的本质     本质:重建索引在数据库内部是先执行删除操作,再执行插入操作。

3、反对重建索引的理由     a. 大多数脚本都依赖 index_stats 动态表。此表使用以下命令填充:         analyze index ... validate structure;

       尽管这是一种有效的索引检查方法,但是它在分析索引时会获取独占表锁。对于大型索引,其影响会是巨大的,因为在此期间不允许对表执行DML 操作。        虽然该方法可以在不锁表的情况下在线运行,但是可能要消耗额外的时间。

    b. 重建索引的直接结果是 REDO 活动可能会增加,总体系统负载也可能会提高。

       插入/更新/删除操作会导致索引随着索引的分割和增长不断发展。        重建索引后,它将连接的更为紧凑;但是,随着对表不断执行 DML 操作,必须再次分割索引,直到索引达到平衡为止。        结果,重做活动增加,且索引分割更有可能对性能产生直接影响,因为我们需要将更多的 I/O、CPU 等用于索引重建。        经过一段时间后,索引可能会再次遇到“问题”,因此可能会再被标记为重建,从而陷入恶性循环。        因此,通常最好是让索引处于自然平衡和(或)至少要防止定期重建索引。

4、Oracle的最终建议     一般而言,极少需要重建 B 树索引,基本原因是 B 树索引很大程度上可以自我管理或自我平衡。     大多数索引都能保持平衡和完整,因为空闲的叶条目可以重复使用。     插入/更新和删除操作确实会导致索引块周围的可用空间形成碎片,但是一般来说这些碎片都会被正确的重用。     Clustering factor群集因子反映了给定的索引键值所对应的表中的数据排序情况。重建索引不会对群集因子产生影响,集群因子只能通过重组表的数据改变。     强烈建议不要定期重建索引,而应使用合适的诊断工具。     个人结论,如果重建索引的巨大工作量与之对应的是极小的收益,那就得不偿失。如果系统有可用空闲期,重建之前和之后的测量结果表明性能有提高,值得重建。 5、改良方法     通常是优先考虑index coalesce(索引合并),而不是重建索引。索引合并有如下优点:        a、不需要占用近磁盘存储空间 2 倍的空间        b、可以在线操作        c、无需重建索引结构,而是尽快地合并索引叶块,这样可避免系统开销过大。

6、真正需要重建索引的情形     索引或索引分区因介质故障损坏     标记为UNUSABEL的索引需要重建     索引移动到新的表空间或需要改变某些存储参数     通过SQL*Loader加载数据到表分区后,需要重建索引分区     重建索引以启用键压缩     位图索引本质不同于B树索引,建议重建

7、相关参考

  • Oracle 聚簇因子(Clustering factor)
  • Oracle 索引监控(monitor index)
  • Oracle 索引监控与外键索引
  • 收集统计信息导致索引被监控
  • Oracle 监控索引的使用率
  • NULL 值与索引(一)
  • NULL 值与索引(二)
  • 函数使得索引列失效
  • Oracle 索引质量分析

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Spark学习技巧

Hive性能优化(全面)

面对这些问题,我们能有哪些有效的优化手段呢?下面列出一些在工作有效可行的优化手段:

1.1K40
来自专栏架构师之路

一分钟了解索引技巧 | 架构师之路

花1分钟时间,了解聚集索引,非聚集索引,联合索引,索引覆盖。 举例,业务场景,用户表,表结构为: t_user( uid primary key, login_...

404120
来自专栏枕边书

见招拆招-PostgreSQL中文全文索引效率优化

前言 上文 使用PostgreSQL进行中文全文检索 中我使用 PostgreSQL 搭建完成了一套中文全文检索系统,对数据库配置和分词都进行了优化,基本的查询...

61480
来自专栏数据之美

常用统计分析 SQL 在 AWK 中的实现

最近有需求需要本地处理一些临时的数据,用做统计分析。如果单纯的 MYSQL 也能实现, 不过一堆临时数据这样从 mysql 导来导去还是挺麻烦的,比较理想的选...

27390
来自专栏逸鹏说道

维护索引(4)——通过重组索引提高性能

前言: 如果碎片程度小于30%,建议使用重组而不是重建。因为重组不会锁住数据页或者数据表,并且降低CPU的资源。 总得来说,重组会清空当前的B-TREE,特别是...

26780
来自专栏杨建荣的学习笔记

Oracle表中含有255列以上时需要注意的(r12笔记第77天)

今天看JL(Jonathan Lewis)的一篇文章,真是费了不少的脑细胞,玩Oracle几十年的老司机,看问题的角度和深度果然不一样,当时看他的大作《O...

438100
来自专栏杨建荣的学习笔记

MySQL中的反连接(r12笔记第45天)

关于Oracle的半连接,反连接,我一直认为这是一个能讲很长时间的话题,所以在我的新书《Oracle DBA工作笔记》中讲性能优化的时候,我花了不少的笔墨做...

28350
来自专栏架构师之路

InnoDB,5项最佳实践,知其所以然?

第一篇,说说MySQL两个最常用的存储引擎,MyISAM和InnoDB。照自己的理解,把一些知识点总结出来,不只说知识点,多讲“为什么”。 一、关于count...

10520
来自专栏杨建荣的学习笔记

一个简单的sql审核案例 (r8笔记第90天)

今天开发的同学发来一封邮件,希望我帮忙对一个sql语句做一个评估。他们也着急要用,但是为了稳妥起见,还是希望我来审核一下,这是一个好的习惯。 打开邮件,看到的语...

31260
来自专栏维C果糖

史上最简单的 MySQL 教程(十九)「范式」

在数据存储之后,凡是能够通过关系寻找出来的数据,坚决不再重复存储,范式的终极目标是减少数据冗余。

42680

扫码关注云+社区

领取腾讯云代金券