Oracle 11.2.0.4 PSU p36575425安装与回滚指南

简介面向需要维护和升级企业级Oracle数据库的DBA与系统管理员该压缩包是Oracle Database 11.2.0.4在Linux x86-64平台上的PSU补丁集编号p36575425由Oracle于2024年7月发布集成了上一PSU以来的关键安全修复与稳定性改进可帮助数据库实例及时规避已知问题。包内共2000个文件压缩后大小约536MB以o对象文件、so共享库、xml配置及sql脚本为主同时包含class、jar、plb等补丁运行与校验组件目录结构完整便于按官方文档执行opatch补丁操作。已有938人学习/下载适用于正在使用Oracle 11.2.0.4且需要跟进季度补丁更新的生产环境。下载后可直接用于本地或测试环境的PSU部署验证也可作为研究Oracle补丁机制与文件组成的参考素材。1. 这个补丁包是什么p36575425 与 11.2.0.4 季度 PSU 的定位Oracle 11.2.0.4 到现在还有大量生产库在跑这没什么好避讳的很多单位的核心业务就压在这个版本上。标题里的11.2.0.4.240717.Linux64和p36575425指的就是 2024 年 7 月发布的 Database PSU补丁集更新平台是 Linux x86-64。PSU 是 Oracle 季度发布的累积补丁里面装的是上一季度安全漏洞修复和一批高影响 bug 的修复不改变数据库架构也不动你的数据文件格式。对 DBA 来说打这类补丁是例行工作里最需要谨慎的一类操作不打的后果是漏洞敞口越来越大打的过程中如果翻车恢复时间可能比补丁本身还长。这篇笔记就适合接手老库的 DBA、负责运维的同事把从预检、apply 到验证回滚这一整条路讲清楚。2. 动手前先别急着 apply环境检查与补丁冲突预检2.1 先读补丁 README识别这个 PSU 到底包含什么PSU 补丁解压后通常是一个目录里面放着完整的README.txt。我不论多熟悉流程都会先把 README 打开看一遍重点看三块内容要求的 OPatch 最低版本、前置补丁prerequisite patches、以及安装后是否需要额外执行 SQL 脚本。p36575425 这个编号对应的补丁集比较大里面可能还包含针对 Grid Infrastructure 的独立补丁所以解压后先看目录结构找到Database或Grid Infrastructure子目录别对整个补丁目录直接执行 opatch apply那样大概率报错。另外README 里会标注这个补丁是否支持 rolling也就是能否在 RAC 环境里逐节点滚动打。11.2.0.4 的多数 PSU 支持滚动但前提是节点间版本差距在一个补丁以内。如果不支持滚动RAC 环境就得停集群这个决策会影响后续所有步骤。2.2 对拍 OPatch 版本与环境变量三条命令先跑一轮打补丁前OPatch 工具版本是第一道门槛。OPatch 版本太老连 prereq 检查都过不了会直接提示需要升级。我一般会按顺序跑这三条命令# 确认当前 ORACLE_HOME 指向的是要打补丁的那套环境 echo $ORACLE_HOME # 查看当前 OPatch 版本注意是 11.2.0.4 对应的 OPatch $ORACLE_HOME/OPatch/opatch version # 查看已安装补丁确认目标补丁号是否已经在库里 $ORACLE_HOME/OPatch/opatch lsinventory -bugs_fixed | grep -i 36575425 || echo not installed第一条命令的输出必须是你准备打补丁的那套数据库软件的安装路径这个如果指错后面所有操作都会落到错误的 ORACLE_HOME 上。第二条命令的版本要和 README 里要求的 OPatch 最低版本对拍一般是11.2.0.3.42以上达不到就先下载对应 OPatch 包替换。第三条命令用来确认补丁是不是真的没打过有时候运维同事记不清之前是否打过一个名字相似的补丁这一步能避免重复 apply。顺带提一句OPatch目录的权限要保持是oracle用户可写如果之前被别人 chown 过apply 时会直接报Permission denied这种问题最常见也最隐蔽。2.3 用 opatch prereq 在 apply 前把冲突和空间一次查清预检阶段能做的检查opatch prereq基本都覆盖了。我最常用的是以下三条# 检查补丁与当前 ORACLE_HOME 内已安装补丁的冲突 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/patch/36575425 # 检查补丁所需系统空间是否足够 $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir /u01/patch/36575425 # 检查补丁的前置依赖是否满足 $ORACLE_HOME/OPatch/opatch prereq CheckPrereq -phBaseDir /u01/patch/36575425注意-phBaseDir指向的路径要精确到补丁目录如果 p36575425 解压后下面还有一层带日期的子目录比如36575425/240717那-phBaseDir就要指到最内层。这个参数很看细节指错层级的现象是 prereq 直接报Patch location not found。三个检查项各看一个方面冲突检查看的是新补丁会不会和已安装补丁在同一个文件上做修改有冲突时输出里会列出具体文件系统空间检查看的是 ORACLE_HOME 所在文件系统和/tmp的剩余空间PSU 这类大补丁光备份文件就占好几个 G空间不足的坑后面专门讲前置依赖检查看的是是否缺少某些必须提前安装的补丁不满足时 apply 会半路失败。这三个都通过再往下一步。2.4 备份策略ORACLE_HOME 和数据库各留一手打 PSU 之前我会做两层备份。第一层用 RMAN 把数据库备份到磁盘至少保证能恢复到 apply 前的状态第二层把$ORACLE_HOME目录整个 tar 一份因为 opatch 会替换和新增大量二进制文件光靠 opatch rollback 不一定能恢复到文件级别的一模一样。# 数据库备份按你已有的备份策略执行即可 rman target / RMAN backup database plus archivelog format /backup/psu_240717_%U; # ORACLE_HOME 文件系统备份tar 时不带尾斜杠 cd /u01/app/oracle tar czf /backup/oracle_home_240717.tar.gz product/11.2.0/dbhome_1RMAN 备份这里我只写了最小命令实际环境里按你平时备份脚本跑就行关键是备份完成后要确认有RMAN-没有报错、归档日志没断档。ORACLE_HOME 的 tar 备份时间取决于库大小一般十几分钟到半小时这个时间值得花。如果打补丁过程中发现某几个二进制文件被改坏了又不知道改了什么这份 tar 就是后悔药。3. 单实例下把 PSU 装上从 shutdown 到 SQL 脚本的完整操作3.1 先把实例、监听和应用会话全部停干净打 PSU 的铁律是数据库要处于 shutdown 状态或者至少是 mount 状态且没有应用连接否则 opatch apply 替换二进制文件时可能出现文件被占用或者即使成功后续跑 SQL 脚本也会因为会话锁导致执行失败。我最稳妥的顺序是先停监听、再停应用、最后 shutdown 实例# 1. 停监听 lsnrctl stop # 2. 以 sysdba 登入关掉实例 sqlplus / as sysdba SQL shutdown immediate; # 3. 确认进程已退出 ps -ef | grep pmon | grep -v grepshutdown immediate会等待当前事务结束如果应用连接还挂着这条命令可能长时间卡住。所以我会在 shutdown 之前先检查v$session把来自应用服务器的会话一个个 kill 掉或者干脆让应用团队先停服务。shutdown abort虽然快但实例异常关闭后重启要跑实例恢复打补丁前我不建议用除非确实有无法等待的紧急窗口。有时会遇到已经 stop 了监听、应用也停了但shutdown immediate还是卡住这时候查一下后台是否有长事务实在不行只能shutdown abort。这种情况下的教训是停应用的时间点要提前给事务足够的收尾时间。3.2 执行 opatch apply关键参数与输出解读实例关掉后就可以执行 apply 了。用oracle用户操作不要用 root。命令如下# 切到补丁目录注意路径精确到子目录 cd /u01/patch/36575425/240717 # 执行 apply-phBaseDir 可以省略因为已经在目录内 $ORACLE_HOME/OPatch/opatch apply -postinstall-postinstall参数的意思是应用完文件后opatch 自动执行补丁自带的 post-install 步骤。但我个人的习惯是不加这个参数而是先opatch apply把文件装好之后再手动去执行 SQL 脚本。原因很简单postinstall 里的 SQL 脚本会自动执行一旦执行失败opatch 的返回码会混在一起不好判断是文件替换失败还是 SQL 失败手动跑 SQL 可以把两段操作的日志分开排查起来清楚得多。apply 过程中会输出大量信息我关注的就三类关注点怎么看正常表现冲突检查输出前段的Prerequisite check段出现CheckPassed文件更新中间的Updating archive files段逐文件列出不报错完成状态结尾的Apply complete返回码为 0无OPatch failedapply 整个过程根据 ORACLE_HOME 的大小从几分钟到半小时不等中途不要 SSH 断开最好用nohup或者 tmux 挂着否则断连可能导致操作中止在中间状态。另外/tmp空间要留足opatch 会在/tmp下创建临时目录空间不足时会在中途报错退出。3.3 跑 PSU 自带的 SQL 脚本顺序、时长与锁表观察文件替换完成后数据库还不能马上投入使用。PSU 的修复里有一部分是数据字典更新和内部对象变更这些需要 SQL 脚本来完成。脚本位置一般在两个地方补丁目录下的Files子目录或者$ORACLE_HOME/rdbms/admin下名字里带有postinstall或catbundle字样。我的标准做法是# 先把数据库启动到 open 状态SQL 脚本需要在 open 状态下跑 sqlplus / as sysdba SQL startup; # 退出 sqlplus用 nohup 后台执行脚本避免终端断连 cd $ORACLE_HOME/rdbms/admin nohup sqlplus / as sysdba catbundle_PSU_11_2_0_4_240717.sql /tmp/psu_sql.log 21 脚本名里的日期部分要以实际解压出来的文件名为准别照抄我这里的240717。我习惯用ls -l $ORACLE_HOME/rdbms/admin/*bundle*先看一下实际有哪些脚本再执行对应名字的那个。执行期间数据库处于 open 状态但建议不要让业务流量进来因为脚本会做大量 DDL 操作跑的过程中会有锁等待。脚本执行时间通常在 10 到 40 分钟之间取决于数据库里对象数量。期间可以隔一段时间看一眼日志tail -f /tmp/psu_sql.log日志末尾如果出现Catbundle completed或类似字样说明执行完成。如果中途报错不要急着重跑先看是哪种错误如果是某张表被锁导致的ORA-04021杀掉阻塞会话后可以重新执行如果是ORA-01950这类权限问题得检查补丁脚本运行账号的权限。3.4 重启验证确认无效对象和组件状态正常SQL 脚本跑完后再做一次干净的重启然后执行编译无效对象的操作。这一步是很多人容易跳过的因为不重启直接查也没问题但既然打了补丁一个干净启动能确认二进制文件没有隐性问题。# 重启数据库 sqlplus / as sysdba SQL shutdown immediate; SQL startup; # 编译无效对象第一次跑通常需要几分钟 SQL $ORACLE_HOME/rdbms/admin/utlrp.sql # 确认无效对象数量收敛 SQL select count(*) from dba_invalid_objects where status ! VALID;utlrp.sql是 Oracle 自带的无效对象编译脚本会自动并行编译。执行完再查一遍dba_invalid_objects如果还有少量残留通常过几分钟再跑一次utlrp.sql就能清掉。如果反复编译还有大量无效对象就要拿具体对象名去看是不是版本不兼容问题少数情况是 PSU 和某个组件补丁冲突导致的。4. 打补丁这些年踩过的坑现象、原因、解决办法4.1 opatch 提示 “already applied” 但 lsinventory 里其实没有现象执行opatch apply时输出里有一个Patch 36575425 is already applied直接退出。但用opatch lsinventory -bugs_fixed查并没有这个补丁号。原因最常见是-phBaseDir指错了目录。补丁解压后目录层级比较深如果你指向的是外层的父目录而父目录里包含了多个子补丁opatch 在识别时可能读取到了残留的etc/config文件导致判断误伤。另一个可能是在同一套环境里曾做过 opatch apply 到一半被取消inventory 里留下了半截记录。解决先检查ls -lR /u01/patch/36575425 | grep -i readme找到最内层补丁目录重新执行opatch version和opatch lsinventory -bugs_fixed | grep 36575425双双确认再换到正确目录 apply。如果确认确实有残留记录用opatch util rollback -id 36575425清掉残留或者直接把对应_remove记录从 inventory 里删掉不过后者风险大我一般不推荐。4.2 ORACLE_HOME 空间不足apply 过程中途失败现象opatch apply跑到Updating files阶段报错错误信息里带No space left on device进程退出。原因ORACLE_HOME 所在的文件系统剩余空间不够。PSU 补丁在替换二进制文件时会先备份旧文件、再写新文件两个版本同时存在占的空间远超补丁包本身。再加上/tmp也会被 opatch 用来放临时文件两个位置都紧张时特别容易翻车。解决apply 之前用df -h看两个位置一个是$ORACLE_HOME的挂载点另一个是/tmp。我在 2.3 节提到的CheckSystemSpace就是干这个的但有时候它会算出“刚好够”实际跑起来还是差一点。我的习惯是给 ORACLE_HOME 留至少 5GB 余量给/tmp留至少 2GB。如果空间确实不够清理 ORACLE_HOME 里的 *.aud 日志和 monitor 目录下的旧 trace 文件或者把/usr/lib某些不用的大文件移走。扩容是最后手段。4.3 跑 SQL 脚本时 ORA-04021卡在锁等待上现象执行catbundle_PSU_*.sql时日志里持续出现ORA-04021: timeout occurred while waiting to lock object脚本长时间不前进。原因打补丁前应用会话没停干净或者有定时任务在后台跑占用了数据字典对象上的锁。11.2.0.4 的系统里常见的是 AWR 快照、统计信息任务正好在这个时间点执行和补丁 SQL 抢锁。解决先查v$session找出阻塞catbundle的会话。select sid, serial#, username, blocking_session, sql_id, wait_class from v$session;找到阻塞会话后 kill 掉脚本会自动继续。另外执行补丁 SQL 前把DBMS_SCHEDULER里那些自动维护任务停掉例如sql_tune_task和auto_space_advisor能少掉很多这类麻烦。我现在的做法是打补丁前就写一个停任务脚本跑完 SQL 再启动任务。4.4 打完补丁 sqlplus 起不来报 libclntsh.so 相关错误现象apply 完成、重启数据库时sqlplus / as sysdba直接报error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file。原因这个锅通常不在补丁而在环境变量。ORACLE_HOME 里的lib目录被 LD_LIBRARY_PATH 覆盖了或者 OPatch 在替换文件时某些软链接失效了。还有一种情况是打完补丁后relink没有执行完整而 11.2.0.4 的某些 PSU 在 README 里要求安装后做一次 relink all。解决先检查环境变量。echo $LD_LIBRARY_PATH ls -l $ORACLE_HOME/lib/libclntsh.so*如果libclntsh.so指向的软链接断了重新执行 relink。relink 命令在 11.2.0.4 上是cd $ORACLE_HOME/lib make -f ins_rdbms.mk relink_all环境变量里LD_LIBRARY_PATH要包含$ORACLE_HOME/lib少了就补上。这个问题在用了多个 Oracle 版本的环境里特别常见因为不同版本的lib目录会互相干扰。4.5 RAC 滚动打补丁时节点状态不一致现象RAC 环境按 rolling 方式打补丁节点一打完后节点二还没开始此时应用请求刚好连到节点二出现版本不一致导致的接口报错甚至 ORA-00600。原因滚动补丁允许两个节点短暂版本不一致但前提是应用能够接受这个窗口。问题是很多库的 11.2.0.4 RAC 使用 service 做负载均衡没有把节点一切出 service请求还是会飘到正在打补丁的节点。解决我的习惯是无论如何滚动前先把补丁涉及的节点从 service 里摘掉。11.2.0.4 环境下可以用srvctl# 把节点一的 service 禁用只影响连接不影响实例 srvctl stop service -d orcl -s myservice -n node1打完一个节点、验证完再处理下一个。如果 README 标注这个 PSU 不支持 rolling那就直接停整个集群打别偷这个懒。另外RAC 环境里 ASM 实例也要一并打补丁ASM 的 ORACLE_HOME 和数据库的 ORACLE_HOME 分开的话要分别 apply这个点很容易漏。4.6 忘了备份回滚时进退两难现象打完补丁后第三天发现某个业务行为异常需要回滚补丁。执行opatch rollback时报错因为 rollback 找不到备份文件或者备份文件在 /tmp 下已被清理。原因opatch apply 时会自动在 ORACLE_HOME 下保留一份被替换文件的备份但这些备份占空间某些清理脚本会在晚上把 /tmp 下的 opatch 临时文件清掉连带着备份一起没了。另一个场景是应用层在补丁后又装了别的软件改了库里的文件回滚时新旧文件混在一起。解决唯一的后悔药就是 2.4 节那份独立 tar 备份。没有这份备份遇到严重问题只能重装数据库软件、重新 apply 补丁成本高得多。我现在每条环境打完补丁后都会把opatch lsinventory -detail输出和备份文件路径记在变更记录里留一个月。5. 验证与回滚确认真正装好同时留好一条退路5.1 三条命令验证补丁真正生效打完补丁别急着收工验证要做两层。第一层是opatch层面确认补丁在 inventory 里第二层是数据库内部确认 SQL 脚本和组件状态正确。# 确认补丁号出现在已安装列表里 $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425 # 从数据库内部查补丁注册记录 sqlplus / as sysdba SQL select PATCH_ID, PATCH_TYPE, ACTION, STATUS from DBA_REGISTRY_SQLPATCH where PATCH_ID 36575425;DBA_REGISTRY_SQLPATCH是 12c 以后的视图11.2.0.4 里没有这个视图对应的查询是DBA_REGISTRY_HISTORY或者DBA_REGISTRY。11.2.0.4 的环境我一般查DBA_REGISTRY_HISTORY看有没有对应日期的 APPLY 记录同时查DBA_OBJECTS里的无效对象数量。如果补丁的 SQL 部分没跑opatch 记录会有但数据库内部没有注册这个差异是判断“文件装完但脚本没跑”的关键。5.2 业务冒烟与日志观察验证完补丁状态后我会让业务侧做一轮最小功能冒烟。不需要全量回归但至少要把核心链路的几个操作跑通。同时把 alert log 打开重点看有没有下面这些关键字ORA-600、ORA-7445、ORA-04031。# 观察 alert log 尾部新产生的报错 tail -f $ORACLE_HOME/diag/rdbms/orcl/orcl/trace/alert_orcl.log如果库里有等保要求打完补丁再顺手确认一下审计相关配置没被重置有些 PSU 的脚本会重建一部分数据库字典对象理论上不影响AUDIT_TRAIL参数但我确实见过补丁后审计日志写入异常的案例。这种属于概率低但代价高的事顺手查一下show parameter audit_trail不费事。5.3 回滚操作的最低要求和我的习惯回滚不是把补丁卸了就完事。opatch rollback只恢复二进制文件之前跑过的 SQL 脚本对数据字典的修改需要靠补丁自带的回滚脚本来撤销。我的完整回滚步骤是先执行数据库回滚 SQL 脚本再执行opatch rollback -id 36575425然后重启数据库并重新编译无效对象。所以补丁目录和那份 tar 备份至少保留一个月再删不要打完就清理磁盘。这些年打了无数轮 PSU我自己的习惯是每轮都建一个变更记录写上补丁号、apply 时间、SQL 脚本日志路径、备份路径、验证结果。下次遇到同样版本的环境直接照着一份跑比自己现场回忆细节靠谱得多。也希望这篇关于 Oracle 11.2.0.4 打 database PSU 的笔记能把你绕过的几个弯直接省掉希望帮到你。本文还有配套的精品资源点击获取