背景：兩套同樣的測試環境，一套資料庫Undo使用率一直處於99%，已經持續了很長一段時間，而另外一套幾乎為0

排查手段：

1. 檢視佔用高的undo表空間使用情況，發現都是unexpired的狀態

-- 整體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
 

2. 確認undo配置。

show parameter undo  --undo_retention配置為預設值900

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會覆蓋已過期的

3. 搜尋引擎得到的

聽聞Oracle從10.2開始自動啟用了undo表空間的自動調增功能，可以通過檢視v$undostat.tuned_undoretention確認真實的undo_retention，經檢視tuned_undoretention都是900，可以排除這種原因。

但仔細一看，v$undostat中事務的begin_time為2018年9月，現在才6月。。

到此原因就已經清楚了，主機往前調整過時間，調整期間這部分9月份的事務是永遠不會過期的！只有默默捱到9月份

4. 解決方法