背景：兩套同樣的測試環境，一套資料庫undo使用率一直處於99%，已經持續了很長一段時間，而另外一套幾乎為0
排查手段：
-- 整體undo使用情況
select b.tablespace_name,
nvl(used_undo, 0) "used_undo(m)",
total_undo "total_undo(m)",
trunc(nvl(used_undo, 0) / total_undo * 100, 2) used_pct
from (select nvl(sum(bytes / 1024 / 1024), 0) used_undo, tablespace_name
from dba_undo_extents
where status in ('active', 'unexpired')
and tablespace_name in
(select value from v$parameter where name = 'undo_tablespace')
group by tablespace_name) a,
(select tablespace_name, sum(bytes / 1024 / 1024) total_undo
from dba_data_files
where tablespace_name in
(select value from v$parameter where name = 'undo_tablespace')
group by tablespace_name) b
where a.tablespace_name(+) = b.tablespace_name;
-- 各狀態undo使用情況統計
select tablespace_name,status,sum(bytes)/1024/1024 mb from dba_undo_extents
where tablespace_name like 'undotbs%'
group by tablespace_name,status
order by 1
select file_name,autoextensible from dba_data_files where tablespace_name='undotbs1'; --已關閉自動擴充套件
select tablespace_name,retention from dba_tablespaces where tablespace_name='undotbs1'; --nogurantee，說明暫時還不會報錯，undo會覆蓋已過期的
聽聞oracle從10.2開始自動啟用了undo表空間的自動調增功能，可以通過檢視v$undostat.tuned_undoretention確認真實的undo_retention，經檢視tuned_undoretention都是900，可以排除這種原因。
但仔細一看，v$undostat中事務的begin_time為2023年9月，現在才6月。。
到此原因就已經清楚了，主機往前調整過時間，調整期間這部分9月份的事務是永遠不會過期的！只有默默挨到9月份
主機時間向前調整比如從9月份調整到3月份會出現此問題，9月份的事務一直不能被覆蓋，往後調整則沒有該問題。重啟資料庫後事務時間即可與主機時間同步。但仍然需要重建undo表空間：新建undotbs2並進行切換，刪除原有的undotbs1，不細說了
表空間使用率
檢視表空間名稱 大小 使用大小 剩餘大小和使用率 select a.tablespace name 表空間名稱 total 1024 1024 表空間大小 m free 1024 1024 表空間剩餘大小 m total free 1024 1024 表空間使用大小 m total 1024 102...
UNDO表空間使用率100 ，也不要擔心
undo,表空間 undo retention設的為900秒是指undo資料留在undo段裡面至少要900秒以後才能被覆蓋掉。因為undo段是迴圈的，如果乙個dml操作產生了大量的undo資訊時，可能undo空間不夠用，此時 就要覆蓋掉一些undo塊，undo retention就是保證900秒後那...
表空間使用率查詢
select a.file id 檔案號,a.tablespace name 表空間名稱,b.file name 物理檔名,b.autoextensible 自動擴充套件,b.maxbytes 1024 1024 1024 最大空間g,total 1024 1024 表空間mb,free 1024 ...