Oracle OEM 13c数据库监控平台部署实战：从架构到告警配置

凌晨三点的电话，任何人都不想接。上周我的手机一晚上弹出十几条告警通知，全是同一台数据库主机发出的——/u01分区使用率冲到 97%，业务链路已经明显卡顿，可我手里连这台机器过去一小时内的性能趋势都拿不出来，只能临时登录上去一条条 SQL 手工排查。那次之后我彻底想通了一个问题：靠零散的脚本和记忆去管数据库，迟早会被打脸。把 OEM 13c 完整配置起来，用它统一纳管所有数据库实例，才是眼前最该做的事。

这篇文章我会把整个部署与纳管过程尽量完整地写出来，覆盖环境准备、组件安装、目标添加、监控凭据、告警配置和排错经验，目标读者是那些还在用散装脚本、或者装了 OEM 13c 却只用了很小一部分功能的人。你可以把这当一份实操笔记，按步骤走，基本能把一套能用的监控平台搭起来。

1. 为什么我把核心监控押在 OEM 13c 上

1.1 从一次凌晨的磁盘告警说起

那天夜里真正让我难受的不是磁盘满了，而是我发现自己对这套环境的"健康状况"完全没有历史依据。磁盘是不是三天前就开始缓慢增长？哪个表空间造成的？会话数是不是同时段也在爬升？这些在事发当时全部答不上来，只能靠记忆碎片和临时翻日志。

那段时间我其实也有一套"能用"的监控方案：每台库上部署了自定义 shell 脚本，通过 crontab 定时采集表空间、会话数、关键等待事件，再汇总到一台跳板机上，出问题就发邮件。但那套东西的问题是历史趋势太弱——脚本采集的数据只保留最近几天，一旦想回溯更早的数据，或者对比不同时间窗口的指标变化，基本是无能为力的。

真正把问题推到我面前的是另一个场景：一套核心库的active session数量从前一天下午开始异常攀升，但没有任何监控平台在事发时告诉我"这个变化是从哪个时间点开始的、和哪个 SQL 关联"，我只能在事后去翻 AWR 报告，靠猜。折腾到凌晨四点，问题定位是定位了，但那种"两眼一抹黑"的感觉让人特别窝火。

1.2 OEM 13c 在监控体系里的真实定位

OEM 13c 全称是 Oracle Enterprise Manager Cloud Control 13c，它是 Oracle 官方推出的企业管理平台，重点解决的就是 Oracle 数据库及中间件等资源的统一监控与管理。它的定位不是"又一套 Zabbix"，而是和 Oracle 内核深度绑定的管理中枢：从实例状态、等待事件、SQL 执行计划到 ADDM 分析、AWR 报告、备份恢复，几乎全部可以在同一套界面里完成。

实际使用下来，我觉得美誉 OEM 13c 最大的价值是"原生"。它对 Oracle 指标的理解是基于内部视图和字典表的，比如v$session、v$sysmetric、dba_tablespaces这些。你不需要自己再写一堆 SQL 去采集表空间使用率、会话数、归档频率、等待事件序列，装上之后基本"开箱即用"，而且同一个界面上还能看到主机层级的 CPU、内存、磁盘读写，省掉了以往在多个系统之间来回切来切去的痛苦。

对于有多套 Oracle 环境的人来说，OEM 13c 还能把你平时用的那些零散命令集中化：日常巡检直接看 OEM 的仪表盘，分析性能问题直接在 OEM 里拉 AWR 和 ASH，连执行 SQL 调优都可以在平台上做，统一度和一致性都提升了不少。

1.3 和 Zabbix、Grafana 那套方案对比，差异在哪

我不否认 Zabbix 和 Grafana 在某些场景下很灵活，尤其当你需要对接大量非 Oracle 目标、或者想自定义展示大屏的时候，它们反而更顺手。Zabbix 胜在轻量、开源、社区庞大，但它的短板在于对 Oracle 的指标采集深度不够。你想监控一个数据库的log file sync等待、某个 SQL 的物理读变化、或者查看v$active_session_history的内容，Zabbix 默认根本做不到，需要你自己写采集脚本、自己维护监控项，工作量不小。

Grafana 更偏向可视化展示，数据源还是得靠别的系统提供，本质上它不负责采集和告警溯源。如果你已经有一套完整的数据采集管道，那 Grafana 是很好的展示层；但如果你的目标只是"把 Oracle 数据库管起来"，那从安装到出监控图再到告警，OEM 13c 是一条更短的路。

