解决ORA-01502 state unusable错误成因

　　接到开发人员和业务人员的通知，说一个登陆页面不能用了，报错：
　　
　　2005-01-31 13:59:02,721 [com.ASPire.common.dao.OamUserDAO]- -214:select错误
　　Java.sql.SQLException: ORA-01502 state
　　
　　这个错误是由于索引失效造成的，重建索引后，问题就解决了。
　　
　　为了搞清楚索引为什么会失效，以及如何解决，我们做个测试：
　　
　　首先我们创建一个普通的测试表（非分区表）：
　　SQL> create table t(a number);
　　
　　Table created.
　　
　　SQL> select tablespace_name from user_segments where segment_name='T';
　　
　　TABLESPACE_NAME
　　------------------------------
　　DATA_DYNAMIC
　　
　　SQL>
　　
　　然后，我们创建一个普通索引
　　
　　SQL> create index idxt on t(a);
　　
　　Index created.
　　
　　SQL> insert into t values(10);
　　
　　1 row created.
　　
　　SQL> set linesize 200
　　SQL> select index_name,index_type,tablespace_name,table_type,status from user_indexes where index_name='IDXT';
　　
　　INDEX_NAME　　　　　　　　　　 INDEX_TYPE　　　　　　　　　TABLESPACE_NAME　　　　　　　　TABLE_TYPE　STATUS
　　------------------------------ --------------------------- ------------------------------ ----------- --------
　　IDXT　　　　　　　　　　　　　 NORMAL　　　　　　　　　　　DATA_DYNAMIC　　　　　　　　　 TABLE　　　 VALID
　　
　　SQL>
　　
　　模拟索引是失效的情况：
　　SQL> alter table　t move tablespace tools
　　　2　/
　　
　　Table altered.
　　
　　SQL> select index_name,index_type,tablespace_name,table_type,status from user_indexes where index_name='IDXT';
　　
　　INDEX_NAME　　　　　　　　　　 INDEX_TYPE　　　　　　　　　TABLESPACE_NAME　　　　　　　　TABLE_TYPE　STATUS
　　------------------------------ --------------------------- ------------------------------ ----------- --------
　　IDXT　　　　　　　　　　　　　 NORMAL　　　　　　　　　　　DATA_DYNAMIC　　　　　　　　　 TABLE　　　 UNUSABLE
　　
　　SQL>
　　我们看到，当使用类似 alter table xxxxxx move tablespace xxxxxxx 命令后，索引就会失效。
　　
　　当然，作为测试，也可以直接使用alter index idxt unusable;命令使索引失效，例如：
　　SQL> alter index idxt unusable;
　　
　　Index altered.
　　
　　SQL>
　　
　　在这种情况下，我们向表中插入数据看看是什么情况：
　　SQL> insert into t values(11);
　　insert into t values(11)
　　*
　　ERROR at line 1:
　　ORA-01502: index 'MISC.IDXT' or partition of sUCh index is in unusable state
　　
　　SQL>
　　我们看到，这时就出现了常见的“ORA-01502: index 'XXXXXXXX' or partition of such index is in unusable state”错误。
　　
　　检查一下索引状态，我们会注重到索引已经是“UNUSABLE”了。
　　SQL> select index_name,index_type,tablespace_name,table_type,status from user_indexes where index_name='IDXT';
　　
　　INDEX_NAME　　　　　　　　　　 INDEX_TYPE　　　　　　　　　TABLESPACE_NAME　　　　　　　　TABLE_TYPE　STATUS
　　------------------------------ --------------------------- ------------------------------ ----------- --------
　　IDXT　　　　　　　　　　　　　 NORMAL　　　　　　　　　　　DATA_DYNAMIC　　　　　　　　　 TABLE　　　 UNUSABLE
　　
　　SQL>
　　
　　对于普通表中的不同索引（非唯一索引），我们有两种方法解决这个问题。

　　
　　方法一：设置 skip_unusable_indexes=true;
　　SQL> alter session set skip_unusable_indexes=true;
　　
　　Session altered.
　　
　　SQL> insert into t values(11);
　　
　　1 row created.
　　
　　SQL> commit;
　　
　　Commit complete.
　　
　　SQL> select * from t;
　　
　　　　　　 A
　　----------
　　　　　　 1
　　　　　　 2
　　　　　　 3
　　　　　　 4
　　　　　　 5
　　　　　　10
　　　　　　11
　　
　　7 rows selected.
　　
　　SQL> select index_name,index_type,tablespace_name,table_type,status from user_indexes where index_name='IDXT';
　　
　　INDEX_NAME　　　　　　　　　　 INDEX_TYPE　　　　　　　　　TABLESPACE_NAME　　　　　　　　TABLE_TYPE　STATUS
　　------------------------------ --------------------------- ------------------------------ ----------- --------
　　IDXT　　　　　　　　　　　　　 NORMAL　　　　　　　　　　　DATA_DYNAMIC　　　　　　　　　 TABLE　　　 UNUSABLE
　　
　　SQL>
　　现在我们看到，这个索引的状态虽然还是“UNUSABLE”但是，通过设置“alter session set skip_unusable_indexes=true;”，
　　
　　我们已经可以访问这个表了，但是请注重，这种情况下，这个索引是不可用的，也就是说优化器在考虑是否要使用索引时是不考虑这个所以的。
　　
　　方法二：通过常见所以彻底解决这个问题
　　
　　首先，先设置 “skip_unusable_indexes=false”，也就是不跳过失效索引
　　SQL> alter session set skip_unusable_indexes=false;
　　
　　Session altered.
　　
　　SQL>
　　
　　然后重建这个失效的索引
　　SQL> alter index idxt rebuild;
　　
　　Index altered.
　　
　　SQL> select index_name,index_type,tablespace_name,table_type,status from user_indexes where index_name='IDXT';
　　
　　INDEX_NAME　　　　　　　　　　 INDEX_TYPE　　　　　　　　　TABLESPACE_NAME　　　　　　　　TABLE_TYPE　STATUS
　　------------------------------ --------------------------- ------------------------------ ----------- --------
　　IDXT　　　　　　　　　　　　　 NORMAL　　　　　　　　　　　DATA_DYNAMIC　　　　　　　　　 TABLE　　　 VALID
　　
　　SQL>
　　我们看到重建索引后，索引的状态就正常了。
　　
　　现在插入数据，看看是正常：
　　SQL> insert into t values(12);
　　
　　1 row created.
　　
　　SQL> commit;
　　
　　Commit complete.
　　
　　SQL>
　　看来，重建索引才是解决这类问题的彻底的方法。