一、 问题分析
收到告警有系统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，只能打补丁修复。

二、 补充根因分析
检查发现我们其他11.2.0.4版本的数据库也都遇到了这个bug中描述的报错，追了SR问这个bug的触发条件是什么？是只要11.2.0.4版本的数据库都会遇到吗？

下面是SR的回复：

根据这个bug的rediscovery note，只要mnnn trace中有如下报错就是匹配这个bug的。

An AWR auto flush in MMON job might produce errors like below when
running dbms_stats.copy_table_stats

*** KEWROCISTMTEXEC – encountered error: (ORA-06525: Length Mismatch for CHAR
ORA-06512: at “SYS.DBMS_STATS”, line 29022
ORA-06512: at line 1
)
*** SQLSTR: total-len=93, dump-len=93,
STR={begin dbms_stats.copy_table_stats(‘SYS’, :bind1, :bind2, :bind3, flags=>1, force=>TRUE
); end;}

Rediscovery Notes
Above errors in Mnnn tracefile<<<<<
触发原因可以参考如下internal描述，应该是有分区表的环境才会遇到的：

INTERNAL PROBLEM DESCRIPTION:

When copying table stats in dbms_stats, we will call a C callout to get the min/max of a column in the partitioning key. An output variable of this C callout is an OCIRaw number, which stores the raw value of the min/max. An OCIRaw variable must have its length set up to perform properly. However in the current code we only assign the length when certain conditions have been satisified. If those conditions are not met, for example, when the column is null, the OCIRaw number will be passed back without data populated and an uninitialized length.

INTERNAL FIX DESCRIPTION:

The fix is to immediately initialize the length after the OCIRaw variable has been created.

还想请教一下：

1. 这里说的“有分区表的环境” 是指业务表有分区表还是系统的分区表也算？
2. 这个bug除了会导致awr数据清理失败sysaux表空间一直增大，还会有其他的影响吗？
3. 打了补丁之后如果我没有手动清理旧数据，它是不是会从snap_id=1一直清到只剩最近62天的数据？
下面是SR的回复：

1&2： 这个研发没有提，但是从开bug的客户情况来看，是在WRH$_FILESTATS（AWR的数据文件统计信息）上遇到的：

From the trace file “*_m000_4140.trc” :
>>
========== FRAME [44] (kewrsgp_split_glob_partn()+1437 ->
kewrclps_clone_partn_statistics()) ==========
defined by frame pointers 0xbf8b560 and 0xbf8b110
CALL TYPE: CALL??? ERROR SIGNALED: no COMPONENT: AWR
Dump of memory from 0x000000000BF8B160 to 0x000000000BF8B560
00BF8B160 00000000 00000000 41FD7838 00000001 [……..8x.A….]
00BF8B170 65746C61 61742072 20656C62 24485257 [alter table WRH$]
00BF8B180 4C49465F 41545345 20535854 696C7073 [_FILESTATXS spli]
00BF8B190 61702074 74697472 206E6F69 24485257 [t partition WRH$]
00BF8B1A0 4C49465F 5F545345 36313231 31343732 [_FILEST_12162741]
00BF8B1B0 335F3832 61203333 31282074 32363132 [28_333 at (12162]
00BF8B1C0 32313437 35332C38 69202937 206F746E [74128,357) into ]
00BF8B1D0 72617028 69746974 57206E6F 5F244852 [(partition WRH$_]
00BF8B1E0 454C4946 315F5453 32363132 32313437 [FILEST_121627412]
实际发生问题的sql（它递归调用的上面dump中的sql）是这个：

begin
dbms_stats.copy_table_stats(‘SYS’, ‘WRH$_FILESTATXS’,’WRH$_FILEST_1216274128_333′,’WRH$_FILEST_1216274128_357′,flags=>1,force=>TRUE);
end;
前面给的internal description中第一句话提到When copying table stats in dbms_stats, we will call a C callout to get the min/max of a column in the partitioning key，就是指上述dbms_stats.copy_table_stats操作。这个操作除了AWR自身用到，很少有人工执行的可能性吧，所以是否有其他影响应该看是否会在分区表上用到dbms_stats.copy_table_stats操作。

3：打补丁是避免今后的awr自动清理失败。而对于已经清理失败的历史数据，还是需要手工清理的。

三、 故障修复
主要分两个步骤，一是打补丁，二是清理旧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/
————————————————
版权声明：本文为CSDN博主「Hehuyi_In」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Hehuyi_In/java/article/details/104860448