当然，OEM 13c 也有让我不爽的地方。它比较吃资源，部署一台 OMS 至少准备 16 GB 以上内存；它的安装过程也比 Zabbix 繁琐得多，第一次搞很容易在仓库库、WebLogic 这些环节卡住。但考虑到它在 Oracle 生态里能覆盖的深度，这个代价我认为是值得的。尤其是当你管理的库以 Oracle 为主时，部署一套 OEM 13c，长期算账绝对划算。

2. 装机之前先把这几个概念嚼透：OMS、仓库库与 Agent

2.1 三个核心组件各自的职责

OEM 13c 的整体架构不算复杂，但第一次接触的人往往被一堆名词劝退。说人话就是三样东西：

• OMS（Oracle Management Service）：负责跑 Web 控制台、处理监控数据、调度各类管理任务的 Java 服务。你浏览器里打开的https://主机名:7803/em就是它在提供服务。OMS 本身不存监控数据，它更像一个"中转和处理中枢"。
• 仓库库（Management Repository）：一个专门存放 OEM 所有元数据和监控数据的 Oracle 数据库。所有 Agent 上报的指标、历史趋势、告警记录、配置信息，全都落在这个仓库里。OMS 启动的时候要连仓库库，Agent 上传数据也是由 OMS 写入仓库库。
• Agent（Management Agent）：部署到每一台被监控主机上的轻量客户端。它负责在目标主机上采集操作系统和 Oracle 数据库的指标，然后通过 HTTPS 上传给 OMS。Agent 本身占用的资源不大，但它是整个监控链路的末梢神经，少了它，OMS 就变成了瞎子。

我用个生活化的比喻：仓库库是档案室，所有资料按规矩归档；OMS 是办公室，你查资料、看报表都在这里；Agent 是派到各个分支机构的驻场联络员，它定期把各地情况写成汇报材料交回办公室。三个角色缺一不可，理解了它们，后续很多配置就不会觉得晕。

2.2 主机、操作系统、端口和仓库库的硬性准备

OEM 13c 的安装门槛主要卡在内存和操作系统兼容性上，下面这几点我在部署前反复确认过：

主机配置

• CPU 建议至少 4 核，越多越好，尤其当被监控目标数量超过几十个时，OMS 的 JVM 很快会成为瓶颈。
• 内存建议不少于 16 GB。我的生产部署给了 32 GB，实际用下来 OMS 自带的那几个 Java 进程加上仓库库实例，空闲时占用就在 12 GB 以上。如果你在低配机器上硬装，后面 OMS 启动和页面响应会非常痛苦。
• 磁盘建议单独划分/u01给 OMS 软件，空间至少给 100 GB。仓库库的表空间增长很快，尤其当你开启 AWR、会话历史等长期保留功能之后，数据量会以每天几 GB 的速度长大，提前规划好磁盘空间很有必要。

操作系统要求

官方支持列表里，Oracle Linux 7/8、RedHat 7/8 是主流选择。操作系统还需要准备常用的依赖包，比如libaio、glibc-devel、ksh、unixODBC等。我遇到过因为缺少libaio导致安装程序直接退出安装向导的情况，所以建议提前用 yum 把基础依赖一次性装好：

yum install -y libaio libaio-devel glibc glibc-devel ksh unixODBC unixODBC-devel sysstat compat-libstdc++

主机名和 /etc/hosts

这是很多人忽略的坑。OMS 主机名、Agent 主机名都必须能在/etc/hosts里正确解析到静态 IP。如果主机名解析有问题，后续 Agent 注册、证书生成、反向连接都会出现奇奇怪怪的问题。我的建议是安装前就把/etc/hosts写好，并且不要用 DHCP 分配的主机名：

192.168.10.20 oem01.example.com oem01 192.168.10.31 db01.example.com db01

端口规划

OEM 安装过程中会让你填一堆端口，常用的包括：

服务	默认端口	说明
Web 控制台 HTTPS	7803	浏览器访问入口
OMS 上传端口 HTTPS	4900	Agent 上报数据的通道
WebLogic 管理端口	7102	管理员后台
NodeManager 端口	7401	WebLogic 节点管理
Agent 上传端口 HTTPS	3872	Agent 主动连接 OMS 的默认端口

