不可用索引

    本文并不是要说明如何把索引标记为不可用(unusable)或者如何使不可用索引恢复到可用状态，而是要看看当索引变成不可用状态时会有什么出现什么情况。在进入主题之前，我们先来简单探讨一下什么是索引。表的索引是按一定顺序(默认为升序排列)存储表列值以及RowID值的数据结构，是供使用者快速查找数据的“指路人”。

　　可以在索引创建脚本设置设置列排序，如下：

　　create index temp_jp_idx on temp_jp(col1 asc);

　　create index temp_jp_idx on temp_jp(col1 desc);

　　那RowID又是什么呢?一个RowID就是用来标识表中一行的伪列，代表了这一行在表中的物理位置。在Oracle 9i以后的版本中，RowID的格式均为扩展RowID格式，如 <object id><file id><block id><row number>(对象ID>文件ID>块ID>行号)，其显示形式为OOOOOOFFFBBBBBBRRR。

　　如果在运行某项操作时，表中数据的物理位置改变了，那么数据库就会将该表的索引标记为不可用，为什么会这样呢?在表中的数据被移动后，当前的数据RowID指向了新的物理位置。而索引中旧的RowID还是和执行移动命令前的一样仍然指向旧的物理位置，而那个位置已经没有任何数据了。这样，Oracle就无法通过存有无效RowID的索引来访问检索数据了。因此，Oracle数据库会在执行了移动命令以后把该表的所有索引都标记为不可用。

　　为了更好的理解这个问题，我们可以进行一个模拟测试。

 

drop table temp_jp; drop table temp_rowids_jp; create table temp_jp(col1 number,col2 varchar2(20)) tablespace users1; insert into temp_jp values(1,'RAMA'); insert into temp_jp values(3,'SITA'); insert into temp_jp values(2,'LAKSHMAN'); commit; set autot on exp select * from temp_jp where col1=3;       COL1 COL2 ---------- --------------------          3 SITA Execution Plan ----------------------------------------------------------    0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=1 Bytes=25)    1    0   TABLE ACCESS (FULL) OF 'TEMP_JP' (TABLE) (Cost=3 Card=1 Bytes=25)

 

　　Oracle对temp_jp表执行了一次全表扫描，显示该表没有索引。下面为temp_jp表创建一个索引。

 

create index temp_jp_idx on temp_jp(col1 asc); set autot on exp select * from temp_jp where col1=3;       COL1 COL2 ---------- --------------------          3 SITA Execution Plan ----------------------------------------------------------    0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=25)    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TEMP_JP' (TABLE) (Cost=2  Card=1 Bytes=25)    2    1     INDEX (RANGE SCAN) OF 'TEMP_JP_IDX' (INDEX) (Cost=1 Card  =1)

 

接下来，使用temp_jp_idx索引来访问表temp_jp的数据。

 

select index_name, status  from dba_indexes where table_name='TEMP_JP'; INDEX_NAME                     STATUS ------------------------------ -------- TEMP_JP_IDX                    VALID

 

　　temp_jp_idx索引是有效索引，在检索表temp_jp的数据时，Oracle会使用该索引。下面找出表temp_jp数据的当前RowID。

 

 

 

select rowid,a.* from temp_jp a; ROWID                    COL1 COL2 ------------------ ---------- -------------------- AAA16tAAEAAAADoAAA          1 RAMA AAA16tAAEAAAADoAAB          3 SITA AAA16tAAEAAAADoAAC          2 LAKSHMAN

 

　　在移动表数据之前，我们先来保存从temp_jp表得到的当前RowID，以便稍后进行对照参考。

　　create table temp_rowids_jp as select col1,rowid as before_move_rowid from temp_jp;

　　从RowID找出相应的对象id、文件id和行号：

 

select dbms_rowid.rowid_object(rowid) "object",       dbms_rowid.rowid_relative_fno(rowid) "file",       dbms_rowid.rowid_block_number(rowid) "block",       dbms_rowid.rowid_row_number(rowid) "row" from temp_jp     /     object       file      block        row ---------- ---------- ---------- ----------     220845          4        232          0     220845          4        232          1     220845          4        232          2

 

　　接着，从dba_object中找到ID为220845的对象所有者、对象名和对象类型。

 

