ORA-01502 state unusable錯誤成因和解決方法(一)
2024-07-21 02:09:42
供稿：網友
接到開發人員和業務人員的通知，說一個登陸頁面不能用了，報錯：
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;”，
我們已經可以訪問這個表了，但是請注意，這種情況下，這個索引是不可用的，也就是說優化器在考慮是否要使用索引時是不考慮這個所以的。
方法2：通過常見所以徹底解決這個問題
首先，先設置 “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>
看來，重建索引才是解決這類問題的徹底的方法。
