AWR引入的一个结果，就是系统需要根据配置内容将性能数据保存在数据库中。从10g之后，sysaux表空间从system表空间从脱离开来，就提供了这种可能性。我们在实际运维工作中，是可能会遇到AWR元数据引起的故障问题。本篇主要介绍这个案例，留待需要同仁待查。

1、问题说明

运维人员都有“节日休假恐怖症”，越到节日、休假和外出出差，系统越可能出现问题。笔者在进行一个系统的例行检查时，出现了问题。

数据库版本为11gR2，具体版本编号为11.2.0.3。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

PL/SQL Release 11.2.0.3.0 - Production

CORE? ? 11.2.0.3.0? ? Production

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 – Production

问题发现的由头是生成AWR报告的时候，发现近几天都没有正常生成AWR Snapshot。由于是很少用的系统，所以笔者只在每月进行一次跟踪。这种情况肯定不正常，进入10g之后，AWR后台默认每隔一小时，都会自动生成一个Snapshot镜像数据。

这种情况，笔者本能想去定位alert log，大部分异常情况，Oracle都会记录在数据库中。果然在其中发现了问题。

Wed Sep 30 14:24:15 2015

ORA-1653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 128 in? ? ? ? ? ? ? ? tablespace SYSAUX?

Errors in file /home/oracle/app/diag/rdbms/xxx/xxxdb/trace/xxxdb_j000_3385.trc:

ORA-01653: unable to extend table . by? in tablespace?

ORA-01653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 128 in tablespace SYSAUX

Wed Sep 30 15:06:58 2015

ORA-1653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 128 in? ? ? ? ? ? ? ? tablespace SYSAUX?

Errors in file /home/oracle/app/diag/rdbms/xxxdb/xxxdb/trace/xxxdb_j000_5102.trc:

ORA-01653: unable to extend table . by? in tablespace?

ORA-01653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 128 in tablespace SYSAUX

从内容上看，是sysaux表空间满了。默认情况下，Oracle的系统性质表空间都是不支持文件自动拓展的。如果原有大小写满了，同时不支持自动拓展，的确会有报错异常。

此时，AWR配置内容是默认方式。

SQL> select * from dba_hist_wr_control;

? ? ? DBID SNAP_INTERVAL? ? ? ? ? ? ? ? ? ? ? ? ? RETENTION? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TOPNSQL

---------- --------------------------------------- --------------------------------------- ----------

1778314713 +00000 01:00:00.0? ? ? ? ? ? ? ? ? ? ? +00008 00:00:00.0? ? ? ? ? ? ? ? ? ? ? DEFAULT

默认AWR是每小时保存一个镜像，镜像数据会保存八天。此时，AWR中已经没有对应的数据镜像了。

SQL> select snap_id, dbid, startup_time from dba_hist_snapshot;

? SNAP_ID? ? ? DBID STARTUP_TIME

---------- ---------- --------------------------------------------------------------------------------

2、问题缓解

一般数据库故障，通常不是一个单独策略可以解决的。笔者认为：问题分轻重缓急，解决方案也分猛药温补。关键的取舍取决于不同的场景优先级别。在这种情况下，恢复AWR工作，增加sysaux表空间存储是首要需求。

这种操作比较简单，只要单独定位和允许文件自动拓展即可。

SQL> alter database datafile '/data/xxxdb/systs/sysaux01.dbf' autoextend on;

Database altered

SQL> select bytes/1024/1024, AUTOEXTENSIBLE from dba_data_files where tablespace_name='SYSAUX';

BYTES/1024/1024 AUTOEXTENSIBLE

--------------- --------------

? ? ? ? ? 1032 YES

Alert log中记录信息。

YSAUX

Wed Sep 30 15:30:13 2015

alter database datafile '/data/xxxdb/systs/sysaux01.dbf' autoextend on

Completed: alter database datafile '/data/xxxdb/systs/sysaux01.dbf' autoextend on

手工测试生成AWR镜像，判断问题是否解决。

SQL> exec dbms_workload_repository.create_snapshot;

PL/SQL procedure successfully completed

SQL> select snap_id, to_char(BEGIN_INTERVAL_TIME,'yyyy-mm-dd hh24:mi:ss') from dba_hist_snapshot;

? SNAP_ID TO_CHAR(BEGIN_INTERVAL_TIME,'Y

---------- ------------------------------

? ? 23383 2015-09-30 15:40:16

在日志中没有新的报错信息出现。可以认为初步问题解决。下一步就是定位问题：为什么会出现sysaux爆棚的情况。

3、深层分析过程

AWR和其他一些性能收集，的确是不断的将数据收集到sysaux表空间里面进行记录。笔者一直认为：任何正确的数据架构模式，必要条件之一就是“有进有出”。数据不断积累，一定要有机制（系统内或者系统外）让数据可以脱离系统。从微观角度看，数据表要维持一个稳定的体积容量结构。