select object_id,owner, object_name, object_type,created from dba_objects where object_id = 220845; OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED ---------   ------ ---------------  ------------------- ---------    220845   SCOTT  TEMP_JP          TABLE             30-MAR-08 select object_id,owner,object_name,object_type,created     from dba_objects  where created > trunc(sysdate) -1/24; OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED ---------   ------ ---------------  ------------------- ---------    220846   SCOTT  TEMP_JP_IDX       INDEX              30-MAR-08    220845   SCOTT  TEMP_JP           TABLE              30-MAR-08    220847   SCOTT  TEMP_ROWIDS_JP    TABLE              30-MAR-08 select object_id,owner,object_name,object_type,created  from dba_objects   where object_id in (select max(object_id) from dba_objects); OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED ---------   ------ ---------------  ------------------- ---------    220847   SCOTT  TEMP_ROWIDS_JP    TABLE              30-MAR-08

 

接下来，让我们用当前的RowID来查询表temp_jp的数据。

 

select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB';       COL1 COL2 ---------- --------------------          3 SITA

 

　　结果显示，RowID正确地指向了表temp_jp相应行的位置。表temp_jp的temp_jp_idx索引存储了该表数据的正确RowID。从RowID算得的object_id已经转换到正确的表了。使用RowID可以准确的访问该表的数据。

　　这样，我们就可以开始测试了，将该表移动到另外一个表空间，然后看看会出现什么情况。

 

 

alter table temp_jp move tablespace users2; SQL> select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB'; select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB'               * ERROR at line 1: ORA-01410: invalid ROWID

 

　　表被移走后，其RowID也改变了。旧的RowID不再指向该表的实际数据了。在移动之前，我们使用RowID对表temp_jp进行select查询是可以得到正确的查询结果的，而现在则出现查询失败的错误信息。

　　现在让我们再来找找执行了move命令之后表temp_jp数据现在的RowID。

 

select rowid,a.* from temp_jp a; ROWID                       COL1        COL2 ------------------          ---------- -------------------- AAA16wAAMAAAC+MAAA          1           RAMA AAA16wAAMAAAC+MAAB          3           SITA AAA16wAAMAAAC+MAAC          2           LAKSHMAN

 

　　从查询结果可以看到，执行完move命令后，该表的RowID也已经发生了变化。根据上文介绍的RowID定义，我们知道它的表现形式包含了。自该表从users1表空间移动到users2表空间后，这些行的物理属性，如file_id和block_id，都发生了改变。因此其该表的RowID也变了。我们可以从新的RowID计算出执行完move命令后该表的object_id、 file_id、block_id和行号。

 

select dbms_rowid.rowid_object(rowid) "object",           dbms_rowid.rowid_relative_fno(rowid) "file",           dbms_rowid.rowid_block_number(rowid) "block",           dbms_rowid.rowid_row_number(rowid) "row" from temp_jp  /  object       file      block        row  --------- ---------- ---------- ----------  220848         12      12172          0  220848         12      12172          1  220848         12      12172          2

 

执行完move命令后，Oracle为该表指定了一个新的object_id。属于users2表空间的文件号为12。当前的块ID为12172。而行号还保持和原来一样。Move命令改变了表的位置，但没有改变表内行的排列顺序。接下来，我们还可以用新的object_id来查找该对象的详细信息。

　　select object_id,owner, object_name, object_type,created from dba_objects where object_id = 220848;

　　no rows selected

　　从执行move命令后的新RowID得到了object_id没有检索到该对象的详细信息。相反，从dba_objects视图看该表的对象ID表现为执行move命令前的旧object_id。

 

 

select object_id,owner, object_name, object_type,created from dba_objects where object_name = 'TEMP_JP'; OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED ---------   ------ --------------- -------------------  --------- 220845      SCOTT  TEMP_JP          TABLE               30-MAR-08

 

　　这可能是Oracle数据库的一个漏洞。我们来查找一下在过去一小时内创建的对象：

 