这些端口在防火墙里需要放行，否则 Agent 装上之后数据传不上来，页面里目标会一直显示"无数据"或"Pending"状态。我第一次部署时就因为忘了放开 4900 端口，折腾了大半天。

仓库库的版本

仓库库数据库本身的版本建议至少为 12.1.0.2，我这边用的是 19c。仓库库必须是独立的 Oracle 实例，不能和业务库共用，否则高负载下监控平台会把业务库性能拖垮。安装 OMS 时可以选择"新建仓库库数据库"或"使用已有数据库"，如果你已经有一套闲置的 Oracle 环境，可以走"使用已有"这条路，能省掉不少时间。

2.3 仓库库数据库的关键参数设置

仓库库虽然可以复用已有的 Oracle 实例，但建议单独创建一套实例，并且把初始化参数调整到适合 OEM 的水平。下面是我在新实例上用的参数，供参考：

alter system set sga_target=8G scope=spfile; alter system set pga_aggregate_target=2G scope=spfile; alter system set processes=1500 scope=spfile; alter system set sessions=1600 scope=spfile; alter system set job_queue_processes=20 scope=spfile; alter system set open_cursors=1000 scope=spfile;

这些参数之所以重要，是因为 OEM 的仓库库会频繁进行大批量插入和统计信息刷新。processes如果设得太小，安装过程中很可能出现ORA-12520: TNS:listener could not find available handler之类的连接错误。sga_target设置大一些，能明显减少 OMS 在生成报表、查询仓库时的物理读。

另外，仓库库的字符集尽量用AL32UTF8。不同字符集可能导致安装阶段直接报错，或者界面中文乱码。如果已经有其他字符集的实例，我的建议是别强行复用，新建一个实例更省心。

3. 完整安装实测：从启动安装程序到 Agent 上线

3.1 安装文件准备与 runInstaller 启动

OEM 13c 的安装包分几个 zip 文件，以 13.5 Release 为例，典型的有：

• em13500_linux64.bin：安装引导程序
• em13500_linux64-2.zip
• em13500_linux64-3.zip

首先要用一个非 root 用户（比如oracle）来运行安装程序，如果直接用 root 启动，安装脚本会拒绝执行。把 bin 文件和 zip 包放到同一目录下，给 bin 文件加执行权限后启动：

chmod +x em13500_linux64.bin ./em13500_linux64.bin

安装程序启动后是图形向导模式，如果你的本地没有图形环境，需要借助 VNC 或者 X11 转发。当初我在无界面服务器上安装，就是通过 VNC 连上去完成的。如果实在不想用图形界面，也可以尝试用静默安装，但静默安装的响应文件编写比较繁琐，我建议第一次部署还是走图形向导，至少能看到每一步的校验结果。

3.2 图形化安装中值得注意的每一项配置

安装向导每走一步，我都会停下来确认一遍，因为很多选项一旦装完再改就很麻烦。

首先是选择安装类型。我需要部署的是一套全新的 OMS，所以我选的是"Enterprise Manager Cloud Control Advanced Installation"，这是完整安装模式。接下来安装程序会让你选择"创建一个新企业管理系统"还是"添加一个现有的企业管理系统"，因为我环境里还没有任何 OMS，所以选择前者。

然后是配置 OMS 实例信息。这里要设置 Weblogic 管理账号（weblogic）密码、OMS 实例名、以及默认使用的 WebLogic 域目录。密码要求比较严格，需要同时包含大小写字母和数字，太简单会直接卡在密码强度校验。

接下来就是端口配置界面。默认的 7803、4900、7102 等端口如果你的环境里没有冲突，直接用默认值最省心。我记得当时还因为某个端口被占用了，安装程序报了个红色警告，排查一会儿才发现是本机原来部署的其他服务占用了，改掉就通过了。

再往下是关键的中级一步——仓库库配置。如果你选择的是使用已有数据库，这里需要填仓库库的连接信息，包括主机名、端口、SID/服务名、SYS 用户密码。安装程序会在这个阶段向仓库库中创建所有 OEM 需要的表空间和对象，耗时较长，期间仓库库的 CPU 和 IO 会被拉高，属正常现象，不用紧张。

最后一步配置 Agent 注册密码。这个密码要记住，后续新装 Agent 后注册到 OMS 时会用到。安装向导会列出所有配置项，建议截图或存一份，提交后安装程序就正式开跑，这个过程通常需要一个小时以上，取决于机器性能。

