最近遇到这个case的问题比较多,不知道是不是碰到去年国家要求信息安全啥的,很多数据库都被加上了审计,在积累了一段时间后,问题在最近集中的爆发了.
其实最主要的问题主要集中在AUD$表过大的问题,而且默认设置时候是放在system tablespace中,即使用定期的清除策略,但是大家知道最终AUD$的高水位是没法降低的.除了常见的truncate这张表降低高水位提高可用空间外,而shrink在system表空间的对象是无法使用的,因为system 表空间是属于字典管理的嘛~其实也可以通过将AUD$表设置到其他本地管理的表空间,再配合shrink执行.设置过程也简单,借用DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION函数,
The DBMS_AUDIT_MGMT package provides a subprogram that allows you to move the database audit trail tables out of the SYSTEM tablespace. This improves overall database performance. It also allows you to dedicate an optimized tablespace for audit records.
通过类似如下的命令即可:
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD, audit_trail_location_value => 'LUDATOU'); END; /
然后在后续的回收AUD$空间时候就可以配合定期删除策略采用alter table sys.aud$ shrink cascade来执行,但是在移到新表空间后需要将表aud$的rowmoment的属性打开.
alter table sys.aud$ enable row movement;
移回system表空间的语法类似,
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD, audit_trail_location_value => 'SYSTEM'); END; /
