记一次undo表空间使用率99%的问题

2018-01-08 Oracle 宅必备

这个专题讲一些日常运维的异常处理

今天讲一次undo表空间使用率99%的问题处理

1. 现象

公司一套11g的RAC undo表空间使用率在99%，一直不会下降，由于我们用的是自动UNDO空间管理，可能的原因可能就是由于会话一直在利用UNDO里面的内容

2. 原因查找

2.1 查询undo空间使用率

SELECT round(((SELECT (NVL(SUM(bytes), 0))FROM dba_undo_extents

WHERE tablespace_name =

(select value from v$parameter

where lower(name) = 'undo_tablespace')

AND status IN ('ACTIVE', 'UNEXPIRED')) * 100) /

(SELECT SUM(bytes) FROM dba_data_files

WHERE tablespace_name =

(select value from v$parameter

where lower(name) = 'undo_tablespace')), 2) PCT_INUSE

FROM dual

2.2 查看当前事务占用的undo大小

SELECT s.sid, s.username, s.program, t.name,

  t.used_ublk * (SELECT value/1024/1024 FROM v$system_parameter2 WHERE name='db_block_size') as "undoMB",

  flag,space,recursive,noundo,ptx, t.start_time start_mmddyy, t.status

FROM v$transaction t, v$session s

WHERE t.addr=s.taddr(+)

ORDER BY t.used_ublk DESC;

从这里我们会看到START_MMODYY栏位有一些会话是很多天前

继而通过SID获取HASH_VALUE,然后查看具体的SQL语句

发现这些语句为通过DBLINK来获取数据的语句

联想到这个远程数据库前几天发生故障

这里可以肯定是由于分布式查询导致的问题

2.3查看undo表空间各个时间段retention大小

select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,

to_char(end_time, 'DD-MON-RR HH24:MI') end_time,

tuned_undoretention

from v$undostat

order by end_time;

3.问题处理

3.1 查找SQL语句

找到了源头我们先看下这个会话对应的SQL语句

select sid,serial#, decode(sql_hash_value,0,prev_hash_value,sql_hash_value) from v$session where sid=277

这里我们可以间隔一段时间后查看 hash_value是否变化

最后我们查询其对应的语句

select sql_text from v$sqltext where hash_value=195271222 order by piece;

如果为空，表示可能这个会话处于假死状态

3.2 结束会话

首先我们采用常规的命令来杀死会话

alter system kill session '277,35'

发现杀不掉，那么我们采用杀死进程的方式

首先找到该会话对应的进程

select  b.spid from v$session a,v$process b where a.PADDR=b.addr and a.SID='277'

接下来查询该进程的开始时间

发现时间为10月24日,和故障发生的点契合

这时我们放心的杀死他

kill -9 25163

4. 处理完成

杀完之后我们等待一段时间后查询UNDO使用率，发现已经下去了

这时处理完成

5.横向展开

从这个异常我们看出一些分布式的查询可能导致会话异常hang住，从而有个各种问题，我们平时可以通过监控一些长时间运行的会话来确保这个问题不会发生

使用Django批量监控Oracle长会话

6.更多Undo管理内容

Oracle基本概念(Undo空间)

Oracle参数(Undo_Retention)

Oracle基本参数(UNDO_TABLESPACE)

记一次undo表空间使用率99%的问题 undo99