DBMS_SERVER_ALERT.SET_THRESHOLD 能用但需满足前提：启用指标、statistics_level设为TYPICAL/ALL、仅限本地管理表空间、参数类型和大小写严格匹配，否则无效。
直接说结论：dbms_server_alert.set_threshold 能用，但必须先启用指标、配对参数类型、避开 temp/undo 表空间，否则调了也白调。
为什么 SET_THRESHOLD 调了没反应？
最常见的情况是：函数执行成功，但 DBA_OUTSTANDING_ALERTS 里始终为空。这不是代码写错了，而是底层指标根本没注册。
- 查一下：
SELECT object_name, metric_name FROM dba_thresholds WHERE object_type = 'TABLESPACE'—— 如果返回空，说明指标未启用 - 必须先运行：
DBMS_SERVER_ALERT.ENABLE('Tablescape Used Space')（注意大小写和空格） -
statistics_level必须是TYPICAL或ALL，BASIC下该指标不可用 - 只支持本地管理表空间（LMT），TEMP 和 UNDO 表空间在 EM 和 DBMS_SERVER_ALERT 中都禁用阈值配置
调用 SET_THRESHOLD 的关键参数怎么填？
参数顺序、类型、大小写全错一个就失效。尤其注意 warning_value/critical_value 是字符串，不是数字。
-
metrics_id必须用常量：DBMS_SERVER_ALERT.TABLESPACE_UTILIZATION（不是字符串'TABLESPACE_UTILIZATION'） -
warning_value和critical_value是字符串类型，必须加单引号，例如'85'，不是85 -
object_name填表空间名，区分大小写（如'USERS'），不能填路径或通配符 -
object_type必须显式指定为DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE，不能省略 - 想监控剩余空间（字节）而非使用率？换用
DBMS_SERVER_ALERT.TABLESPACE_BYT_FREE，此时warning_operator要改成DBMS_SERVER_ALERT.OPERATOR_LE（≤），值填字节数字符串，如'10240'表示 10 MB
告警不发邮件？别怪 SET_THRESHOLD
DBMS_SERVER_ALERT 只负责生成告警记录，不负责投递。它把结果写进 DBA_OUTSTANDING_ALERTS，后续靠 EM Agent 推送。
-
SELECT * FROM DBA_OUTSTANDING_ALERTS有记录，但没收到邮件 → 检查 EM 的 Notification Methods 是否配了 SMTP 并启用了对应规则 -
DBA_OUTSTANDING_ALERTS为空 → 不是邮件问题，是前面的指标启用或参数配置出了问题 - EM Agent 停了、Repository 数据库连不上、或者
oraagent进程异常，都会导致告警“静默” - 不要去查
alert.log找表空间告警 —— 它们根本不会写进去
真正容易被忽略的是：阈值依赖每小时一次的 DBA_HIST_TBSPC_SPACE_USAGE 采样，而这个视图本身又依赖 AWR 快照和统计收集。哪怕所有配置都对，如果数据库刚重启且还没跑满一小时，第一次告警也可能延迟出现。
