Oracle alter index rebuild 说明

在ITPUB 论坛上看到的一个帖子，很不错。根据论坛的帖子重做整理了一下。 原文链接如下：

alter index rebuild online引发的血案

http://www.itpub.net/thread-1445427-1-1.html

一. 官网说明

在MOS 上的一篇文章讲到了rebuild online 和offline的区别：

Index Rebuild Is Hanging Or Taking Too Long [ID 272762.1]

Symptoms:
=========
Performance issues while rebuilding very large indexes. The offline rebuilds of their index is relatively quick -finishes in 15 minutes. Issuing index rebuild ONLINE statement => finishes in about an hour. This behavior of ONLINE index rebuilds makes it a non-option for large tables as it just takes too long to scan the table to rebuild the index. The offline may not be feasible due to due to the 24/7 nature of the database. This may be a loss of functionality for such situations. If we attempt to simultaneously ONLINE rebuild the same indexes we may encounter hanging behavior indefinitely (or more than 6 hours).

DIAGNOSTIC ANALYSIS:
--------------------
We can trace the sessions rebuilding the indexes with 10046 level 12. Comparing the IO reads for the index-rebuild and the index-rebuild-online reveals the following:
ONLINE index rebuilds： It scans the base table and it doesn't scan the blocks of the index.
OFFLINE index rebuilds：It scans the index for the build operation.

This behaviour is across all versions.

Cause/Explanation
=============
When you rebuild index online, it will do a full table scan on the base table. At the same time it will maintain a journal table for DML data, which has changed during this index rebuilding operation. So it should take longer time, specially if you do lots of DML on the same table,while rebuilding index online.
-- rebuild index online的时候，会选择全表扫描，同时会维护一个中间日志表，用来记录在rebuild 期间的增量数据，原理类似于物化视图日志，日志表是一个索引组织表(IOT)，这张中间表只有插入，不会有删除和修改操作，而且只有主键条件查询，正是IOT最合适的场景。

On the other hand, while rebuilding the index without online option, Oracle will grab the index in X-mode and rebuild a new index segment by selecting the data from the old index. So here we are not allowing any DML on the table hence there is no journal table involved and it is doing an index scan. Hence it will be pretty fast.

--rebuild offline时，选择的6模式的X 锁，它根据old index 来rebuild。 因此不允许进行DML，也就没有中间表。因此也比较块。

Solution/Conclusion:
===========
- The ONLINE index rebuild reads the base table, and this is by design.
- Rebuilding index ONLINE is pretty slow.
- Rebuilding index offline is very fast, but it prevents any DML on the base table.

二. rebuild index 说明

有关锁的模式信息如下：

锁模式	锁描述	解释	SQL操作
0	none
1	NULL	空	Select
2	SS(Row-S)	行级共享锁，其他对象只能查询这些数据行	Select for update、Lock for update、Lock row share
3	SX(Row-X)	行级排它锁，在提交前不允许做DML操作	Insert、Update、 Delete、Lock row share
4	S(Share)	共享锁: 阻止其他DML操作	Create index、Lock share
5	SSX(S/Row-X)	共享行级排它锁：阻止其他事务操作	Lock share row exclusive
6	X(Exclusive)	排它锁：独立访问使用	Alter table、Drop able、Drop index、Truncate table 、Lock exclusive

锁 死锁 阻塞 Latch 等待 详解

http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5822674.aspx

DML操作一般要加两个锁，一个是对表加模式为3的TM锁，一个是对数据行的模式为6的TX锁。只要操作的不是同一行数据，是互不阻塞的。

在rebuild index online 的开始和结束阶段时，需要短暂的对表持有模式为4的TM锁的，当获取到4级别的锁之后，才降为2级。如果rebuild online一直没获取到4级别的锁,那么相关的DML全部产生等待。 在执行期间只持有模式2的TM锁，不会阻塞DML操作。 在Oracle 11g之后,oracle做了特殊处理,后续的dml不会被rebuild online的4级别锁阻塞.

所以如果在执行rebuild index online前长事务，并且并发量比较大，则一旦执行alter index rebuild online，可能因为长事务阻塞，可能导致系统瞬间出现大量的锁，对于压力比较大的系统，这是一个不小的风险。这是需要迅速找出导致阻塞的会话kill掉，rebuild index online一旦执行，不可轻易中断，否则可能遇到ORA-08104。