安装完成后，第一个要做的事就是检查 OMS 本身的状态：

$OMS_HOME/bin/emctl status oms

看到类似Enterprise Manager running的输出，说明 OMS 已经起来了。再用浏览器打开https://oem01.example.com:7803/em，能看到登录页面就算正常。

3.3 Agent 的两种部署方式和验证方法

OMS 装好之后，真正的监控工作要从 Agent 落地开始。Agent 的部署方式有两种，我分别试过：

第一种是在 OEM 控制台里用"添加目标"功能推送安装。先在"设置"->"添加目标"->"手动添加目标"里选择添加一台主机，输入主机连接信息（主机名、SSH 端口、OS 用户名密码），OEM 会通过 SSH 把 Agent 软件传到目标主机并执行静默安装。这种方式优点是省事，缺点是需要提前在主机上配好 SSH 用户和权限，而且网络状况不好时传输容易失败。

第二种是把 Agent 安装介质下载到目标主机，手工安装。在控制台的"添加目标"界面里，OEM 会提供一个agentDeploy.sh脚本和 agent 安装包的下载链接。在目标主机上执行：

./agentDeploy.sh OMS_HOST=oem01.example.com AGENT_PORT=3872

脚本会完成后续的系统检查和安装。这种方式适合内网环境复杂、OMS 无法直接 SSH 到目标主机的情况，出问题时也更容易定位。

Agent 装完后，需要验证状态：

$AGENT_HOME/bin/emctl status agent

正常状态会显示Agent is Running and is currently uploading。如果显示Pending，说明 Agent 和 OMS 之间的证书或注册信息还没同步好，需要去控制台里接受待定 Agent。这一步我做的时候也卡了很久，后来才发现是因为 Agent 注册密码填错了，重新提交注册就正常了。

4. 把生产数据库正式纳入监控：目标发现与凭据配置

4.1 手动添加目标的完整流程

Agent 装好、主机能被监控了，下一步就是把数据库实例加进来。在 OEM 控制台里，进入"目标"->"目标管理器"，选择"添加"->"手动添加目标"，会有几种路径，我习惯用"使用发现向导"的方式。

发现向导先让你选择 Agent 和发现目标的主机范围。选择已经装好的那台 Agent，然后向导会连到主机上扫描出这个主机上所有的 Oracle 环境和监听器。扫描出来的数据库实例会被列在结果中，我勾选需要监控的实例后，点击"监控"进入下一步。

接下来要为这个数据库配置监控方式。OEM 支持多种监控方式：通过管理代理、通过 JDBC 直连等，我用的是默认的"通过管理代理"。这一步需要提供数据库的监控凭据，OEM 会利用这个凭据连接到数据库，创建一组监控视图用户所需的对象并开始采集数据。

提交之后，目标库会被添加到 OEM 的资源列表中，初始状态可能会显示"发现中"或"等待首次上载"，等几分钟后刷新页面，状态会变成"运行中"，“运行正常”等。如果一直都处于"目标无数据"状态，大概率是凭据没配上或者 Agent 和数据库实例之间的网络不通，可以顺着这个思路排查。

4.2 监控用户应该怎么建、给什么权限

OEM 通过连接数据库来采集指标，所以必须提供一个有足够权限的数据库用户。很多人图省事直接用SYS，我在测试阶段也是这么干的，但在生产环境这么做我会建议慎重，因为 OEM 的指标采集都是高频度读取，如果某个 SQL 写得不够高效，用SYS身份去跑可能会在数据库里留下比较大的审计和安全风险。

更稳妥的做法是创建一个专用的监控用户，只授最小必要权限。我用的脚本大致如下：

CREATE USER oem_monitor IDENTIFIED BY "你的强密码" DEFAULT TABLESPACE system QUOTA UNLIMITED ON system; GRANT CONNECT TO oem_monitor; GRANT SELECT_CATALOG_ROLE TO oem_monitor; GRANT SELECT ANY DICTIONARY TO oem_monitor;

SELECT_CATALOG_ROLE是 Oracle 专门给监控类用户使用的角色，能读取数据字典视图但不具备修改能力，基本能满足 OEM 的大部分监控需求。如果后续要做备份恢复类操作，可能还要额外授予SYSDBA，但那是另一套场景。最重要的原则是：能不用最高权限就不用，监控用户的权限能持续收敛就收敛。

