Oracle 11.2.0.4 PSU补丁安装全解析：单实例与RAC滚动

简介面向 Oracle 数据库管理员与系统运维人员的 11.2.0.4 版本补丁集更新PSU压缩包对应 2022 年 1 月发布的 p33477185 补丁适用于 Linux x86-64 环境。该更新聚合了安全修复、性能优化与已知问题解决方案是保持数据库稳定运行的重要维护组件。压缩包共含 3658 个文件以动态链接库so、目标文件o、XML 配置与补丁描述文件xml为主同时包含 SQL 脚本、OPatch 工具所需的 jar/a/class 等资源整体大小约 436.52MB文件类型覆盖补丁程序、元数据、安装脚本与辅助工具。已有 854 人学习下载。通过完整的 PatchSearch.xml 元数据与对应编号的补丁程序使用者可借助 OPatch 完成补丁应用、验证与回滚合理部署该补丁能有效修复已知漏洞、提升数据库性能并为后续维护提供规范的补丁管理基线。1. 拿到DB-PSU-11.2.0.4.220118这个包先读懂文件名再动手手上拿到一个DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64这样的压缩包时Oracle DBA 的第一反应通常不是惊喜而是确认三件事这个季度 PSU 覆盖了哪些问题、能不能在现有环境成功 apply、打完之后库还稳不稳。文件名拆成四段读就好DB是 Oracle 数据库11.2.0.4是版本基线220118代表 2022 年 1 月 18 日的季度补丁日期p33477185是 My Oracle Support 上的补丁号Linux-x86-64是目标平台。这是一份 11.2.0.4 老库在 2022 年第一季度可以打的补丁集合适合还在维护 11.2 环境的 DBA、运维和准备做合规审计的团队核心价值是安全漏洞修复加一批已知 bug 的代码级修复。下面这套流程按单实例、RAC 两条线讲退化场景怎么回滚也一并交代清楚。2. PSU 补丁的类型辨析与环境基线检查先搞清楚该认谁2.1 PSU 与 CPU、SPU、RU 的关系11.2.0.4 只认 PSUOracle 11.2.0.4 这个版本发布已经超过十年但它的补丁体系跟 12.2 之后的版本完全不是一回事。早年的 CPUCritical Patch Update只修安全漏洞后来被 PSUPatch Set Update取代PSU 在安全修复之外还捆绑了该季度积累的一批高影响 bug 修复所以日常基线补丁基本都打 PSU。补丁类型全称包含内容适用版本CPUCritical Patch Update仅安全漏洞10g / 11g 早期PSUPatch Set Update安全漏洞 特定 bug 修复11.2.0.4 主流SPUSecurity Patch Update仅安全漏洞PSU 的纯安全分支特殊情况RURelease Update安全 bug季度全量12.2 及以后如果你在 11.2.0.4 上看到RU字样的补丁那是从 12.2 引入的命名11.2 老环境不用理会。这个p33477185是标准的季度 PSU包含该季度安全补丁以及一批在 11.2.0.4 上确认过的严重 bug 修复不是那种只改配置文件的 mini patch它会替换$ORACLE_HOME下的一批二进制文件并更新数据字典。2.2 解压后的目录结构README 排第一patch 目录排第二把 zip 解压之后目录名一般是33477185。先别急着 apply第一步永远是读 README。这里面的信息在 My Oracle Support 的 Patch 页面也能找到但本地这份最直接。unzip p33477185_112040_Linux-x86-64.zip cd 33477185 ls -la目录下通常是README.txt或README.html、etc配置目录、files或patch目录里面放着实际要覆盖的二进制。README 里必须确认三件事OPatch 的最低版本要求、打补丁前后的系统配置要求、postinstall SQL 脚本步骤。经常有人跳过 README 直接 apply结果在 postinstall 阶段卡住再回来翻文档浪费一个维护窗口。注意unzip解压大 zip 包时偶尔会报 CRC 错误多半是下载损坏或者解压工具太老。遇到这种情况用jar xf p33477185_112040_Linux-x86-64.zip代替 unzip 通常能绕过去。2.3 环境基线三查OPatch 版本、ORACLE_HOME 空间、已有补丁冲突打补丁前最后一道检查系统性地确认三件事。# 查 OPatch 版本 $ORACLE_HOME/OPatch/opatch version # 查 ORACLE_HOME 剩余空间 df -h $ORACLE_HOME # 查当前已经安装的补丁 $ORACLE_HOME/OPatch/opatch lsinventoryopatch version输出如果低于 11.2.0.3.23这台机器打这个 PSU 大概率会直接报版本不支持。这时候需要先从 My Oracle Support 下载p6880880工具包更新 OPatch解压覆盖到$ORACLE_HOME即可cd $ORACLE_HOME unzip -o p6880880_112000_Linux-x86-64.zipOPatch 是补丁工具的统称p6880880是它的通用补丁包编号按你实际下载到的平台版本解压。空间检查上11.2.0.4 的 PSU 解压加备份通常会吃掉 3GB 以上空间$ORACLE_HOME所在文件系统至少留 5GB 才稳妥。用df -h看一眼是 Linux 下最基础的排查动作这里也用得上。opatch lsinventory输出里如果已经存在和本 PSU 冲突的补丁apply 的时候会直接中断这个后面专门讲。3. 单实例库打 PSU 的一条龙停库、apply、catbundle、验证3.1 停库前的最后检查与备份不管库有多忙打 PSU 前必须先做状态记录。我一般先确认数据库当前状态、归档模式和 invalid 对象数量再决定要不要额外备份。sqlplus / as sysdba SQL SELECT open_mode, log_mode FROM v$database; SQL SELECT COUNT(*) FROM dba_objects WHERE statusINVALID;输出里open_mode是 READ WRITE、log_mode是 ARCHIVELOG这是最理想的打补丁状态。INVALID对象数量先记下来打完补丁之后再查一次作为判断补丁影响范围的依据。如果统计值在几千上万说明这个库本来就有大量失效对象打完 catbundle 之后要及时跑utlrp.sql重编译。备份策略上11.2 的 PSU 虽然一般不会动用户数据但按我的习惯至少做一个控制文件备份加数据文件头备份。有 RMAN 的跑一条backup current controlfile没条件的把$ORACLE_HOME/dbs下的参数文件复制一份出来这都是打补丁的后悔药。3.2 停监听、停库、执行 opatch apply单实例库的停止顺序必须是先停应用连接、再停监听、最后停数据库。lsnrctl stop sqlplus / as sysdba SQL shutdown immediate;监听停掉之后新的连接进不来已经建立的连接在shutdown immediate时会被回滚终止所以要在业务低峰做。库停干净之后用 oracle 用户执行 applycd 33477185 $ORACLE_HOME/OPatch/opatch applyopatch apply不指定参数时会自动用$ORACLE_HOME和默认的oraInst.loc定位 Oracle 安装信息。如果你的环境是.0这种非标准 GI 布局或者$ORACLE_HOME没设进环境变量就需要显式指定$ORACLE_HOME/OPatch/opatch apply -invPtrLoc /etc/oraInst.loc执行过程中会先做冲突检测再进入备份和文件替换阶段。输出里的关键行是这样一段话OPatch succeeded。看到这个才算 apply 成功。整个过程快则十分钟慢则半小时取决于磁盘速度中途千万别按 CtrlC一旦中断在备份阶段会把$ORACLE_HOME搞成中间态。3.3 打二进制只是第一步catbundle.sql 必须执行很多新手栽在这里opatch apply明明显示成功结果不跑 SQL 脚本就直接把库起起来之后跑业务报 ORA-04021 或对象状态异常又回头重跑。PSU 不只是替换二进制文件它还要更新数据字典里的对象、包和视图定义这一步由catbundle.sql完成。sqlplus / as sysdba SQL ?/rdbms/admin/catbundle.sql PSU apply?会展开成$ORACLE_HOME这条命令实际执行的是$ORACLE_HOME/rdbms/admin/catbundle.sql后面跟的PSU apply两个参数告诉脚本当前是 PSU 补丁的 apply 阶段。脚本执行时间跟库内对象数量正相关小库十分钟左右大库可能要半小时以上。执行过程中数据库必须是启动状态通常用startup upgrade但 11.2.0.4 的 PSU 文档一般允许正常startup后执行具体看 README 要求。如果脚本跑了一半中断直接重新执行同一条命令。catbundle.sql有断点续跑逻辑已经应用过的部分会跳过不会重复执行造成二次污染。3.4 验证补丁生效lsinventory 加 SQL 双确认打完补丁重启数据库然后从两个层面确认生效。$ORACLE_HOME/OPatch/opatch lsinventory -detail | grep 33477185-detail参数会展开补丁的详细信息如果补丁确实应用成功这里能看到补丁号和描述。SQL 层面的验证更重要因为二进制替换成功不代表数据字典更新成功sqlplus / as sysdba SQL SELECT patch_id, action, status, description FROM dba_registry_sqlpatch WHERE patch_id 33477185;dba_registry_sqlpatch是 11.2.0.4 上记录 SQL 补丁历史的视图结果里ACTIONAPPLY、STATUSSUCCESS才算真正完成。最后再跑一遍 invalid 对象统计和补丁前的数字对比差异不大就说明这次补丁没有引入新的失效对象。4. RAC 滚动打 PSU逐节点维护比 opatch auto 更可控4.1 RAC 为什么不能照搬单实例的停库顺序RAC 环境最大的约束是集群不能全停实例不能同时关。数据库层的 PSU 通常只涉及 DB Home不涉及 GI Home所以不需要滚动 GI只需要逐节点滚动实例。如果把单实例那套lsnrctl stopshutdown immediate整个搬过来在节点一执行完停库节点二还在对外服务只要节点二的实例没停补丁 apply 就有可能在检查阶段直接报实例未完全关闭。RAC 下数据库的共享部分比如数据字典所有节点都指向同一套。所以 postinstall 的catbundle.sql只在其中一个节点执行一次即可两个节点都跑反而会因为字典锁问题报错。这一点是 RAC 打 DB PSU 和单实例最大的区别。4.2 逐节点滚动停实例、apply、起实例、跑 SQL两节点 RAC 的标准滚动顺序是节点一停实例、apply、起实例、跑 SQL节点二停实例、apply、起实例SQL 不重复跑。# 节点一执行 srvctl stop instance -d orcl -i orcl1 # 节点一继续执行 cd 33477185 $ORACLE_HOME/OPatch/opatch applysrvctl stop instance后面的-d orcl是数据库名-i orcl1是实例名两个参数缺一不可。如果不记得实例名可以srvctl status database -d orcl先查。apply 完成后启动实例srvctl start instance -d orcl -i orcl1节点一实例起来后找一个空闲窗口执行 SQL 补丁脚本因为字典是共享的这一步在节点一做完节点二就不需要再做sqlplus / as sysdba SQL ?/rdbms/admin/catbundle.sql PSU apply然后节点二重复第一步和第二步跳过 SQL 脚本。节点二的opatch apply会再次更新本节点的二进制但对共享字典的改动已经在节点一完成了。4.3 opatch auto 的适用边界与日志路径有些 DBA 习惯用opatch auto一条命令完成 RAC 的补丁自动滚动$ORACLE_HOME/OPatch/opatch auto /u01/psu/33477185 -oh $ORACLE_HOMEopatch auto会自动识别 RAC 环境把补丁分发到各个节点逐个滚动实例。它的问题是控制粒度太粗什么时候切实例、失败后停在哪个节点完全由工具自动决定。11.2 时代的opatch auto处理 DB PSU 时会尝试连接 GI 相关组件如果碰到 GI Home 版本和 DB Home 不一致就会在检查阶段翻车输出一团日志但补丁一个都没打上。日志路径在$ORACLE_HOME/cfgtoollogs/opatchauto/下按日期生成目录。我的血泪经验是opatch auto只适合补丁内容明确只涉及 GI 或者只涉及 DB、环境完全规范化的场景只要有一点点历史遗留问题它生成的日志能把人逼疯。手工逐节点滚动虽然多敲几条命令但每步结果都可控出了问题可以精确回滚。4.4 两节点以上的滚动节奏三节点以上的 RAC滚动顺序仍然是串行的节点一处理完并确认opatch lsinventory -detail能看到补丁号才允许动节点二。并行处理不同节点是省时间但一旦补丁本身有隐含的跨节点依赖并行 apply 可能互相踩。我一般按「节点一完整验证 → 节点二 apply 并起实例 → 节点三 apply 并起实例」的顺序走每个节点的验证命令统一是$ORACLE_HOME/OPatch/opatch lsinventory -detail | grep 33477185每完成一个节点顺手把 alert 日志里该实例的启动时间点、有无 ORA 错误记录到操作文档里。全部节点处理完再回到执行过 SQL 脚本的节点查dba_registry_sqlpatch确认STATUSSUCCESS整个 RAC 的 PSU 才算真正落地。5. 补丁翻车现场五条高频踩坑记录与补救5.1 OPatch 版本过旧直接报不支持现象opatch apply一开始就退出报错信息里出现OPatch version is not supported之类的描述。原因$ORACLE_HOME/OPatch里的工具版本低于该 PSU 要求。11.2.0.4 的 PSU 一般要求 OPatch 至少 11.2.0.3.23早几年装的库可能还是 11.2.0.3.2。解决先去 MOS 下载p6880880对应 11.2 平台的 OPatch 包解压覆盖到$ORACLE_HOME下再跑opatch version确认版本号变了最后重新执行 apply。5.2 ORACLE_HOME 空间不足导致 apply 中断现象apply 进行到一半退出提示OPatch requires xxx bytes free under ORACLE_HOME。原因OPatch 在替换二进制前会在 home 下建备份目录空间需求是补丁体积的数倍。df -h $ORACLE_HOME看到剩余空间只剩几百 MB 时基本都会踩这个坑。解决先清理$ORACLE_HOME下的logs、trace、core文件通常 dbs 目录下的 core dump 是空间杀手。清理完再重新执行 apply。如果 apply 已经在备份阶段中断最好先用opatch rollback -id 33477185恢复再清空间重打不要直接在残状态上继续。5.3 冲突补丁导致 apply 直接中止现象输出中出现Following patches are conflict with existing patches带着一串冲突补丁号apply 没有继续。原因这台机器之前打过某个 CPU、SPU 或 interim patch本次 PSU 的代码基线覆盖了它。解决先opatch lsinventory确认冲突的是哪个补丁再执行opatch rollback -id 冲突补丁号把它卸掉最后重新opatch apply。代码基线差异大的环境可能有一次 BUG 修复被多个历史补丁打过rollback 的顺序要按安装倒序来乱序卸会卸出新的黑洞。5.4 库没停干净apply 和 startup 互相较劲现象apply 报数据库实例仍在运行的错误或者启动实例时 ORA-01034 提示无法打开。原因单实例环境下有人先startup再 apply或者shutdown abort后进程没清干净。RAC 环境下某个节点的 smon 进程还挂着就执行了 apply。解决用ps -ef | grep smon检查每个节点是不是只剩本节点的 smon确认没有其他进程残留后再 apply。RAC 统一用srvctl status database -d orcl查看所有实例状态。5.5 catbundle SQL 脚本执行时报错或中断现象?/rdbms/admin/catbundle.sql PSU apply执行中报 ORA-01722 或长时间挂在某条语句上最后连接断开。原因通常是库里有应用自定义触发器、DBMS_JOB 在脚本执行期间抢 DDL 锁或者是会话被shutdown打断。这类错误没有统一规律查alert_dbname.log才能定位到具体语句。解决先把数据库的 job 队列停掉确认没有应用在跑 DDL然后重新执行catbundle.sql PSU apply。它有断点续跑能力已经应用的部分不会重复执行。执行完再查dba_registry_sqlpatch确认STATUSSUCCESS这条脚本跑通补丁才算真正闭环。6. 打完 PSU 的一个月SQL 补丁验证与下一季度补丁的准备补丁打完之后验证工作不是当天完事就结束建议按周跟踪。第一周内的检查重点是三个地方dba_registry_sqlpatch的状态是否持续 SUCCESSalert日志里有没有新增的 ORA 错误以及 invalid 对象数量有没有异常增长。alert日志相当于数据库的黑匣子把 apply 前后的日志文件和之后一周的日志并排看异常变化一目了然。SQL 补丁的历史记录建议固化到运维文档里。每次打完 PSU我会在维护文档里记录补丁号、应用日期、opatch apply的输出摘要、catbundle的执行时长、补丁前后 invalid 对象数量的对比。等下一个季度补丁出来直接拿这些记录做基线重点比对 invalid 对象数量和执行时间的变化。准备下一季度补丁时回归测试清单至少包含数据库启停、监听服务正常注册、RMAN 备份可用、业务系统关键 SQL 的执行计划没有因为字典更新而劣化。RAC 环境还要确认srvctl status各实例状态正常opatch auto如果上次没走通这次仍然建议手工逐节点来。从那以后我每次打完 PSU 都会顺手做一次opatch lsinventory -detail把补丁列表归档到文件等下一季度补丁来的时候直接比对省得临时翻记录。希望帮到你。本文还有配套的精品资源点击获取