我這邊生產環境，一般undo表空間都會預先設定一個大小，並且保留資料檔案的自動擴充套件，一直也相安無事。最近有套系統的undo表空間一直報警，使用率超過85%。看了下表空間大小，才5個G，以後確實是undo表空間過小了，於是擴到10G。結果第二天又報警了，嘿，不信了，於是擴到20g。哎呦，跟我槓上了，第二天又報警了。

      沒辦法，生了個awr報告，看到到底是哪個倒黴孩子寫的大事務一句一直不提交。哎呦我去，沒有找到嫌疑語句，啥情況。找來開發人員，交流一下，不存在批量之類的業務。怪了。

     查了下undo狀態：select status,sum(bytes)/1024/1024/1024 from dba_undo_extents group by status;發現未過期的undo竟然佔了表空間的百分之九十左右。但是我實時檢視資料庫狀態，確實沒有發現正在活動的大事務。於是懷疑，莫非是遇到undo方面的bug了，是不是存在未過期undo一直沒釋放的情況？

    在MOS上看到一篇文件doc：413732.1，有如下解釋：

When the UNDO tablespace is created with NO AUTOEXTEND, following the allocation algorithm, here is the explanation for this correct behavior:

For a fixed size UNDO tablespace (NO AUTOEXTEND), starting with 10.2, we provide max retention given the fixed undo space, which is set to a value based on the UNDO tablespace size. 
This means that even if the undo_retention is set to a number of seconds (900 default), the fixed UNDO tablespace supports a bigger undo_retention time interval (e.g: 36 hours), based on the tablespace size, thing that makes the undo extents to be UNEXPIRED. But this doesn't indicate that there are no available undo extents when a transaction will be run in the database, as the UNEXPIRED undo segments will be reused.

大致意思是如果資料檔案設定成非自動擴充套件的，oracle不會按照undo_retention引數所設定的值，對undo資料進行過期。我測試了下，在12.2.0.1版本，依然存在這樣的情況。將上述存在問題的undo表空間資料檔案設定成自動擴充套件後，過了一會，未過期的undo資料逐漸減少，直至undo表空間使用率恢復正常。

  oracle當真是博大精深，總有一些知識點很難觸及，遇到了，總要記錄一番。