清理sysaux表空间的wrh$_latch_children表
周六 被突然起来的短信 轰醒. 一看有63条短信. 都是来之与监控中的.有关表空间大小超过某个警戒值。
发现 sysaux表空间超过了15gb
通过下面代码查看sysaux表空间的功能占用情况
select occupant_name item,
      space_usage_kbytes / 1048576 space used (gb),
      schema_name schema,
      move_procedure move procedure
  from v$sysaux_occupants
order by 2 desc
基本来之于 
itemspace used (gb)schema
sm/awr15.3005981445313sys
查看相应表和索引大小排行榜
select *
  from (select segment_name,
              partition_name,
              segment_type,
              bytes / 1024 / 1024
          from dba_segments
        where tablespace_name = 'sysaux'
        order by 4 desc)
 where rownum
segment_name partition_name segment_type bytes/1024/1024
wrh$_latch_children wrh$_latch__567344007_15885 table partition 3971
wrh$_latch_children_pk wrh$_latch__567344007_15885 index partition 2822
wrh$_latch_children wrh$_latch__567344007_0 table partition 2213
wrh$_latch_children wrh$_latch__567344007_15909 table partition 1984
wrh$_latch_children_pk wrh$_latch__567344007_0 index partition 1537
wrh$_latch_children_pk wrh$_latch__567344007_15909 index partition 1412
基本上都是 wrh$表的分区过大  其中 wrh$_latch__567344007_15909  第一个数字是dbid 第二数字是快照id.
需要检查上面 15885 15909 0 三个id 是否是近期的id?
查看id的时间 发现 是最近2天的id
select snap_id, begin_interval_time from sys.dba_hist_snapshot order by snap_id;
是不是 把statistics_level 设置了all 导致他们变大了呢?
不过关如何 我们把 0给清空掉!
alter table wrh$_latch_children truncate partition wrh$_latch__567344007_0;
把原来默认awr 保留31天 改成保留10天
select dbms_stats.get_stats_history_retention from dual;
exec dbms_stats.alter_stats_history_retention(10);
清空掉 11天的统计信息
exec dbms_stats.purge_stats(systimestamp -11);
说实在的 这些统计信息占空间不多, 只是为了保持一致行. 库大了保留31天是否很不划算的事。
本文永久更新链接地址：
，