sysaux表空间异常增长之awr数据未自动清理

一、问题分析

收到告警有系统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/

Hehuyi_In

发布了295 篇原创文章 · 获赞 35 · 访问量 8万+

私信关注