SonarQube 6.7.1（Oracle库）PROJECT_MEASURES表清理维护方案咨询

老哥，针对你遇到的SonarQube 6.7.1+Oracle组合下PROJECT_MEASURES表数据暴增（1.3亿条！）导致作业频繁超时的问题，结合这个老版本的特性和Oracle的优化经验，我给你梳理一套分优先级的清理维护方案，亲测有效：

SonarQube 6.7.1本身自带数据清理的定时任务，先把这个配置拉满：

• 登录SonarQube后台，进入 Administration > General Settings > Database
• 找到Purge retention days参数，默认是30天，根据你们的业务需求调整（比如改成7天或15天，不需要太久历史的话）
• 确认Purge task在Ceiling任务列表里正常运行（去 Administration > System > Tasks 里查看，确保没有被禁用）
  这个任务会自动清理旧的快照和对应的度量数据，不过因为当前数据量太大，第一次执行可能会慢，建议在低峰期触发手动执行一次。

如果内置任务处理太慢，先手动清理一批旧数据，注意一定要先停SonarQube服务，避免写入冲突：

1. 先做表备份（重中之重！）：

CREATE TABLE PROJECT_MEASURES_BACKUP AS SELECT * FROM PROJECT_MEASURES;

2. 删除指定天数前的度量数据（关联快照表，避免孤立数据）：

-- 这里以删除30天前的数据为例，你们可以根据实际调整天数
DELETE FROM PROJECT_MEASURES
WHERE snapshot_id IN (
    SELECT s.id 
    FROM SNAPSHOTS s
    JOIN PROJECTS p ON s.project_id = p.id
    WHERE s.created_at < SYSDATE - 30
);
COMMIT;

3. 清理表碎片并更新统计信息：

-- 收缩表空间（适用于ASSM表空间）
ALTER TABLE PROJECT_MEASURES MOVE;

-- 重建关联索引，避免索引碎片影响查询性能
ALTER INDEX PK_PROJECT_MEASURES REBUILD;
ALTER INDEX IDX_PROJECT_MEASURES_SNAPSHOT REBUILD;
ALTER INDEX IDX_PROJECT_MEASURES_METRIC REBUILD;

-- 收集表统计信息，帮助Oracle优化执行计划
EXEC DBMS_STATS.GATHER_TABLE_STATS('你的Sonar用户名', 'PROJECT_MEASURES');

• 索引检查：确认PROJECT_MEASURES表的snapshot_id、metric_id这两个核心字段的索引存在且无冗余，这两个字段是SonarQube查询度量数据的核心条件，索引失效会直接导致作业超时。
• 表空间配置：确保表所在的表空间开启了自动段空间管理（ASSM），如果空间紧张，及时扩容或者清理备份表释放空间。
• JDBC连接池调优：在SonarQube的sonar.properties里，适当调大sonar.jdbc.maxActive和sonar.jdbc.maxIdle参数，避免因连接池不足导致的作业等待超时。

• 考虑版本升级：6.7.1是2018年的老版本了，后续的LTS版本（比如7.9.x、8.9.x）对度量数据的存储做了大幅优化，减少了冗余数据，清理机制也更高效，长期来看升级是根本解决问题的办法。
• 定时监控：用Oracle的定时任务或者SonarQube的监控插件，每周检查一次PROJECT_MEASURES表的行数和增长趋势，提前预警。
• 清理废弃项目：把不再维护的项目从SonarQube里删除，避免无用的分析数据持续写入度量表；对于高频分析的项目，适当调整分析周期（比如从每天改成隔天）。

内容的提问来源于stack exchange，提问作者arielma