由于开启审计导致故障的紧急处理

CPU 内存 100%原因

由于开启审计导致故障的紧急处理

 

紧急故障截图：

--找出消耗物理IO资源最大的的SQL语句
select disk_reads, substr(sql_text,1,4000) from v$sqlarea  order by disk_reads desc;

SELECT TO_CHAR(current_timestamp AT TIME ZONE 'GMT', 'YYYY-MM-DD HH24:MI:SS TZD') AS curr_timestamp, COUNT(username) AS failed_count
FROM  sys.dba_audit_session WHERE returncode != 0 AND TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') >= TO_CHAR(current_timestamp - TO_DSINTERVAL('0 0:30:00'), 'YYYY-MM-DD HH24:MI:SS')

这条语句严重影响了数据库性能

其中sys.dba_audit_session 是ORACLE得审计表

 

 

10G 默认审计是关闭的
11G 安装的时候默认开启的
由于前台应用程序异常的用户连接失败，继续连接。

往审计表DBA_AUDIT_SESSION  中不停的写涉及CONNECT 和DISCONNECT 的所有审计跟踪记录

DBA_AUDIT_SESSION 表中目前有1千多万条的记录，而且记录数还在增加。

当启动OEM的时候，导致Oracle自己的低效SQL

这个SQL在Elapsed Time、CPU Time、User I/O Wait Time、Buffer Gets、Physical Reads都会出现，其SQL模块是Oracle Enterprise Manager.Metric Engine。显然这是一个OEM自己的SQL，检查完整SQL语句：
SELECT TO_CHAR(current_timestamp AT TIME ZONE 'GMT', 'YYYY-MM-DD HH24:MI:SS TZD') AS curr_timestamp, COUNT(username) AS failed_count FROM sys.dba_audit_session WHERE returncode != 0 AND TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') >= TO_CHAR(current_timestamp - TO_DSINTERVAL('0 0:30:00'), 'YYYY-MM-DD HH24:MI:SS')

这个检查DBA_AUDIT_SESSION的SQL语句写法很烂，以致于一开始我还不太相信是出自Oracle，不过Oracle Enterprise Manager.Metric Engine的MODULE NAME已经说明了问题，Oracle居然自己违反对列进行操作以及不必要的转换原则。
此外，这个SQL基本上没有办法使用索引，如果DBA_AUDIT_SESSION中记录很多，那么这个SQL会非常耗时，这也算是OEM的bug，至少也是一种设计缺陷。

我们的平台的版本号为oracle 11.2.0.1

 

处理办法：
删除 DBA_AUDIT_SESSION 表中目前有1千多万条的记录

truncate table DBA_AUDIT_SESSION

 

 

 

 

 

 

 

此问题 网上有类似的文章帖子

 

--=============================================

查找相关问题

参考

此问题 网上有类似的文章帖子
地址 http://www.eygle.com/archives/2011/02/failed_login_count.html

OEM模块审计查询语句占用较大资源
作者: yangtingkun(http://yangtingkun.itpub.net)
发表于: 2011.10.14 23:21
分类: ORACLE , Bug
出处: http://yangtingkun.itpub.net/post/468/524338
---------------------------------------------------------------