oracle怎么重建索引,如何找出Oracle中需要或值得重建的索引

01fac6460a22031b8af8da5848698a70.png

This script determines whether an index is a good candidate for a rebuild or for

a bitmap index.  All indexes for a given schema or for a subset of schema’s are

analyzed (except indexes under SYS and SYSTEM)

Instructions

Execution Environment:

Access Privileges:

Requires DBA privileges in order to be executed.

Usage:

sqlplus / @rebuild.index.sql

Instructions:

Copy the script into the file ind_an.sql. Execute the script from SQL*Plus connected

with a user with DBA privileges.  The script requires to parameters:

1. Name of the output file where the report while be generated

2. Name of the SCHEMA to be analyzed.

PROOFREAD THIS SCRIPT BEFORE USING IT! Due to differences in the way text

editors, e-mail packages, and operating systems handle text formatting (spaces,

tabs, and carriage returns), this script may not be in an executable state

when you first receive it. Check over the script to ensure that errors of

this type are corrected.

Description

This script determines whether an index is a good candidate for a rebuild or for

a bitmap index.  All indexes for a given schema or for a subset of schema’s are

analyzed (except indexes under SYS and SYSTEM).

REM =============================================================

REM

REM rebuild_indx.sql

REM

REM Copyright (c) Oracle Software, 1998 - 2000

REM

REM Author : Jurgen Schelfhout

REM

REM The sample program in this article is provided for educational

REM purposes only and is NOT supported by Oracle Support Services.

REM It has been tested internally, however, and works as documented.

REM We do not guarantee that it will work for you, so be sure to test

REM it in your environment before relying on it.

REM

REM This script will analyze all the indexes for a given schema

REM or for a subset of schema's. After this the dynamic view

REM index_stats is consulted to see if an index is a good

REM candidate for a rebuild or for a bitmap index.

REM

REM Database Version : 7.3.X and above.

REM

REM NOTE: If running this on 10g, you must exclude the

REM objects in the Recycle Bin

REM cursor c_indx is

REM select owner, table_name, index_name

REM from dba_indexes

REM where owner like upper('&schema')

REM and table_name not like 'BIN$%'

REM and owner not in ('SYS','SYSTEM');

REM

REM Additional References for Recycle Bin functionality:

REM Note.265254.1 Flashback Table feature in Oracle Database 10g

REM Note.265253.1 10g Recyclebin Features And How To Disable it(_recyclebin)

REM

REM =============================================================

prompt

ACCEPT spoolfile CHAR prompt 'Output-file : ';

ACCEPT schema CHAR prompt 'Schema name (% allowed) : ';

prompt

prompt

prompt Rebuild the index when :

prompt - deleted entries represent 20% or more of the current entries

prompt - the index depth is more then 4 levels.

prompt Possible candidate for bitmap index :

prompt - when distinctiveness is more than 99%

prompt

spool &spoolfile;

set serveroutput on;

set verify off;

set linesize 140;

declare

c_name INTEGER;

ignore INTEGER;

height index_stats.height%TYPE := 0;

lf_rows index_stats.lf_rows%TYPE := 0;

del_lf_rows index_stats.del_lf_rows%TYPE := 0;

distinct_keys index_stats.distinct_keys%TYPE := 0;

cursor c_indx is

select owner, table_name, index_name

from dba_indexes

where owner like upper('&schema')

and owner not in ('SYS', 'SYSTEM');

begin

dbms_output.enable(1000000);

dbms_output.put_line('Owner Index Name % Deleted Entries Blevel Distinctiveness');

dbms_output.put_line('-------------- --------------------------------- ------------ ----- -----');

c_name := DBMS_SQL.OPEN_CURSOR;

for r_indx in c_indx loop

DBMS_SQL.PARSE(c_name,

'analyze index ' || r_indx.owner || '.' ||

r_indx.index_name || ' validate structure',

DBMS_SQL.NATIVE);

ignore := DBMS_SQL.EXECUTE(c_name);

select HEIGHT,

decode(LF_ROWS, 0, 1, LF_ROWS),

DEL_LF_ROWS,

decode(DISTINCT_KEYS, 0, 1, DISTINCT_KEYS)

into height, lf_rows, del_lf_rows, distinct_keys

from index_stats;

/*

- Index is considered as candidate for rebuild when :

- - when deleted entries represent 20% or more of the current entries

- - when the index depth is more then 4 levels.(height starts counting from 1 so > 5)

- Index is (possible) candidate for a bitmap index when :

- - distinctiveness is more than 99%

*/

