一、 问题分析
收到告警有系统sysaux表空间使用率超过90%,正常这个表空间使用率是不该这么高的,需要分析问题原因。
查看sysaux表空间中占用最多的部分,发现占最大的是AWR数据,数据量达到29G。
select OCCUPANT_NAME,OCCUPANT_DESC,SPACE_USAGE_KBYTES/1024 USAGE_MB
from V$SYSAUX_OCCUPANTS order by SPACE_USAGE_KBYTES desc;
这个系统平时负载很低,按理不该有这么多AWR数据。找了一个负载较高的系统对比,发现那个系统AWR数据只有约7G。
查看sysaux表空间中占用空间最大的对象名
SELECT D.SEGMENT_NAME, D.SEGMENT_TYPE,SUM(BYTES)/1024/1024 SIZE_MB
FROM DBA_SEGMENTS D
WHERE D.TABLESPACE_NAME = 'SYSAUX'
GROUP BY D.SEGMENT_NAME, D.SEGMENT_TYPE
ORDER BY SIZE_MB DESC;
挑一个大表查询其中数据,发现居然有snap_id=2的数据(当前最新已到8万多)
查看dba_ash视图,发现其中还有snap_id=1的数据,而其对应的时间查到基本就是db的创建时间,所以自db创建以来,awr数据都没清除过。
查看alert日志,发现并没有相关的报错,由于清理awr数据是由m00*进程负责的,还需检查是否有相应trace报错。检查发现确实有,而且每天都有。
查看trace日志内容,发现报错的确实就是Auto-Purge相关操作
查mos文档发现完全符合Doc ID 17079301.8中的情况
该bug没有workaround,只能打补丁修复。
二、 故障修复
主要分两个步骤,一是打补丁,二是清理旧awr数据。根据网上文章,awr数据清理是用delete来清的,不但时间非常长,产生的归档量相对于这个小库来说也很巨大,经沟通决定直接truncate掉过大的基表。
1. 检查OPatch版本
$ORACLE_HOME/OPatch/opatch version
2. 补丁冲突检查
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
3. 关服务器打快照
- 1. select * from v$transaction 检查是否存在回滚长期的事物
- 2. 停监听 lsnrctl stop (lsnrctl status检查)
- 3. 停数据库(约5min)
alter system switch logfile; -- 执行三次。
alter system checkpoint; -- 执行三次。
shutdown immediate; -- 正常关闭数据库。
-- 检查数据库进程是否还存在 ps -ef |grep -i ora_
- 停服务器 init 0
- 联系主机组打快照(秒级完成)
- 主机组启动服务器(先去掉数据库开机自启动)
4. 补丁安装
以下为测试环境操作结果(约1min,先从库后主库约2min)
安装检验
5. 启动数据库,恢复主从同步(5~10min)
主库
startup
lsnrctl start
从库
startup mount
lsnrctl start
--日志应用使用
alter database recover managed standby database disconnect;
--待所有redo日志应用完成后打开数据库
select value from v$dataguard_stats where name='apply lag';
alter database recover managed standby database cancel;
alter database open;
--此时可以采用实时日志应用
alter database recover managed standby database using current logfile disconnect from session parallel 4;
验证同步状态ok后可通知业务起应用连接,重新启用数据库开机自启动。
6. 手动清理过大的WRH$基表
按照 Doc ID 2099998.1 文档所给delete语句统计,几个大表需delete 3000万到5500万行,时间过长并且产生归档量过大,最好使用truncate。若有必要可以先备份数据,WRH$_EVENT_HISTOGRAM 表62天数据约600万行,量依然较大。
统计较大表如下:
truncate语句如下(50MB以上表):
truncate table WRH$_EVENT_HISTOGRAM;
truncate table WRH$_LATCH;
truncate table WRH$_PARAMETER;
truncate table WRH$_SQLSTAT;
truncate table WRH$_SYSSTAT;
truncate table WRH$_LATCH_MISSES_SUMMARY;
truncate table WRH$_SEG_STAT;
truncate table WRH$_ACTIVE_SESSION_HISTORY;
truncate table WRH$_SYSTEM_EVENT;
truncate table WRH$_SERVICE_STAT;
truncate table WRH$_ROWCACHE_SUMMARY;
truncate table WRH$_MVPARAMETER;
truncate table WRH$_SERVICE_WAIT_CLASS;
truncate table WRH$_DB_CACHE_ADVICE;
truncate table WRH$_SYSMETRIC_HISTORY;
truncate table WRH$_SYSMETRIC_SUMMARY;
truncate table WRH$_SGASTAT;
truncate table WRH$_RSRC_CONSUMER_GROUP;
truncate table WRH$_SYS_TIME_MODEL;
truncate table WRH$_WAITSTAT;
truncate table WRH$_OSSTAT;
另外还搜到另一个bug会导致awr无法清理,如果不符合上文描述情况,可以看看
- WRH$_LATCH, WRH$_SYSSTAT, and WRH$_PARAMETER Consume the Majority of Space within SYSAUX ( Doc ID 2099998.1 )
- Bug 14084247 - ORA-1555 or ORA-12571 Failed AWR purge can lead to continued SYSAUX space use。对于已发生Bug 14084247的情况,可按 Doc ID 2099998.1 的步骤手工删除orphan rows来解决。
- http://blog.itpub.net/26736162/viewspace-2152868/