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不再出現。
本篇文章來源于 Linux公社網站(www.linuxidc.com) 原文鏈接：http://www.linuxidc.com/Linux/2012-10/73260.htm