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
---------------------------------------------------------------