凌晨三点的电话任何人都不想接。上周我的手机一晚上弹出十几条告警通知全是同一台数据库主机发出的——/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、仓库库与 Agent2.1 三个核心组件各自的职责OEM 13c 的整体架构不算复杂但第一次接触的人往往被一堆名词劝退。说人话就是三样东西OMSOracle Management Service负责跑 Web 控制台、处理监控数据、调度各类管理任务的 Java 服务。你浏览器里打开的https://主机名:7803/em就是它在提供服务。OMS 本身不存监控数据它更像一个中转和处理中枢。仓库库Management Repository一个专门存放 OEM 所有元数据和监控数据的 Oracle 数据库。所有 Agent 上报的指标、历史趋势、告警记录、配置信息全都落在这个仓库里。OMS 启动的时候要连仓库库Agent 上传数据也是由 OMS 写入仓库库。AgentManagement 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 控制台 HTTPS7803浏览器访问入口OMS 上传端口 HTTPS4900Agent 上报数据的通道WebLogic 管理端口7102管理员后台NodeManager 端口7401WebLogic 节点管理Agent 上传端口 HTTPS3872Agent 主动连接 OMS 的默认端口这些端口在防火墙里需要放行否则 Agent 装上之后数据传不上来页面里目标会一直显示无数据或Pending状态。我第一次部署时就因为忘了放开 4900 端口折腾了大半天。仓库库的版本仓库库数据库本身的版本建议至少为 12.1.0.2我这边用的是 19c。仓库库必须是独立的 Oracle 实例不能和业务库共用否则高负载下监控平台会把业务库性能拖垮。安装 OMS 时可以选择新建仓库库数据库或使用已有数据库如果你已经有一套闲置的 Oracle 环境可以走使用已有这条路能省掉不少时间。2.3 仓库库数据库的关键参数设置仓库库虽然可以复用已有的 Oracle 实例但建议单独创建一套实例并且把初始化参数调整到适合 OEM 的水平。下面是我在新实例上用的参数供参考alter system set sga_target8G scopespfile; alter system set pga_aggregate_target2G scopespfile; alter system set processes1500 scopespfile; alter system set sessions1600 scopespfile; alter system set job_queue_processes20 scopespfile; alter system set open_cursors1000 scopespfile;这些参数之所以重要是因为 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.zipem13500_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_HOSToem01.example.com AGENT_PORT3872脚本会完成后续的系统检查和安装。这种方式适合内网环境复杂、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 告警时发送邮件给 dba-opsexample.com。规则里可以限定目标类型、严重级别、通知方式邮件/脚本/SNMP 等。配置完成之后一定要做一次主动测试。最省事的方法是把某个监控指标的阈值临时调低制造一个真实告警观察有没有收到邮件。收到之后再调回正常值。如果一直收不到要按这几个常见原因依次排查SMTP 服务器端口通不通、发件人认证是否正确、收件人地址是否被公司邮件网关拦截、通知规则是否关联了正确的目标组。6. 上线后的第一轮验证监控数据采集是否正常6.1 判断采集链路是否真的通了添加完目标、配置完告警不是说这就算结束了。一定要做一轮完整的验证确保我们看到的数据是活的。我最常用的验证方式是在目标数据库的主页上查看性能标签页等 5 到 10 分钟后如果能出现实时的 CPU、内存、活动会话数曲线说明 Agent 采集、上传、入库、展示这条链路都是通的。如果性能页面空白或者一直转圈可以按下面这套思路排查先确认 Agent 状态正常emctl status agent。再确认 Agent 能上传数据emctl upload命令可以手动触发一次上传看有没有报错。在 OMS 主机上看有没有收到 Agent 的上传请求检查 OMS 的上传日志。在控制台里看目标的监控状态如果是数据收集停止或无数据通常是监控凭据失效或目标库的某些参数被改动了。我遇到过最常见的原因就是监控用户密码改了而 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 依赖的某个监听端口初始化失败。排查思路一条条来先确认仓库库本身是正常打开的能用sqlplus从 OMS 主机连过去。连不上就先解决网络、监听或者防火墙问题。再确认 OMS 配置文件里的仓库库连接信息是否正确。配置文件在$OMS_HOME/sysman/config/emd.properties里重点看oracle.sysman.eml.maxRet、oracle.sysman.db.instancename等参数。我遇到过一次因为 SID 填错导致 OMS 一直连不上仓库库的情况。检查内存。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 配置成数据库监控管理的核心平台大概就是上面这套流程。它并不会让所有数据库问题一夜之间消失但能让你在最需要的时候知道该往哪儿看、问题从什么时候开始这比什么都重要。如果你也刚部署完这套东西或者正准备开始建议先把这篇文章里的关键点过一遍至少能少踩几处我踩过的坑。