oracle 不可用,Oracle不可用索引的原因是什么呢？

文并不是要说明如何把索引标记为不可用(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格式，如 (对象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 expselect * from temp_jp where col1=3;

COL1 COL2---------- --------------------

3 SITAExecution 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 expselect * from temp_jp where col1=3;

COL1 COL2---------- --------------------

3 SITAExecution 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)。

全部