4.3 首选身份配置，这是后续一切自动化操作的前提

目标发现和监控凭据搞定之后，还有一个经常被忽略的步骤：配置首选身份（Preferred Credentials）。这一步的意义在于，后续你要在 OEM 界面上执行"运行 SQL"、刷新主机配置、运行作业等操作时，OEM 会默认使用你配置好的首选身份去连接目标，而不是每次都让你重新输入密码。

在"设置"->"安全性"->"首选身份"里，可以分别设置主机首选身份和数据库首选身份。主机首选身份用来在目标主机上执行 OS 级别操作，数据库首选身份用来连接数据库实例执行管理任务。把之前创建的oem_monitor用户作为数据库首选身份，把安装 Agent 时使用的 OS 用户（比如oracle）作为主机首选身份，并保存测试通过即可。

这一步配置好之后，日常运维会顺畅很多。比如我想看一下某个库当前的等待事件分布，直接在 OEM 里打开 SQL 工作表，它会以首选身份自动连接，不用我再手工找密码，省去很多麻烦。

5. 让告警从"轰炸"变成"有效"：指标模板与通知配置

5.1 默认阈值里最需要调的几个地方

OEM 装好、目标添加完成之后，它自带了一套默认的指标模板，开箱就能告警。但这套默认模板放在真实生产环境里，很多时候是"只报平安不报问题"，或者在真正出问题的瞬间才报警，等看到告警已经晚了。我的建议是花点时间把默认模板里的关键指标过一遍，按自己的环境重新设置阈值。

我实际调整最多的几个指标是：

• 表空间使用率：默认的warning和critical阈值分别在 85% 和 97% 左右，但对一些大表空间来说，85% 的容量可能还有几十 GB 的余量，忽略即可；而对小表空间，85% 可能只剩几百 MB，随时会被撑满。所以我会针对不同表空间单独设置阈值，重要的核心表空间在 80% 时就给 warning。
• 告警日志中的 ORA- 错误：默认指标会统计告警日志中出现的错误数量，但平时常见的ORA-28000账号锁定、ORA-12541网络问题等等，如果全按默认告警，一天能收到一堆无关通知。我一般会把已知的、非关键的错误代码加入忽略列表，只保留和实例健康强相关的内容。
• 活动会话数：这是最能反映数据库压力的指标之一。默认阈值有时是"不告警"或"阈值过高"，我会按业务基线把它调到一个合理的范围，比如平常空闲时active session是 5，高峰期是 20，那我就会把 warning 设在 30、critical 设在 50，这样既不会产生太多噪音，也能在高负载来临时及时发现。

修改指标的路径是：目标主页 -> "性能"或"监控"相关菜单 -> 选择目标指标，点击"阈值"标签页，在具体指标行上修改即可。不同的指标单位不同，有的百分比、有的是计数，修改时留意一下单位，别设错了。

5.2 分级设置阈值，避免告警疲劳

告警疲劳是监控系统上线后最容易出现的问题之一。如果告警太多，运维人员会本能地忽略所有的告警，反而让真正严重的告警被淹没在噪音里。我在实际运营中定了三条原则：

• 按业务等级分级：核心生产库的阈值要比开发测试库严格得多。同一个表空间使用率，核心库 80% 就 warning，测试库 90% 都不报警。
• 使用告警抑制和延迟：OEM 支持对某些指标设置告警抑制条件，比如"仅在连续 3 次采集都超过阈值时才触发告警"，这样可以过滤掉那些因为瞬时波动导致的误报。
• 针对重复告警设置频率限制：比如某个指标持续超标 10 分钟，我只希望在开始的那一时刻收到一封邮件，而不是每隔五分钟收到一封。OEM 的通知规则里可以配置聚合和抑制间隔，把这个时间窗口调整好，能大幅减少告警噪音。

5.3 邮件通知配置与验证

告警必须能送出来才有价值，否则全淹在平台上没人看。OEM 的邮件通知配置在"设置"->"通知方式"->"邮件服务器"里，填入你公司 SMTP 服务器的地址、端口、是否启用 SSL、发件人邮箱及认证信息，然后保存。

接下来要配置"通知规则"。在"设置"->"通知方式"->"通知规则"里，可以定义一个规则，比如"当任意目标出现 Critical 告警时发送邮件给 [e-mail]"。规则里可以限定目标类型、严重级别、通知方式（邮件/脚本/SNMP 等）。

