ADDM过滤需在CREATE_TASK后、EXECUTE_TASK前调用ADD_SEGMENT_FILTER等函数，并确保MODE设为'TYPICAL'，否则过滤无效；TIME_LIMIT不低于300秒，且每次任务用唯一task_name以避免缓存干扰。
ADDM报告里总出现不关心的IO警告，怎么过滤掉
addm默认分析整个数据库负载，常把临时表空间争用、归档延迟这类你已知且暂不处理的问题反复标为“严重”。关键不是关addm，而是用dbms_advisor.add_sqlwkld_filter或dbms_advisor.add_segment_filter在分析前就切掉干扰项。
- 只对当前任务生效：必须在
DBMS_ADVISOR.CREATE_TASK之后、EXECUTE_TASK之前调用过滤函数，执行完再加无效 - 按对象过滤最常用：比如不想看
TEMP表空间，就跑DBMS_ADVISOR.ADD_SEGMENT_FILTER('ADDM_TASK_123', 'TABLESPACE', 'TEMP') - SQL级过滤要谨慎：用
ADD_SQLWKLD_FILTER时，attribute_name填SQL_ID或MODULE，但ADDM本身不保证捕获所有SQL，漏掉的仍会进分析
DBMS_ADVISOR.SET_TASK_PARAMETER设错参数导致过滤失效
常见错误是把MODE参数设成'COMPREHENSIVE'还硬塞过滤——ADDM在该模式下会忽略所有用户过滤，强制全量扫描。真正起效的只有'TYPICAL'模式（默认值）。
-
DBMS_ADVISOR.SET_TASK_PARAMETER('ADDM_TASK_123', 'MODE', 'TYPICAL')必须显式调一次，尤其从模板复制的任务容易继承COMPREHENSIVE -
TIME_LIMIT设太小（如60秒）会导致ADDM跳过过滤逻辑直接返回粗略结果，建议至少300 - 别碰
DBMS_ADVISOR.SET_TASK_PARAMETER里的DB_INSTANCE或INSTANCE，多实例RAC环境下填错实例名会让过滤完全不加载
为什么禁用某类警告后ADDM报告还是显示“Performance Issue”
ADDM的“Performance Issue”是顶层结论，由多个底层发现聚合而来。即使你过滤了DB_FILE_SCATTERED_READ等待事件，只要还有其他未过滤的瓶颈（比如enq: TX - row lock contention），它仍会标红。
- 先查实际触发点：
SELECT finding_name, impact FROM DBA_ADVISOR_FINDINGS WHERE task_name = 'ADDM_TASK_123'，确认哪些finding没被滤掉 - 过滤粒度不够细：比如只想屏蔽“归档慢”，但只过滤了
ARCHIVE_LAG_TARGET参数，而真实问题是log file sync等待，得换ADD_WAIT_CLASS_FILTER - ADDM缓存影响：同一时间窗口的任务ID重复使用时，旧过滤规则可能残留，建议每次新建唯一task_name
修改后验证过滤是否真生效
别只看报告里有没有那条警告，重点检查DBA_ADVISOR_RECOMMENDATIONS和DBA_ADVISOR_RATIONALE里对应finding的task_id是否真的消失。
- 执行后立刻查：
SELECT COUNT(*) FROM DBA_ADVISOR_FINDINGS WHERE task_name = 'ADDM_TASK_123' AND finding_name LIKE '%I/O%'，数字应明显下降 - 对比基线：用
DBMS_ADVISOR.CREATE_TASK创建同时间段的对照任务（不加过滤），两份报告的FINDING_COUNT字段差值就是过滤掉的数量 - 注意
STATUS字段：过滤成功的finding在DBA_ADVISOR_FINDINGS里状态是INACTIVE，不是INVALID或空
事情说清了就结束。过滤逻辑只作用于单次ADDM任务，且高度依赖MODE参数和过滤时机——这两点漏掉一个，前面全白干。
