这年头搞数据库运维最怕的不是数据库挂而是挂着挂着才知道挂了。我带团队接手过一家公司生产环境三十多套Oracle库散落在不同网段和机房平时靠脚本加定时任务硬扛着巡检漏报是家常便饭。后来需求很简单也很硬核要有一个平台所有库的状态、空间、告警打开浏览器就能看还要能自动通知。最后我选了Oracle自己的Enterprise Manager也就是大家常说的OEM具体版本用了13c核心任务就是配置OEM 13c去监控和管理我们自己这些数据库。聊之前先给没接触过的朋友补个底。OEM的全称是Oracle Enterprise Manager是Oracle官方的统一管理平台。13c是这个平台的版本号市面上常见的是13.3到13.7这几个小版本。它的能力范围很广日常我们最常用的是几块实例状态监控、表空间使用率查询和预警、告警通知、AWR/ADDM报告生成还有补丁和备份作业管理。对人员不多、Oracle数量却很多的团队来说这东西几乎是刚需对安全要求高、不让第三方监控工具进生产网的单位Oracle自家的产品在合规层面也更好通过。这篇文章适合三类人第一次搭建OEM的DBA、想从手工巡检转型成平台化监控的运维工程师以及需要给团队做技术选型的架构师。1. OEM 13c到底是什么它帮你解决什么问题1.1 从一次巡检翻车说起先来讲讲我自己经历的一个场景。刚接手那会我让团队里一个实习生写了个巡检脚本每天早上8点跑一遍把每个库的状态发到群里。脚本逻辑很简单能用sqlplus连上数据库就认为正常连不上就报警。听起来没毛病吧结果有一次某个核心库的监听挂了但实例还活着脚本自然连不上于是报警。大家兴冲冲上去修监听结果发现更严重的问题归档日志目录已经满了实例只差一步就要hang死。巡检脚本只发现了表面问题容量、等待事件、告警趋势这些根本无从谈起。那一刻我就下定决心必须上OEM 13c这种能真正“持续采集”的平台而不是用脚本去猜数据库状态。这个例子其实说明了一件事手工巡检再怎么精细永远是被动式的只有平台化的持续监控才能把数据库的“身体状况”完整记录下来。OEM 13c就是Oracle官方给的答案它不光是监控还带分析、告警、作业编排是一个真正能落地的管理平台。1.2 三个组件各干各的活OEM 13c的逻辑结构说破天就是三个组件OMS、Management Repository、Agent。OMSOracle Management Service是整个平台的“大脑”。它本身是个Web服务跑在WebLogic之上负责给浏览器端的管理页面提供数据接收Agent送来的监控样本再把命令下发回Agent。平时我们在界面上点来点去不管查性能还是创建作业背后都是在跟OMS打交道。Management Repository是“记忆”。OMS会把所有监控数据、告警、作业历史、系统配置写到这个数据库里。它可以是独立的一套Oracle数据库也支持部署成RAC。仓库库规划得好不好直接决定整个平台跑得顺不顺。Agent是“感官”装在被监控的服务器上负责采集操作系统指标、数据库指标周期性地打包发给OMS。同时Agent还能自己跑作业比如你在OEM里新建了个备份作业实际下达执行的是目标机器上的Agent。这三个组件缺一不可理解了这个架构后面很多问题的排查方向就清楚了。比如页面打不开先查OMS数据不更新查Agent心跳告警和历史报表查Repository的采集任务。我在给团队培训的时候总是强调OEM不是装完就结束的工具它是一个持续运行的系统你得知道它的关键节点在哪出问题才不慌。1.3 版本选型没必要追新够用就行OEM 13c有多个小版本13.2、13.3、13.4、13.5、13.6、13.7等。多数生产环境现在跑13.5或13.6。选版本有一个原则先看你的数据库版本。比如Repository库在13.5开始建议用19c而且对数据库补丁版本还有最低要求。如果你现有的数据库环境以19c为主直接用13.5或13.6都能平滑支持如果环境里还有不少12c的老库13c的任意小版本也都兼容。不建议一上来就追最新版。OEM的升级逻辑是从13.5到13.6再到13.7一级一级走跨大版本升级并不轻松。而且企业环境里OEM属于“管理基础设施”稳定性远比新功能重要。我见过有人装了13.7结果Agent版本太新和几台老服务器的操作系统兼容性出问题最后又退回13.6纯属自找麻烦。2. 部署前的准备工作别让环境坑了你2.1 硬件、操作系统和网络部署OEM 13c并不挑机器但特别吃内存和磁盘。官方文档给的是一个最低值实际生产建议翻倍。如果你的OMS和Repository库装在同一台服务器上CPU建议至少8核内存至少16GB我自己的经验是32GB比较舒服因为在这台机器上要跑OMS的WebLogic进程、Agent进程再加上数据库实例16G会显得很紧张。磁盘更不要省。OMS安装目录、Repository库的数据文件、还有Agent采集的中间文件都占地方。我一般给/u01分配300GB以上/tmp给足4GB以上因为安装过程和后续补丁解压都会用到临时目录。如果条件允许最好给Repository库单独挂一块SSD监控平台有大量的小样本写入对IOPS的要求比想象的高。操作系统建议用Linux 7.x或8.x用Oracle Linux最省心兼容性最好。网络方面安装机、Agent目标机之间要能互通域名解析至少保证hosts文件里写清楚了主机名和IP的对应关系否则后面Agent加目标的时候会被主机名解析坑到怀疑人生。13c对老旧的Linux 6已经不太友好如果环境还是CentOS 6劝你慎重装起来会碰到一堆缺库缺依赖的幺蛾子。2.2 提前把仓库库准备好安装OMS之前最好先把Repository库准备好。在安装向导里虽然可以选择让安装程序自动配置一个仓库库但那需要你提供一个已经存在的Oracle数据库实例并把sys、system这些账号口令准备好。我的习惯是提前单独建一个实例字符集用AL32UTF8开启归档表空间大小另说重点是要尽量避免最后因为数据库字符集不匹配导致安装失败。仓库库不要和生产业务库混用。原因有两点第一OEM的采集数据增长很快会和业务抢IO第二OEM日常要重启OMS服务甚至做库级别调整如果这台库上面还跑着业务风险不可控。如果团队预算实在紧张至少把仓库库放在专门的服务器上别和生产库待在一台。仓库库的数据库版本选型也有讲究13c对Repository库的版本有具体要求。以13.5为例推荐19c且补丁版本至少到2020年以后的季度补丁。如果你的仓库库补丁太旧安装向导在检测时就会直接报错而且错误提示并不友好——我第一次遇到时愣是查了半天才发现是数据库PSU版本太低。2.3 hosts、内核参数、依赖包一个都不能少在Linux上装OEM本质上还是在装一套Java中间件加一个数据库客户端所以Oracle数据库的那些前置条件同样适用。先检查hosts。我踩过一个特别经典的坑安装机的主机名映射写成了127.0.0.1 localhost hostname然后OMS启动以后WebLogic一直起不来日志报成localhost.localdomain的主机无法解析。正确做法是在/etc/hosts里把实际IP和主机名放在第一行比如192.168.10.10 oms-server不要依赖DNS尤其是在内网环境。内核参数也建议提前调好。最常用的几个fs.file-max建议 6815744kernel.sem建议250 32000 100 128net.ipv4.ip_local_port_range建议9000 65500vm.swappiness建议10。这些参数在Oracle数据库安装文档里都有出处OEM安装时也会默认检查。调完记得执行sysctl -p生效。依赖包方面13c对libnsl.so.1、libaio.so.1、libXext.so.6这些库都有要求尤其是新装的最小化Linux系统经常缺这个缺那个。安装过程如果报了类似“GLIB library not found”的错误多半就是依赖包少了。最简单的办法在安装前先yum装一遍yum install -y binutils compat-libcap1 gcc gcc-c glibc \ glibc-devel ksh libaio libaio-devel libX11 libXext libXrender \ libXtst libXi libgcc libstdc libstdc-devel libnsl sysstat \ unixODBC unixODBC-devel装完以后再去跑安装程序能少掉90%的环境拦路虎。同时记得关闭SELinux改SELINUXdisabled后需要重启防火墙的话要么直接关闭要么把OMS相关端口全部放通。生产中最怕的是防火墙开着但忘了放端口页面或Agent死活连不上查了半天都是防火墙。3. 一步步安装OMS最费时间的其实是等待3.1 下载解压和安装入口安装文件可以从Oracle官网下载OEM 13c的几个大包加一起大概有几个GB建议下载到本地后传到目标服务器解压后仔细检查磁盘空间因为解压出来的目录和后续安装目录加起来很可观。假设你把安装包解压到/u01/app/oem/soft进入目录后直接执行./install.sh。这里要注意一点安装程序需要图形界面交互。如果你用的是有桌面的服务器直接执行如果是纯命令行服务器就得提前配置好X11转发或者用VNC建立远程图形会话。没有图形界面硬跑只会得到一句“无法启动DISPLAY”的报错。很多时候安装不顺利不是软件问题是运维环境还没准备到位。3.2 安装向导里的关键选项安装向导本身是中文还是英文取决于你的环境语言和界面设置不过选项含义都一样。我挑几个容易出问题的选项单独说。第一选择“创建一个新的Enterprise Manager系统”。这里不要手滑选成升级。接下来会让你选装哪些组件建议保持默认把OMS和Management Repository都勾上。第二关键一步Repository配置。一种是选择使用“现有数据库”另一种是配置一个新的Repository库。如果你按我前面说的提前准备了独立库这里就填独立库的连接信息主机名、端口、服务名或SID、sys口令。安装程序会在这个库里自动创建一堆OMS Schema。第三口令配置。OEM会让你输入WebLogic管理员weblogic、OEM管理员sysman等多个账号口令。生产环境建议设置复杂口令但千万别用带特殊字符的口令比如感叹号很多系统脚本处理时会出问题。我有一次就是因为口令里带了个!导致后续Agent推式安装失败排查了大半天最后换个口令全好了。第四端口模式。选择“使用默认端口”还是自定义端口。默认端口规划通常是HTTPS端口7799、HTTP端口7788、Agent上传端口4903。如果服务器上已经有Web服务占了这些端口就要自定义否则安装进行到一半会报端口冲突。端口规划最好列一张表后面配置防火墙和Agent都用得上。安装到快结束的时候会要求你在root用户下执行一个root.sh脚本。这个步骤不能省也不能拖。有些网上的教程说可以最后一起执行我的建议是它在提示你执行的时候就立刻开一个root会话执行完然后再点下一步确认避免最后卡在一个奇怪的阶段。3.3 安装完成后的验证和端口清单安装完成不代表大功告成先做几个验证动作。第一执行emctl status oms正常输出会显示OMS running、Agent running等。如果显示BIPRS的问题也要等服务起来再观察。第二浏览器访问https://oms-server:7799/em能弹出登录页就算成功。默认管理员是sysman口令就是你在安装向导里设置的那个。第三验证仓库库是否正常。可以登录仓库库查几个核心表是否存在如果OMS页面能打开通常仓库库就没什么大问题。给端口常记在一张表里用途默认端口说明OMS管理页面HTTP7788建议用HTTPS而不是HTTPOMS管理页面HTTPS7799浏览器访问主端口Agent上传监控数据4903Agent到OMS的上行通道OMS下行到Agent3872OMS给Agent下发指令时使用WebLogic管理端口7101一般不需要对外开放Node Manager端口7401一般不对外端口不一定非得用默认值但选择自定义后务必在安装记录里留下一份端口对照表。我看过太多团队半年之后忘了端口换了人要重新查半天。4. Agent部署监控的最后一公里4.1 Agent的两种部署方式有了OMS还得把Agent装到每一台被监控的服务器上。Agent有两种主流部署方式。第一种是推式部署在OMS界面的“添加目标向导”里填上目标机器的SSH凭证OMS会自动把Agent软件推过去并安装。这种方式最大的好处是批量部署效率高适合几十台机器一次性加进来。但前提是目标机器允许OMS通过SSH连进来很多安全要求高的生产环境根本不开放这个通道所以推式部署在测试环境很爽到了生产往往用不了。第二种是手动部署也就是拉式安装。先从OMS下载对应操作系统的Agent安装包传到目标服务器解压后执行安装脚本。这种方式看似麻烦但胜在可控。跨网段、跨DMZ、不允许SSH直连的环境基本都靠它。我的习惯是先在测试机用手动方式完整走一遍再决定要批量还是单台部署。4.2 手动部署Agent的完整流程手动部署的完整动作大概有四步。第一步从OMS下载Agent安装包。在OMS页面里找“下载Agent”相关入口一般会列出Linux x86-64、Windows等平台的包。下载后传到目标服务器比如放到/u01/app/agent_soft。第二步解压。Agent安装包本身自带Java运行环境大多数情况下不需要单独安装JDK但前提是目标机器上不能有版本冲突的Java环境变量。解压后会得到一个类似agentDeploy.sh的脚本。第三步执行安装脚本关键参数是OMS的主机名和HTTPS端口。示例./agentDeploy.sh OMS_HOSToms-server OMS_PORT7799 \ ORACLE_HOME/u01/app/oracle/agent/agent_inst如果需要在非root用户下运行可以加AGENT_USERoracle之类的线程参数具体以安装包里的README为准。如果目标机上已经有旧Agent这里会检测到并提示冲突。我的建议是先停止并卸载旧Agent再装新的不要想着“覆盖安装”省事两个Agent进程抢同一端口的情况我见过不止一次。第四步配置目标机器上的/etc/hosts把OMS的主机名和IP写进去确保Agent正向解析和反向解析都能对上。配置完成后执行emctl start agent然后回到OMS界面等几分钟让Agent自动注册。正常情况下“目标”列表里会自动出现这台主机的操作系统目标然后你就能在这台主机上添加数据库目标了。如果没有自动出现先emctl status agent看状态再查Agent日志。4.3 Agent日常维护状态、日志、心跳部署完Agent不是一劳永逸日常维护最常用的命令就三个emctl status agent查看Agent健康状态和心跳上报时间emctl upload手动触发一次数据上传诊断数据延迟时很管用emctl stop agent和emctl start agent重启Agent。日志方面Agent的日志一般在Agent安装目录的sysman/log下面最常看的是gcagent.log。如果Agent上报的数据有延迟或者失败这个日志里会记录到具体的上传错误和HTTP状态码。别一上来就看什么系统日志先看gcagent.log90%的问题都写在里面。还有一个容易被忽略的点Agent所在机器的时间必须同步。OEM监控体系严重依赖时间戳机器时间偏差太大Agent采集的数据会被OMS拒收表现就是目标状态显示“无数据”。所以装好Agent后第一件事就是检查date和ntpq -p确保和OMS服务器时间一致。5. 添加数据库目标真正开始监控5.1 从发现目标到保存凭据Agent注册成功后添加数据库目标就顺理成章了。在OMS界面的“目标”菜单里选“添加目标”再选“添加数据库”系统会让你选择目标主机。如果Agent已经发现主机就会列出这台主机上通过监听发现的数据库。你也可以手动填数据库连接串。这里有几个细节要注意。一是数据库监听必须能被Agent所在主机访问。如果你是先给一台目标机装了Agent再在这台机器上添加数据库目标数据库通常就在本机监听地址一般为localhost:1521。但如果是远程数据库就要保证网络能通。二是需要提供数据库的管理凭据。OEM要求使用具有监控和诊断权限的账号比如DBSNMP账号或者单独创建一个oem_monitor用户并授予SELECT_CATALOG_ROLE、SELECT ANY DICTIONARY等角色。我不建议直接给sys口令万一OEM被攻破等于拿到了所有库的管理员权限。我通常会在每套库里创建一个专用账号只给够用的权限并在口令策略里设置过期时间。三是添加完成后在“数据库目标”页面上会有一个“运行状况”和“配置信息”的概览默认会在5到10分钟内开始采集数据。如果等了半小时还是“无法连接”先回到Agent和目标主机检查数据库目标依赖主机Agent的正常工作主机Agent掉了数据库目标必然跟着挂。5.2 告警阈值和邮件通知配置数据库目标加进来以后重点就是要配告警阈值。OEM默认给了一些常见指标的阈值但多数情况下默认值不适合所有环境需要自己改。我最常改的几个指标和阈值指标警告阈值严重阈值说明表空间使用率85%97%阈值要根据数据增长率和磁盘容量调整实例状态不可用不可用数据库无法采集时立即触发活动会话数820根据CPU核数和并发量调节生产库建议自定义CPU利用率85%95%注意区分“平均负载”和“CPU使用率”归档目录剩余空间剩余10GB剩余5GB归档模式库必须盯紧修改阈值的入口在目标数据库的属性或监控配置里。我个人建议先把阈值表打印出来贴在工位上团队按这张表统一执行避免每个人乱改。告警通知主要靠邮件或脚本。配置方法是在“通知”菜单里添加一个通知方式填SMTP服务器地址、发件人、收件人列表再在“规则”里把告警和通知方式绑定。我一般会建三条规则紧急级别直接邮件加电话如果有集成严重级别邮件警告级别汇总晨报。规则越简单越好复杂规则容易漏告警。5.3 我平时用得最多的监控功能监控平台建好以后我日常用得最多的功能按频次排序大概是这五类。第一数据库目标总览页。打开浏览器就能看到所有库的运行状态、最近告警、性能和空间趋势。这是每天的例行工作入口。第二性能页的实时等待事件。当开发说“某条SQL好慢”时我能在几秒内定位到是CPU等待、I/O等待还是锁等待这种能力在以前手工时代根本不敢想。第三ADDM和AWR报告。在EM里可以一键生成最近一小时或一整天的ADDM分析报告它会直接告诉你“某个SQL占用了多少DB Time建议做什么”。生成AWR报告也只是一个按钮的事情不需要再用sqlplus手动跑脚本。第四表空间容量规划。在“容量”页面上能看到每个表空间近30天的增长趋势我据此做扩容计划。以前扩容全靠拍脑袋现在至少有一个数据支撑。第五作业管理。在OEM里可以创建定时作业比如每天凌晨自动刷新统计信息或者定期归档冷数据。作业由目标机器上的Agent执行执行结果自动汇总到OMS省去了在各个库上分别配置定时任务的麻烦。对于有PDB架构的环境OEM 13c也能分别展示容器库和各个PDB的独立监控数据。添加目标时选择容器库EM会自动列出里面的PDB你可以单独为一个PDB设置阈值和告警。这个功能在混合负载和多租户场景下非常实用。6. 常见问题与排查实录6.1 OMS页面打不开先查这三件事OMS页面打不开几乎是装机后最常遇到的问题。按照我自己的排查顺序从来都是三步走。先看服务状态。执行emctl status oms查看OMS是否running、Agent是否running。如果OMS服务没起来看一下emctl start oms的输出再查OMS日志。日志里如果有权限错误、磁盘满之类的通常一眼就能看出来。再看端口。执行ss -ltnp | grep 7799看HTTPS端口是否在监听。如果端口根本没监听很大可能是WebLogic有问题如果监听但页面打不开多半是防火墙或代理问题。最后看浏览器访问的地址。很多人图省事直接访问IP但如果你的OMS证书是用主机名签的用IP访问会被浏览器拦截证书错误。正确做法是访问https://oms-server:7799/em并把主机名解析到OMS所在IP。6.2 Agent离线凌晨天天掉线Agent的问题里最让人崩溃的就是“有时在线有时离线”。我碰到过一个案例Agent在白天正常凌晨三点左右就不上传了早上起来又恢复。排查思路是这样的先看目标机器的时间再查Agent日志。凌晨三点掉线最可疑的是系统定时任务或监控脚本在凌晨跑了重活把系统资源占满导致Agent进程被卡住。我们当时就是有一个凌晨的全库备份脚本资源争夺导致Agent上报超时。后来给备份任务加了ionice和cgroup限制Agent再也没掉过线。另一个常见原因是Agent的心跳周期和OMS的容忍时间配置不匹配。13c默认的Agent上报间隔是15分钟如果网络不稳定一次上报失败没有及时重试OMS端就会把目标标记为不可用。解决办法有两个一是调整Agent的上报频率和重试次数二是把“目标丢失判定”的时间阈值调大一些。6.3 表空间告警不准和仓库库狂涨表空间告警不准通常是因为采集频率太低。OEM采集表空间数据默认周期可能是一个小时以上而生产库数据文件扩展往往很快等到告警发出来可能已经晚了。我的建议是把表空间的采集频率调到15分钟或更短同时开启“空间预测”功能让EM根据历史增长趋势提前预警。仓库库狂涨是另一个让人头疼的问题。监控平台运行越久Repository库越大。查询历史、告警历史、性能基线都会占用大量空间。治理手段有三招定期清理EM的维护数据调整保留策略对不需要的AWR快照做清理在OEM维护页面里把“指标历史保留天数”从默认的30天调整到实际需要的天数。仓库库建议每月做一次容量巡检别等磁盘满了再处理。6.4 我踩过的坑汇总表最后把几年里在OEM 13c上踩过的比较典型的坑列成表时刻提醒自己坑现象解决办法JVM版本不匹配Agent启动即报错日志显示Java版本未知优先用OEM安装介质自带的JDK不手改Agent的JAVA_HOMEhostname解析混乱OMS页面显示目标主机名带.localdomain/etc/hosts写全主机名和IP避免使用localhost当作主机名防火墙未放行Agent端口Agent无法上传状态离线放通4903、3872确保Agent到OMS的双向端口可达仓库库与生产库混用OMS维护时业务受影响仓库库独立实例独立存储口令带特殊字符推式部署Agent失败口令只用字母数字和下划线不要用!#等符号表空间采集频率太低告警滞后根据业务增长调高采集频率Agent多实例冲突两个Agent进程抢端口装新Agent前彻底卸载旧Agent时间不同步监控数据不更新所有服务器统一NTP时间偏差尽量小于1分钟内容到这里基本把OEM 13c从装到用、从踩坑到填坑的路子走完了。如果一定要我总结一条经验我认为最值钱的不是安装技巧而是它改变了整个团队的运维节奏。以前我们靠巡检脚本被动等告警现在每个早晨的第一件事变成了打开OEM看一遍“总览”该扩容的扩容、该预告警的预告警很多故障在用户感知之前就处理掉了。最后再分享一个小技巧OEM 13c支持REST API如果想把它和公司的飞书、钉钉群机器人打通直接用API抽取告警数据再推送到群消息比手工看页面高效得多。我现在的自动化日报、周报也是靠这套接口在跑基本不占人力。等你有了一台跑稳定的OEM后续再接入新的数据库或者做多实例联邦监控都是顺水推舟的事。