上个月帮客户搭了一套Oracle Enterprise Manager 13c后面简称OEM用来把散落在六台服务器上的十几个Oracle数据库实例全部纳入统一监控。这套东西核心就是一件事配置一套企业级管理平台让DBA能用浏览器在一个界面里看到所有库的性能、空间、告警和备份状态。真折腾下来发现安装并不难难的是把Agent部署、目标发现和告警规则串顺。这篇文章就把我自己整理的配置流程和踩坑记录放出来给需要搭OEM监控数据库的朋友做个参考。我要先说清楚一个前提这里说的OEM是Oracle Enterprise Manager不是联想、惠普上那种Windows OEM系统别搞混。OEM是Oracle官方的企业级管理工具专门用来管理数据库、中间件、服务器等资源。13c是目前使用比较广泛的版本功能比12c完善也比14c到国内用户手里时更成熟所以如果你是做Oracle DBA大概率绕不开它。1. 项目概述与整体思路1.1 Oracle Enterprise Manager 13c到底能干什么简单说OEM 13c解决的是“我有一堆Oracle数据库怎么统一看、统一管”的问题。没有它之前我们经常是每台服务器手动登录数据库敲SQL查表空间、查告警日志、查会话数再一个个处理。库少还行库一多就很痛苦。OEM可以做的事包括自动发现主机上的Oracle实例、监听器、ASM实例集中展示状态采集性能指标包括等待事件、DB Time、活动会话、I/O、CPU、内存等监控空间使用情况如表空间增长趋势、数据文件大小、归档区使用率通过阈值和告警规则自动触发邮件或脚本通知和RMAN集成可以在页面上配置备份、查看备份历史、发起恢复提供AWR、ADDM、Performance Hub等工具方便做性能分析和SQL调优生成各类报表支撑月度巡检和容量规划。适合它的场景很明确企业内部Oracle库数量比较多希望有一套官方工具统一管理而不是在不同服务器之间来回切。第三方监控工具如Zabbix、Prometheus也可以做指标采集但是它们对Oracle内部状态的理解深度不如OEM尤其在等待事件分析、RMAN集成、ADDM建议这些方面官方工具有天然优势。1.2 采用OMS加Agent加仓库库架构的逻辑OEM 13c的核心架构是三件套OMS、Agent、Management Repository。OMSOracle Management Service是平台的应用层负责Web控制台、任务调度、告警聚合、页面查询等Agent是部署在每台被管理主机上的采集代理周期性地采集主机和数据库信息再上传给OMSManagement Repository是OEM的“档案室”也就是一个独立的Oracle数据库实例存储所有配置信息、监控历史、性能数据和报表结果。用一个容易理解的说法OMS是指挥中心Agent是派驻到各机房的巡检员仓库库是值班记录本。指挥中心把巡检员的记录收上来、整理好最终通过浏览器页面呈现给DBA。为什么Oracle要设计成这种分布式采集、集中管理的模式如果每台数据库服务器都单独开一套Web管理接口DBA要记一大堆地址安全策略也难做。Agent采集模式的好处是监控数据先在本地汇总再批量上传即使OMS临时不可用Agent也会缓存数据网络恢复后继续补传不会因为管理平台重启就丢掉监控历史。具体到本项目只要求监控数据库不需要上多OMS集群也不需要部署WebLogic插件或其他中间件插件。一台OMS主机加若干台被管主机上的Agent就可以覆盖需求。这也是大部分中型企业比较合理的落地方式先把数据库管起来后续有需要再扩展其他目标的监控。2. 配置前的环境准备与安装规划2.1 软硬件参数与系统要求OEM 13c是一个重量级应用对硬件的要求不能按普通Web应用来考虑。第一次搭的人最容易犯的错就是把机器规格规划得太小结果安装到一半报内存不足或者后面跑了一段时间仓库库空间暴涨。先说硬件。内存生产环境建议OMS主机至少16GB如果仓库库也放在同一台机器上建议32GB。我后来给客户用的是32GB内存、8核CPU的虚拟机跑起来算比较稳。你要是拿4GB内存的机器试安装向导根本走不完。磁盘OMS软件、Agent安装包、仓库库数据文件加在一起100GB起步。仓库库运行三个月以后AWR和各类历史表的数据量会明显增长所以建议把数据文件放到可以扩展的存储上至少预留200GB比较稳妥。操作系统Linux x86_64是主流选择RHEL 7/8、Oracle Linux 7/8我都用过。Windows也可以部署但路径上容易遇到权限和中文编码问题没必要自找麻烦。再说软件。JDK安装OEM 13c时会内置合适的JDK不需要提前装但系统里已有的JDK版本要注意避免PATH干扰安装程序。管理仓库库必须使用Oracle数据库作为仓库库。13c不同小版本对仓库库版本的要求不同13.2可以用12c或者18c13.3和13.5可以支持19c。我这次用的是Oracle 19c作为仓库库OEM版本用的13.5兼容性没问题。内核参数方面可以参考Oracle数据库的经典要求主要调整共享内存和信号量。在/etc/sysctl.conf里加入如下配置kernel.shmall 2097152 kernel.shmmax 2147483648 kernel.shmmni 4096 kernel.sem 250 32000 100 128 fs.file-max 6815744 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576 vm.nr_hugepages 0改完执行sysctl -p让它生效。群集或单机环境里这些参数基本通用。注意shmmax不能设置得比物理内存还大否则内核会报警告。2.2 安装介质、账号与端口规划安装介质建议从Oracle Software Delivery Cloud下载搜索Enterprise Manager 13c按平台选择Linux x86_64的OMS安装包。整个安装包有好几个GB下载前先确认网络和磁盘。账号规划是很多人容易忽略的一步。至少需要提前准备好以下几类账号操作系统账号建议统一用oracle用户主组为oinstall辅助组为dba仓库库账号管理仓库的数据库实例需要一个SYS或者有DBA权限的账号OEM安装向导会用它来创建仓库schema默认账号是SYSMANWeb控制台超级管理员也就是安装完成后登录https://oms_host:port/em的账号默认是sysman密码在安装时设置Agent注册口令用于Agent向OMS注册口令要记好后面手工部署Agent时要用。端口规划尽量简洁。OEM 13c安装时默认会给一组端口常用的是这几个用途默认端口Enterprise Manager控制台HTTPS7803Agent上传端口4903OMS管理端口7799Agent注册端口3802生产环境要确保OMS主机防火墙对Agent上传端口4903放行否则Agent连不上做了后面就是“代理不可达”的闹心事。控制台端口7803只对DBA办公网段开放不要整个公网都能访问。主机名解析也建议提前处理好。最省事的办法是直接在OMS主机和各被管主机的/etc/hosts里写上互相的IP和主机名避免DNS解析出问题。Agent连接OMS时如果主机名对不上会出现证书校验失败或者注册不上。3. OEM 13c核心配置流程实操3.1 安装OMS与初始化管理仓库安装OEM 13c核心是让安装向导完成两件事装好OMS应用并在仓库库里初始化出OEM运行所需的大量schema对象和基础数据。我从自己的实验和交付经验来看推荐提前准备一个独立的Oracle数据库实例作为管理仓库安装时选择“使用现有数据库”方式。这个数据库的版本要在兼容范围内字符集必须设置为AL32UTF8这是OEM的硬性要求不是建议项。如果仓库库字符集不对安装向导会在检查阶段直接抛出错误后面根本走不动。另外给仓库库初始化空间时别太小。SYSTEM、SYSAUX、UNDO、TEMP这些表空间至少各给10GB初始空间因为OEM初始化时要写入大量元数据后面运行起来还会有很多历史数据进来。安装步骤大概是这样的把OMS安装包解压到OMS主机的目录比如/u01/app/oms_software。进入解压目录执行./runInstaller启动OUI图形安装向导。选择“安装新的Enterprise Manager系统”部署类型选“简单安装”或者“高级安装”。第一次练手建议用高级安装后面可控性更强。在仓库库配置页选择“使用现有数据库”填写仓库库所在主机的host、端口、SID或Service Name以及SYS账号口令。设置Web控制台的口令也就是sysman管理员的登录密码。设置Agent注册口令。确认端口配置控制台HTTPS端口默认是7803Agent上传端口默认是4903如果被占用就换一个并记录好。运行安装前检查有警告项最好处理完再继续红色报错项必须解决。向导会在最后提示以root用户运行两个脚本一般是在/u01/app/oraInventory下的orainstRoot.sh和OMS安装目录下的root.sh。这一步很关键忘记执行或者执行失败会导致后续服务起不来。安装完成后启动OEM服务。可以用emctl start oms命令来控制OMS。安装完成后访问https://oms_host:7803/em用sysman登录。如果页面能正常打开说明OMS和管理仓库已经通了。需要注意安装过程非常耗时20到40分钟很正常。不要因为进度条不动就重启机器先看日志。日志位置一般在OMS_HOME/cfgtoollogs/下面按时间目录排列。3.2 使用Agent发现并添加数据库目标OMS装好了只是第一步真正监控数据库要把Agent部署到每个数据库所在的主机上。Agent的部署方式有三种在控制台远程推送、手动下载安装介质部署、通过脚本批量部署。对于只有几台机器的情况直接在控制台推送最方便。流程是先到“目标”菜单下选择“添加目标”再选择“添加主机”。填写目标主机的主机名、操作系统平台以及SSH连接凭据。OEM会通过SSH把Agent安装包推送到目标主机自动解压、安装并完成和OMS的注册。这步对SSH的要求比较直接OMS主机必须能免密登录到目标主机或者至少能正确识别目标主机的SSH密钥。如果没有免密配置先把OMS主机上oracle用户的公钥追加到目标主机oracle用户的~/.ssh/authorized_keys里并确保权限是600。经常有人忽略权限导致SSH登录失败报错还很误导人提示权限太大之类的。手动部署的方式也可以。在控制台“部署Agent”页面下载Agent安装介质scp到目标主机解压后执行agentDeploy.sh脚本按提示输入OMS地址、Agent注册口令等等安装完成再用emctl status agent确认状态为online。Agent部署成功之后它会自动扫描目标主机上的Oracle数据库实例、监听器、ASM实例并把发现结果上传到OMS。这时候回到控制台“目标”菜单下就能看到待处理的目标。这里是新手最容易迷茫的地方Agent明明在线为什么看不到数据库原因往往是没有给数据库配置监控凭据。我们需要在数据库目标上设置DBSNMP账号的密码OEM靠这个账号去采集数据库内部数据。Oracle数据库默认自带DBSNMP用户OEM就是用这个账号做监控采集的。数据库安装时如果没特别改DBSNMP存在但可能处于锁定状态需要先解锁并设置密码。执行下面的SQLALTER USER dbsnmp IDENTIFIED BY your_password ACCOUNT UNLOCK;然后回到OEM数据库目标页面把DBSNMP凭据填好。首次配置完成后过一两分钟刷新页面数据库的各项指标就会开始出现。到这里最基本的“监控管理数据库”已经实现了。后续要做的是把监控做细把告警加好。3.3 登录OEM控制台验证监控效果配置完成后先用实际访问验证一下。浏览器打开https://oms_host:7803/em输入sysman账号密码登录。首页会有仪表板展示当前所有目标的状态汇总。正常情况会看到若干主机、数据库实例、监听器都显示为“状态正常”或向上箭头。点开任意一个数据库实例概览页面会展示实例运行状态、活动会话数、DB Time、当前等待事件、告警日志中的错误数量等。要确认监控数据确实在采集而不是页面上的静态值可以在数据库里做一个小实验执行一条比较消耗资源的查询比如对一个大表做全表扫描同时打开OEM数据库概览页看活动会话数和DB Time的变化或者把一个测试表空间的数据文件占满看空间指标和告警是否出现。这种实证比单纯看页面更让人安心。如果发现Agent显示为“代理不可达”或者数据库状态一直是“待确认”不要犹豫直接去查Agent日志。Agent日志在AGENT_INST/sysman/log/下面重点看emagent.trc和gcagent.log两个文件。日志里有具体的错误原因通常指向网络不通、注册口令人不对、主机名解析失败三类问题。验证通过后再往下就是对监控项和告警做定制这是让OEM真正“管理”数据库的关键一步。4. 数据库监控与告警配置实战4.1 关键监控指标与阈值设定很多人在OEM里看了一圈之后就不知道干什么了因为默认监控项已经够多反而不知道哪些值得配阈值。根据我的交付经验Oracle数据库日常最值得盯的指标加上建议阈值可以列成一张表监控指标建议警告阈值建议严重阈值说明表空间使用率85%92%到达92%时很多表已经无法扩展必须提前介入归档日志区使用率80%90%归档空间满会直接挂库这是最危险的告警之一活动会话数视CPU核数而定视CPU核数而定一般超过CPU核数两倍以上说明性能异常告警日志中ORA-00600无严重内部错误必须立即处理告警日志中ORA-01555警告无快照过旧需要检查UNDO数据文件平均I/O延迟30ms60ms超过30ms基本上是存储有瓶颈log file sync平均等待20ms50ms提交变慢常见于磁盘I/O或日志组压力配置入口在数据库目标概览页的“管理”菜单下选择“指标和阈值”。不建议把阈值改成“只要不报警就不管”的心态太小阈值会造成告警轰炸最终大家看到报警也无感。我见过有团队把表空间阈值设成70%结果每个库天天发邮件时间长了都懒得看真正90%以上的告警反而被淹没。阈值设定的核心理念是宁可少而准不要多而废。对于性能类监控可以重点关注“等待事件”和“DB Time”。在数据库概览页的Performance Hub里可以交互式地查看某个时间段的等待事件分布、SQL执行情况、活动会话热图。这个工具是13c版本里很实用的组件调SQL特别方便。4.2 邮件通知与值班告警配置监控数据只是静物能及时通知到人才算闭环。OEM的告警通知分两个层面一个是通知方法也就是发信的通道一个是通知规则解决“什么级别、什么目标触发后要通知谁”的问题。配置通知方法的位置在“设置”菜单下选“通知方法”再选“电子邮件”。填写SMTP服务器地址、端口、发件人邮箱如果SMTP需要认证就打开认证开关并填账号密码。公司内部有自己的邮件网关就用内部网关走公网邮件容易有延时。配置完成后接着配置规则。在“设置”菜单下选“通知规则”可以创建多条规则。我的建议是至少创建两条规则严重级别规则把“严重”级别的告警发给DBA邮件组。凡是严重级别的告警基本都是数据库节点、归档空间满、重要进程宕掉这类必须立刻处理的问题。警告级别规则把“警告”级别的告警发给DBA个人邮箱或者只记录台账不立即发送。更复杂的做法是配置升级机制例如警告持续15分钟不消失再升级为严重。OEM也支持在通知时执行自定义脚本如果你要用企业微信或者钉钉机器人可以写一个脚本接收OEM传递的告警参数再调用Webhook发出消息。不过这个要自己开发我不展开太多首次落地还是先用邮件稳。还有一个实用的技巧利用OEM的“作业”功能每天凌晨自动运行一个巡检作业把当天各数据库的状态、空间变化、告警摘要生成报表发到值班邮箱。这样每天早上只需要看一封邮件就能掌握全库情况。4.3 在OEM中执行备份、巡检与报表监控告警只是“看”真正的“管理”还得能操作。OEM 13c把RMAN备份集成到了Web页面里可以在数据库目标概览页的“可用性”菜单下进入“备份/恢复”子页面配置备份策略。OEM内部会把你的配置翻译成RMAN命令按计划执行。对于不想天天敲RMAN命令的DBA来说这个功能能省不少事。但我要提醒一点不要因为OEM集成了备份就完全依赖页面恢复脚本仍然建议在RMAN命令行里手工做过一次演练。毕竟页面封装会隐藏很多细节一旦真出故障你要保证你能看懂底层脚本在干什么。巡检方面OEM的“报表”菜单提供了大量模板例如“数据库空间汇总”“容量规划趋势”“配置变更报表”“合规性报告”等。生成报表可以手动触发也可以通过作业定时运行。月报季报用这些模板会比手工整理SQL快得多。Performance Hub里的AWR和ADDM是我最常用的两个功能。以前做性能分析得手动生成AWR报告再慢慢看现在直接在页面里选定时间范围等待事件、TOP SQL、ADDM建议都列得很清楚。特别是ADDM给出的建议虽然不能全盘照做但是排查方向可以省很多时间。5. 常见问题与排查避坑实录5.1 安装与仓库配置典型报错配置OEM的过程中我踩过的坑不少有些坑卡了我大半天。整理成表格方便你对照排查。报错现象常见原因解决方法安装检查提示仓库库字符集不是AL32UTF8创建仓库库时选错了字符集重新创建数据库字符集选AL32UTF8安装进度卡在ExecutingPrereqChecks系统缺少某些依赖包如libaio、compat-libcap根据日志安装缺失依赖包后重跑root.sh执行报权限错误非root用户直接执行切换到root用户严格按路径执行OMS启动失败或进程起不来内存不足或某个所需端口被占查看OMS_HOME/cfgtoollogs下的日志释放端口EM Console页面打不开HTTPS端口不通或服务未启动执行emctl status oms并确认防火墙放行仓库库字符集这个坑最隐蔽因为很多数据库安装时默认选的是WE8MSWIN1252或其他字符集安装的时候不容易意识到问题。建议在搭建仓库库之初就固定字符集为AL32UTF8后面会省掉很多麻烦。还有一个容易被忽略的点是/etc/hosts里的配置。如果OMS主机名解析到127.0.0.1或者主机名包含下划线OEM服务启动时可能出现各种诡异问题。解决办法是让主机名作为完整域名解析到真实IP不要和localhost混在一起。5.2 Agent部署与目标发现常见故障Agent相关的故障在贴吧和群里永远有人问我这几年遇到过的基本集中在三类第一类Agent状态一直为“代理不可达”。多数原因是OMS到Agent的回连端口不通。Agent会主动向OMS上传数据但OMS有时候也要反向连Agent做一些操作。检查Agent所在主机的防火墙尤其是4903端口再检查Agent和OMS的主机名是否有DNS冲突。确认可以后执行emctl status agent看详细状态。如果日志提示Certificate验证失败多半是Agent安装时使用的OMS主机名和实际不一致最干净的办法是卸载Agent重新部署。第二类控制台推送Agent失败。排除网络问题后最常见原因是SSH免密没配好。手动执行一遍ssh oracletarget_host echo ok能返回ok再在控制台触发。如果目标主机的SELinux是Enforcing状态SSH公钥认证可能被拦截可以先临时setenforce 0测试确定是这个原因再设计放行策略。第三类数据库目标不出现或者显示“待固定”。Agent安装好了数据库没被发现常见原因是监听器没有正常注册或者DBSNMP密码还没配好。处理方式先确认监听器状态lsnrctl status再确保DBSNMP账号解锁并设置了密码最后在OEM数据库目标页面手动执行“强制监控”。5.3 仓库库空间维护与性能优化仓库库自己也会长大如果不维护最终反过来影响OEM本身。这是“监控工具反噬”的典型场景。我遇到过最极端的一次仓库库的SYSAUX表空间涨到100多GBOEM页面直接卡得打不开。OEM有自带的清理机制位置在“设置”菜单里的“清理策略”。可以配置历史数据保留周期比如AWR数据保留30天系统指标保留60天历史作业记录保留90天。建议根据实际需要配置不是保留越久越好。如果仓库库已经很大并且清理策略已开放但空间没有回收可以手工做一次purge。官方也提供了emdemo purge类的脚本具体命令要对照版本文档。更简单的做法是把历史数据分区删除配合表空间压缩处理。这些操作要谨慎执行前备份仓库库。6. 实操心得最后聊点实在的。我在实际配置中发现OEM 13c这套平台技术细节很多但真正的坑往往不在产品本身而在准备工作。仓库库字符集、主机名规划、端口策略、SSH免密这些基础配置只要有一个不顺手后面就会连环报错。很多人安装到一半卡住就急着折腾OEM日志其实是基础设施没打通。给第一次搭建的朋友一个建议先用自己的测试环境完整跑一遍从“零”到“页面上能看到数据库状态”再碰生产环境。这个过程会让你熟悉安装阶段到底要准备什么也试出哪些参数在自己的网络里无法使用。我早期就是在测试环境里踩完Agent推送的坑才敢去客户生产环境一次交付成功。另外OEM装好之后别急着配一堆告警规则。先把监控范围缩小到核心两三个库验证监控数据确实准确、告警邮件确实能发出来再慢慢扩大管理范围。一次性把所有库都加进来看不到数据或误报太多的时候排查起来反而焦虑。后续如果还想扩展OEM 13c可以通过插件继续监控Oracle WebLogic中间件、Exadata一体机、甚至部分第三方存储设备。同一个平台越用越贴合自己的运维体系这种投入还是值得的。