简介Oracle 数据库 11.2.0.4 版本的 PSU 补丁包补丁编号 p33477185发布于 2022 年 1 月专为 Linux x86-64 平台设计。面向数据库管理员与系统运维人员用于修复已知安全漏洞、提升数据库稳定性与运行性能是保持生产环境数据库健康运行的关键更新组件。压缩包共含 3658 个文件整体约 436.52MB以动态库so、目标文件o、XML 元数据、SQL 脚本及 JAR 组件为主其中 PatchSearch.xml 记录了补丁元数据与安装条件SQL 与 PLB 文件用于执行数据字典更新各类二进制库则保障与现有数据库环境的完整兼容。目前已有 850 人学习下载。安装后可获得完整的 OPatch 补丁应用支持体系涵盖补丁本体、依赖校验信息、安装脚本及配套配置模板能够帮助 DBA 在离线或内网环境下完成补丁部署、验证与回滚准备尤其适合需要定期维护 Oracle 11g 生产库的技术团队参考使用。2022年初的11.2.0.4最终PSU补丁p33477185安装全记录老库用户看到这串字符应该很眼熟DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64。没错这就是Oracle 11.2.0.4在2022年1月发布的季度PSU补丁包补丁号p33477185适用于Linux x86-64平台。11.2.0.4这个版本属于Oracle Database的“超长待机”版本官方支持早就结束但企业生产环境里还在跑的数量相当可观。这篇文章就把这次打补丁的完整过程记录下来从补丁包命名规则到安装细节再到回滚方案给还在维护11.2.0.4的兄弟们一个参考。如果你是刚接手老库的运维或者正在为等保、审计要求补丁版本头疼这篇文章正好可以当作一份操作手册来用。1. 补丁包基本信息与命名规则拆解1.1 文件名里藏着的所有信息先把这个长文件名拆开看每个字段都有实际意义DB-PSUDatabase Patch Set Update数据库补丁集更新Oracle在季度补丁计划中发布的常规补丁类型。11.2.0.4数据库版本号对应Oracle Database 11g Release 2的最后一个基础版本。220118补丁发布日期即2022年1月18日。Oracle的季度补丁一般在1月、4月、7月、10月的中间周发布。p33477185补丁唯一编号Oracle内部MOS文档中通过这个编号检索补丁信息和Readme。Linux-x86-64平台标识指Linux 64位x86架构对应Oracle支持的Linux x86-64平台。这套命名规则从10g时代延续至今理解之后看到任何PSU补丁包都能一眼判断版本和平台是否匹配。比如DB-PSU-11.2.0.4.221018就是2022年10月的补丁补丁号变了但结构完全一致。1.2 PSU与CPU、SPU的关系很多刚接触Oracle补丁的人容易被CPU、PSU、SPU这几个缩写搞晕。简单梳理一下CPUCritical Patch UpdateOracle每季度发布的安全补丁更新修复安全漏洞名字后来改成了SPUSecurity Patch Update。PSUPatch Set Update在CPU基础上额外包含一些重要的非安全修复Bug Fix同时包含了上一个PSU以来的全部修复内容。两者关系PSU是CPU的超集。打了最新PSU等于同时拥有了最新CPU的安全修复和一批经过验证的功能修复。11.2.0.4这个版本比较特殊Oracle在扩展支持阶段持续发布了PSU补丁直到2022年1月这个p33477185基本算是该版本的收官之作了。对于还在跑11.2.0.4的环境这个补丁应该是最后一个值得打的PSU后面再出补丁也是安全补丁为主。1.3 为什么建议升级到这一版我在生产环境维护的几套11.2.0.4数据库之前一直停在2021年7月的补丁版本。这次升级到2022年1月版主要考虑了三个因素安全漏洞修复2021年底到2022年初暴露了几个值得关注的安全漏洞PSU补丁里包含了对应的修复。稳定性改进官方Release Notes里列出了几十个Bug修复覆盖了RAC节点间通信、AWR报表生成、SQL执行计划异常等问题我这边正好有两个AWR相关的小问题长期存在值得一试。合规要求等保测评和内部安全审计对数据库补丁版本有硬性要求超过一年的补丁滞后会被判定为高风险项。如果你是异地灾备环境或者升级到19c的过渡期在11.2.0.4上打这个补丁也是合理的过渡步骤。不过要提醒一句别指望这个补丁解决所有性能问题它主要修复的是安全和稳定性问题SQL性能问题通常需要单独排查。2. 安装前的准备工作关键检查项与补丁依赖2.1 补丁包下载与解压补丁包从Oracle SupportMOS下载文档ID 33477185就是补丁的检索入口。下载时注意选择正确的平台Linux x86-64对应的文件就是本文标题中的这个包。补丁包大小约200MB左右下载完成后用unzip解压会得到一个以补丁号命名的目录33477185。解压后建议核对一下校验值官方页面会提供MD5或SHA-1校验值用md5sum命令验证一下避免下载损坏。这一步容易被忽略但一旦补丁包损坏安装过程中报莫名其妙的错误排查起来非常折磨。2.2 OPatch工具版本检查PSU补丁安装强依赖OPatch工具版本。在11.2.0.4上OPatch最低要求是11.2.0.3.6推荐升级到更高版本。检查当前OPatch版本cd $ORACLE_HOME/OPatch ./opatch version我当时的环境输出为OPatch Version: 11.2.0.3.4低于最低要求所以先下载了OPatch工具更新包p6880880_112000_Linux-x86-64.zip将OPatch目录替换为最新版本。OPatch升级替换步骤cd $ORACLE_HOME mv OPatch OPatch_bak_$(date %Y%m%d) unzip /tmp/p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME # 检查权限确认opatch可执行 $ORACLE_HOME/OPatch/opatch version实测下来OPatch版本升级本身不会影响数据库运行但做之前还是建议把OPatch原目录备份一下防止意外。2.3 补丁依赖检查与冲突判断11.2.0.4的PSU补丁依赖常常包括前序补丁。p33477185的Readme中明确列出了前置补丁要求我在安装前用opatch prereqCheck命令去验证过cd $ORACLE_HOME ./OPatch/opatch prereq CheckApplicable -phBaseDir /u01/software/33477185这条命令会检查补丁是否可应用、是否存在依赖缺失、是否有冲突。如果检查结果出现“Warning”需要仔细查看具体原因避免直接安装导致失败。我遇到过一次“Requires the base bug fix for 1234567”的提示说明还缺一个前置补丁需要一并下载安装。2.4 数据库环境备份与停机准备任何补丁操作前备份永远是第一优先级。在数据库层面我的做法是使用RMAN备份数据库至少备份system、sysaux和undo表空间备份Oracle Home下的dbs、network和sqlplus相关配置记录当前数据库版本、PSU版本和关键初始化参数# RMAN增量备份示例全备归档根据生产环境调整 rman target / RMAN backup database plus archivelog delete input;在停机窗口方面单实例环境需要完全停库RAC环境可以逐节点滚动但实际操作时我一般还是选择在维护窗口内完成所有节点。检查清单上的每项都确认无误后再开始正式安装。3. 补丁安装详细步骤与核心环节实现3.1 停止数据库实例和监听补丁安装过程中需要替换Oracle Home中的二进制文件因此必须停止所有使用该Oracle Home的进程和数据库实例。# 切换环境变量 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export ORACLE_SIDORCL # 关闭监听 lsnrctl stop # 关闭数据库实例 sqlplus / as sysdba SQL shutdown immediate;shutdown immediate会等待当前事务完成并回滚未提交事务正常生产库通常几分钟内就能关闭。如果出现长时间无法关闭检查是否存在活动会话可以用shutdown abort兜底但重启恢复时需要做实例恢复时间上会更久一些。3.2 正式执行opatch apply执行补丁安装命令cd /u01/software/33477185 $ORACLE_HOME/OPatch/opatch applyopatch apply执行过程分几个阶段前置检查再次确认补丁适用性、冲突和依赖文件替换将JAR包、二进制文件、脚本等替换为新版本这个过程会输出大量日志后置检查确认所有文件替换正确整个过程大约需要20到30分钟取决于服务器磁盘IO性能。中途不要中断进程否则可能导致Oracle Home处于不一致状态。我当时的环境是普通SATA盘完整跑完大概是27分钟。安装成功后opatch会输出“OPatch succeeded”字样。此时可以先用opatch lsinventory确认补丁列表$ORACLE_HOME/OPatch/opatch lsinventory在输出列表中能看到补丁33477185状态为applied。3.3 执行数据字典升级脚本二进制补丁装完后还需要将补丁中的SQL变更应用到数据库数据字典。这一步是关键中的关键漏掉会导致数据库版本信息不一致后续可能出现异常。Oracle为PSU补丁提供了catbundle.sql脚本位置在$ORACLE_HOME/rdbms/admin。先启动数据库到升级模式sqlplus / as sysdba SQL startup upgrade;然后执行SQL ?/rdbms/admin/catbundle.sql PSU apply这个脚本会创建PSU应用记录表、执行数百个SQL变更、更新数据字典中的版本信息耗时通常10到20分钟。执行完成后重启数据库到正常模式SQL shutdown immediate; SQL startup;最后验证版本信息SQL select * from dba_registry_history where actionAPPLY order by action_time;正常输出能看到一条2022年1月PSU的应用记录对应补丁号33477185。这个表记录的信息在后续排查问题时非常有用。注意补丁Readme中强调catbundle.sql必须以sys用户执行且数据库启动到upgrade模式。如果跳过这一步骤下次运行catproc或其他升级脚本时可能报很多兼容性错误。3.4 重新编译失效对象停库、升级数据字典之后通常会出现一些失效的PL/SQL对象。重启数据库完成后用utlrp.sql重建失效对象SQL ?/rdbms/admin/utlrp.sql然后在执行完后检查失效对象数量SQL select count(*) from dba_objects where statusINVALID;正常情况下失效对象数量应为0。如果还有残存失效对象查看具体对象名称多数是因为依赖的包未完全编译再次执行utlrp.sql通常能解决。3.5 RAC环境下的特别注意点如果你的环境是RAC补丁安装过程会稍有不同。11.2.0.4的PSU补丁在RAC环境中支持滚动安装即逐个节点打补丁但需要注意第一个节点执行opatch apply时使用-rolling参数数据字典脚本只在最后一个节点执行一次每个节点都要替换OPatch版本并执行opatch apply滚动期间数据库可以保持对外服务但跨节点访问的会话会短暂中断我的实际经历是两节点RAC在业务低谷期逐节点打补丁整个过程约1.5小时业务无感知。但操作复杂度相对单实例高不少对RAC架构不够熟练的话建议还是全部节点停库后在维护窗口内完成。4. 补丁安装常见问题与排查实录4.1 OPatch版本过低导致apply失败最常见的坑就是OPatch版本过低。我在另一台测试机上直接跑opatch apply报错信息大概是“OPatch version 11.2.0.3.4 below the minimum required version 11.2.0.3.6”。这种问题解决起来简单提前下载p6880880升级即可。不要试图绕过这个检查否则后续可能遇到文件替换不完整的问题。4.2 前置补丁未安装导致检查不通过opatch apply的prereq阶段如果报“Missing required patch”说明缺少某个前置补丁。此时不要强行用-opatch_skip_prereq跳过尤其是在依赖补丁涉及安全修复的情况下。正确做法是按Readme要求下载对应前置补丁并安装再重新执行opatch apply。4.3 磁盘空间不足导致补丁应用失败补丁解压和安装过程占用空间不小。p33477185解压后约500MB加上Oracle Home的备份空间至少预留2GB以上。我遇到过/tmp目录空间不足导致opatch apply中断的情况建议提前检查四类空间/tmp至少1GB可用Oracle Home所在分区至少1GB补丁目录所在分区至少1GB归档日志目录确保补丁期间归档不会撑满磁盘4.4 跑catbundle.sql时遇到ORA-04021或ORA-04031ORA-04021代表对象被其他会话锁定ORA-04031代表共享池内存不足。排查方法确认没有其他会话在执行DDL或编译操作关闭其他数据库实例确保是单实例访问如果仍然报ORA-04031重启数据库实例后再以upgrade模式启动增加共享池大小SQL startup upgrade; SQL alter system set shared_pool_size500M scopeboth; SQL ?/rdbms/admin/catbundle.sql PSU apply4.5 补丁应用后数据库版本信息不一致有时opatch lsinventory显示补丁已应用但dba_registry_history表中没有对应记录因为漏跑了catbundle.sql。如果遇到这种情况不需要重新打一遍补丁只需启动到upgrade模式再执行一遍catbundle.sql即可。这个方法我实际验证过数据字典版本能正确更新到与二进制版本一致。整理成速查表更直观问题报错特征解决方法OPatch版本不够opatch version低于11.2.0.3.6下载p6880880替换OPatch前置补丁缺失Missing required patch按Readme下载前缀补丁安装/tmp空间不足No space left on device清理/tmp或设置TMPDIR到大数据盘数据字典版本不更新dba_registry_history无记录执行catbundle.sql PSU apply失效对象残留utlrp后仍有INVALID对象重跑utlrp或单独编译依赖对象5. 回滚方案与安装后的验证清单5.1 opatch rollback与数据库回滚如果补丁安装过程中出现严重问题可以考虑回滚。二进制层面的回滚方式$ORACLE_HOME/OPatch/opatch rollback -id 33477185但如果已经执行过catbundle.sql回滚就不是简单一个命令能搞定的了。数据字典的变更不能自动回滚需要从备份中恢复数据库或使用降级脚本。实际操作中在补丁安装前做全备是唯一靠谱的回滚方案一定要形成习惯。我的建议是在打PSU补丁前使用RMAN全备并备份归档日志同时使用expdp导出关键业务schema双保险。5.2 安装后验证清单补丁装完重启数据库建议按以下清单逐项验证确认无误后再恢复业务流量检查各实例告警日志alert_*.log末尾确认无ORA-600等内部错误检查监听状态和服务注册lsnrctl status检查关键业务会话能否正常连接和查询检查dba_registry_history中PSU记录是否正确检查dba_objects中失效对象数量是否为0如有Data Guard环境确认备库同步正常检查完这些项基本可以确认本次补丁安装操作完成。6. 写在最后的一点经验11.2.0.4这个版本我从2015年用到现在大大小小的补丁打了不下十轮每次过程都有微小的不同但核心流程始终是那几步下载、备份、检查、安装、验证。p33477185作为该版本的2022年1月PSU在安装过程中没有遇到什么特别棘手的问题整个流程走下来和以往PSU安装基本一致。唯一要提醒的是11.2.0.4已处于扩展支持后期如果条件允许建议尽快规划升级到19c或21c毕竟版本越老出问题时能借力的资源就越少。如果这篇文章能帮你在下次打补丁时少走一步弯路那就值了。遇到具体问题可以留言一起讨论数据库补丁安装这事细节太多了。本文还有配套的精品资源点击获取 Oracle 11.2.0.4 PSU p33477185补丁安装实战与回滚全记录
简介Oracle 数据库 11.2.0.4 版本的 PSU 补丁包补丁编号 p33477185发布于 2022 年 1 月专为 Linux x86-64 平台设计。面向数据库管理员与系统运维人员用于修复已知安全漏洞、提升数据库稳定性与运行性能是保持生产环境数据库健康运行的关键更新组件。压缩包共含 3658 个文件整体约 436.52MB以动态库so、目标文件o、XML 元数据、SQL 脚本及 JAR 组件为主其中 PatchSearch.xml 记录了补丁元数据与安装条件SQL 与 PLB 文件用于执行数据字典更新各类二进制库则保障与现有数据库环境的完整兼容。目前已有 850 人学习下载。安装后可获得完整的 OPatch 补丁应用支持体系涵盖补丁本体、依赖校验信息、安装脚本及配套配置模板能够帮助 DBA 在离线或内网环境下完成补丁部署、验证与回滚准备尤其适合需要定期维护 Oracle 11g 生产库的技术团队参考使用。2022年初的11.2.0.4最终PSU补丁p33477185安装全记录老库用户看到这串字符应该很眼熟DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64。没错这就是Oracle 11.2.0.4在2022年1月发布的季度PSU补丁包补丁号p33477185适用于Linux x86-64平台。11.2.0.4这个版本属于Oracle Database的“超长待机”版本官方支持早就结束但企业生产环境里还在跑的数量相当可观。这篇文章就把这次打补丁的完整过程记录下来从补丁包命名规则到安装细节再到回滚方案给还在维护11.2.0.4的兄弟们一个参考。如果你是刚接手老库的运维或者正在为等保、审计要求补丁版本头疼这篇文章正好可以当作一份操作手册来用。1. 补丁包基本信息与命名规则拆解1.1 文件名里藏着的所有信息先把这个长文件名拆开看每个字段都有实际意义DB-PSUDatabase Patch Set Update数据库补丁集更新Oracle在季度补丁计划中发布的常规补丁类型。11.2.0.4数据库版本号对应Oracle Database 11g Release 2的最后一个基础版本。220118补丁发布日期即2022年1月18日。Oracle的季度补丁一般在1月、4月、7月、10月的中间周发布。p33477185补丁唯一编号Oracle内部MOS文档中通过这个编号检索补丁信息和Readme。Linux-x86-64平台标识指Linux 64位x86架构对应Oracle支持的Linux x86-64平台。这套命名规则从10g时代延续至今理解之后看到任何PSU补丁包都能一眼判断版本和平台是否匹配。比如DB-PSU-11.2.0.4.221018就是2022年10月的补丁补丁号变了但结构完全一致。1.2 PSU与CPU、SPU的关系很多刚接触Oracle补丁的人容易被CPU、PSU、SPU这几个缩写搞晕。简单梳理一下CPUCritical Patch UpdateOracle每季度发布的安全补丁更新修复安全漏洞名字后来改成了SPUSecurity Patch Update。PSUPatch Set Update在CPU基础上额外包含一些重要的非安全修复Bug Fix同时包含了上一个PSU以来的全部修复内容。两者关系PSU是CPU的超集。打了最新PSU等于同时拥有了最新CPU的安全修复和一批经过验证的功能修复。11.2.0.4这个版本比较特殊Oracle在扩展支持阶段持续发布了PSU补丁直到2022年1月这个p33477185基本算是该版本的收官之作了。对于还在跑11.2.0.4的环境这个补丁应该是最后一个值得打的PSU后面再出补丁也是安全补丁为主。1.3 为什么建议升级到这一版我在生产环境维护的几套11.2.0.4数据库之前一直停在2021年7月的补丁版本。这次升级到2022年1月版主要考虑了三个因素安全漏洞修复2021年底到2022年初暴露了几个值得关注的安全漏洞PSU补丁里包含了对应的修复。稳定性改进官方Release Notes里列出了几十个Bug修复覆盖了RAC节点间通信、AWR报表生成、SQL执行计划异常等问题我这边正好有两个AWR相关的小问题长期存在值得一试。合规要求等保测评和内部安全审计对数据库补丁版本有硬性要求超过一年的补丁滞后会被判定为高风险项。如果你是异地灾备环境或者升级到19c的过渡期在11.2.0.4上打这个补丁也是合理的过渡步骤。不过要提醒一句别指望这个补丁解决所有性能问题它主要修复的是安全和稳定性问题SQL性能问题通常需要单独排查。2. 安装前的准备工作关键检查项与补丁依赖2.1 补丁包下载与解压补丁包从Oracle SupportMOS下载文档ID 33477185就是补丁的检索入口。下载时注意选择正确的平台Linux x86-64对应的文件就是本文标题中的这个包。补丁包大小约200MB左右下载完成后用unzip解压会得到一个以补丁号命名的目录33477185。解压后建议核对一下校验值官方页面会提供MD5或SHA-1校验值用md5sum命令验证一下避免下载损坏。这一步容易被忽略但一旦补丁包损坏安装过程中报莫名其妙的错误排查起来非常折磨。2.2 OPatch工具版本检查PSU补丁安装强依赖OPatch工具版本。在11.2.0.4上OPatch最低要求是11.2.0.3.6推荐升级到更高版本。检查当前OPatch版本cd $ORACLE_HOME/OPatch ./opatch version我当时的环境输出为OPatch Version: 11.2.0.3.4低于最低要求所以先下载了OPatch工具更新包p6880880_112000_Linux-x86-64.zip将OPatch目录替换为最新版本。OPatch升级替换步骤cd $ORACLE_HOME mv OPatch OPatch_bak_$(date %Y%m%d) unzip /tmp/p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME # 检查权限确认opatch可执行 $ORACLE_HOME/OPatch/opatch version实测下来OPatch版本升级本身不会影响数据库运行但做之前还是建议把OPatch原目录备份一下防止意外。2.3 补丁依赖检查与冲突判断11.2.0.4的PSU补丁依赖常常包括前序补丁。p33477185的Readme中明确列出了前置补丁要求我在安装前用opatch prereqCheck命令去验证过cd $ORACLE_HOME ./OPatch/opatch prereq CheckApplicable -phBaseDir /u01/software/33477185这条命令会检查补丁是否可应用、是否存在依赖缺失、是否有冲突。如果检查结果出现“Warning”需要仔细查看具体原因避免直接安装导致失败。我遇到过一次“Requires the base bug fix for 1234567”的提示说明还缺一个前置补丁需要一并下载安装。2.4 数据库环境备份与停机准备任何补丁操作前备份永远是第一优先级。在数据库层面我的做法是使用RMAN备份数据库至少备份system、sysaux和undo表空间备份Oracle Home下的dbs、network和sqlplus相关配置记录当前数据库版本、PSU版本和关键初始化参数# RMAN增量备份示例全备归档根据生产环境调整 rman target / RMAN backup database plus archivelog delete input;在停机窗口方面单实例环境需要完全停库RAC环境可以逐节点滚动但实际操作时我一般还是选择在维护窗口内完成所有节点。检查清单上的每项都确认无误后再开始正式安装。3. 补丁安装详细步骤与核心环节实现3.1 停止数据库实例和监听补丁安装过程中需要替换Oracle Home中的二进制文件因此必须停止所有使用该Oracle Home的进程和数据库实例。# 切换环境变量 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export ORACLE_SIDORCL # 关闭监听 lsnrctl stop # 关闭数据库实例 sqlplus / as sysdba SQL shutdown immediate;shutdown immediate会等待当前事务完成并回滚未提交事务正常生产库通常几分钟内就能关闭。如果出现长时间无法关闭检查是否存在活动会话可以用shutdown abort兜底但重启恢复时需要做实例恢复时间上会更久一些。3.2 正式执行opatch apply执行补丁安装命令cd /u01/software/33477185 $ORACLE_HOME/OPatch/opatch applyopatch apply执行过程分几个阶段前置检查再次确认补丁适用性、冲突和依赖文件替换将JAR包、二进制文件、脚本等替换为新版本这个过程会输出大量日志后置检查确认所有文件替换正确整个过程大约需要20到30分钟取决于服务器磁盘IO性能。中途不要中断进程否则可能导致Oracle Home处于不一致状态。我当时的环境是普通SATA盘完整跑完大概是27分钟。安装成功后opatch会输出“OPatch succeeded”字样。此时可以先用opatch lsinventory确认补丁列表$ORACLE_HOME/OPatch/opatch lsinventory在输出列表中能看到补丁33477185状态为applied。3.3 执行数据字典升级脚本二进制补丁装完后还需要将补丁中的SQL变更应用到数据库数据字典。这一步是关键中的关键漏掉会导致数据库版本信息不一致后续可能出现异常。Oracle为PSU补丁提供了catbundle.sql脚本位置在$ORACLE_HOME/rdbms/admin。先启动数据库到升级模式sqlplus / as sysdba SQL startup upgrade;然后执行SQL ?/rdbms/admin/catbundle.sql PSU apply这个脚本会创建PSU应用记录表、执行数百个SQL变更、更新数据字典中的版本信息耗时通常10到20分钟。执行完成后重启数据库到正常模式SQL shutdown immediate; SQL startup;最后验证版本信息SQL select * from dba_registry_history where actionAPPLY order by action_time;正常输出能看到一条2022年1月PSU的应用记录对应补丁号33477185。这个表记录的信息在后续排查问题时非常有用。注意补丁Readme中强调catbundle.sql必须以sys用户执行且数据库启动到upgrade模式。如果跳过这一步骤下次运行catproc或其他升级脚本时可能报很多兼容性错误。3.4 重新编译失效对象停库、升级数据字典之后通常会出现一些失效的PL/SQL对象。重启数据库完成后用utlrp.sql重建失效对象SQL ?/rdbms/admin/utlrp.sql然后在执行完后检查失效对象数量SQL select count(*) from dba_objects where statusINVALID;正常情况下失效对象数量应为0。如果还有残存失效对象查看具体对象名称多数是因为依赖的包未完全编译再次执行utlrp.sql通常能解决。3.5 RAC环境下的特别注意点如果你的环境是RAC补丁安装过程会稍有不同。11.2.0.4的PSU补丁在RAC环境中支持滚动安装即逐个节点打补丁但需要注意第一个节点执行opatch apply时使用-rolling参数数据字典脚本只在最后一个节点执行一次每个节点都要替换OPatch版本并执行opatch apply滚动期间数据库可以保持对外服务但跨节点访问的会话会短暂中断我的实际经历是两节点RAC在业务低谷期逐节点打补丁整个过程约1.5小时业务无感知。但操作复杂度相对单实例高不少对RAC架构不够熟练的话建议还是全部节点停库后在维护窗口内完成。4. 补丁安装常见问题与排查实录4.1 OPatch版本过低导致apply失败最常见的坑就是OPatch版本过低。我在另一台测试机上直接跑opatch apply报错信息大概是“OPatch version 11.2.0.3.4 below the minimum required version 11.2.0.3.6”。这种问题解决起来简单提前下载p6880880升级即可。不要试图绕过这个检查否则后续可能遇到文件替换不完整的问题。4.2 前置补丁未安装导致检查不通过opatch apply的prereq阶段如果报“Missing required patch”说明缺少某个前置补丁。此时不要强行用-opatch_skip_prereq跳过尤其是在依赖补丁涉及安全修复的情况下。正确做法是按Readme要求下载对应前置补丁并安装再重新执行opatch apply。4.3 磁盘空间不足导致补丁应用失败补丁解压和安装过程占用空间不小。p33477185解压后约500MB加上Oracle Home的备份空间至少预留2GB以上。我遇到过/tmp目录空间不足导致opatch apply中断的情况建议提前检查四类空间/tmp至少1GB可用Oracle Home所在分区至少1GB补丁目录所在分区至少1GB归档日志目录确保补丁期间归档不会撑满磁盘4.4 跑catbundle.sql时遇到ORA-04021或ORA-04031ORA-04021代表对象被其他会话锁定ORA-04031代表共享池内存不足。排查方法确认没有其他会话在执行DDL或编译操作关闭其他数据库实例确保是单实例访问如果仍然报ORA-04031重启数据库实例后再以upgrade模式启动增加共享池大小SQL startup upgrade; SQL alter system set shared_pool_size500M scopeboth; SQL ?/rdbms/admin/catbundle.sql PSU apply4.5 补丁应用后数据库版本信息不一致有时opatch lsinventory显示补丁已应用但dba_registry_history表中没有对应记录因为漏跑了catbundle.sql。如果遇到这种情况不需要重新打一遍补丁只需启动到upgrade模式再执行一遍catbundle.sql即可。这个方法我实际验证过数据字典版本能正确更新到与二进制版本一致。整理成速查表更直观问题报错特征解决方法OPatch版本不够opatch version低于11.2.0.3.6下载p6880880替换OPatch前置补丁缺失Missing required patch按Readme下载前缀补丁安装/tmp空间不足No space left on device清理/tmp或设置TMPDIR到大数据盘数据字典版本不更新dba_registry_history无记录执行catbundle.sql PSU apply失效对象残留utlrp后仍有INVALID对象重跑utlrp或单独编译依赖对象5. 回滚方案与安装后的验证清单5.1 opatch rollback与数据库回滚如果补丁安装过程中出现严重问题可以考虑回滚。二进制层面的回滚方式$ORACLE_HOME/OPatch/opatch rollback -id 33477185但如果已经执行过catbundle.sql回滚就不是简单一个命令能搞定的了。数据字典的变更不能自动回滚需要从备份中恢复数据库或使用降级脚本。实际操作中在补丁安装前做全备是唯一靠谱的回滚方案一定要形成习惯。我的建议是在打PSU补丁前使用RMAN全备并备份归档日志同时使用expdp导出关键业务schema双保险。5.2 安装后验证清单补丁装完重启数据库建议按以下清单逐项验证确认无误后再恢复业务流量检查各实例告警日志alert_*.log末尾确认无ORA-600等内部错误检查监听状态和服务注册lsnrctl status检查关键业务会话能否正常连接和查询检查dba_registry_history中PSU记录是否正确检查dba_objects中失效对象数量是否为0如有Data Guard环境确认备库同步正常检查完这些项基本可以确认本次补丁安装操作完成。6. 写在最后的一点经验11.2.0.4这个版本我从2015年用到现在大大小小的补丁打了不下十轮每次过程都有微小的不同但核心流程始终是那几步下载、备份、检查、安装、验证。p33477185作为该版本的2022年1月PSU在安装过程中没有遇到什么特别棘手的问题整个流程走下来和以往PSU安装基本一致。唯一要提醒的是11.2.0.4已处于扩展支持后期如果条件允许建议尽快规划升级到19c或21c毕竟版本越老出问题时能借力的资源就越少。如果这篇文章能帮你在下次打补丁时少走一步弯路那就值了。遇到具体问题可以留言一起讨论数据库补丁安装这事细节太多了。本文还有配套的精品资源点击获取