配置完成之后，一定要做一次主动测试。最省事的方法是把某个监控指标的阈值临时调低，制造一个真实告警，观察有没有收到邮件。收到之后再调回正常值。如果一直收不到，要按这几个常见原因依次排查：SMTP 服务器端口通不通、发件人认证是否正确、收件人地址是否被公司邮件网关拦截、通知规则是否关联了正确的目标组。

6. 上线后的第一轮验证：监控数据采集是否正常

6.1 判断采集链路是否真的通了

添加完目标、配置完告警，不是说这就算结束了。一定要做一轮完整的验证，确保我们看到的数据是"活的"。我最常用的验证方式是在目标数据库的主页上查看"性能"标签页，等 5 到 10 分钟后，如果能出现实时的 CPU、内存、活动会话数曲线，说明 Agent 采集、上传、入库、展示这条链路都是通的。

如果性能页面空白或者一直转圈，可以按下面这套思路排查：

1. 先确认 Agent 状态正常：emctl status agent。
2. 再确认 Agent 能上传数据：emctl upload命令可以手动触发一次上传，看有没有报错。
3. 在 OMS 主机上看有没有收到 Agent 的上传请求，检查 OMS 的上传日志。
4. 在控制台里看目标的"监控状态"，如果是"数据收集停止"或"无数据"，通常是监控凭据失效或目标库的某些参数被改动了。

我遇到过最常见的原因就是监控用户密码改了，而 OEM 里存的首选身份没有同步更新，导致 Agent 连接数据库失败，采集链路中断。这种问题在更换 DBA 密码后尤其容易发生，所以做密码变更时一定要顺手更新 OEM 里的凭据。

6.2 巡检页面的常用入口

数据链路验证通过后，OEM 就成了一天工作里的"仪表盘指挥所"。日常巡检我主要看下面几个页面：

数据库主页的"性能"页：一眼能看到 CPU、IO、等待事件、活动会话数的趋势曲线。出现突发高峰时，可以直接在图上拖选时间段，下钻到 ASH 分析，找出这段时间里到底在跑什么 SQL。这个过程我从以前手工翻 AWR 需要一小时，缩短到十分钟以内，提升非常明显。

"存储"页面：列出所有表空间、数据文件、控制文件、日志组的状态。表空间使用率的环比趋势也能在图上看到，能提前发现"这个表空间每周增长 10%，预计 6 周后会写满"之类的潜在风险，比等满了再去扩要从容得多。

"指标"页面：可以查看某台库的所有采集指标，包括当前值、历史值和阈值，做自定义分析时很方便。

"信息面板"：OEM 13c 还提供了一些针对数据库的整体健康快照页面，比如Database Backups、Compliance Summary等。我每周会扫一眼合规页面，确认没有突然冒出的安全配置告警，省去大量人工核查时间。

6.3 AWR、ADDM 这类功能在 OEM 里怎么用

很多 DBA 习惯在命令行里执行awrrpt.sql生成 AWR 报告，然后下载、查看、另存 PDF，步骤不少。OEM 13c 把 AWR 和 ADDM 整合进了页面里，在数据库主页的"性能"下拉菜单里选择"AWR"或"ADDM"，直接选择时间范围，就能自动生成报告、直接在浏览器里查看。

这个功能在实际生产环境中非常实用。比如某天业务反馈下午三点系统卡顿，我可以直接在 OEM 里选02:00 PM 到 03:00 PM这个时间段，生成 AWR，然后在"等待事件"部分一眼看到DB CPU还是log file sync占了大头，再顺着下钻到具体的 SQL 语句，整个问题定位链条在同一个界面里完成。

ADDM 功能还会自动给出优化建议，比如"发现某条 SQL 做了大量全表扫描，建议创建索引"之类的。它的建议不一定每条都直接采纳，但作为一个分析起点，能帮你快速圈定问题范围，剩下的精细优化再结合 SQL 执行计划去处理，效率比完全从零开始高很多。

7. 摸爬滚打总结的踩坑清单

7.1 OMS 起不来、仓库库装不上这类部署大坑

部署期最典型的一个坑就是 OMS 启动失败。现象是执行emctl start oms后进程起了一下又立刻退出，翻日志能看到 OMS 连接仓库库失败，或者是 OMS 依赖的某个监听端口初始化失败。排查思路一条条来：

