ORA-01555:快照過舊。 一個對于Oracle DBA來說最經(jīng)典問題。
發(fā)生的根本原因：一致性讀出了問題。
看到網(wǎng)上有個同學(xué)，舉例說明，覺得不錯，拿來用下：
假設(shè)有張表，叫table1，里面有5000萬行數(shù)據(jù)，假設(shè)預(yù)計(jì)全表掃描1次需要1個小時，我們從過程來看：
1、在1點(diǎn)鐘，有個用戶A發(fā)出了select * from table1;此時不管將來table1怎么變化，正確的結(jié)果應(yīng)該是用戶A會看到在1點(diǎn)鐘這個時刻的內(nèi)容。這個是沒有疑問的。
2、在1點(diǎn)30分，有個用戶B執(zhí)行了update命令，更新了table1表中的第4000萬行的這條記錄，這時，用戶A的全表掃描還沒有到達(dá)第4000萬條。毫無疑問，這個時候，第4000萬行的這條記錄是被寫到了回滾段里去了的，我假設(shè)是回滾段RBS1，如果用戶A的全表掃描到達(dá)了第4000萬行，是應(yīng)該會正確的從回滾段RBS1中讀取出1點(diǎn)鐘時刻的內(nèi)容的。
3、這時，用戶B將他剛才做的操作commit了，但是這時，系統(tǒng)仍然可以給用戶A提供正確的數(shù)據(jù)，因?yàn)槟堑?000萬行記錄的內(nèi)容仍然還在回滾段RBS1里，系統(tǒng)可以根據(jù)SCN來到回滾段里找到正確的數(shù)據(jù)，但是大家注意到，這時記錄在RBS1里的第4000萬行記錄已經(jīng)發(fā)生了一點(diǎn)重大的改變：就是這個第4000萬行的在回滾段RBS1里的數(shù)據(jù)有可能隨時被覆蓋掉，因?yàn)檫@條記錄已經(jīng)被提交了！！！
4、由于用戶A的查詢時間漫長，而業(yè)務(wù)在一直不斷的進(jìn)行，RBS1回滾段在被多個不同的tracnsaction使用著，這個回滾段里的extent循環(huán)到了第4000萬行數(shù)據(jù)所在的extent，由于這條記錄已經(jīng)被標(biāo)記提交了，所以這個extent是可以被其他transaction覆蓋掉的！
5、到了1點(diǎn)40分，用戶A的查詢終于到了第4000萬行，而這時已經(jīng)出現(xiàn)了第4條說的情況，需要到回滾段RBS1去找數(shù)據(jù)，但是已經(jīng)被覆蓋掉了，于是01555就出現(xiàn)了。
這次出現(xiàn)的ORA-01555，引起的原因很特殊。
報(bào)錯是回滾段SYSSMU1有問題.
所以斷定的是，并不是因?yàn)榇罅康淖x寫，造成的一致性讀錯誤，而且因?yàn)榛貪L段的錯誤，使快照出現(xiàn)了問題。
首先觀察下回滾段：
SQL> select segment_name,tablespace_name,status from dba_rollback_segs;
發(fā)現(xiàn)表空間UNDOTBS1的回滾段_SYSSMU1$-10$都是online。
發(fā)現(xiàn)表空間UNDOTBS2的回滾段SYSSMU1是竟然是needs recovery,其他都是offline。
最有趣的是這個數(shù)據(jù)庫指定的UNDO是UNDOTBS1，UNDOTBS2實(shí)際已經(jīng)被棄用了。
嘗試把該回滾段offline后刪除，但是提示非法。
重啟數(shù)據(jù)庫后該回滾段狀態(tài)變成了availabe。
再次嘗試offline后刪除，還是提示正在使用。
用直接更新數(shù)據(jù)字典的方法
SQL>update undo$ set status$=2 where name='SYSSMU1';
發(fā)現(xiàn)該回滾段狀態(tài)變更為offline，drop掉即可。
ORA-1555不再出現(xiàn)。
本篇文章來源于 Linux公社網(wǎng)站(www.linuxidc.com) 原文鏈接：http://www.linuxidc.com/Linux/2012-10/73260.htm