dbms_server_alert.set_threshold对表空间告警无效是因为指标未启用，需先确认statistics_level=typical/all、启用'tablesapce used space'指标，并严格按参数顺序和类型调用set_threshold。
DBMS_SERVER_ALERT.SET_THRESHOLD 对表空间告警无效？不是函数写错了，而是指标根本没启用。
为什么 SET_THRESHOLD 调用成功却没告警
执行完 DBMS_SERVER_ALERT.SET_THRESHOLD 后表空间涨到 95%，DBA_OUTSTANDING_ALERTS 里查不到记录——这不是代码问题，而是 Oracle 的告警机制有前置依赖：
- 必须先确认
'Tablesapce Used Space'指标已注册：运行SELECT object_name, metric_name FROM dba_thresholds WHERE object_type = 'TABLESPACE';，结果为空就说明指标未启用 - 该指标仅在 Oracle 10gR2+ 且
STATISTICS_LEVEL = TYPICAL或ALL时可用（ALTER SYSTEM SET STATISTICS_LEVEL=TYPICAL SCOPE=BOTH;） - 必须显式调用
DBMS_SERVER_ALERT.ENABLE('Tablesapce Used Space')（注意大小写和空格，漏一个字符都不行）
SET_THRESHOLD 参数顺序和类型容易踩的坑
参数名（如 metrics_id）只是可读性辅助，真正起作用的是传参顺序和类型。常见错误包括把表空间名当第一个参数、数值不加单引号、对象类型写错：
- 第一个参数是指标 ID，固定用
DBMS_SERVER_ALERT.TABLESPACE_UTILIZATION，不是字符串'TABLESPACE_UTILIZATION' -
warning_value和critical_value是 字符串类型，必须写成'85'，不能写85或'85%' -
object_type必须明确指定为DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE，不能省略或填'TABLESPACE' -
object_name是具体表空间名，区分大小写（如'USERS'），不支持通配符，'%'或空字符串会静默失败
告警触发后去哪查、怎么验证
告警不会写入 alert.log，也不会自动发邮件——它只生成记录到数据字典视图：
- 实时查是否触发：查询
SELECT * FROM DBA_OUTSTANDING_ALERTS WHERE object_type = 'TABLESPACE'; - 确认阈值已生效：查
SELECT * FROM DBA_THRESHOLDS WHERE object_type = 'TABLESPACE'; - 后台进程
MMON每分钟轮询一次，所以告警延迟最多 60 秒；若长时间不出现，优先检查STATISTICS_LEVEL和指标启用状态 - 已有告警不会自动消失，需等监控周期结束或手动触发 AWR 快照（
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;）
禁用告警不是删视图，而是重置阈值
DBA_OUTSTANDING_ALERTS 是只读视图，删不掉也清不了——它只是 MMON 进程比对结果的快照。要停告警，得关掉阈值监控本身：
- 把对应表空间的阈值设为 NULL：
warning_value => NULL, critical_value => NULL, warning_operator => DBMS_SERVER_ALERT.OPERATOR_DO_NOT_CHECK - 不能只设
critical_value => NULL而漏掉warning_operator，否则仍可能触发 warning 级告警 - 如果想全局禁用所有表空间告警，需对每个表空间逐个调用
SET_THRESHOLD，Oracle 不提供批量开关
最常被忽略的一点：即使阈值设了，如果表空间启用了 AUTOEXTENSIBLE，真实瓶颈可能是磁盘空间而非 Oracle 内部使用率——查 DBA_DATA_FILES.MAXBYTES 才知道还能扩多少。
