system表空间暴涨问题

今天接到一个案例，客户数据库系统system表空间增长非常快，达到了32个G，要求查一下原因。
心理第一个反应是，有人把业务数据放到system表空间下了？先查查看：

select username,default_tablespace from dba_users ;

查看了，没有业务数据放到system表空间下。
再次，考虑表的增长，11G默认审计是开启的，查一下：

show parameter audit 

审计状态 开启。级别DB select * from dba_segments where segment_name = 'AUD$'; 再查一下，审计相关表AUD$

看来问题确实是 审计表出现大规模增长了。继续查具体信息:

select COUNT(1)from dba_audit_trail ;

select * from dba_audit_trail ;

发现异常，同一个K 用户，在爆连数据库，先锁了K用户，联系开发和安全工程师会同查看是否程序端有问题，接下来要解决掉异常登陆的BUG程序，并在库端清除异常登陆审计信息，回收大额空间即可。
此外，我看到别人的案例中思路是:
alter system set audit_trail=none scope = spfile;
停掉审计,我本人并不赞同。
可以对system表空间做一次数据清理，将表中历史数据做一个转存， 然后：
truncate table aud$ reuse storage;
再逐步回收段空间：
alter table aud$ deallocate unused keep 3000M;
再缩小数据文件大小：
ALTER DATABASE DATAFILE 'D:\ora_tablespace\SYSTEM01.dbf' RESIZE 5000M;可分步执行。
此过程中可能会报错：
ORA-03297: file contains used data beyond requested RESIZE value
原因是数据文件收缩大大小取决于高水位线（HWM）的位置，压缩表空间大小，最小必须是该表空间目前最大块段的大小
还可能是表的初始大小分配的太大。（truncate可以降低HWM，所以你收缩表空间之前，可以先查一下truncate aud$后最大块的段所占用的空间，再权衡RESIZE的合理值）
在此引用别人的一个解决方案：https://blog.csdn.net/aptweasel/article/details/8988427，我不再赘述。