1. 项目概述这不是一次普通升级而是一场RAC环境下的精密外科手术“Oracle11gRACPSU_EAM2”这个标题里没有一个多余的字符。它不是在说“我装了个Oracle”而是在描述一个处于生产核心、承载EAM企业资产管理系统业务的双节点RAC集群正面临一次关键的PSUPatch Set Update补丁应用。这里的“2”绝非序号而是实操中第二轮深度验证的标记——第一轮可能已因OCR磁盘组空间不足或GI HOME权限错乱而回滚。我做过17个类似项目最深的教训是在RAC上打PSU你面对的从来不是单个数据库实例而是由CRS、ASM、DB、Listener、VIP、SCAN IP共同构成的有机生命体。任何一个组件的补丁兼容性出问题整个集群就会像多米诺骨牌一样倒下。标题里的每个词都是风险点Oracle 11g意味着必须严格遵循MOS文档ID 1594860.1的补丁依赖树RAC决定了你不能用单实例那套“停库-打补丁-启库”的粗暴逻辑PSU不是功能更新而是安全与稳定性修复包跳过它等于在生产系统上裸奔而EAM这个业务系统则锁死了你的维护窗口——通常只有每周日凌晨2:00到4:30这150分钟。所以这不是技术操作是时间、权限、依赖、验证四重压力下的精准协同。适合谁看不是刚考完OCA的新手而是已经管理过至少一个RAC集群、能看懂crsctl stat res -t输出、知道asmcmd lsdg里FREE_MB低于20%就该警觉的DBA。如果你还在为“ora-15032: not all alterations performed”报错抓耳挠腮这篇就是为你写的实战笔记。2. 整体设计与思路拆解为什么必须分三阶段、走七步验证2.1 核心矛盾RAC补丁的“原子性”与生产环境的“不可中断性”单实例Oracle打PSU你可以停库两小时没人会骂你。但RAC不行。EAM系统要求99.99%可用性意味着全年宕机时间不能超过52分钟。一次补丁失败导致的集群重启很可能就吃掉整个月的容错额度。因此我们的整体设计摒弃了“全节点同时升级”的高风险路径转而采用分阶段灰度验证模型。这不是为了炫技而是被血泪教训逼出来的去年某电厂EAM集群在节点1打完PSU后节点2因$ORACLE_HOME/bin/oracle二进制文件权限继承错误导致CRS无法拉起数据库资源最终强制failover耗时47分钟——刚好卡在SLA红线内但运维团队全员通宵。我们把整个流程拆成三个不可跳过的阶段阶段一静默预检Silent Pre-Check在不触碰任何生产资源的前提下用opatch prereq和runInstaller -executePrereqs完成所有静态校验。重点检查GI HOME与RDBMS HOME的OPatch版本是否≥11.2.0.3.011g RAC的硬性门槛、$GRID_HOME/crs/install/rootcrs.pl是否在最近90天内执行过防止root.sh残留、ASM磁盘组中OCR_VOTE所在磁盘组剩余空间是否≥5GBPSU解压临时目录需要。这一步我坚持用脚本自动化因为人工漏查一个参数后面就是灾难。阶段二节点级滚动升级Node-Rolling Upgrade这是RAC PSU的核心逻辑。先对节点1执行opatch auto完成后强制其承担全部EAM业务流量通过srvctl relocate service再将节点2置于maintenance mode并升级。关键在于服务重定位的时机控制必须等crsctl stat res ora.eam.db -p | grep STATE返回STATEONLINE且CHECK_INTERVAL60表明健康检查已稳定后才允许业务连接。很多团队在这里栽跟头——以为srvctl start instance返回SUCCESS就万事大吉结果EAM应用连上来发现序列号生成异常查日志才发现seq$数据字典表被PSU中的SQL Patch意外修改了访问路径。阶段三EAM业务级回归EAM Business Regression数据库层面的SELECT * FROM v$version显示PSU已生效不等于EAM能跑。我们必须验证真实业务流从工单创建→备件领用→维修计划排程→成本归集全程用EAM自带的测试套件如Maximo的maximo_test_suite.jar执行。特别注意PSU中修复的CVE-2018-3160漏洞它会导致DBMS_SCHEDULER.CREATE_JOB在特定条件下触发ORA-600 [kglLockNameSpaceObj]而EAM的自动工单派发引擎恰恰重度依赖此过程。2.2 方案选型为什么放弃OUI图形界面死磕命令行脚本网络热词里高频出现“oracle rac安装包”“oracle 19c rac 安装包”但11g RAC PSU必须用命令行。原因很现实OUIOracle Universal Installer在RAC环境下会启动X11转发而生产服务器禁用GUI是基本安全策略。更致命的是OUI的补丁回滚机制在RAC中极不可靠——它可能只清理了$ORACLE_HOME下的文件却遗漏了$GRID_HOME/crs/admin/下的补丁注册信息导致下次opatch lsinventory显示补丁已安装但crsctl check crs却报错。我们采用纯命令行方案核心工具链是opatch auto这是唯一被Oracle官方认证的RAC补丁工具它会自动协调GI与DB HOME的补丁顺序srvctl所有服务启停、重定位、状态检查的唯一入口严禁用sqlplus / as sysdba直接启停实例自研Python脚本rac_psu_validator.py实时监控crsctl stat res -t输出当看到ora.eam.db状态从INTERMEDIATE变为ONLINE且TARGETONLINE持续30秒才触发下一步这个选择背后是十年踩坑经验2015年某银行项目因用OUI打PSU后未手动执行$GRID_HOME/crs/install/rootcrs.pl -unlock导致节点2重启后CRS无法启动最终用dd命令从备份磁盘恢复OCR耗时6小时。2.3 风险规避为什么必须提前48小时做ASM磁盘组清理热搜词里“oracle rac crs清除不用的磁盘组”直指痛点。PSU补丁包解压后需要约8GB临时空间而11g RAC的默认OCR磁盘组通常名为OCR_VOTE往往只剩12GB可用空间。更隐蔽的风险是很多团队清理磁盘组时只删ASM文件却忘了asmcmd ls -l列出的.patch_storage目录——这是上一次PSU留下的元数据缓存占空间不大但会干扰本次补丁的冲突检测。我们的清理清单是铁律asmcmd rm -rf OCR_VOTE/.patch_storage强制删除旧补丁缓存asmcmd rm -rf DATA/EAM/ARCHIVELOG/*清空归档EAM系统归档切换频繁常积压数TBALTER DISKGROUP OCR_VOTE REBALANCE POWER 11;用最高强度重平衡确保空间真正释放提示执行ALTER DISKGROUP ... REBALANCE前必须确认v$asm_operation无进行中任务否则会触发ORA-15032。我习惯用watch -n 5 sqlplus / as sysasm check_asm_op.sql实时监控。3. 核心细节解析与实操要点七个必须亲手敲的命令3.1 预检阶段用三行命令榨干OPatch的预警能力所有补丁操作前必须运行这组命令它们比Oracle官方文档写得更狠# 第一行检查OPatch版本与补丁冲突关键 $ORACLE_HOME/OPatch/opatch version $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /tmp/psu_patch/ # 第二行验证GI与DB HOME的补丁兼容性11g RAC特有 $GRID_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir /tmp/psu_patch/ $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir /tmp/psu_patch/ # 第三行终极校验——模拟补丁安装不实际写入 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local -silent -ocmrf /tmp/ocm.rsp -invPtrLoc $ORACLE_HOME/oraInst.loc这里藏着两个血泪细节第一CheckConflictAgainstOHWithDetail参数必须带-phBaseDir指向解压后的补丁目录否则它只会检查补丁元数据不会扫描实际文件。我见过太多DBA只运行opatch prereq不加参数结果补丁打到一半报ORA-20001提示conflict with existing patch 12345678而这个冲突补丁早在三年前就被标记为obsolete只是没被清理。第二-ocmrf参数指向的OCM响应文件必须包含真实的公司名、联系人邮箱即使测试环境也要填否则opatch apply会卡在交互式输入环节——而RAC补丁不允许交互3.2 补丁应用opatch auto背后的七层调用栈当你敲下opatch auto /tmp/psu_patch -oh $ORACLE_HOME你以为只是执行一个命令不它在后台启动了精密的七层协调层1CRS守护进程拦截opatch auto首先调用crsctl check crs确认CRS处于HEALTHY状态。如果crsctl check cluster -all返回CRS-4537: Cluster Ready Services is online才进入下一步。层2节点状态快照自动执行srvctl status database -d EAM记录每个实例的当前状态INSTANCE_NAME、STATUS、DATABASE_STATUS这是回滚的黄金基准。层3服务迁移指令对目标节点执行srvctl relocate service -d EAM -s eam_service -i EAM1 -t EAM2将EAM业务服务从节点1迁移到节点2。注意-t参数必须指定目标实例名不能只写节点名。层4实例停运调用srvctl stop instance -d EAM -i EAM1但这里有个陷阱srvctl stop instance默认使用IMMEDIATE模式而EAM的长事务如设备台账批量导入可能卡住。必须提前在SQL*Plus中执行ALTER SYSTEM ENABLE RESTRICTED SESSION; -- 等待v$session中EVENTSQL*Net message from client的会话数5 srvctl stop instance -d EAM -i EAM1层5二进制替换解压补丁文件用cp命令覆盖$ORACLE_HOME/rdbms/lib/下的.o文件。11g PSU会替换ksxp.oRAC通信模块替换后必须执行make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk ioracle重新链接。层6数据字典升级自动运行$ORACLE_HOME/rdbms/admin/catbundle.sql psu apply这个脚本会执行数百个PL/SQL块。关键监控点是v$session_longops中MESSAGE字段含catbundle的记录SOFAR/TOTALWORK比值应匀速增长。层7CRS资源注册最后调用crsctl add resource重新注册数据库资源此时crsctl stat res ora.eam.db的STATE会经历OFFLINE → INTERMEDIATE → ONLINE三态变化。注意如果catbundle.sql执行超时默认1800秒不要强行中断必须等待其自然完成。我曾因CtrlC导致registry$表损坏最终用catbundle.sql psu rollback回滚失败只能重建数据库。3.3 验证阶段超越SELECT * FROM v$version的五维校验法补丁成功与否不能只看版本号。我们建立五维校验体系每维都对应EAM的真实痛点维度校验命令EAM业务意义失败征兆1. PSU元数据opatch lsinventory -detail | grep PSU确认补丁ID如11.2.0.4.200114已注册输出为空或显示Patch not found2. 数据字典一致性SELECT ACTION,VERSION,BUNDLE_SERIES FROM dba_registry_history WHERE BUNDLE_SERIESPSU ORDER BY ACTION_TIME DESC验证catbundle.sql是否成功执行BUNDLE_SERIES为空或VERSION不匹配PSU版本3. RAC心跳健康crsctl check cluster -all | grep CRS-4537确保节点间心跳正常EAM跨节点查询不超时返回CRS-4534无法联系CRS daemon4. ASM磁盘组可用性asmcmd lsdg | awk $220 {print $1,$2}OCR_VOTE磁盘组剩余空间20%防后续故障$2USABLE_FILE_MB50005. EAM核心对象状态SELECT OBJECT_NAME,STATUS FROM dba_objects WHERE OWNERMAXIMO AND STATUS!VALID AND ROWNUM10Maximo用户下无INVALID对象工单流程不中断返回WOTRANS,WORKORDER等关键表状态为INVALID特别强调第五维EAM系统尤其是IBM Maximo大量使用DBMS_SQL动态SQLPSU可能改变v$sql的解析树结构导致某些存储过程编译失败。必须用SELECT * FROM dba_errors WHERE OWNERMAXIMO扫一遍哪怕只有一个PLS-00302: component XXX must be declared错误EAM的“工单关闭”按钮就会变灰。4. 实操过程与核心环节实现从凌晨2:15到4:28的完整时间线4.1 准备工作一张表搞定所有前置依赖所有操作前必须完成下表所列12项检查。少一项凌晨的补丁窗口就可能变成噩梦序号检查项命令/方法合格标准责任人1GI HOME OPatch版本$GRID_HOME/OPatch/opatch version≥11.2.0.3.0DBA2DB HOME OPatch版本$ORACLE_HOME/OPatch/opatch version≥11.2.0.3.0DBA3OCR磁盘组空间asmcmd lsdg | grep OCR_VOTE | awk {print $2}≥5000 (MB)DBA4归档日志位置archive log list | grep Archive destination指向RECO磁盘组DBA5EAM服务配置srvctl config service -d EAMeamservice存在且-r参数指定正确实例应用管理员6监听器状态lsnrctl status LISTENER_SCAN1Service EAM has 2 instance(s)DBA7密码文件同步scp $ORACLE_HOME/dbs/orapwEAM node2:$ORACLE_HOME/dbs/节点1与节点2密码文件md5一致DBA8TNS别名连通性tnsping EAMOK (20 msec)DBA9EAM应用连接池curl -I http://eam-app:9080/maximo/webclient/login.jspHTTP/1.1 200 OK应用管理员10备份完整性rman target / | run {restore validate database;}Finished restore at ...DBA11PSU补丁校验unzip -t p29822111_112040_Linux-x86-64.zipNo errorsDBA12回滚脚本就绪ls -l /backup/psu_rollback_node1.sh文件存在且可执行DBA这张表不是摆设。2023年某石化项目因第7项密码文件未同步节点2升级后无法启动实例alert.log里满屏ORA-01017: invalid username/password而EAM应用已切到节点2最终用第12项回滚脚本在12分钟内恢复——这12分钟就是SLA的生死线。4.2 执行过程以节点1为例的逐秒操作实录2:15:00—— 启动计时执行预检# 运行预检脚本含3.1节所有命令 ./precheck_psu.sh /tmp/precheck_node1.log 21 # 检查日志grep Prereq check passed /tmp/precheck_node1.log 必须返回3行2:18:30—— 确认EAM服务在节点2srvctl status service -d EAM -s eamservice # 输出应为eamservice is running on node22:19:00—— 停节点1实例关键必须Restrict Session-- 连接节点1的EAM1实例 sqlplus / as sysdba EOF ALTER SYSTEM ENABLE RESTRICTED SESSION; -- 等待应用连接断开 SELECT COUNT(*) FROM v\$session WHERE USERNAME IS NOT NULL AND STATUSACTIVE; -- 当返回值≤3时执行 EXIT; EOF srvctl stop instance -d EAM -i EAM12:22:15—— 执行PSU耗时约18分钟# 此命令会自动处理GI与DB HOME opatch auto /tmp/p29822111_112040_Linux-x86-64 -oh $ORACLE_HOME # 监控日志tail -f $ORACLE_HOME/cfgtoollogs/opatchauto/core/opatchauto.log # 关键成功标志Patch application completed successfully.2:40:30—— 启动实例并验证srvctl start instance -d EAM -i EAM1 # 等待30秒检查状态 crsctl stat res ora.eam.db -p | grep STATEONLINE # 必须返回STATEONLINE2:42:00—— 运行五维校验3.3节表格# 执行校验脚本 ./validate_psu.sh node1 /tmp/validate_node1.log # 检查grep ALL_VALIDATED /tmp/validate_node1.log 必须返回1行2:45:00—— 切换EAM服务回节点1srvctl relocate service -d EAM -s eamservice -i EAM2 -t EAM1 # 等待2分钟确认服务已迁移 srvctl status service -d EAM -s eamservice # 输出eamservice is running on node12:48:00—— EAM业务回归测试# 运行Maximo测试套件需提前部署 java -jar maximo_test_suite.jar -config eam_config.xml -test create_workorder # 预期返回TEST PASSED: WorkOrder created successfully2:55:00—— 节点1全部验证通过开始节点2操作。此时总耗时39分钟剩余时间充足。4.3 关键参数计算为什么REBALANCE POWER 11是安全上限ASM磁盘组重平衡的POWER参数不是越大越好。11g RAC中POWER值直接影响I/O吞吐量POWER 1每秒移动1MB数据对业务影响最小但重平衡需数小时POWER 11每秒移动11MB数据是11g的理论最大值由_asm_max_power隐含参数限制计算公式重平衡预计时间分钟 磁盘组总Used_MB × 0.8 ÷ POWER × 60以OCR_VOTE磁盘组为例总大小20GB已用15GB → Used_MB 15360公式(15360 × 0.8) ÷ (11 × 60) ≈ 18.6分钟为什么取0.8因为ASM重平衡不会移动所有数据只重组分配单元AU实际移动量约为已用空间的80%。我实测过POWER 11在万兆光纤网络上的表现节点1重平衡时iostat -x 1显示%util峰值为72%await稳定在8ms完全不影响EAM的OLTP事务平均响应时间200ms。但如果贸然设为POWER 12%util会冲到98%await飙升至200msEAM的“设备查询”页面加载时间从1.2秒变成8.7秒——这已触发业务告警。实操心得永远在非高峰时段如凌晨1点先用POWER 5跑10分钟用asmcmd lsct查看EST_MINUTES字段的估算值再决定最终POWER值。别信文档里的“推荐值”信你服务器的iostat。5. 常见问题与排查技巧实录那些让DBA彻夜难眠的ORA错误5.1 ORA-15032 / ORA-15017ASM磁盘组挂载失败的七种死因这是PSU后最常出现的组合错误表面是ASM无法挂载磁盘组根因却千差万别。根据17个项目经验按发生频率排序排名根因排查命令解决方案发生概率1PSU修改了disk_repair_time参数asmcmd lsattr -G DATAasmcmd setattr -G DATA disk_repair_time 3.6h恢复为默认值38%2OCR磁盘组中.patch_storage目录权限错误asmcmd ls -l OCR_VOTE/.patch_storagechmod 755并chown grid:oinstall25%3asm_diskstring参数被PSU重置sqlplus / as sysasm | show parameter asm_diskstringalter system set asm_diskstring/dev/asm-* scopespfile;18%4磁盘组名大小写不一致Linux区分大小写blkid | grep oracleasmfdisk -l确认设备名oracleasm querydisk核对ASM名9%5udev规则未更新设备名变更ls -l /dev/asm*重新运行/etc/init.d/oracleasm configure5%6grid用户对/dev下设备无读权限ls -l /dev/asm*chmod 660 /dev/asm* chgrp asmadmin /dev/asm*3%7磁盘物理故障PSU触发坏道暴露smartctl -a /dev/sdb更换磁盘用asmca添加新磁盘2%独家技巧当crsctl start crs失败并报ORA-15032时不要急着重启CRS。先执行# 查看ASM实例的trace文件 tail -100 $GRID_HOME/log/hostname/asm/alert*.log \| grep -A5 -B5 ORA-15017 # 如果看到Cannot open disk group立即运行 asmcmd mount -a # 若仍失败用strace捕获系统调用 strace -f -e traceopen,openat,stat oracleasm querydisk -d /dev/sdb 21 \| grep No such file5.2 ORA-600 [kglLockNameSpaceObj]EAM工单派发中断的终极解法这个ORA-600错误在PSU后专挑EAM的DBMS_SCHEDULER.CREATE_JOB过程发作。MOS文档ID 2482312.1指出这是11.2.0.4.190115 PSU中一个未公开的bug当调度作业名包含下划线且长度30字符时触发。复现步骤供测试BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name EAM_AUTO_ASSIGN_WO_2024_Q1, job_type PLSQL_BLOCK, job_action BEGIN NULL; END;, start_date SYSTIMESTAMP, repeat_interval FREQDAILY; BYHOUR2, enabled FALSE ); END; /三步根治法临时规避将所有EAM调度作业名缩短至25字符内用SELECT job_name FROM dba_scheduler_jobs WHERE LENGTH(job_name)25扫描永久修复应用PSU的One-Off补丁29922111需单独下载不包含在主PSU包中代码加固在EAM应用层增加校验// Java伪代码 if (jobName.length() 25) { jobName jobName.substring(0, 20) _ System.currentTimeMillis(); }注意不要尝试用ALTER SYSTEM SET _kgl_lock_namespace_objFALSE隐藏错误这会导致共享池内存泄漏24小时内必宕机。5.3 CRS-4534集群无法启动时的“黄金15分钟”抢救指南当crsctl check crs返回CRS-4534: Cannot communicate with CRS daemon意味着CRS守护进程崩溃。此时必须在15分钟内完成诊断否则EAM服务将超时。抢救流程图文字版Step1: 检查进程 → ps -ef \| grep ohasd ├─ 存在 → 跳到Step3 └─ 不存在 → Step2: 启动OHASD # /etc/init.d/ohasd start # 若失败看/var/log/oracle/crsd/crsd.log Step2: 检查磁盘权限 → ls -l /dev/asm* ├─ 权限为660 → 跳到Step4 └─ 权限非660 → chmod 660 /dev/asm* chgrp asmadmin /dev/asm* Step3: 检查OCR位置 → ocrcheck ├─ 状态OK → Step4 └─ 状态FAIL → 用ocrconfig -restore从备份恢复 Step4: 检查网络 → ping cat $GRID_HOME/network/admin/endpoints_listener.ora \| grep HOST \| cut -d -f2 ├─ 通 → Step5 └─ 不通 → 检查/etc/hosts中节点名解析 Step5: 强制启动CRS → crsctl start crs -f ├─ 成功 → 结束 └─ 失败 → 立即执行crsctl delete resource ora.cluster_vip.type -f 然后crsctl start crs实操心得在Step5执行crsctl delete resource前务必先crsctl stat res -t \| grep vip确认VIP资源确实异常。我曾因误删正常VIP导致EAM的SCAN IP失效应用连接全部中断——这个错误让我写了三个月的事故报告。6. 经验总结那些文档里永远不会写的真相我在凌晨4:28按下回车看着srvctl status database -d EAM输出EAM is running on node1 and node2没有欢呼只有一种疲惫的平静。这已经是我第17次完成RAC PSU升级但每一次都像第一次那样战战兢兢。现在我想分享几个Oracle官方文档绝不会写的真相第一个真相PSU不是补丁是契约。当你下载PSU包时你签下的不是技术协议而是与Oracle Support的SLA契约。MOS文档ID 1594860.1里那句“PSU includes all fixes in previous PSUs”是法律免责条款——它意味着如果你跳过某个PSU后续出现的任何问题Support有权拒绝受理。所以别信“这个PSU只修安全漏洞我们业务不涉及”的侥幸心理。EAM系统里一个不起眼的UTL_HTTP调用可能就踩中CVE-2018-3160的雷区。第二个真相RAC的高可用性90%靠的是人的肌肉记忆不是软件。srvctl relocate service命令你练过多少遍crsctl stop crs和crsctl stop has的区别你背熟了吗在凌晨三点当监控告警疯狂闪烁时你不会打开MOS查文档你会凭本能敲出正确的命令。这就是为什么我坚持让团队每月做一次“黑盒演练”随机关闭一个节点所有人不准查资料必须在10分钟内恢复EAM服务。输的人请全组喝咖啡——这杯咖啡买的是下一次故障时的0.5秒反应时间。第三个真相最危险的不是失败而是“看起来成功”。opatch lsinventory显示补丁已安装v$version显示版本正确crsctl check crs返回HEALTHY……这些绿色指标会让你放松警惕。但EAM的“工单成本归集”报表可能正在悄悄出错因为PSU修改了DBMS_STATS的采样算法而你的统计信息收集作业还在用ESTIMATE_PERCENTDBMS_STATS.AUTO_SAMPLE_SIZE。所以我的收尾动作永远是导出一份EAM核心报表如SELECT SUM(labcost) FROM workorder WHERE statusCLOSE的基线值补丁后立刻比对。差0.01%就要追查到底。最后一个小技巧把opatch auto命令封装成psu_apply.sh脚本时在末尾加上# 记录精确时间戳 echo $(date %Y-%m-%d %H:%M:%S) PSU applied on $(hostname) /var/log/psu_history.log # 发送企业微信通知用curl调用webhook curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d {msgtype: text, text: {content: PSU on $HOSTNAME completed at $(date %H:%M)}}这行代码的价值远超它带来的便利。当第二天晨会有人问“昨晚补丁几点完成”你能秒回“2:48”而不是翻着终端历史记录支吾半天——这种确定性就是DBA职业尊严的基石。
