本篇內(nèi)容介紹了“怎么避免數(shù)據(jù)庫ORA-01555錯誤”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
原因：
當(dāng)進(jìn)行DML操作時，undo段會記錄數(shù)據(jù)變更前的狀態(tài)（通過構(gòu)造原數(shù)據(jù)的一致性數(shù)據(jù)塊）。如果用戶還沒有進(jìn)行commit操作，其他人查詢此條數(shù)據(jù)會看到數(shù)據(jù)變更前的狀態(tài)。因為其他用戶讀到的數(shù)據(jù)是undo段中原數(shù)據(jù)塊中的數(shù)據(jù)，保證沒有commit的數(shù)據(jù)讀取的一致性。
會話A在9:50分的時候?qū)表發(fā)起了一次查詢，需要10分鐘完成查詢結(jié)果打印。會話B在9:51分對T表進(jìn)行了一次update，并且commit。此時undo段會記錄會話B在update的反向操作，假設(shè)名為undo1。會話C在9:52分對T表進(jìn)行了一次insert，并且同樣commit。此時undo段會記錄insert反向操作，假設(shè)名為undo2。會話A的查詢在發(fā)起時已經(jīng)記錄數(shù)據(jù)庫當(dāng)前的SCN號，假設(shè)此時SCN號為950。由于ILT事務(wù)槽記錄最新的SCN號，所以再與數(shù)據(jù)塊頭部ILT事務(wù)槽中的SCN號進(jìn)行比對時發(fā)現(xiàn)當(dāng)前SCN大于950，所以需要對undo段進(jìn)行查詢。查詢到undo2段信息進(jìn)行比對發(fā)現(xiàn)SCN大于950，通過undo中記錄的事務(wù)信息在進(jìn)行前一個數(shù)據(jù)變更查找，此時undo1的SCN還是大于950，再繼續(xù)查找前面的undo信息，發(fā)現(xiàn)undo0的SCN號比950要早，此時會將undo0記錄的數(shù)據(jù)的信息+未變更的數(shù)據(jù)塊信息打印給用戶。由于undo段是通過覆蓋的方式進(jìn)行記錄的，如果時間過長或頻繁進(jìn)行DML操作。那么在尋找過程中可能會出現(xiàn)沒有小于SCN號950的undo段，會返回一個經(jīng)典錯誤ORA-1555 snapshoot too old（快照過舊），這樣是為了避免幻影讀、臟讀等現(xiàn)象，保證讀一致性的絕對特性。
簡單講，就是SQL語句執(zhí)行時間太長、UNDO表空間過小、事務(wù)量過大，提交過于頻繁，導(dǎo)致執(zhí)行SQL過程中進(jìn)行一致性讀時，修改的原數(shù)據(jù)（UNDO數(shù)據(jù)）在UNDO表空間中已經(jīng)被覆蓋，不能構(gòu)造一致性讀塊。
規(guī)避：
1、加大回滾段的容量
2、將undo_retention參數(shù)內(nèi)的提交后保留時間設(shè)置更大一些
如果當(dāng)一個查詢觸發(fā)延遲塊清除的時候，ORACLE需要去查詢回滾段獲得該事務(wù)提交的SCN，如果事務(wù)前鏡像信息已經(jīng)被覆蓋，并且查詢的SCN小于回滾段記錄中記錄的最小提交SCN信息，那么oracle將無法判斷查詢的scn和事物提交scn的大小．則將commit 標(biāo)記為 回滾段中所能找到的最小 scn（對于查詢安全）。
如果最近一次變更與查詢間隔時間過長、間隔中進(jìn)行過大量事務(wù)變更或頻繁進(jìn)行事務(wù)提交，造成undo段中的數(shù)據(jù)已經(jīng)被覆蓋，無法判斷數(shù)據(jù)的變更情況和提交時間。此時oracle會查將該數(shù)據(jù)塊中ITL事務(wù)信息清除并將commit SCN變更為回滾段中最老的事務(wù)，即最小的SCN號。以便保證數(shù)據(jù)能夠查詢，此時會報ORA-1555錯誤。
“怎么避免數(shù)據(jù)庫ORA-01555錯誤”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！
重慶分公司
重慶分公司