1. 先确认仓库库本身是正常打开的，能用sqlplus从 OMS 主机连过去。连不上就先解决网络、监听或者防火墙问题。
2. 再确认 OMS 配置文件里的仓库库连接信息是否正确。配置文件在$OMS_HOME/sysman/config/emd.properties里，重点看oracle.sysman.eml.maxRet、oracle.sysman.db.instancename等参数。我遇到过一次因为 SID 填错导致 OMS 一直连不上仓库库的情况。
3. 检查内存。OMS 的 JVM 默认堆大小如果不能分配，进程会直接退出。在gc.properties里可以调整内存设置，把 JVM 堆放大一点，问题一般就解决了。

还有一次安装卡在"仓库库创建"这一步很久，后来发现是仓库库数据库的sga_target设定太小，导致 OMS 在创建大量 OEM 表对象时发生内存不足。把sga_target调大、重启仓库库后重新跑安装，才顺利通过。安装很简单，但安装执行过程复杂，日志路径多在$OMS_HOME/cfgtoollogs/下，遇到中途失败优先翻日志，别盲目重来。

7.2 Agent 脱管、上传失败与证书问题

Agent 相关的问题恐怕是所有 OEM 运维者都会遇到的，我自己踩过最多的就是"Agent 突然显示脱管"或者上传失败。常见的几个原因和应对方法如下表：

现象	可能原因	处理方式
Agent 显示Pending，无法注册	Agent 注册密码填错或 Agent 证书未同步	在 OMS 控制台里删除目标 Agent，重新提交注册
Agent 状态Running但上传失败	4900 端口不通，或 OMS 的接受证书过期	检查防火墙，emctl secure add重新注册证书
Agent 日志报410或404HTTP 错误	Agent 版本和 OMS 版本不匹配	升级 Agent 到与 OMS 匹配的版本
目标库长期无数据	监控用户密码被修改，或目标库监听不可达	更新数据库首选身份，重启 Agent 后验证

证书过期是很多人忽略的一个隐性坑。OEM 的 Agent 和 OMS 之间通过证书进行双向认证，证书不是永久的，会定期轮换。一旦证书过期或轮换失败，Agent 即使进程还活着，也无法正常上传数据。这时候最好的办法是登录到目标主机，重新执行一次 Agent 的证书注册操作：

$AGENT_HOME/bin/emctl secure add

并按提示输入 OMS 主机名和管理员账号，让它重新建立信任关系。这个问题遇到一次之后，我养成了一个习惯：每半年检查一次 Agent 的证书有效期，避免在夜深人静的时候突然断链。

7.3 数据采集异常的排查思路

最后再讲一类常见但隐蔽的问题——目标数据库显示在监控中，但某个指标的数据总是缺失。我遇到过的情况是：其他所有指标都正常，唯独表空间使用率某一天开始不再更新了。查了很久才发现是目标库的DBA_TABLESPACE_USAGE_METRICS视图在某些版本下查询效率特别低，Agent 在采集这个指标时超时了，OEM 自动跳过了该指标。

这种问题排查起来会比较耗时，我的建议是先到目标主机上看 Agent 日志：

$AGENT_HOME/sysman/log/emagent.log

搜索对应指标采集相关的错误信息。如果日志显示 timeout，可以考虑调整 Agent 采集的超时时间，或者优化目标库对应视图的统计信息。如果日志里啥都没写，那可能是 OMS 侧没有接收到这部分数据，需要去 OMS 的上传日志里继续找，总归有迹可循。

还有一次问题出在监控用户的权限上。我之前给监控用户升过级、优化过权限，但授权情况在不同版本数据库上不一致，导致某些新版本的 OEM 需要的视图权限没被授予，某几个新指标就无法采集。我把SELECT_CATALOG_ROLE重新授予了一遍并刷新了权限，指标马上就恢复采集了。所以如果你给监控用户做过权限调整，记得回头确认这些基础权限没被动过。

把 OEM 13c 配置成数据库监控管理的核心平台，大概就是上面这套流程。它并不会让所有数据库问题一夜之间消失，但能让你在最需要的时候知道该往哪儿看、问题从什么时候开始，这比什么都重要。如果你也刚部署完这套东西，或者正准备开始，建议先把这篇文章里的关键点过一遍，至少能少踩几处我踩过的坑。