简介这份补丁包是 Oracle 11g Release 211.2.0.4针对 Windows x64 平台整理的 2022.10.18 补丁集合适用于仍需维护 11g 数据库的 DBA、运维人员及企业信息化团队目的是在系统升级到 12c/19c 之前持续修复已知漏洞、获得性能优化与安全增强。包体采用 RAR 压缩共 463 个文件总大小约 637.5MB。文件构成上以 jar、dll、exe 等程序与运行库为核心properties、xml、sh、bat、pm 等配置与脚本负责环境配置和命令执行md、txt 等文档提供补丁说明cacerts、cert 类文件与安全传输及证书校验相关。资源内置 OPatch 工具及 opatch.bat、oplan.bat 等脚本能够完成补丁应用、查询与验证。已有 2257 人学习/下载特别适合在生产环境升级前做补丁预演、环境排查及版本确认的 DBA。通过本包可以掌握 11.2.0.4 补丁集的实际目录结构与关键文件用途并结合 lsinventory 等命令验证补丁是否生效从而降低维护风险、提升数据库运行稳定性。1. 补丁包2022.10.18的Win64包到底是什么先搞清楚它解决什么周末晚上十点被电话叫起来说核心业务库出现ORA-600内部错误查了MOS发现是已知bug修复补丁正好包含在2022年10月18日发布的11.2.0.4季度补丁包里——这是很多老DBA的日常。这个标题指向的是Oracle 11.2.0.4在Windows 64位平台上的最新季度补丁包它聚合了数据库内核、Java组件OJVM和一批已知问题的修复一次apply就能把补丁基线拉到2022年10月。这篇文章面向两类人一类是刚接手11.2.0.4生产库、需要把补丁水平补齐的运维另一类是已经下载了补丁但不确定安装顺序和坑在哪的DBA。我会按准备、安装、验证、排错的顺序把这套流程完整拆开。2. 拆开2022.10.18的Win64补丁包PSU与RU的区别和三个前置条件2.1 PSU和RU你拿到的是整体包还是叠加包Oracle 11.2.0.4的季度补丁在官方体系里叫PSUPatch Set Update这套机制在12c以后演化为RURelease Update但在11.2.0.4上你看到的名字仍然是Database PSU。2022年10月18日是Oracle 2022年10月季度CPUCritical Patch Update的发布窗口这个日期对应的补丁包是一个完整的PSU基线它不是在一个旧补丁上叠加增量而是整体替换——新PSU包含了上一版PSU的全部修复内容。适用平台是Windows x64对应的补丁包格式是zip压缩包解压后会得到一个以补丁号命名的目录里面有etc、files、filesync目录以及README文本。判断你拿到的是单个PSU还是包含多个子补丁的组合包看README里的Bundled patches章节即可。2022年10月这个包通常包含Database PSU、OJVM PSU偶尔会带一个Windows平台专属的修复补丁。OJVM PSU针对的是Java虚拟机组件如果库上跑了Java存储过程或Oracle JVM相关功能比如Spatial的某些模块这个子补丁不能跳过。很多DBA只盯着数据库PSU忽略OJVM结果等保扫描或后续打WebLogic补丁时暴露版本不一致问题。需要注意的是11.2.0.4的Premier Support在2015年初就结束了Extended Support持续到2020年底。2022年还能产出补丁包说明这个版本处于持续支持Sustaining Support阶段或者你所在的单位购买了延长支持服务。不管渠道如何安装流程一致但有一点要清醒这个补丁包解决的是已知bug不是让11.2.0.4获得新功能。表 2-1 常见Oracle补丁类型对比补丁类型发布频率包含内容安装方式PSU每季度安全补丁 高影响bug修复整体替换opatch applyCPU每季度安全补丁为主常与PSU捆绑随PSU一并安装One-off随时单个bug修复可独立安装opatch applyBundle Patch不定期Windows平台特有按月/季度发布opatch apply2.2 打补丁前的基线检查把opatch lsinventory输出存好拿到补丁包先别急着解压安装。第一步是确认当前环境的补丁基线。Windows平台下以管理员身份打开cmd进入OPatch目录执行cd C:\app\oracle\product\11.2.0\dbhome_1\OPatch opatch.bat lsinventory C:\temp\inventory_before.txt这条命令会把当前ORACLE_HOME下所有已安装补丁、OPatch工具版本、系统信息全部写到文本文件里。我习惯把这份清单保留到补丁安装完因为后续对比“到底装上了什么”全靠它。如果之前已经存在某个旧PSU输出里会看到对应的PSU编号和Bundle series信息。11.2.0.4后期版本的PSU要求OPatch的最低版本比较高通常在11.2.0.3.31以上具体以补丁包README的Prerequisites章节为准。查看OPatch版本opatch.bat version如果版本不达标需要先从MOS单独下载OPatch工具包替换%ORACLE_HOME%\OPatch目录。替换前把原目录改名备份而不是直接删除这是避免把OPatch搞坏的保险动作。另外检查%ORACLE_HOME%\crs或者%ORACLE_HOME%\cfgtoollogs下有没有残留的安装会话文件如果有清空后再执行否则容易出现OPatch session already exists的报错。这条报错是11.2.0.4上最常见的翻车点之一本质是上一次异常退出留下的会话锁文件没有清理干净。2.3 备份与回退预案打补丁前的两件后悔药补丁安装本质上是替换ORACLE_HOME下的二进制文件同时向数据库字典里写入变更记录。一旦过程被中断最坏的情况不是补丁没打上而是ORACLE_HOME处于“半新半旧”状态服务起不来数据库打不开。所以备份不是可选项是必选项。第一件后悔药是备份ORACLE_HOME目录。Windows上直接复制整个dbhome_1目录到安全位置即可注意要包含dbs、network、OPatch子目录。11.2.0.4的ORACLE_HOME全量拷贝大约6-10GB视安装组件而定拷贝过程耗时十几分钟值得。如果你用的是虚拟化环境打补丁前做一次虚拟机快照是效率最高的方案回退只需一条命令。第二件后悔药是数据库层面的备份。最稳妥的流程是shutdown immediate后冷备数据文件和控制文件或者用RMAN做一次全备。注意生产环境里不是每次都能等到冷备窗口如果权衡后决定用RMAN在线备份那么补丁安装期间数据库必须是关闭的备份的意义在于“如果补丁把字典搞坏至少有份干净的备份可以恢复”。另外把第2.2节生成的inventory_before.txt打印一份放着回退时你要靠它确认“回到哪个补丁基线”。提示如果库里有大量失效对象建议在打补丁前先跑一遍utlrp.sql编译一次否则补丁后的字典升级会带着一堆失效对象跑最终状态更难判断是补丁导致还是原本就失效。3. Windows 64位平台补丁安装从停服务到catbundle的完整操作流3.1 停服务与设置环境变量Windows下打补丁的起手式Windows平台与Linux平台最大的区别在于服务模型。Linux上直接shutdown实例、srvctl stop监听即可Windows上必须通过net stop或服务管理器把Oracle相关的Windows服务停掉否则DLL文件被进程占用apply阶段报Error in writing或Access is denied是必然的。推荐的停服务顺序net stop OracleServiceORCL net stop OracleOraDb11g_home1TNSListener服务名可能因安装时的配置不同而有差异。OracleServiceORCL中的ORCL是数据库SIDOracleOraDb11g_home1TNSListener中的dbhome_1是ORACLE_HOME名称。如果机器上还有OEM代理服务OracleDBConsoleorcl一并停掉。用net stop停不掉的场景说明有进程还没释放文件不要硬敲先用tasklist | findstr /i oracle找到残留进程taskkill /F /PID 进程号强制结束。停完服务后设置环境变量。Windows上OPatch依赖ORACLE_HOME和ORACLE_SID两个变量在cmd里手动设置set ORACLE_HOMEC:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SIDORCL set PATH%ORACLE_HOME%\bin;%ORACLE_HOME%\OPatch;%PATH%为什么强调手动设置因为Windows服务启动时走的注册表路径与你cmd会话里的环境变量未必一致。如果安装时ORACLE_HOME路径是D:\oracle\product\11.2.0\dbhome_1而你手工起了一个cmd用默认的注册表变量OPatch会把补丁打到完全错误的位置。这类错误不常见但一旦发生代价是打错位置的补丁污染另一个环境的二进制文件。所以每次都echo %ORACLE_HOME%确认一次再动手。RAC环境走的是另一套流程srvctl stop database -d orcl -o immediate节点级补丁操作需配合crsctl维护资源。单实例环境不需要这么复杂但如果机器上同时装了11.2.0.4的多个ORACLE_HOME比如一套跑应用、一套跑仓库务必确认当前cmd会话里set的ORACLE_HOME指向你要打补丁的那套。3.2 opatch apply单补丁与批量补丁的命令差异把zip补丁包解压到一个不含空格的路径例如C:\patches\。注意补丁路径中如果包含中文或空格OPatch在解压文件时可能报莫名其妙的错误这是Windows平台的老毛病。解压后确认目录下只有一个补丁号文件夹进入OPatch目录执行cd %ORACLE_HOME%\OPatch opatch.bat apply C:\patches\34419486补丁号以你实际从MOS下载的编号为准上面命令里的34419486仅作示意。如果是包含多个子补丁的组合包有的补丁包要求使用opatch napply方式批量应用opatch.bat napply C:\patches -skip_subset -skip_duplicate-skip_subset和-skip_duplicate的含义分别是“跳过已包含在当前较高补丁中的条目”和“跳过已安装过的重复补丁”。用napply的场景通常是补丁包目录下放了多个独立的one-off补丁而标准PSU包直接用apply。apply过程的输出信息量很大核心是看几个节点。第一是Prerequisite check这一步会检查OPatch版本、前置补丁、环境变量是否齐全任何一项不通过都不建议用force强行绕过。第二是Applying patch这一步会逐条列出正在替换的文件。第三是最后的OPatch succeeded字样。当看到这个字样才意味着二进制层面安装成功。如果中途报错不要在同一会话里重复执行apply先执行opatch lsinventory看补丁是否残留了部分注册状态再做opatch rollback或清理会话锁文件。很多人在这一步栽跟头apply报告成功就认为补丁打完了直接启动服务。这恰恰漏掉了最关键的一步——数据字典更新。OPatch只负责替换文件数据库字典里的变更需要SQL脚本来完成也就是下一节的catbundle。3.3 catbundle.sql补丁生效的临门一脚二进制更新完成后启动数据库实例并执行catbundle脚本这一步的作用是把新版本的SYS对象、内部表和dba_registry_history记录同步到数据库字典中。如果不执行数据库可能启动正常但运行中会出现ORA-00600或PL/SQL包状态异常因为二进制版本和字典版本不匹配。net start OracleServiceORCL cd %ORACLE_HOME%\rdbms\admin sqlplus / as sysdbaSQL*Plus中的执行顺序startup catbundle.sql psu applycatbundle脚本执行过程中会出现大量Package created、Package body created的输出耗时通常在5-15分钟。执行完毕后退出SQL*Plus然后需要重新编译失效对象。补丁会致使部分存储在字典中的对象状态变为INVALID需要运行utlrp脚本cd %ORACLE_HOME%\rdbms\admin sqlplus / as sysdba utlrp.sqlutlrp脚本会返回失效对象的数量和编译结果通过查询dba_objects确认状态为VALID即可。需要注意catbundle执行时用的连接用户必须是SYS普通DBA账号没有权限更新字典基表很多报ORA-01031的问题就是在这个细节上翻车的。提示如果是12.1以上版本还需要处理多租户环境的PDB11.2.0.4没有这个困扰直接实例级执行即可。4. 补丁生效验证与五个高频坑监听、客户端和回退的那些事4.1 验证补丁是否生效三分钟检查法几杯茶的功夫就能完成验证。第一步看OPatch层面的补丁状态opatch.bat lsinventory C:\temp\inventory_after.txt对比第2.2节的inventory_before.txt确认新的PSU编号出现在列表里同时旧的PSU已经不在列表——因为新PSU是整体替代关系。第二步查数据库字典select action, comments, bundle_series, version from dba_registry_history where action like %PSU% order by action_time;如果bundle_series字段显示新的PSU编号说明catbundle脚本确实执行成功。第三步看数据库日志检查alert log里有没有ORA-00600、ORA-07445等内部错误顺便确认监听器状态lsnrctl status三分钟检查法重点在于“对比”而不是只看单条输出。曾经遇到一个案例应用侧反馈打完补丁后PL/SQL Developer连接报错ORA-28040查下来是服务端补丁升级后客户端版本太旧所致而OPatch和字典层面检查都是通过的。所以验证的范畴不只是数据库本身还包括周边客户端工具。表 4-1 补丁前后对照检查表检查项检查命令补丁前记录补丁后预期OPatch补丁列表opatch lsinventory旧PSU或空新PSU编号OPatch版本opatch version基线版本满足README要求字典版本dba_registry_history旧PSU记录新PSU bundle_series失效对象dba_objects原有失效数接近0监听状态lsnrctl status正常正常4.2 五个高频坑现象、原因与解决办法把这几年在11.2.0.4 Windows环境打补丁遇到的典型问题整理出来按“现象→原因→解决”三段式写方便直接对照。坑一apply到一半报“Access is denied”或文件被占用现象opatch apply执行到替换文件阶段报错提示某个exe或dll文件无法写入安装中断。原因Windows服务没有完全停止或者某个进程还持有Oracle文件的句柄——常见的元凶是OEM代理服务、数据库Console服务以及通过系统计划任务拉起的后台进程。解决不要反复重试apply先执行tasklist | findstr /i oracle查看残留进程逐条taskkill /F结束确认没有任何oracle开头的进程后清理会话锁文件再重新apply。坑二catbundle.sql执行时报ORA-00942或ORA-01219现象执行catbundle.sql psu apply时报ORA-00942: table or view does not exist或者ORA-01219: database not open。原因第一个报错通常是用非SYS用户执行了脚本或者数据库处于mount状态第二个报错是没先执行startup。解决切换到SYS用户确保数据库处于OPEN状态再执行。11.2.0.4没有PDB概念startup之后直接跑脚本不需要额外参数。坑三打补丁过程中失败回退时opatch rollback不干净现象apply失败后执行opatch rollback提示补丁未完全注册回退到一半卡住。原因OPatch的apply过程分阶段记录中途失败时可能部分文件已替换但部分尚未替换rollback只处理已注册的步骤导致文件状态处于新旧混合。解决如果操作前按照第2.3节备份了整个ORACLE_HOME目录最快的路径是直接停服务、用备份目录整体替换回原位置然后重新apply。不要纠结于用opatch把混合状态修回正常那是白白消耗时间。坑四打完补丁后PL/SQL Developer和自研Java程序连接报错现象服务端补丁成功但客户端连接报ORA-28040: No matching authentication protocol或ORA-03134。原因11.2.0.4的补丁包含安全增强会启用更严格的口令版本协商如果客户端用的是老版本PL/SQL Developer自带oci.dll或Java程序的ojdbc6.jar版本过旧与服务端握手失败。解决要么升级客户端组件到配套版本比如Kettle等工具里替换对应的ojdbc6.jar到11.2.0.4后续版本要么在服务端sqlnet.ora里临时设置SQLNET.ALLOWED_LOGON_VERSION_CLIENT8做兼容。后者是应急手段长期方案还是统一升级客户端驱动。坑五监听服务无法启动报TNS-01150现象补丁装完重启机器监听起不来报TNS-01150: The address specified is not valid或TNS-12541。原因监听配置文件listener.ora里的路径或者端口与补丁后的环境不一致常见于ORACLE_HOME路径包含版本号目录补丁升级时目录被重建导致监听指向失效。解决检查listener.ora里的ADR_BASE和LISTENER配置用lsnrctl start前台启动看详细报错修正路径后重启监听。这个问题和补丁本身关系不大但往往在补丁后的重启过程中被放大遇到时先看文件路径再怀疑补丁。5. 打过一次就够的补丁台账版本记录与下次升级的决策点5.1 用一张台账管住所有节点的补丁状态如果你手上不止一套数据库靠记忆记住每台机器打了哪个补丁是不现实的。我习惯在打补丁当天把关键信息落成一张表格放到专门的目录里表 5-1 补丁记录台账字段内容主机名db01-win数据库版本11.2.0.4.0SIDORCL补丁包2022.10.18 Win64 PSU补丁号以MOS下载为准OPatch版本11.2.0.3.31补丁前inventory文件C:\temp\inventory_before.txt补丁后inventory文件C:\temp\inventory_after.txt操作日期2023-xx-xx操作人自己每次等保检查或安全扫描时这张台账能直接回应“当前Oracle补丁水平是多少”的问题不需要重新登录每台机器去查。另一个小习惯是把catbundle执行后的dba_registry_history查询结果导出保存与台账放一起万一未来需要和第三方审计核对有据可查。5.2 11.2.0.4的补丁周期还能走多远规划升级比继续打补丁更重要坦白说11.2.0.4已经进入持续支持阶段补丁更新的频率和覆盖范围都在收缩。如果你手上有多个11.2.0.4实例且业务系统短期内无法升级那么把这个补丁包作为基线统一所有环境的补丁版本让运维口径保持一致是当前最务实的做法。但另一方面如果新项目还在选型数据库版本不要再新建11.2.0.4实例Oracle 19c是当前更合适的长期支持版本补丁机制也换成了更清晰的RU体系。回到标题本身2022.10.18这个补丁包给Windows 64位上的11.2.0.4提供了超出预期的续航能力。我个人的习惯是每次打完补丁把备份的ORACLE_HOME目录保留三个月再清理不急着删——有些问题要在业务高峰后才会浮出水面留着那份拷贝是最后的后悔药。希望这些步骤和踩坑记录能帮你把这个补丁包顺利装上少走几趟夜路。本文还有配套的精品资源点击获取 Oracle 11.2.0.4 Win64平台2022年10月PSU补丁安装实战指南
简介这份补丁包是 Oracle 11g Release 211.2.0.4针对 Windows x64 平台整理的 2022.10.18 补丁集合适用于仍需维护 11g 数据库的 DBA、运维人员及企业信息化团队目的是在系统升级到 12c/19c 之前持续修复已知漏洞、获得性能优化与安全增强。包体采用 RAR 压缩共 463 个文件总大小约 637.5MB。文件构成上以 jar、dll、exe 等程序与运行库为核心properties、xml、sh、bat、pm 等配置与脚本负责环境配置和命令执行md、txt 等文档提供补丁说明cacerts、cert 类文件与安全传输及证书校验相关。资源内置 OPatch 工具及 opatch.bat、oplan.bat 等脚本能够完成补丁应用、查询与验证。已有 2257 人学习/下载特别适合在生产环境升级前做补丁预演、环境排查及版本确认的 DBA。通过本包可以掌握 11.2.0.4 补丁集的实际目录结构与关键文件用途并结合 lsinventory 等命令验证补丁是否生效从而降低维护风险、提升数据库运行稳定性。1. 补丁包2022.10.18的Win64包到底是什么先搞清楚它解决什么周末晚上十点被电话叫起来说核心业务库出现ORA-600内部错误查了MOS发现是已知bug修复补丁正好包含在2022年10月18日发布的11.2.0.4季度补丁包里——这是很多老DBA的日常。这个标题指向的是Oracle 11.2.0.4在Windows 64位平台上的最新季度补丁包它聚合了数据库内核、Java组件OJVM和一批已知问题的修复一次apply就能把补丁基线拉到2022年10月。这篇文章面向两类人一类是刚接手11.2.0.4生产库、需要把补丁水平补齐的运维另一类是已经下载了补丁但不确定安装顺序和坑在哪的DBA。我会按准备、安装、验证、排错的顺序把这套流程完整拆开。2. 拆开2022.10.18的Win64补丁包PSU与RU的区别和三个前置条件2.1 PSU和RU你拿到的是整体包还是叠加包Oracle 11.2.0.4的季度补丁在官方体系里叫PSUPatch Set Update这套机制在12c以后演化为RURelease Update但在11.2.0.4上你看到的名字仍然是Database PSU。2022年10月18日是Oracle 2022年10月季度CPUCritical Patch Update的发布窗口这个日期对应的补丁包是一个完整的PSU基线它不是在一个旧补丁上叠加增量而是整体替换——新PSU包含了上一版PSU的全部修复内容。适用平台是Windows x64对应的补丁包格式是zip压缩包解压后会得到一个以补丁号命名的目录里面有etc、files、filesync目录以及README文本。判断你拿到的是单个PSU还是包含多个子补丁的组合包看README里的Bundled patches章节即可。2022年10月这个包通常包含Database PSU、OJVM PSU偶尔会带一个Windows平台专属的修复补丁。OJVM PSU针对的是Java虚拟机组件如果库上跑了Java存储过程或Oracle JVM相关功能比如Spatial的某些模块这个子补丁不能跳过。很多DBA只盯着数据库PSU忽略OJVM结果等保扫描或后续打WebLogic补丁时暴露版本不一致问题。需要注意的是11.2.0.4的Premier Support在2015年初就结束了Extended Support持续到2020年底。2022年还能产出补丁包说明这个版本处于持续支持Sustaining Support阶段或者你所在的单位购买了延长支持服务。不管渠道如何安装流程一致但有一点要清醒这个补丁包解决的是已知bug不是让11.2.0.4获得新功能。表 2-1 常见Oracle补丁类型对比补丁类型发布频率包含内容安装方式PSU每季度安全补丁 高影响bug修复整体替换opatch applyCPU每季度安全补丁为主常与PSU捆绑随PSU一并安装One-off随时单个bug修复可独立安装opatch applyBundle Patch不定期Windows平台特有按月/季度发布opatch apply2.2 打补丁前的基线检查把opatch lsinventory输出存好拿到补丁包先别急着解压安装。第一步是确认当前环境的补丁基线。Windows平台下以管理员身份打开cmd进入OPatch目录执行cd C:\app\oracle\product\11.2.0\dbhome_1\OPatch opatch.bat lsinventory C:\temp\inventory_before.txt这条命令会把当前ORACLE_HOME下所有已安装补丁、OPatch工具版本、系统信息全部写到文本文件里。我习惯把这份清单保留到补丁安装完因为后续对比“到底装上了什么”全靠它。如果之前已经存在某个旧PSU输出里会看到对应的PSU编号和Bundle series信息。11.2.0.4后期版本的PSU要求OPatch的最低版本比较高通常在11.2.0.3.31以上具体以补丁包README的Prerequisites章节为准。查看OPatch版本opatch.bat version如果版本不达标需要先从MOS单独下载OPatch工具包替换%ORACLE_HOME%\OPatch目录。替换前把原目录改名备份而不是直接删除这是避免把OPatch搞坏的保险动作。另外检查%ORACLE_HOME%\crs或者%ORACLE_HOME%\cfgtoollogs下有没有残留的安装会话文件如果有清空后再执行否则容易出现OPatch session already exists的报错。这条报错是11.2.0.4上最常见的翻车点之一本质是上一次异常退出留下的会话锁文件没有清理干净。2.3 备份与回退预案打补丁前的两件后悔药补丁安装本质上是替换ORACLE_HOME下的二进制文件同时向数据库字典里写入变更记录。一旦过程被中断最坏的情况不是补丁没打上而是ORACLE_HOME处于“半新半旧”状态服务起不来数据库打不开。所以备份不是可选项是必选项。第一件后悔药是备份ORACLE_HOME目录。Windows上直接复制整个dbhome_1目录到安全位置即可注意要包含dbs、network、OPatch子目录。11.2.0.4的ORACLE_HOME全量拷贝大约6-10GB视安装组件而定拷贝过程耗时十几分钟值得。如果你用的是虚拟化环境打补丁前做一次虚拟机快照是效率最高的方案回退只需一条命令。第二件后悔药是数据库层面的备份。最稳妥的流程是shutdown immediate后冷备数据文件和控制文件或者用RMAN做一次全备。注意生产环境里不是每次都能等到冷备窗口如果权衡后决定用RMAN在线备份那么补丁安装期间数据库必须是关闭的备份的意义在于“如果补丁把字典搞坏至少有份干净的备份可以恢复”。另外把第2.2节生成的inventory_before.txt打印一份放着回退时你要靠它确认“回到哪个补丁基线”。提示如果库里有大量失效对象建议在打补丁前先跑一遍utlrp.sql编译一次否则补丁后的字典升级会带着一堆失效对象跑最终状态更难判断是补丁导致还是原本就失效。3. Windows 64位平台补丁安装从停服务到catbundle的完整操作流3.1 停服务与设置环境变量Windows下打补丁的起手式Windows平台与Linux平台最大的区别在于服务模型。Linux上直接shutdown实例、srvctl stop监听即可Windows上必须通过net stop或服务管理器把Oracle相关的Windows服务停掉否则DLL文件被进程占用apply阶段报Error in writing或Access is denied是必然的。推荐的停服务顺序net stop OracleServiceORCL net stop OracleOraDb11g_home1TNSListener服务名可能因安装时的配置不同而有差异。OracleServiceORCL中的ORCL是数据库SIDOracleOraDb11g_home1TNSListener中的dbhome_1是ORACLE_HOME名称。如果机器上还有OEM代理服务OracleDBConsoleorcl一并停掉。用net stop停不掉的场景说明有进程还没释放文件不要硬敲先用tasklist | findstr /i oracle找到残留进程taskkill /F /PID 进程号强制结束。停完服务后设置环境变量。Windows上OPatch依赖ORACLE_HOME和ORACLE_SID两个变量在cmd里手动设置set ORACLE_HOMEC:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SIDORCL set PATH%ORACLE_HOME%\bin;%ORACLE_HOME%\OPatch;%PATH%为什么强调手动设置因为Windows服务启动时走的注册表路径与你cmd会话里的环境变量未必一致。如果安装时ORACLE_HOME路径是D:\oracle\product\11.2.0\dbhome_1而你手工起了一个cmd用默认的注册表变量OPatch会把补丁打到完全错误的位置。这类错误不常见但一旦发生代价是打错位置的补丁污染另一个环境的二进制文件。所以每次都echo %ORACLE_HOME%确认一次再动手。RAC环境走的是另一套流程srvctl stop database -d orcl -o immediate节点级补丁操作需配合crsctl维护资源。单实例环境不需要这么复杂但如果机器上同时装了11.2.0.4的多个ORACLE_HOME比如一套跑应用、一套跑仓库务必确认当前cmd会话里set的ORACLE_HOME指向你要打补丁的那套。3.2 opatch apply单补丁与批量补丁的命令差异把zip补丁包解压到一个不含空格的路径例如C:\patches\。注意补丁路径中如果包含中文或空格OPatch在解压文件时可能报莫名其妙的错误这是Windows平台的老毛病。解压后确认目录下只有一个补丁号文件夹进入OPatch目录执行cd %ORACLE_HOME%\OPatch opatch.bat apply C:\patches\34419486补丁号以你实际从MOS下载的编号为准上面命令里的34419486仅作示意。如果是包含多个子补丁的组合包有的补丁包要求使用opatch napply方式批量应用opatch.bat napply C:\patches -skip_subset -skip_duplicate-skip_subset和-skip_duplicate的含义分别是“跳过已包含在当前较高补丁中的条目”和“跳过已安装过的重复补丁”。用napply的场景通常是补丁包目录下放了多个独立的one-off补丁而标准PSU包直接用apply。apply过程的输出信息量很大核心是看几个节点。第一是Prerequisite check这一步会检查OPatch版本、前置补丁、环境变量是否齐全任何一项不通过都不建议用force强行绕过。第二是Applying patch这一步会逐条列出正在替换的文件。第三是最后的OPatch succeeded字样。当看到这个字样才意味着二进制层面安装成功。如果中途报错不要在同一会话里重复执行apply先执行opatch lsinventory看补丁是否残留了部分注册状态再做opatch rollback或清理会话锁文件。很多人在这一步栽跟头apply报告成功就认为补丁打完了直接启动服务。这恰恰漏掉了最关键的一步——数据字典更新。OPatch只负责替换文件数据库字典里的变更需要SQL脚本来完成也就是下一节的catbundle。3.3 catbundle.sql补丁生效的临门一脚二进制更新完成后启动数据库实例并执行catbundle脚本这一步的作用是把新版本的SYS对象、内部表和dba_registry_history记录同步到数据库字典中。如果不执行数据库可能启动正常但运行中会出现ORA-00600或PL/SQL包状态异常因为二进制版本和字典版本不匹配。net start OracleServiceORCL cd %ORACLE_HOME%\rdbms\admin sqlplus / as sysdbaSQL*Plus中的执行顺序startup catbundle.sql psu applycatbundle脚本执行过程中会出现大量Package created、Package body created的输出耗时通常在5-15分钟。执行完毕后退出SQL*Plus然后需要重新编译失效对象。补丁会致使部分存储在字典中的对象状态变为INVALID需要运行utlrp脚本cd %ORACLE_HOME%\rdbms\admin sqlplus / as sysdba utlrp.sqlutlrp脚本会返回失效对象的数量和编译结果通过查询dba_objects确认状态为VALID即可。需要注意catbundle执行时用的连接用户必须是SYS普通DBA账号没有权限更新字典基表很多报ORA-01031的问题就是在这个细节上翻车的。提示如果是12.1以上版本还需要处理多租户环境的PDB11.2.0.4没有这个困扰直接实例级执行即可。4. 补丁生效验证与五个高频坑监听、客户端和回退的那些事4.1 验证补丁是否生效三分钟检查法几杯茶的功夫就能完成验证。第一步看OPatch层面的补丁状态opatch.bat lsinventory C:\temp\inventory_after.txt对比第2.2节的inventory_before.txt确认新的PSU编号出现在列表里同时旧的PSU已经不在列表——因为新PSU是整体替代关系。第二步查数据库字典select action, comments, bundle_series, version from dba_registry_history where action like %PSU% order by action_time;如果bundle_series字段显示新的PSU编号说明catbundle脚本确实执行成功。第三步看数据库日志检查alert log里有没有ORA-00600、ORA-07445等内部错误顺便确认监听器状态lsnrctl status三分钟检查法重点在于“对比”而不是只看单条输出。曾经遇到一个案例应用侧反馈打完补丁后PL/SQL Developer连接报错ORA-28040查下来是服务端补丁升级后客户端版本太旧所致而OPatch和字典层面检查都是通过的。所以验证的范畴不只是数据库本身还包括周边客户端工具。表 4-1 补丁前后对照检查表检查项检查命令补丁前记录补丁后预期OPatch补丁列表opatch lsinventory旧PSU或空新PSU编号OPatch版本opatch version基线版本满足README要求字典版本dba_registry_history旧PSU记录新PSU bundle_series失效对象dba_objects原有失效数接近0监听状态lsnrctl status正常正常4.2 五个高频坑现象、原因与解决办法把这几年在11.2.0.4 Windows环境打补丁遇到的典型问题整理出来按“现象→原因→解决”三段式写方便直接对照。坑一apply到一半报“Access is denied”或文件被占用现象opatch apply执行到替换文件阶段报错提示某个exe或dll文件无法写入安装中断。原因Windows服务没有完全停止或者某个进程还持有Oracle文件的句柄——常见的元凶是OEM代理服务、数据库Console服务以及通过系统计划任务拉起的后台进程。解决不要反复重试apply先执行tasklist | findstr /i oracle查看残留进程逐条taskkill /F结束确认没有任何oracle开头的进程后清理会话锁文件再重新apply。坑二catbundle.sql执行时报ORA-00942或ORA-01219现象执行catbundle.sql psu apply时报ORA-00942: table or view does not exist或者ORA-01219: database not open。原因第一个报错通常是用非SYS用户执行了脚本或者数据库处于mount状态第二个报错是没先执行startup。解决切换到SYS用户确保数据库处于OPEN状态再执行。11.2.0.4没有PDB概念startup之后直接跑脚本不需要额外参数。坑三打补丁过程中失败回退时opatch rollback不干净现象apply失败后执行opatch rollback提示补丁未完全注册回退到一半卡住。原因OPatch的apply过程分阶段记录中途失败时可能部分文件已替换但部分尚未替换rollback只处理已注册的步骤导致文件状态处于新旧混合。解决如果操作前按照第2.3节备份了整个ORACLE_HOME目录最快的路径是直接停服务、用备份目录整体替换回原位置然后重新apply。不要纠结于用opatch把混合状态修回正常那是白白消耗时间。坑四打完补丁后PL/SQL Developer和自研Java程序连接报错现象服务端补丁成功但客户端连接报ORA-28040: No matching authentication protocol或ORA-03134。原因11.2.0.4的补丁包含安全增强会启用更严格的口令版本协商如果客户端用的是老版本PL/SQL Developer自带oci.dll或Java程序的ojdbc6.jar版本过旧与服务端握手失败。解决要么升级客户端组件到配套版本比如Kettle等工具里替换对应的ojdbc6.jar到11.2.0.4后续版本要么在服务端sqlnet.ora里临时设置SQLNET.ALLOWED_LOGON_VERSION_CLIENT8做兼容。后者是应急手段长期方案还是统一升级客户端驱动。坑五监听服务无法启动报TNS-01150现象补丁装完重启机器监听起不来报TNS-01150: The address specified is not valid或TNS-12541。原因监听配置文件listener.ora里的路径或者端口与补丁后的环境不一致常见于ORACLE_HOME路径包含版本号目录补丁升级时目录被重建导致监听指向失效。解决检查listener.ora里的ADR_BASE和LISTENER配置用lsnrctl start前台启动看详细报错修正路径后重启监听。这个问题和补丁本身关系不大但往往在补丁后的重启过程中被放大遇到时先看文件路径再怀疑补丁。5. 打过一次就够的补丁台账版本记录与下次升级的决策点5.1 用一张台账管住所有节点的补丁状态如果你手上不止一套数据库靠记忆记住每台机器打了哪个补丁是不现实的。我习惯在打补丁当天把关键信息落成一张表格放到专门的目录里表 5-1 补丁记录台账字段内容主机名db01-win数据库版本11.2.0.4.0SIDORCL补丁包2022.10.18 Win64 PSU补丁号以MOS下载为准OPatch版本11.2.0.3.31补丁前inventory文件C:\temp\inventory_before.txt补丁后inventory文件C:\temp\inventory_after.txt操作日期2023-xx-xx操作人自己每次等保检查或安全扫描时这张台账能直接回应“当前Oracle补丁水平是多少”的问题不需要重新登录每台机器去查。另一个小习惯是把catbundle执行后的dba_registry_history查询结果导出保存与台账放一起万一未来需要和第三方审计核对有据可查。5.2 11.2.0.4的补丁周期还能走多远规划升级比继续打补丁更重要坦白说11.2.0.4已经进入持续支持阶段补丁更新的频率和覆盖范围都在收缩。如果你手上有多个11.2.0.4实例且业务系统短期内无法升级那么把这个补丁包作为基线统一所有环境的补丁版本让运维口径保持一致是当前最务实的做法。但另一方面如果新项目还在选型数据库版本不要再新建11.2.0.4实例Oracle 19c是当前更合适的长期支持版本补丁机制也换成了更清晰的RU体系。回到标题本身2022.10.18这个补丁包给Windows 64位上的11.2.0.4提供了超出预期的续航能力。我个人的习惯是每次打完补丁把备份的ORACLE_HOME目录保留三个月再清理不急着删——有些问题要在业务高峰后才会浮出水面留着那份拷贝是最后的后悔药。希望这些步骤和踩坑记录能帮你把这个补丁包顺利装上少走几趟夜路。本文还有配套的精品资源点击获取