周六 被突然起来的短信 轰醒. 一看有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
基本来之于
Item | Space Used (GB) | Schema |
SM/AWR | 15.3005981445313 | SYS |
查看对应表和索引大小排行榜
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 <= 10;
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天是否非常不划算的事.