MOS 的文档：

Session Was Killed During The Rebuild Of Index ORA-08104 [ID 375856.1]

While running an online index rebuild your session was killed or otherwise terminated abnormally. You are now attempting to run the index rebuild again and is throwing the error:
ORA-08104: this index object ##### is being online built or rebuilt

关于这个错误NiGoo 同学的blog 有说明，链接如下：

http://www.ningoo.net/html/2007/dba_memo_online_rebuild_index_encounter_ora-08104.html

根据以上说明，我们可以知道在进行online rebuild 的时候，Oracle 会修改如下信息：

（1）修改ind$中索引的flags，将该flags+512. 关于这个flags的含义，在下面的实验中进行说明。

（2）在该用户下创建一个journal table 来保存在rebuild期间的增量数据。 该表明名称: sys_journal_<object_id>.

如果异常结束online rebuild操作，那么oracle就没及时清理journal table和ind$的flags标志位，系统会认为online rebuild还在操作。

当然SMON 进程会来处理这些临时段。 在maclean 同学(10g,11g OCM)的Blog里提到了功能：

了解你所不知道的SMON功能(一):清理临时段

http://www.oracledatabase12g.com/archives/smon-cleanup-temporary-segment.html

对于永久表空间上的temporary segment，SMON会三分钟清理一次(前提是接到post)，如果SMON过于繁忙那么可能temporary segment长期不被清理。temporary segment长期不被清理可能造成一个典型的问题是:在rebuild index online失败后，后续执行的rebuild index命令要求之前产生的temporary segment已被cleanup，如果cleanup没有完成那么就需要一直等下去。

如果SMON 不能及时清理，在操作时就会报ORA-08104的错误。

在Oracle10gR2中可以使用dbms_repair.online_index_clean手工清理这些信息，在Oracle 9i下，需要打Bug 3805539 后才可以使用该工具。

手工处理的步骤如下：

（1）先查看ind$ flags 标志，如果不正确，就减去512.

sql>update ind$ set flags=flags-512 where obj#=<object id>;

（2）drop journal table，这个步骤可能会报资源忙，因为有大量的日志正在插入，可以反复重试一下。

sql>drop table <owner>.sys_journal_<object_id>;

注意：

这个步骤不能反，如果先删除sys_journal_<object_id>临时表，然后再修改index的flags状态，则会报出ora-600 [4610]号错误，即数据字典不一致的错误。

官网关于dbms_repair.online_index_clean 的说明：

ONLINE_INDEX_CLEAN Function

This function performs a manual cleanup of failed or interrupted online index builds or rebuilds. This action is also performed periodically by SMON, regardless of user-initiated cleanup.

This function returns TRUE if all indexes specified were cleaned up and FALSE if one or more indexes could not be cleaned up.

Syntax

DBMS_REPAIR.ONLINE_INDEX_CLEAN (

object_id IN BINARY_INTEGER DEFAULT ALL_INDEX_ID,

wait_for_lock IN BINARY_INTEGER DEFAULT LOCK_WAIT)

RETURN BOOLEAN;

Parameters

Parameter	Description
object_id	Object id of index to be cleaned up. The default cleans up all object ids that qualify.
wait_for_lock	This parameter specifies whether to try getting DML locks on underlying table [[sub]partition] object. The default retries up to an internal retry limit, after which the lock get will give up. If LOCK_NOWAIT is specified, then the lock get does not retry.

因此在做rebuild index online的时候，一定要在开始和结束阶段观察系统中是否有长事务的存储，对于并发量较大的系统，最严重的后果，可能在这两个关键点导致数据库产生大量锁等待，系统负载飙升，甚至宕机。

三. rebuild index 的一些测试

NiGoo 的blog 上示例：

http://www.ningoo.net/html/2008/lock_mechanism_of_rebuild_index_online.html

3.1 准备工作

先创建一个测试表：

SYS@anqing2(rac2)> create table rb_test(id number,con varchar2(20));

Table created.

插入一些测试数据：

SYS@anqing2(rac2)> begin

2 for i in 1..1000000 loop

3 insert into rb_test values(i,'hello DBA');

4 if mod(i,1000)= 0 then

5 commit;

6 end if;

7 end loop;

8 end;

9 /

PL/SQL procedure successfully completed.

