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参数和过滤时机——这两点漏掉一个，前面全白干。