if (height > 5) OR ((del_lf_rows / lf_rows) > 0.2) then

dbms_output.put_line(rpad(r_indx.owner, 16, ' ') ||

rpad(r_indx.index_name, 40, ' ') ||

lpad(round((del_lf_rows / lf_rows) * 100, 3),

17,

' ') || lpad(height - 1, 7, ' ') ||

lpad(round((lf_rows - distinct_keys) * 100 /

lf_rows,

3),

16,

' '));

end if;

end loop;

DBMS_SQL.CLOSE_CURSOR(c_name);

end;

/

spool off;

set verify on;

Sample Output:

SQL> @rebuild_index

Output-file : index_rebuild

Schema name (% allowed) : maclean

Rebuild the index when :

- deleted entries represent 20% or more of the current entries

- the index depth is more then 4 levels.

Possible candidate for bitmap index :

- when distinctiveness is more than 99%

Owner Index Name % Deleted Entries Blevel Distinctiveness

-------------- --------------------------------- ------------ ----- -----

MACLEAN SYS_MTABLE_00000CFD4_IND_2 25 0 25

MACLEAN SYS_MTABLE_00000D3F3_IND_2 33.333 0 33.333

PL/SQL procedure successfully completed.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
一、重建索引的前提 1、表上频繁发生update,delete操作; 2、表上发生了alter table ..move操作(move操作导致了rowid变化)。 二、重建索引的标准 1、索引重建是否有必要,一般看索引是否倾斜的严重,是否浪费了空间, 那应该如何才可以判断索引是否倾斜的严重,是否浪费了空间, 对索引进行结构分析(如下): SQL>Analyze index index_name validate structure; 2、在执行步骤1的session查询index_stats表,不要到别的session去查询。 SQL>select height,DEL_LF_ROWS/LF_ROWS from index_stats; 说明:当 查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 。 举例: (t_gl_assistbalance 26 万多条信息 ) SQL> select count(*) from t_gl_assistbalance ; 输出结果: COUNT(*) ---------- 265788 SQL> Analyze index IX_GL_ASSTBAL_1 validate structure; Index analyzed SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; 输出结果: HEIGHT DEL_LF_ROWS/LF_ROWS ---------- ------------------- 4 1 三、重建索引的方式 1、drop 原来的索引,然后再创建索引; 举例: 删除索引:drop index IX_PM_USERGROUP; 创建索引:create index IX_PM_USERGROUP on T_PM_USER (fgroupid); 说明:此方式耗时间,无法在24*7环境实现,不建议使用。 2 、直接重建: 举例: alter index indexname rebuild; 或alter index indexname rebuild online; 说明:此方式比较快,可以在24*7环境实现,建议使用此方式。 四、alter index rebuild 内部过程和注意点 alter index rebuild 和alter index rebuil online的区别 1、扫描方式不同 1.1、Rebuild以index fast full scan(or table full scan) 方式读取原索引的数据来构建一个新的索引,有排序的操作; 1.2、rebuild online 执行表扫描获取数据,有排序的操作; 说明:Rebuild 方式 (index fast full scan or table full scan 取决于统计信息的cost) 举例1 SQL> explain plan for alter index IX_GL_ASSTBAL_1 rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | INDEX FAST FULL SCAN | IDX_POLICY_ID2 | 999K| 4882K| | --------------------------------------------------------------------- 举例2 SQL> explain plan for alter index idx_policy_id rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 2072K| 9M| 461 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID | | | | | 2 | SORT CREATE INDEX | | 2072K| 9M| | | 3 | TABLE ACCESS FULL | TEST_INDEX | 2072K| 9M| 461 | 举例3 ( 注意和 举例1 比较 ) Rebuil online 方式 : SQL> explain plan for alter index idx_policy_id2 rebuild online; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------| 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | TABLE ACCESS FULL | TEST_INDEX2 | 999K| 4882K| 3219 | 2 、rebuild 会阻塞 dml 操作 ,rebuild online 不会阻塞 dml 操作 ; 3 、rebuild online 时系统会产生一个 SYS_JOURNAL_xxx 的 IOT 类型的系统临时日志表 , 所有 rebuild online 时索引的变化都记录在这个表 , 当新的索引创建完成后 , 把这个表的记录维护到新的索引去 , 然后 drop 掉旧的索引 ,rebuild online 就完成了。 注意点: 1、 执行rebuild操作时,需要检查表空间是否足够; 2、虽然说rebuild online操作允许dml操作,但是还是建议在业务不繁忙时间段进行; Rebuild操作会产生大量redo log ; 五、重建分区表上的分区索引 重建分区索引方法: Alter index indexname rebuild partition paritionname tablespace tablespacename; Alter index indexname rebuild subpartition partitioname tablespace tablespacename; Partition name 可以从user_ind_partitions查找 Tablepace 参数允许alter index操作更改索引的存储空间; 六、索引状态描述 在数据字典查看索引状态,发现有三种: valid:当前索引有效 N/A :分区索引 有效 unusable:索引失效 七、术语 1、高基数:简单理解就是表列的不同值多。 2、低基数:建单理解就是表的列的不同值少。 3、以删除的叶节点数量:指得是数据行的delete操作从逻辑上删除的索引节点 的数量,要记住oracle在删除数据行后,将 “ 死 “ 节点保留在索引,这样做可以加快sql删除操作的速度,因此oracle删除数据行后可以不必重新平衡索引。 4、索引高度:索引高度是指由于数据行的插入操作而产生的索引层数,当表添加大量数据时,oracle将生成索引的新层次以适应加入的数据行,因此,oracle索引可能有4层,但是这只会出现在索引产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目,而具备4层或是更多层的需要重建。 5、每次索引访问的读取数:是指利用索引读取一数据行时所需要的逻辑I/O操作数,逻辑读取不必是物理读取,因为索引的许多内容已经保存在数据缓冲区,然而,任何数据大于10的索引需要重建。 6、什么时候重建呢? 察看 dba_indexes 的 blevel 。这列是说明索引从根块到叶快的级别,或是深度。如果级别大于等于4。则需要重建, 如下 :Select index_name,blevel from dba_indexes where blevel>=4. 另一个从重建受益的指标显然是当该索引的被删除项占总的项数的百分比。如果在20%以上时,也应当重建,如下 SQL>analyze index index_name validate structure SQL>select (del_lf_rows_len/lf_rows_len)*100 from index_stats where name= ’ index_name ’ 就能看到是否这个索引被删除的百分比。 7、什么样的重建方式更好? (1)、建索引的办法: 1.1、删除并从头开始建立索引。 1.2 、 使用 alter index index_name rebuild 命令重建索引。 1.3 、 使用 alter index index_name coalesce 命令重建索引。 (2)、下面讨论一下这三种方法的优缺点: 2.1、删除并从头开始建索引:方法是最慢的,最耗时的。一般不建议。 2.2、Alter index index_name rebuild 快速重建索引的一种有效的办法,因为使用现有索引项来重建索引,如果客户操作时有其他用户在对这个表操作,尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题,alter index index_name rebuild online。 但是,由于新旧索引在建立时同时存在,因此,使用这种技巧则需要有额外的磁盘空间可临时使用,当索引建完后把老索引删除,如果没有成功,也不会影响原来的索引。利用这种办法可以用来将一个索引移到新的表空间。 Alter index index_name rebuild tablespace tablespace_name 。 这个命令的执行步骤如下: 首先,逐一读取现有索引,以获取索引的关键字。 其次,按新的结构填写临时数据段。 最后,一旦操作成功,删除原有索引树,降临时数据段重命名为新的索引需要注意的是alter index index_name rebuild 命令必须使用tablespace字句,以保证重建工作是在现有索引相同的表空间进行。 2.3、alter index index_name coalesce 使用带有coalesce参数时重建期间不需要额外空间,它只是在重建索引时将处于同一个索引分支内的叶块拼合起来,这最大限度的减少了与查询过程相关的潜在的加锁问题,但是,coalesce选项不能用来将一个索引转移到其他表空间。 八、其他 1、truncate 分区操作和truncate 普通表的区别? 1.1、Truncate 分区操作会导致全局索引失效; truncate 普通表对索引没有影响; 1.2、Truncate 分区操作不会释放全局索引的空间,而truncate 普通表会释放索引所占空间; 2、rename 表名操作对索引没有影响,因为rename操作只是更改了数据字典,表数据行的rowid并没有发生变化 总结: 1、判断是否需要重建索引: SQL>analyze index index_name validate structure; SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; ( 或 Select index_name,blevel from dba_indexes where blevel>=4 ); 说明 : 当查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 ; 2 、重建索引方法 : 方法一、 Alter index index_name rebuild tablespace tablespace_name; 优点:是快速重建索引的一种有效的办法,可以用来将一个索引移到新的表空间。 缺点:重建期间需要额外空间。 方法二、 alter index index_name coalesce; 优点:重建期间不需要额外空间。 缺点:coalesce选项不能用来将一个索引转移到其他表空间。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值