select object_id,owner,object_name,object_type,created  from dba_objects  where created > trunc(sysdate) -1/24; OBJECT_ID OWNER  OBJECT_NAME     OBJECT_TYPE           CREATED --------- ------ --------------- -------------------   --------- 220846    SCOTT  TEMP_JP_IDX      INDEX                30-MAR-08 220845    SCOTT  TEMP_JP          TABLE                30-MAR-08 220847    SCOTT  TEMP_ROWIDS_JP   TABLE                30-MAR-08 select object_id, owner, object_name, object_type, created  from dba_objects where object_id in (select max(object_id) from dba_objects); OBJECT_ID OWNER   OBJECT_NAME     OBJECT_TYPE          CREATED --------- ------- -------------   -------------------  --------- 220847    SCOTT   TEMP_ROWIDS_JP  TABLE                30-MAR-08

 

　　用新的RowID来查询表temp_jp：

 

select * from temp_jp where rowid = 'AAA16wAAMAAAC+MAAB';       COL1 COL2 ---------- --------------------          3 SITA

 

　　我们用新RowID能够从该表查询到数据。但是，从新RowID得到的objectid并不能检索到对象的详细信息。从这点看来，Oracle并没有使用从目前的RowID得到的objectid来检索该表的数据，而是使用fileid、blockid和行号来访问表数据。

　　那么让我们来看看执行完move命令后表temp_jp的索引状态。

 

select index_name, status from dba_indexes where table_name='TEMP_JP'; INDEX_NAME                     STATUS ------------------------------ -------- TEMP_JP_IDX                    UNUSABLE  set autot on exp  select * from temp_jp where col1=3;       COL1    COL2 ----------    --------------------          3    SITA Execution Plan ----------------------------------------------------------    0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=25)    1    0   TABLE ACCESS (FULL) OF 'TEMP_JP' (TABLE) (Cost=2 Card=1 Bytes=25)

 

由于表temp_jp已有的索引无法使用，我们先对该表进行了一次全表扫描。正如你所想到的，表temp_jp的索引仍然存储着无效的RowID。现在，让我们来看看我们用旧的RowID能不能检索到数据。

 

 

SQL> select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB'; select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB'               * ERROR at line 1: ORA-01410: invalid ROWID

 

　　旧的RowID不再指向该表各行的正确物理位置。而索引temp_jp_idx仍保留着执行move命令前旧的无效RowID，所以，Oracle把这些索引标记为不可用。不过，我们还是可以用新的RowID来访问该表的数据。

 

select * from temp_jp where rowid = 'AAA16wAAMAAAC+MAAB';       COL1 COL2 ---------- --------------------          3   SITA

 

　　让我们来比较一下执行move命令前后表temp_jp的RowID有什么不同。

 

select a.col1, a.before_move_rowid,b.rowid after_move_rowid  from temp_rowids_jp a, temp_jp b where a.col1 = b.col1;      COL1  BEFORE_MOVE_ROWID          AFTER_MOVE_ROWID ---------   ------------------         ------------------         1   AAA16tAAEAAAADoAAA         AAA16wAAMAAAC+MAAA         3   AAA16tAAEAAAADoAAB         AAA16wAAMAAAC+MAAB         2   AAA16tAAEAAAADoAAC         AAA16wAAMAAAC+MAAC

 

　　正如之前所说的，在执行了move命令之后，该表转移到了另外一个表空间，而objectid、fileid和blockid都已经发生了变化。由于表内的数据在表移动的过程中并没有发生改变，所以行号仍保留原样。

　　为了修复不可用索引，用新的正确的RowID来重新生成temp_jp_idx索引即可

 

alter index temp_jp_idx rebuild online; select index_name, status from dba_indexes where table_name='TEMP_JP'; INDEX_NAME                      STATUS ------------------------------  -------- TEMP_JP_IDX                     VALID After rebuilding the unusable index, the index is validated. set autot on exp select * from temp_jp where col1=3;       COL1       COL2       ---------- --------------------                3 SITA        Execution Plan ----------------------------------------------------------    0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=25)    1    0 TABLE ACCESS (BY INDEX ROWID) OF 'TEMP_JP' (TABLE) (Cost=2   Card=1 Bytes=25)    2    1 INDEX (RANGE SCAN) OF 'TEMP_JP_IDX' (INDEX) (Cost=1 Card  =1)

 

　　重新生成索引后，就可以使用该索引来对表temp_jp进行select查询了。

　　记住，当你要移动一个表时，该表的索引会被标记为不可用，但通过重新生成指令来将索引转移到新的物理位置时，索引就可以恢复可用性了。