偶遇ORA-01450

这几天在测试环境部署一个适合多种操作系统多种数据库多实例的监控脚本的时候,在一台测试库上监控到一个索引失效,于是根据提示尝试online rebuild

alter index NINGOO.IDX_TEST_KPI_NAME rebuild online compute statistics;  

SQL> alter index NINGOO.IDX_TEST_KPI_NAME rebuild online compute statistics; 
alter index NINGOO.IDX_TEST_KPI_NAME rebuild online compute statistics
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01450: maximum key length (3215) exceeded

看了下索引是创建在一个varchar2(4000)的列上的:

SQL>  select table_name,column_name,column_length from all_ind_columns where index_name='IDX_TEST_KPI_NAME';

TABLE_NAME      COLUMN_NAME            COLUMN_LENGTH
--------------- ---------------------- -------------
TEST            KPI_NAME               4000

我们知道一个index key不能跨多个block,所以key的长度有限制的。但是索引既然创建成功,这个要求肯定是满足的。实际测试下,对于8K的block,这个限制应该是6398字节。

SQL>  create table test1(a varchar2(4000),b varchar2(4000));
Table created.

SQL> create index ix_test1 on test1(a,b);
create index ix_test1 on test1(a,b)
                         *
ERROR at line 1:
ORA-01450: maximum key length (6398) exceeded

那为什么4000字节的key在online rebuild的时候会有问题呢?而创建和正常rebuild操作都是正常的。

SQL>  create index ix_test1 on test1(a);
Index created.

SQL> alter index ix_test1 rebuild online;
alter index ix_test1 rebuild online
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01450: maximum key length (3215) exceeded

SQL> alter index ix_test1 rebuild;
Index altered.

原因在于IOT表的一些限制,我们可以创建一个IOT表验证一下:

SQL> create table test_iot1(a varchar2(4000),b varchar2(4000),
  2               constraint iot1_pk primary key(a,b))
  3                organization index;
