Oracle undo使用率过高问题处理

本文主要是介绍Oracle undo使用率过高问题处理，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

客户的数据库监控频繁告警UNDO表空间使用率高；维护人员通过加数据文件扩大表空间方式，已经将UNDO表空间扩容到900GB+,仍然会有告警，介入调查处理~

1.1.1. 查看UNDO配置及相关参数

均为正常配置，UNDO保留时间为900秒。未配置相应的隐含参数，数据库版本11.2.0.4

1.1.2. 查看UNDO数据文件的配置

均已经关闭了数据文件自动扩展

1.1.3. 查看UNDO段使用情况

大量UNDO段为UNEXPIRED状态,ACTIVE状态的很少，查询V$UNDOSTAT参数可以发现TUNED_UNDORETENTION 自动调整为20万秒以上，成为UNDO段状态UNEXPIRED的原因。这是由于UNDO自动管理特性AUM导致的问题，参考MOS文档Automatic Tuning of Undo_retention Causes Space Problems (文档 ID 420525.1)，Automatic Tuning of Undo_retention Causes Space Problems (文档 ID 420525.1)都解释了此问题；一般新上线系统都会考虑关闭alter system set “_undo_autotune” = false;或者设置自动调整的最大值alter system set “_highthreshold_undoretention” = 10800;。本处使用默认，所以自动调整的==TUNED_UNDORETENTION 自动调整为20万秒以上，导致UNDO段一直为UNEXPIRED状态。

查UNDO段状态及自动调整的保留时间命令：

select BEGIN_TIME,
       END_TIME,
       MAXQUERYLEN,
       MAXQUERYSQLID,
       TUNED_UNDORETENTION
  from V$UNDOSTAT  Order By begin_time Desc;

查UNDO段EXPIRED等使用情况：

col "Tablespace_Name" for a15
col "Status" for a10
col "Size(GB)" for 99999
col "SIZE(GB)" for 99999.99
SELECT  seg.tablespace_name "Tablespace_Name", 
  round(ts.bytes/1024/1024/1024) "Size(GB)",
  ue.status "Status", count(*) "Used Extents",
  round(sum(ue.bytes)/1024/1024/1024, 2) "US_SIZE(GB)",
  to_char(round(sum(ue.bytes)/ts.bytes*100, 2), 99.99) "Used Rate(%)"
FROM dba_segments seg, DBA_UNDO_EXTENTS ue,
  (SELECT tablespace_name, sum(bytes) bytes
    FROM dba_data_files GROUP BY tablespace_name) ts
WHERE ue.segment_NAME=seg.segment_NAME and seg.tablespace_name=ts.tablespace_name
GROUP BY seg.tablespace_name, ts.bytes, ue.status
ORDER BY seg.tablespace_name;

1.1.4. 解决方案

由于系统重要不能停机，综合考虑，设置隐含参数等方式均动作较大；使用调整UNDO数据文件属性的方式： ALTER DATABASE DATAFILE ‘<datafile_flename>’ AUTOEXTEND ON MAXSIZE <current_size>；这样设置后 V$UNDOSTAT.TUNED_UNDORETENTION 不再基于UNDO表空间使用率计算，而是使用(MAXQUERYLEN secs + 300) and UNDO_RETENTION两个计算的最大值，这样UNDO空间就释放了，如下：

这篇关于Oracle undo使用率过高问题处理的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！