在ID 字段上创建索引：

SYS@anqing2(rac2)> create index idx_rbt_id on rb_test(id);

Index created.

3.2 测试默认的rebuild,即rebuild offline

3.2.1 场景1

session 1:

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild;

因为表比较大，执行需要一定的时间，我们到session 2上查看lock。

session 2：

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

147 DL 53366 0 3 0 2

147 DL 53366 0 3 0 2

147 TM 53366 0 4 0 2

这时候持有的LMODE 4的锁，即在rebuild 期间我们不能执行DML 操作。

这里的lock 类型说明：

TM : DML enqueue 表级锁

TX : Transaction enqueue 行级锁

DL : Direct loader parallel index create

更多信息，参考联机文档：

V$LOCK

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_1147.htm#REFRN30121

3.2.2 场景2

我们update 一下rb_test 表，但不提交，在rebuild offline 看一下：

session 1：

SYS@anqing2(rac2)> update rb_test set con='hello Dave!' where id=168;

1 row updated.

session 2:

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild;

alter index idx_rbt_id rebuild

*

ERROR at line 1:

ORA-00054: resource busy and acquire with NOWAIT specified

我们这时候rebuild 的时候报错。

session 1：提交修改

SYS@anqing2(rac2)> commit;

Commit complete.

session 2：

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild;

Index altered.

3.2.3 场景3

在索引rebuild 期间，我们去update table，并查看v$lock

先查看一个正常update的时间：

SYS@anqing2(rac2)> set timing on

SYS@anqing2(rac2)> update rb_test set con='hello Dave!' where id=168;

1 row updated.

Elapsed: 00:00:00.00

SYS@anqing2(rac2)> commit;

session 1:

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild;

Index altered.

Elapsed: 00:00:11.76

session 2:

SYS@anqing2(rac2)> update rb_test set con='hello Dave!' where id=168;

1 row updated.

Elapsed: 00:00:11.00 -- 这个时间是在等rebuild 操作的结束

session 3: 查看锁信息

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

147 DL 53366 0 3 0 2

147 DL 53366 0 3 0 2

147 TM 53366 0 4 0 1

153 TM 53366 0 0 3 0

SID 153 是我们的update ， 它在request mode 为3的lock。

等我们的rebuild 结束，我们在查看一下锁信息：

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

153 TM 53366 0 3 0 2

153 TX 1114130 289 6 0 2

此时我们的update 的已经修改，但还没有提交。 这个就和我们之前说的一致： DML操作一般要加两个锁，一个是对表加模式为3的TM锁，一个是对数据行的模式为6的TX锁。

我们在session 2上commit 一下，在查看一下：

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

no rows selected

测试已经没有相关的lock了。

3.3 测试 rebuild online

3.3.1 场景1

测试步骤：

（1）sesssion 1：先update 一条记录，但不commit，这时session 持有TM 3 和 TX 6的lock。

（2）session 2： rebuild online

（3）session 3：在进行update 操作

session 1:

SYS@anqing2(rac2)> update rb_test set con='hello Dave!' where id=168;

1 row updated.

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

153 TM 53366 0 3 0 2

153 TX 1179653 288 6 0 2

session 2:

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

-- 测试session 挂住在这

查看一下lock

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

147 DL 53366 0 3 0 2

147 DL 53366 0 3 0 2

153 TM 53366 0 3 0 1

147 TM 53366 0 2 4 2

147 TM 53386 0 4 0 2

153 TX 1179653 288 6 0 2

6 rows selected.

SID 153 是我们之前的update 操作，该DML 只有3和6锁。 147 是我们的rebuild online。 该操作在申请lock mode 为4的锁。 在没有申请到锁之前所有的操作都会被挂住，我们到session 3上在开一个update 验证一下：

session 3：

SYS@anqing2(rac2)> update rb_test set con='hello Dave!' where id=188;

-- 也是挂住的，我们看一下lock

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

147 DL 53366 0 3 0 2

147 DL 53366 0 3 0 2

153 TM 53366 0 3 0 1

147 TM 53366 0 2 4 2

147 TM 53386 0 4 0 2

143 TM 53366 0 0 3 0

153 TX 1179653 288 6 0 2

7 rows selected.

这里多一个SID 143， 它在申请 TM 3的锁，申请成功之后在去申请TX 6. 但没有拿到TM 3，所以也挂住了。

