Oracle 11.2.0.4 Windows补丁实战：OPatch与PSU安装指南

简介面向仍在使用Oracle 11g R2、尚未升级到更高版本的Windows x64数据库管理员这份11.2.0.4最新补丁包2022.10.18用于完成安全修复、性能优化和已知问题修复是保障核心数据库系统安全性与稳定性的关键维护资源。包内专门集成了OPatch补丁管理工具及其完整运行环境共463个文件涵盖jar库文件、dll动态库、exe可执行程序、bat批处理脚本、properties配置文件和pl过程脚本等类型压缩包整体约637.5MB可支持管理员在Windows x64环境下对补丁进行安装、查询和回滚管理。已有2241人学习下载。凭借其中覆盖工具链、脚本和配置模板的完整文件体系读者能够在测试环境先行验证补丁再安全推广至生产库同时通过备份、日志检查等环节降低升级风险较大程度发挥11.2.0.4在性能与安全性方面的优化效果。 早上到公司群里就有人问“Windows Server上的Oracle 11.2.0.4补丁包到底要不要打”这个问题我熟。做过几年DBA的人都知道11.2.0.4是11g R2的最终补丁集版本大批老系统还跑在它上面而Windows x64平台又是补丁升级的“重灾区”文件占用、服务顺序、权限问题稍不留神就装一半卡死。标题里这个2022.10.18的Win64补丁包就是这类季度补丁里的一个代表我之前在生产环境完整走过一遍流程今天就把从认包、准备、打补丁到踩坑排查的完整过程整理出来给正在维护11.2.0.4 Windows库的朋友做个参考。1. 先把补丁包这事看明白1.1 11.2.0.4在Windows上为什么还是主流Oracle 11.2.0.4是Oracle 11g R2的最后一个补丁集版本很多企业核心业务系统这么多年没升级不是不想升而是业务软件兼容性、商务合同、历史包袱这些原因导致系统只能停留在11.2.0.4上。虽然版本老但官方仍然按季度发布关键补丁更新包括安全漏洞修复和问题修复。标题里的2022.10.18就是这类季度补丁的一个发布批次时间对应的安装包通常是面向Windows x6464位平台的PSU或OJVM补丁。版本老不代表可以不打补丁。数据库只要开放访问哪怕只在内网也可能因为已知漏洞被扫描到。就拿安全评估来说一个存在已知CVE的数据库就算业务稳定跑了三年评审时照样可能被判不合格。所以哪怕你短期不打算升级到12c或19c也建议把这个版本的关键补丁好好打上。1.2 补丁类型和文件名里的门道Oracle的补丁术语特别容易搞混我经常看到有人把PSU、CPU、RU混着说。简单梳理一下补丁类型全称特点PSUPatch Set Update累积型补丁包含一段时间内的重要修复和安全更新CPUCritical Patch Update后来的Security Patch Update偏重安全漏洞修复RURelease Update新版数据库12c以后的发布更新相当于PSU的替代OJVMOracle JVM Patch专门修复数据库内置JVM组件漏洞11.2.0.4在Windows平台最常见的是PSU和OJVM补丁。下载下来的文件名通常是类似“pXXXXXXX_112040_MSWIN-x86-64.zip”的格式。这里面p后面跟的是一串补丁号112040就是11.2.0.4版本MSWIN-x86-64代表Windows 64位平台。文件名里的日期不一定等于发布日期但往往对应补丁创建或针对的基准版本。拿到补丁包后第一件事永远是解压后先找README。所有前置要求、opatch版本限制、应用步骤、是否需要跑数据库脚本都写在README里。很多新手栽跟头就是不看文档直接跑命令。2. 动手之前这些检查一项都不能省2.1 核对OPatch版本和HOME环境Windows上打Oracle补丁第一个拦路虎就是OPatch版本。补丁包会对OPatch工具版本提出最低要求如果版本太旧apply命令直接拒绝执行报错类似“OPatch version cannot be less than...”。检查方式很简单set ORACLE_HOMED:\app\oracle\product\11.2.0\dbhome_1 %ORACLE_HOME%\OPatch\opatch.bat version再顺便看看当前实例装了哪些补丁%ORACLE_HOME%\OPatch\opatch.bat lsinventory如果OPatch版本不够需要单独下载对应版本的OPatch工具解压后覆盖到ORACLE_HOME下的OPatch目录。覆盖前一定先备份原目录这是我吃过亏后养成的习惯。新版OPatch覆盖后记得用上面的version命令确认版本号更新成功。这里还要强调一个Windows特定点所有操作都要用管理员身份打开命令提示符。别用普通用户窗口否则很多文件操作会以无权限告终。另外杀毒软件尽量把ORACLE_HOME和补丁解压目录加入白名单我遇到过360安全卫士把补丁释放的临时dll文件直接隔离导致安装进度卡住的情况。2.2 补丁冲突、空间和备份打补丁前检查磁盘空间这个容易被忽略。补丁包解压后可能占几个GB应用过程中还需要临时空间。你可以直接看ORACLE_HOME所在磁盘剩余空间建议至少保留补丁包体积两倍以上的剩余空间。接着检查补丁是否与现有环境冲突。在补丁解压目录下执行%ORACLE_HOME%\OPatch\opatch.bat prereq CheckConflictAgainstOHWithDetail -ph .如果输出没有冲突就可以继续。如果提示冲突需要确认当前已安装的补丁是否可以被新补丁替代或者是否需要先回滚某个旧补丁。这里不建议直接忽略冲突继续应用很容易造成组件版本不一致。备份环节Windows环境至少要做三件事第一数据库用RMAN或冷备份做一次完整备份第二把ORACLE_HOME目录完整复制一份到其他磁盘复制前先停数据库服务否则文件可能不一致第三记录当前的监听服务、数据库服务状态。别嫌麻烦真出问题的时候这些备份就是你的退路。3. 一步步把补丁打上去3.1 解压、环境变量和前置校验先把补丁zip包解压到无中文、无空格的路径比如D:\oracle_patch。目录路径里带有空格或中文个别工具解析会出问题。然后在同一个命令提示符窗口里设置环境变量set ORACLE_HOMED:\app\oracle\product\11.2.0\dbhome_1 set PATH%ORACLE_HOME%\bin;%ORACLE_HOME%\OPatch;%PATH%设置环境变量后最好确认一下当前实际生效的ORACLE_HOME是否是你想要打补丁的那个目录。Windows机器上经常存在多个Oracle软件目录PATH顺序不对就可能用错工具。接下来按README要求做前置校验。比如有些补丁要求先检查数据库组件是否有效用sqlplus执行select comp_id, status from dba_registry;如果存在无效的数据库组件先修复再打补丁不然脚本可能报错。这一步虽然费时间但能避免后续catbundle执行到一半失败。然后停止数据库相关服务。通过服务管理器或命令行停止OracleServiceSID和OracleOraDb11g_home1TNSListener。如果是测试环境可以直接用sqlplus执行shutdown immediate再停服务。注意顺序先停实例后停监听或者一起停都可以但确保两者都处于停止状态。3.2 opatch apply 全流程进入补丁解压目录执行应用命令%ORACLE_HOME%\OPatch\opatch.bat apply -verbose加-verbose参数可以输出更多日志方便定位。整个应用过程会逐文件更新Oracle Home中的二进制、dll、jar包耗时根据机器性能不同通常十几分钟到半小时不等。Windows平台常见报错是“Cannot create file”或“Permission denied”多半是权限不够或文件被占用。如果停了服务仍然报文件占用检查进程列表里是否有oracle.exe残留用任务管理器结束掉再重新试。还有一种情况是杀毒软件或Windows Defender在后台扫描把新增文件锁住了。如果补丁包里同时包含数据库基础补丁和OJVM补丁通常是先应用主补丁再应用OJVM补丁。具体顺序以README为准不要自己推测。安装完成后输出里一般会出现“OPatch succeeded”类似的成功标志。此时先不要急着启动数据库后面还有数据库层脚本要跑。3.3 数据库层脚本和验证对于包含数据库数据字典更新的补丁必须启动数据库后执行SQL脚本。11.2.0.4的PSU通常需要运行catbundle.sql。具体操作sqlplus / as sysdba SQL startup upgrade SQL ?/rdbms/admin/catbundle.sql PSU apply SQL shutdown immediate SQL startup为什么用startup upgrade因为补丁更新涉及数据字典版本变更普通模式启动会阻止部分系统对象的修改必须用升级模式启动。catbundle.sql会根据补丁发布日期调用对应的子脚本执行时间可能持续几十分钟日志里很多“Marking package invalid”之类的内容这是正常的。跑完后查看补丁是否进入数据库select * from registry$history; select version, status from dba_registry where comp_idCATALOG;能看到对应补丁记录说明补丁已经落库。如果补丁文档额外要求执行utlrp.sql重编译无效对象也别忘了跑。我见过有人补丁应用完忘了跑catbundle结果数据库内部版本还是旧的后续查询报错排查半天。4. 翻车现场常见问题与排查4.1 OPatch要求检查失败的几种情况整理一下我实际遇到的高频报错报错表现常见原因处理方法OPatch version cannot be less than XOPatch工具版本太低下载匹配的OPatch版本覆盖更新Patch is not applied / Requisite patches missing缺少前置补丁先安装README要求的依赖补丁Patch conflicts with another patch当前环境已有冲突补丁用prereq检查冲突详情决定是否回滚旧补丁Permission denied非管理员窗口或文件被占用以管理员重新运行检查oracle.exe进程遇到“Check failed”我的建议是先看日志文件一般在ORACLE_HOME\cfgtoollogs\opatch目录下里面会写具体哪个组件没通过检查。不要一上来就加-force强制忽略除非你非常清楚风险否则可能导致环境不可用。4.2 补丁后监听和连接异常打完补丁数据库能起来但应用连不上提示ORA-12514或ORA-12541这种问题十有八九出在监听上。处理方式很简单在命令提示符里重启监听lsnrctl stop lsnrctl start tnsping 服务名如果监听正常但连接仍失败看alert日志检查数据库是否注册到监听。可以执行show parameter local_listener;Windows上还要检查防火墙。有时候补丁安装过程会重置网络相关的系统配置导致1521端口从防火墙规则里消失。把防火墙临时关闭做定位确认是防火墙拦截后再补一条放行1521的入站规则即可。4.3 需要回滚怎么办补丁打出问题如果数据库脚本无法正常执行最坏情况就是回滚。数据库脚本和二进制补丁要分开回滚顺序不能反。先跑数据库脚本回滚再回滚二进制补丁。数据库侧通常是这样SQL startup upgrade SQL ?/rdbms/admin/catbundle.sql PSU rollback然后回到命令行执行%ORACLE_HOME%\OPatch\opatch.bat rollback -id 补丁号回滚报错多数还是文件占用或权限问题检查数据库服务和监听是否完全停止。如果回滚过程中数据字典已经产生部分修改痕迹回滚未必能完全复原。所以在生产环境我遇到回滚方案不清晰时往往直接选择从之前做好的备份恢复反而更快更放心。这也是为什么前面反复强调备份的重要性。5. 经验补遗Windows平台打补丁的细节5.1 选窗口、留后路、记日志补丁升级尽量选业务低峰期别挤在月底结账或批量跑批的时间段。一个补丁加验证预留半天比较稳妥不要想着两小时搞定。另外整个操作过程建议把命令输出同时保存到文件%ORACLE_HOME%\OPatch\opatch.bat apply -verbose D:\oracle_patch\apply_log.txt 21这样即使当时没仔细看屏幕输出事后也能从日志里找到具体错误信息。打完补丁后旧OPatch目录、解压的补丁包都先保留两周确认生产运行稳定后再清理。别急着删东西Windows下很多隐藏问题要过几天才暴露。5.2 从11.2.0.1升级到11.2.0.4的提醒如果你还停留在11.2.0.1先别碰11.2.0.4的季度补丁包直接应用的话大概率报版本不符合。正确路径是先把数据库软件升级到11.2.0.4基础版本再做补丁更新。Windows上安装11.2.0.4软件时如果旧版本也在可以采用新ORACLE_HOME方式安装保留旧环境然后跑升级脚本。升级完成后再应用2022.10.18这个批次的补丁一步到位。直接拿补丁包当升级包用是行不通的。5.3 最后分享一个小习惯我每次在Windows上打补丁前习惯先打开注册表编辑器检查HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE下的ORACLE_HOME键值是否和环境变量一致。Windows平台的Oracle服务启动依赖注册表路径而不只是PATH。偶尔会遇到环境变量指向新路径但注册表还残留旧路径的情况补丁工具会找错地方报一些莫名其妙的错误。把这个检查变成固定动作后我在Windows上打Oracle补丁的失败率明显降下来了。这几个细节希望对正在折腾11.2.0.4补丁的朋友有帮助。本文还有配套的精品资源点击获取