一個非典型的ORA-01555的解決

ORA-01555:快照過舊。    一個對於Oracle DBA來說最經典問題。
發生的根本原因：一致性讀出了問題。   

看到網上有個同學，舉例說明，覺得不錯，拿來用下：
假設有張表，叫table1，裡面有5000萬行資料，假設預計全表掃描1次需要1個小時，我們從過程來看：   
   
1、在1點鐘，有個使用者A發出了select * from table1;此時不管將來table1怎麼變化，正確的結果應該是使用者A會看到在1點鐘這個時刻的內容。這個是沒有疑問的。   
2、在1點30分，有個使用者B執行了update命令，更新了table1表中的第4000萬行的這條記錄，這時，使用者A的全表掃描還沒有到達第4000萬條。毫無疑問，這個時候，第4000萬行的這條記錄是被寫到了復原段裡去了的，我假設是復原段RBS1，如果使用者A的全表掃描到達了第4000萬行，是應該會正確的從復原段RBS1中讀取出1點鐘時刻的內容的。   
3、這時，使用者B將他剛才做的操作commit了，但是這時，系統仍然可以給使用者A提供正確的資料，因為那第4000萬行記錄的內容仍然還在復原段RBS1裡，系統可以根據SCN來到復原段裡找到正確的資料，但是大家注意到，這時記錄在RBS1裡的第4000萬行記錄已經發生了一點重大的改變：就是這個第4000萬行的在復原段RBS1裡的資料有可能隨時被覆蓋掉，因為這條記錄已經被提交了！！！   
4、由於使用者A的查詢時間漫長，而業務在一直不斷的進行，RBS1復原段在被多個不同的tracnsaction使用著，這個復原段裡的extent迴圈到了第4000萬行資料所在的extent，由於這條記錄已經被標記提交了，所以這個extent是可以被其他transaction覆蓋掉的！   
5、到了1點40分，使用者A的查詢終於到了第4000萬行，而這時已經出現了第4條說的情況，需要到復原段RBS1去找資料，但是已經被覆蓋掉了，於是01555就出現了。   
   
這次出現的ORA-01555，引起的原因很特殊。   
報錯是復原段SYSSMU1有問題.   
所以斷定的是，並不是因為大量的讀寫，造成的一致性讀錯誤，而且因為復原段的錯誤，使快照出現了問題。   
   
首先觀察下復原段：   
SQL> select segment_name,tablespace_name,status from dba_rollback_segs;   
發現資料表空間UNDOTBS1的復原段_SYSSMU1$-10$都是online。   
發現資料表空間UNDOTBS2的復原段SYSSMU1是竟然是needs recovery,其他都是offline。   
最有趣的是這個資料庫指定的UNDO是UNDOTBS1，UNDOTBS2實際已經被棄用了。   
   
嘗試把該復原段offline後刪除，但是提示非法。   
重啟資料庫後該復原段狀態變成了availabe。   
再次嘗試offline後刪除，還是提示正在使用。   

 
用直接更新資料字典的方法   
SQL>update undo$ set status$=2 where name='SYSSMU1';   
發現該復原段狀態變更為offline，drop掉即可。   
ORA-1555不再出現。