这个就是我们前面说的一种情况， 当前有大量的事务在操作，我们去rebuild online。 我们的rebuild online 需要拿到TM 4的lock。 如果拿不到就挂在那，并且之后的事务也没办法进行。 如果这个表的事务操作很频繁，数据库就会产生大量锁等待，系统负载飙升，甚至宕机。

这个问题的解决方法就是找到阻止rebuild inline 拿到 TM 4的session。 把它kill 掉， 这样rebuild 拿到TM 4之后就会降到TM 2. 这样其他的DML 就可以操作了。

这点和rebuild offline的区别， 如果是当前有事务操作，rebuild offline 就不会执行，直接报ORA-00054: resource busy and acquire with NOWAIT specified的错误。

后续操作：

session 1： commit

SYS@anqing2(rac2)> commit;

Commit complete.

查看lock 信息：

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

SID TY ID1 ID2 LMODE REQUEST BLOCK

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

147 DL 53366 0 3 0 2

147 DL 53366 0 3 0 2

147 TM 53366 0 2 4 2

147 TM 53386 0 4 0 2

143 TM 53366 0 3 0 1

143 TX 1048602 287 6 0 2

147 TX 983080 291 6 0 2

这里还有两个锁，147 是我们的rebuild online。 143 是我们之前session 3的update DML。

这里要注意的是，如果我们的session 3 不commit，那么我们的rebuild online 还是不会结束。 因为rebuild online 在开始和结束的时候需要申请去拿TM 4的lock。 现在rebuild online 的被我们的session 3阻止了。 在开始是被session 1 阻止了。

我们在session 3 提交一下，在查看lock：

SYS@anqing2(rac2)> commit;

Commit complete.

SYS@anqing2(rac2)> select sid,type,id1,id2,lmode,request,block from v$lock where type in('DL','TM','TX');

no rows selected

rebuild 结束

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

Index altered.

Elapsed: 00:16:44.86

由此可见rebuild online 是个需要谨慎使用的命令。

3.3.2 场景2

在前面说过， kill 掉正在rebuild online 的session。 可能会导致在下次rebuild index或者drop，analyze 的时候报ORA-08104的错误。 因为在异常终止online rebuild操作的时候，oracle没来得及清理相应的临时段和标志位，系统认为online rebuild操作还在进行造成的。

在这里我们就模拟一下这个操作。

在rebuild online 的时候，按下ctrl + c 结束：

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

alter index idx_rbt_id rebuild online

*

ERROR at line 1:

ORA-01013: user requested cancel of current operation

Elapsed: 00:00:01.78

SYS@anqing2(rac2)> exec dbms_stats.gather_table_stats('SYS','RB_TEST');

PL/SQL procedure successfully completed.

Elapsed: 00:00:07.02

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

Index altered.

Elapsed: 00:00:09.38

没有报错。 把数据量弄大一点。在试试

SYS@anqing2(rac2)> insert into rb_test select * from rb_test;

1000000 rows created.

Elapsed: 00:00:23.68

SYS@anqing2(rac2)> commit;

Commit complete.

Elapsed: 00:00:00.08

SYS@anqing2(rac2)> insert into rb_test select * from rb_test;

2000000 rows created.

Elapsed: 00:01:54.36

SYS@anqing2(rac2)> commit;

Commit complete.

Elapsed: 00:00:00.00

用kill session 的方法试试：

SYS@anqing2(rac2)> alter system kill session '147,31436';

System altered.

Elapsed: 00:00:01.01

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

alter index idx_rbt_id rebuild online

*

ERROR at line 1:

ORA-00028: your session has been killed

Elapsed: 00:00:10.89

还是没有报错：

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

Index altered.

Elapsed: 00:00:51.65

比较顽强啊。 有点小崩溃。 再来：

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

启动rebuild online 之后，直接把ssh 强行关闭。

在次ssh 过去，尝试rebuild online：

SYS@anqing2(rac2)> alter index idx_rbt_id rebuild online;

alter index idx_rbt_id rebuild online

*

ERROR at line 1:

ORA-08104: this index object 53367 is being online built or rebuilt

终于报错了。 不容易啊。 不过这个测试也说明了，在rebuild online 期间不能强行关闭ssh。 如果在期间断网的话，估计效果相当。

