undo表空间使用率99%居高不下

背景：两套同样的测试环境，一套数据库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. 解决方法

主机时间向前调整比如从9月份调整到3月份会出现此问题，9月份的事务一直不能被覆盖，往后调整则没有该问题。重启数据库后事务时间即可与主机时间同步。但仍然需要重建undo表空间：新建Undotbs2并进行切换，删除原有的undotbs1，不细说了