首页 > 数据库 > Oracle > UNDO表空间100%诊断
无报错
点击(此处)折叠或打开
点击(此处)折叠或打开
点击(此处)折叠或打开
发现从2012-09-12 09:05:07就有长时间的sql语句出现,每十分钟执行一次,一直持续到2012-09-14 05:02:07,该sql语句失败。SQLID为:gc4xxp228mra3
点击(此处)折叠或打开
从oracle10g开始,oracle提供了Automatic UNDO Retention特性,即oracle会根据实际情况自动调整undo_retention值,从2012-09-12 09:05:07至2012-09-14 05:02:07 期间产生了多次超长时间查询,这段期间MAXQUERYLEN值保持在10万秒以上,为了尽可能避免ORA-01555的报错,尽可能保留更多的UNEXPIRED EXTENT,ORACLE会将这些查询的undo信息保留时间变长,选择在undo tablespace中扩充rollback segment,所以undo tablespace使用率会不断上升,最终导致了undo tablespace空间使用率达到100%。
注:
MAXQUERYLEN 最长查询的耗时(单位:秒)
UNDO_RETENTION undo信息在undo表空间保存的时间,默认900秒
TUNED_UNDORETENTION oracle自动调整后的undo_retention值
1)undo表空间会自动回收,循环使用,可忽略100%问题
2)对于oracle10g版本,使用如下命令强制undo保存时间
alter tablespace UNDOTBS3 retention guarantee;
3)从引发问题的SQL语句下手,应用开发人员分析该SQL语句重复执行的原因。
undo tablespace空间使用率达到100%,只是意味着所有的空间都已经分配给rollback segment,但并不一定会影响到业务的select和insert、delete、update操作,因为rollback segment中的空间是可以重用的。在oracle10g,不能通过监控dba_free_space数据库字典的方法去获得undo tablespace的使用情况,可以考虑通过以下方法进行监控:
1. 监控v$undostat视图,主要包括MAXQUERYLEN、SSOLDERRCNT、NOSPACEERRCNT列值,如:MAXQUERYLEN大于36000秒则报警、SSOLDERRCNT大于0次(或一定次数)则报警、NOSPACEERRCNT大于0次则严重警告等;
2. 监控平均每一秒钟所需的最少回滚表空间容量,如果超过一定范围则报警
SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes"
FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'),
(SELECT (SUM(undoblks)/SUM(((end_time - begin_time)*86400))) AS UPS FROM v$undostat),
(select block_size as DBS from dba_tablespaces where tablespace_name=
(select value from v$parameter where name = 'undo_tablespace'));
Bytes
----------
413215736
那么一个undo表空间的理论大小为:413215736*900
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/24966341/viewspace-1123671/ ,如需转载,请注明出处,否则将追究法律责任。