五一假期期間接到運維同學的微信，說應用報錯了，跟數據庫有關的，發過來截圖一看報錯的信息是could not get next sequence value。以爲是某個sequence達到了最大值，讓幫忙查是哪個sequence。
於是查了dba_sequences，沒有哪個sequence達到了最大值。
於是看session的信息，查詢v$session中的等待事件，發現有大量的等待事件是“latch: undo global data”。從事件名字上來看應該是undo的問題。
查詢undo表空間的使用率，果然到了100%。但undo是可以重複使用的，除非有非常大的事務佔滿了整個undo表空間，undo表空間有460多G，佔滿的可能性不大。
上網搜了latch: undo global data相關的文章，有一個提到MOS上的一篇文檔："LATCH: UNDO GLOBAL DATA" In The Top Wait Events (文檔 ID 1451536.1)
文檔中介紹這個等待事件意味着大量的session在試圖找到新的undo extent和偷取未過期的undo extents。這個等待和隱含參數_undo_autotune設置爲FALSE情況下的UNDO空間不足有關。
當前數據庫的_undo_autotune確實爲FALSE，而且undo_retention=259200，換算下來就是72小時。
先認識一下隱含參數_undo_autotune：
從10.2版本開始，oracle默認採用自動調整undo retention的方法
根據你undo tablespace的大小以及系統的繁忙程度(v$undostat中信息）自動調整undo_retention參數，所以在10g的數據庫上你會經常發現undo tablespace永遠是滿的，因爲當你undo tablespace有空閒空間時，系統自動調大undo_retention來保留更多的undo blocks。這一方法有利於時間長的查詢，但是對於典型的OLTP系統來說不太適用。因爲OLTP上不太可能跑如此長時間的查詢，而且在很繁忙的 OLTP上還會導致上面所遇到的問題。
_undo_autotune=true時，undo_retention不再適用。而_undo_autotune=false時，undo_retention按設置的時間保留。
通過上面的解釋，再加上五一假期期間在做數據清理工作，大量的undo被保留72小時，最終導致了undo表空間爆滿，應用無法正常訪問。
解決方法：
1、設置_undo_autotune=true，可以在線修改
2、增加undo表空間大小(resize現有數據文件或增加數據文件)
3、調小undo_retention參數
最終調小了undo_retention參數設置爲43200（12小時），應用恢復正常。
參考：http://blog.itpub.net/4227/viewspace-1060723/
http://blog.csdn.net/dba_waterbin/article/details/8646982