OEM 13c 表空间告警本质是配置 DBMS_SERVER_ALERT 指标，需手动启用 'Tablespace Used Space' 并正确调用 SET_THRESHOLD，否则即使界面设置也无效。
在 OEM 13c 中设置表空间告警阈值，本质是配置 DBMS_SERVER_ALERT 指标，不是图形界面点几下就完事
OEM 的「表空间使用率」告警背后，调用的是 DBMS_SERVER_ALERT.SET_THRESHOLD，它不认 OEM 界面里填的“90%”这种直观值——所有阈值最终都得落地为 Oracle 内部预定义的指标注册、启用和参数化设置。你看到的 OEM 配置页，只是个外壳；真正起效的，是后台是否成功启用了 'Tablespace Used Space' 这个指标，并为每个表空间单独调用了一次 SET_THRESHOLD。
为什么 OEM 里设了 90% 警告阈值却没邮件？大概率是指标根本没启用
OEM 默认不会自动启用表空间使用率监控指标，哪怕你在界面上勾选了「启用告警」，也只是打开了 OEM 的通知开关，底层指标仍处于休眠状态。
- 先确认指标是否已注册：
SELECT object_name, metric_name FROM dba_thresholds WHERE object_type = 'TABLESPACE';—— 如果返回空，说明'Tablespace Used Space'根本没启用 - 必须手动启用：执行
BEGIN DBMS_SERVER_ALERT.ENABLE('Tablespace Used Space'); END; - 该指标依赖
STATISTICS_LEVEL = TYPICAL或ALL；若当前是BASIC，需先运行ALTER SYSTEM SET statistics_level = TYPICAL; - 临时表空间（
TEMP）不支持此指标 —— 对它设任何百分比阈值都不会触发告警，OEM 界面里对 TEMP 表空间的配置实际无效
OEM 中修改阈值后 DBA_OUTSTANDING_ALERTS 仍为空？检查这四个硬性参数约束
DBMS_SERVER_ALERT.SET_THRESHOLD 是个“零容忍”函数：错一个参数类型或顺序，就静默失败，不报错也不生效。
-
metrics_id必须用常量，比如DBMS_SERVER_ALERT.TABLESPACE_UTILIZATION，不能传字符串'TABLESPACE_UTILIZATION' -
warning_value和critical_value是 字符串类型，必须带单引号，如'85'；写成85会失败 -
object_type必须显式指定为DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE，不能省略或传NULL -
object_name是具体表空间名，区分大小写，比如'USERS'，不能是小写'users'，也不能是数据文件路径
OEM 告警延迟严重（比如卡一周才发邮件）？这是设计行为，不是 Bug
OEM 13c 对「警告级」（Warning）阈值默认采用「持续性触发」策略：表空间使用率超过 90%，但未突破 95%（Critical），系统不会立刻发邮件，而是等待该状态持续满足一定时间窗口（默认 7 天），才生成通知。这不是配置错误，是 Oracle 的告警分级机制。
- 想让警告立即触发邮件，必须在 OEM 中进入对应数据库的「度量」→「表空间使用率」→「编辑阈值」，勾选「立即触发警告事件」（Immediate Warning Alert）选项（部分版本叫
Fire immediately on warning） - 该选项底层会修改
DBMS_SERVER_ALERT.SET_THRESHOLD的observation_period和consecutive_occurrences参数，但 OEM 界面不暴露这些细节，所以一旦需要精确控制延迟，建议绕过 OEM，直接用 PL/SQL 调用并显式传参 - 严重级（Critical）告警不受此限制，只要瞬时突破阈值，就会立即触发
dba_thresholds 视图中每条记录的 object_name 和 warning_value 是否真实存在且格式正确。 
