Oracle Enterprise Manager（简称OEM）是Oracle官方提供的一体化管理平台，其中监控与报警是最核心的功能模块。一套配置合理的监控体系，可以在数据库出现异常的第一时间通知DBA处理，而配置不当的监控则可能带来大量误报，让人逐渐对报警失去信任。本文将从指标分类、阈值配置、通知规则和常见问题排查几个方面，系统讲解OEM监控指标与报警设置的实践方法。
一、OEM核心监控指标有哪些
OEM的监控指标（Metric）数量非常多，一个标准的目标类型下往往有上百个指标，但日常运维中真正需要重点关注的是其中一小部分。按照监控对象和目的，可以将常用指标划分为以下几个类别。
第一类是可用性指标，例如目标Up或Down状态、监听器状态、Agent可达性等。这类指标通常是二值型的，一旦状态发生变化就应该立即告警，是所有监控配置的基础。第二类是空间类指标，最典型的是表空间使用率（Tablespace Space Used %）、Fast Recovery Area使用率、归档日志目录剩余空间等。空间问题发展缓慢但后果严重，一旦数据文件写满，业务会直接中断。
第三类是性能类指标，包括数据库响应时间、每秒事务数、逻辑读与物理读比例、Buffer Cache命中率、Top SQL的CPU消耗等。这些指标通常不建议简单地设置上下限阈值，而是要结合基线（Baseline）做趋势判断。第四类是等待事件与锁类指标，例如enq等待、行级锁阻塞会话数、 latch争用等，这类指标异常往往意味着应用层面存在设计问题。第五类是告警日志类指标，OEM可以扫描alert log，捕获ORA-错误、损坏块等信息并转化为事件。
在OEM界面中，可以通过目标主页进入“监视”菜单下的“度量与收集设置”页面查看全部指标。每个指标都有默认的收集频率和阈值，DBA需要根据业务特点逐项评估，而不是全盘接受默认值。
二、如何配置阈值与修正动作
阈值配置是报警设置的核心环节。OEM支持两种阈值类型：静态阈值和基于基线的自适应阈值。静态阈值适合状态明确、边界清晰的指标，例如表空间使用率超过85%告警、超过95%严重告警。而自适应阈值（Adaptive Thresholds）依赖AWR基线，系统会学习指标在正常时段的波动范围，动态计算告警边界，特别适合具有明显周期性的业务系统，比如白天高负载、夜间批量作业的场景。
配置静态阈值的步骤是：进入目标主页，依次打开“监视”、“度量与收集设置”，找到对应指标后点击编辑图标，在警告阈值和严重阈值栏中填入数值，同时可以设置连续违反次数（Consecutive Occurrences），避免一次瞬时抖动就触发报警。例如CPU使用率指标设置为连续3次超过90%才告警，可以有效过滤掉短暂的负载尖峰。
除了报警之外，OEM还支持为指标配置修正动作（Corrective Action），即在触发阈值时自动执行预定义的处理脚本，例如当表空间使用率超过阈值时自动执行添加数据文件、当发现死锁会话时自动收集详细信息等。修正动作支持SQL脚本、主机脚本和PL/SQL过程三种形式。下面是一个表空间扩容的修正动作示例：
-- 修正动作：当表空间使用率超过90%时自动扩展数据文件
DECLARE
v_tsname VARCHAR2(30);
BEGIN
SELECT tablespace_name INTO v_tsname
FROM dba_tablespace_usage_metrics
WHERE used_percent > 90
AND rownum = 1;
-- 为该表空间对应的自增数据文件触发一次自动扩展
FOR f IN (SELECT file_name FROM dba_data_files
WHERE tablespace_name = v_tsname AND autoextensible = 'YES')
LOOP
EXECUTE IMMEDIATE 'ALTER DATABASE DATAFILE ''' || f.file_name ||
''' RESIZE ' ||
(SELECT TO_CHAR(bytes + 512*1024*1024)
FROM dba_data_files WHERE file_name = f.file_name);
END LOOP;
END;
/需要强调的是，修正动作虽然能自动化处理问题，但必须谨慎设计。任何会改变数据库结构的自动操作都应该先在测试环境充分验证，并且建议在通知中明确标注该事件已执行了哪些修正动作，方便事后审计。
三、通知规则与升级策略配置
阈值只是产生事件，真正触达运维人员的是通知规则。OEM的通知体系由事件规则（Event Rules）和通知方法（Notification Methods）组成。通知方法支持电子邮件、SNMP Trap、脚本调用以及与第三方平台的Webhook集成。建议在生产环境中至少配置两种通知渠道，避免单一邮件服务器故障导致所有报警丢失。
事件规则的编写要点是分层过滤。第一层按目标分组过滤，例如将核心交易库归入“生产关键”组，将测试库归入“非关键”组，两组使用不同的通知策略。第二层按严重程度过滤，Critical事件要求15分钟内响应，Warning事件可以汇总后每日发送。第三层按时间段过滤，非工作时间只通知Critical级别，或者将值班人员的手机号配置到夜间通知渠道中。
升级机制（Escalation）同样重要。当一个Critical事件在指定时间内无人处理时，OEM可以自动将通知升级到上级负责人或备用值班人。配置时可以在规则的“重复通知”选项中设置每30分钟重复一次，最多重复3次，之后升级给值班经理。这种机制保证了重要事件不会因为单人疏漏而被遗漏。
对于大规模环境，逐个目标配置规则效率太低。OEM提供了基于管理模板（Monitoring Template）的批量方式：先在一个目标上调整好全部指标阈值，将其另存为模板，再批量应用到同类的所有目标上。模板还支持导出为文件进行版本管理，示例如下：
# 使用EMCLI导出监控模板，便于版本管理与环境迁移 emcli login -username=sysman -password=xxxx emcli export_template \ -name="OLTP_PROD_TEMPLATE" \ -type=DB_TEMPL \ -output_file=oltp_prod_template.xml # 将模板批量应用到目标列表中的所有实例 emcli apply_monitoring_template \ -name="OLTP_PROD_TEMPLATE" \ -target_type=oracle_database \ -input_file=targets:"/opt/oem/config/prod_db_list.txt"
通过模板统一管理阈值，不仅减少了重复劳动，也保证了同类数据库的监控标准一致，后续调整阈值时只需修改模板再重新应用即可。
四、误报治理与阈值调优思路
很多团队在OEM上线初期都会遇到误报泛滥的问题，常见原因有三类。一是阈值设置过于敏感，直接沿用OEM默认值而未结合实际负载情况，例如Buffer Cache命中率低于95%就告警，对于大量全表扫描的报表库来说几乎天天误报。二是收集频率过高，把瞬时波动放大成了持续问题。三是缺少连续违反次数判断，单次尖峰就触发通知。
治理误报的思路是先做基线分析。利用OEM自带的基线功能，观察指标在至少一到两个业务周期内的正常波动范围，再据此设定阈值。例如通过分析发现某库的正常响应时间在每天上午10点高峰期为800毫秒左右，那么阈值就不应该设为500毫秒，而应设为1200毫秒或者改用自适应阈值。其次要合理利用严重级别区分，Warning级别用于记录和观察，只有Critical级别才触发即时通知，这样即使阈值偏紧也不会频繁打扰值班人员。
另一个实用技巧是利用黑出时段（Blackout）。在计划内的维护窗口、批处理窗口或备份时段，提前为目标设置黑出，OEM将暂停该时段的监控告警，避免维护操作引发的正常告警干扰。黑出可以通过界面配置，也可以用emcli命令行实现：
# 在每周日凌晨2点到6点的备份窗口设置黑出，抑制误报 emcli create_blackout -name="weekly_backup_blackout" \ -add_targets="proddb1:oracle_database" \ -schedule="frequency:weekly;duration:240;start_time:2024-01-07 02:00:00"
最后需要建立定期的报警回顾机制。每月统计各指标的触发次数、真实故障占比，对于误报率高的指标持续调整阈值或收集频率。监控体系不是一次配置就一劳永逸的，它应该随着业务负载的变化不断演进。通过指标分类、模板化管理、分层通知和持续的误报治理，可以搭建出一套既灵敏又可靠的OEM监控报警体系，真正为数据库的稳定运行保驾护航。
Oracle OEM监控指标报警设置修改时间：2026-09-01 02:02:39