create table test_iot1(a varchar2(4000),b varchar2(4000),
*
ERROR at line 1:
ORA-01450: maximum key length (3215) exceeded

Online rebuild的过程中需要创建一个临时的IOT表,所以online rebuild的index 的key的长度限制就被大大缩短了。这一点在我们设计系统的索引的时候要特别注意,如果前期设计的索引超过了IOT index key的长度限制,则后期的维护成本会更高,因为无法online rebuild,则rebuild的时候就会锁表导致业务受到较长时间的中断。

当然,实际业务场景中,在varchar2(4000)列上创建索引并不常见,如果真的需要,也可以考虑只创建部分前缀的函数索引,但这需要业务的SQL也做相应修改,这一点上,PostgreSQL直接支持的前缀索引就要灵活得多。

SQL> create index ix_test1_2 on test1(substr(a,1,100));
Index created.

SQL> alter index ix_test1_2 rebuild online;
Index altered.

对于这个问题,旺旺同学和Jonathan Lewis同学很早就有描述,只是没碰到一般很少碰到key这么长的索引而不容易注意到,再次记录下备忘。

rebuild index online的锁机制浅析(续)

上一篇文章介绍了Oracle10.2.0.4中rebuild index online的锁机制,在开始和结束的时候需要对表加一个模式为4的TM锁,导致在这两个时刻会短暂的阻塞DML。到了Oracle11g,这种情况有所变化,还是通过同样的实验来观察一下Oracle11g到底做出了怎样的改进,对于DBA来说又有怎样的好处。实验环境为Oracle11.1.0.6

session 1:

SQL> delete from t where object_id=28;

1 row deleted.

session 2:

SQL> alter index ix_t rebuild online;

session 2同样被挂起,查看v$lock:

SQL> select sid,type,id1,id2,lmode,request from v$lock where type in('DL','TM','TX'); 

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TX     458781        377          0          4
       170 TM      13596          0          3          0
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       170 TX     458781        377          6          0
       137 TX     524304        402          6          0

其中170为session 1,137为session 2。可以看到session 2正在请求一个模式为4的TX锁,注意和Oracle10.2.0.4请求的TM锁是不一样的,而且在我们以前的概念中,TX锁的模式都是6,这里出现了模式4的TX锁请求,应该是Oracle11g中新引入的。那么模式4的TX锁和TM锁有什么不同呢?我们继续前面的实验步骤:

session 3:

SQL> delete from t where object_id=46;

1 row deleted.

session 3的DML操作顺利完成,没有被阻塞。而在10g当中,session 3是会被session 2请求的TM锁所阻塞的,这一点改进是非常有意思的,这样即使rebuid online操作被session 1的长事务阻塞,其他会话的DML操作,只要不和session 1冲突,都可以继续操作,在Oracle10g及以前版本中的执行rebuild index online而造成锁等待的风险被大大的降低了。

接下来在session 1执行rollback,观察rebuild index online执行期间的锁的情况,136是session 3:

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       136 TM      13596          0          3          0
       136 TX     327684        414          6          0
       137 TX     524304        402          6          0
       137 TX     524321        402          6          0

等待一段时间,rebuild index online临近结束,再次观察锁的情况:

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TX     327684        414          0          4
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       136 TM      13596          0          3          0
       136 TX     327684        414          6          0
       137 TX     524304        402          6          0

可以看到session 2又在请求一个模式为4的TX锁,同样的,这个锁也不会阻塞其他的DML。由于session 3的事务没有提交,session 2被阻塞,这时再将session 3执行提交或者rollback,则session 2的rebuild立即完成。

Oracle11g在很多细节方面确实做了不少的优化,而且像这样的优化,对于提高系统的高可用性的好处是不言而喻的,在Oracle11g中,执行rebuild index online的风险将比10g以及更老版本中小得多,因为从头至尾都不再阻塞DML操作了,终于可以算得上名副其实的online操作了。

rebuild index online的锁机制浅析

一般都说,rebuild index online不阻塞DML操作,这是相对于rebuild index来说的,加上了online,只是在rebuild的期间不阻塞DML,但是在开始和结束阶段还是可能阻塞其他进程的DML的,要弄清楚到底是阻塞还是不阻塞,何处阻塞,为什么阻塞,还是要从锁的角度来分析。本文实验环境为Oracle 10.2.0.4

Oracle中的锁,一共有6两种模式:

  • 0:none
  • 1:null 空
  • 2:Row-S 行共享(RS):共享表锁,sub share
  • 3:Row-X 行独占(RX):用于行的修改,sub exclusive
  • 4:Share 共享锁(S):阻止其他DML操作,share
  • 5:S/Row-X 共享行独占(SRX):阻止其他事务操作,share/sub exclusive
  • 6:exclusive 独占(X):独立访问使用,exclusive

我们知道,DML操作一般要加两个锁,一个是对表加模式为3的TM锁,一个是对数据行的模式为6的TX锁。只要操作的不是同一行数据,是互不阻塞的。但是rebuild index online在开始和结束的时候是需要对表加一个模式为4的TM锁的,这个可以很容易通过实验观察到,实验中的测试表t是通过create table t as select * from all_objects生成,并且多次执行insert into t select * from t产生较多的数据,以便延迟rebuild的时间来观察系统中锁的情况:

session 1:

SQL> delete from t where object_id=28;

1 row deleted.

session 2:

SQL> alter index ix_t rebuild online;

Session 2被阻塞,会话挂起,这时查询v$lock,可以得到如下结果:

SQL> select sid,type,id1,id2,lmode,request from v$lock where type in('DL','TM','TX'); 

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
      1643 DL      10599          0          3          0
      1643 DL      10599          0          3          0
      1622 TM      10599          0          3          0
      1643 TM      10599          0          2          4
      1643 TM      10607          0          4          0
      1622 TX     655398       1361          6          0

Read more of this post

无觅相关文章插件,快速提升流量