sysaux表空间突增原因分析

现象描述：Sysaux表空间由原来的78%突增14%，涨到92%。

最初怀疑是应用把业务表存放于该表空间，通过工具查看SYSAUX表空间未存放应用数据

通过管控工具查看SYSAUX表空间下包含的表，最大的表为1.5G。

应用人员在他们的管理平台上查到一张3G多的大表WRH$_ACTIVE_SESSION_HISTORY,

在管控工具里输入表名确实能查到该表。但是表空间一列为N/A

因为WRH$_ACTIVE_SESSION_HISTORY表为分区表，只能查单个分区的表空间。用上面语句查表的表空间无结果，返回为N/A.

用下面语句查询分区信息，WRH$_ACTIVE_SESSION_HISTORY表为记录ASH相关信息的表。

select dt.table_owner,
       dt.table_name,
       dt.partition_name,
       dt.subpartition_count,
       dt.high_value,
       dt.high_value_length,
       dt.tablespace_name,
       dt.logging,
       dt.compression,
       dt.compress_for,
       dt.num_rows,
       dt.empty_blocks,
       dt.avg_space,
       dt.avg_row_len,
       dt.chain_cnt,
       dt.last_analyzed,
       dt.global_stats,
       dt.user_stats,
       dt.interval,
       dt.segment_created
  from dba_tab_partitions dt
 where dt.table_owner = 'SYS'
   and dt.TABLE_NAME = 'WRH$_ACTIVE_SESSION_HISTORY';

可以看到该表的分区存放在SYSAUX表空间。在应用系统的管理平台上可以看到该表每天会自动建一个分区。

根据分区名查询每一个分区大小及分区创建时间，记录数据的周期

select ds.owner,
       ds.SEGMENT_NAME,
       ds.PARTITION_NAME,
       ds.tablespace_name,
       round(sum(ds.bytes / 1024 / 1024), 2) table_sizemb,
       do.CREATED
  from dba_segments ds,dba_objects do
 where ds.PARTITION_NAME=do.SUBOBJECT_NAME
 and ds.SEGMENT_NAME=do.OBJECT_NAME
 and ds.PARTITION_NAME in ('WRH$_ACTIVE_SES_MXDB_MXSN',
                          'WRH$_ACTIVE_902114296_45347',
                          'WRH$_ACTIVE_902114296_45371',
                          'WRH$_ACTIVE_902114296_45227',
                          'WRH$_ACTIVE_902114296_45443',
                          'WRH$_ACTIVE_902114296_45275',
                          'WRH$_ACTIVE_902114296_45323',
                          'WRH$_ACTIVE_902114296_45395',
                          'WRH$_ACTIVE_902114296_45299',
                          'WRH$_ACTIVE_902114296_45419',
                          'WRH$_ACTIVE_902114296_45251')
   and ds.SEGMENT_NAME = 'WRH$_ACTIVE_SESSION_HISTORY'
 group by ds.owner, ds.SEGMENT_NAME, ds.PARTITION_NAME, ds.tablespace_name,do.CREATED
 order by sum(ds.bytes / 1024 / 1024) desc

问题原因：

发现2017.11.27 00点-----2017.11.28 00点该时间段记录的数据量较大

管控工具查看每个节点的DB_TIME值，发现2,3,4节点在该时间段负载较大。因为WRH$_ACTIVE_SESSION_HISTORY表记录的是活动会话历史，因为那个时间段的数据库负载超出平常很多倍，所以该时间段产生的记录信息才会较平时多。

2，3，4三个节点的dbtime 负载如下（因为很相似，只帖一个）：

提SR与原厂沟通收集相关信息，进一步分析定位问题原因。

解决方法：表空间扩充

系统表空间SYSTEM、SYSAUX出现突增情况处理思路：
问题分析：
1、若SYSTEM表空间突增，考虑是否开启了数据库审计功能，因为审计数据存放在SYSTEM表空间。
show parameter audit_trail
NONE为不开启审计，11G之后默认为DB

2、若SYSAUX表空间突增，考虑是否该时间段数据库负载较大，因为该表空间存放AWR、ASH相关数据，负载较大时就会产生较大的数据量。

3、也可能是应用数据存放于SYSTEM、SYSAUX表空间

sysaux表空间突增原因分析

猜你喜欢