异常分析：由于APM日志过多导致数据库大小异常

一、问题现象

某客户使用RDS数据库，反馈1000GRDS空间即将用尽，需要分析下情况。

二、原因分析

1、沟通现场RDS有多个库，但是正式库近期增速较快，初判可能原因是发生在正式库。

2、如图统计结果显示，正式库当前占用空间合计约555G，直接空闲空间约216G，这部分空闲空间可以收缩，收缩后大约还有约339G大小，现场反馈一个月前数据库大小仅100G左右，多出的239G大小原因不明。

3、排查临时表数量及大小，情况均正常。

SELECT CAST(sum(a.total_pages) * 8 / 1024 AS VARCHAR) + ' MB' [临时表总使用空间]
FROM sys.partitions p
    JOIN sys.allocation_units a ON p.partition_id = a.container_id
    JOIN sys.tables it ON p.object_id = it.object_id
WHERE it.name LIKE 'TM%'

4、在SQL Server Management Studio查看“报表-按排在前面的表的磁盘使用情况”，结果显示T_APM_LOG表占用约248G。

5、T_APM_LOG表存储的是APM日志，一般情况下我们可参考https://vip.kingdee.com/article/184271 获取APM报告用于性能分析，现场这么多APM报告是谁抓取的呢？

6、通过以下SQL，查询了下现场APM报告的创建人，发现都是同一个人，现场确认此用户是WEBAPI集成用户。

7、为何WEBAPI用户会生成如此多的APM日志呢？原来现场参考https://vip.kingdee.com/article/127415816261598464  设置了WEBAPI调用生成APM报告，一直没有关闭导致现场APM日志过大。

三、解决方案

经过上述分析检查已确认问题原因，那接下来就需要解决并避免后续问题：

1、WEBAPI调用在非必要时，不要启用APM功能，二开人员处理。

2、过大的APM报告需要清理，可以从数据库直接清理：

    1）建议备份下数据库，以免操作失误引起数据问题；

    2）执行以下脚本清理日志：

        truncate table T_APM_LOG;

        truncate table T_APM_PAGE;

        truncate table T_APM_TRACE;

        truncate table T_APM_REQUEST;

3、收缩数据库。