查看Flag：

SYS@anqing2(rac2)> select obj#,flags from ind$ where obj#=53367;

OBJ# FLAGS

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

53367 514

根据NiGoo blog 上的说明，可以通过ind$的flags查看是什么类型的标志。

sql.bsq 是个总的说明，在dcore.bsq 里找到了ind$的创建SQL：

/* mutable flags: anything permanent should go into property */
/* unusable (dls) : 0×01 */
/* analyzed : 0×02 */
/* no logging : 0×04 */
/* index is currently being built : 0×08 */
/* index creation was incomplete : 0×10 */
/* key compression enabled : 0×20 */
/* user-specified stats : 0×40 */
/* secondary index on IOT : 0×80 */
/* index is being online built : 0×100 */
/* index is being online rebuilt : 0×200 */
/* index is disabled : 0×400 */
/* global stats : 0×800 */
/* fake index(internal) : 0×1000 */
/* index on UROWID column(s) : 0×2000 */
/* index with large key : 0×4000 */
/* move partitioned rows in base table : 0×8000 */
/* index usage monitoring enabled : 0×10000 */

这里的0×200 等是十六进制来表示的。 Flags 是514， 其16进制是是202，514=0×202，表示该索引状态为index is being online rebuilt : 0×200 + analyzed : 0×02

在上面，我们说减去512. 512 的16进制是200. 对应的是：/* index is being online rebuilt : 0×200 */。 所以，我们在rebuild的时候，会对flags 加上512.

MOS 803008.1 上的说明：

SMON should cleanup the failed online index rebuild operation and so correct this. However, if the table is highly active with transactions, SMON may not be able to get the required lock and so the index will not get cleaned up. In such situations, you can manually cleanup the failed index rebuild using the DBMS_REPAIR.ONLINE_INDEX_CLEAN procedure.

To do this, if activity on the problem table can be stopped, then simply execute:

connect / as sysdba
select dbms_repar.online_index_clean(<problem index object_id>) from dual;
exit

不过这个命令执行没有成功：

SYS@anqing2(rac2)> select dbms_repair.online_index_clean(53367) from dual;

select dbms_repair.online_index_clean(53367) from dual

*

ERROR at line 1:

ORA-06552: PL/SQL: Statement ignored

ORA-06553: PLS-382: expression is of wrong type

纠结中...

If activity on the table cannot be stopped, then it may be possible to resolve the problem using the following PL/SQL block:

declare
isClean boolean;

begin
isClean := FALSE;
while isClean=FALSE loop
isClean := dbms_repair.online_index_clean(dbms_repair.all_index_id,
dbms_repair.lock_wait);
dbms_lock.sleep(2);
end loop;

exception
when others then
RAISE;
end;
/

或者：

DECLARE

RetVal BOOLEAN;

OBJECT_ID BINARY_INTEGER;

WAIT_FOR_LOCK BINARY_INTEGER;

BEGIN

OBJECT_ID := 53367;

WAIT_FOR_LOCK := NULL;

RetVal := SYS.DBMS_REPAIR.ONLINE_INDEX_CLEAN ();

COMMIT;

END;

/

SYS@anqing2(rac2)> select obj#,flags from ind$ where obj#=53367;

OBJ# FLAGS

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

53367 2

在这个测试上也是相当的纠结。 之前产生了ORA-08104的错误，但是如果之后没有其他的DML 来操作这张表，那么online rebuild 产生的lock 一段时间之后就会释放掉，然后ind$的flag 也会变成2. 即正常状态。

如果事务A阻止online rebuild申请TM 4锁，那么之前所有的事务都会挂住，当事务A commit之后，相关的锁会释放，索引也会变成正常状态。

在执行clean命令的时候，可能会遇到：

ORA-00054: resource busy and acquire with NOWAIT specified

多执行几次就ok了。 应该也是和这个锁有关。

可能还是环境模拟的有问题。 这个测试总感觉怪怪的。 纠结啊。

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

Blog： http://blog.csdn.net/tianlesoftware

Email: [e-mail]

DBA1 群：62697716(满); DBA2 群：62697977(满) DBA3 群：62697850(满)

DBA 超级群：63306533(满); DBA4 群： 83829929 DBA5群： 142216823

DBA6 群：158654907 聊天 群：40132017 聊天2群：69087192

--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请