简介Oracle 11.2.0.1 数据库补丁安装操作指南面向需要为生产或测试环境打补丁的 DBA 与运维人员重点解决补丁安装前后常见的环境检查、备份、执行和验证问题。压缩包包含 1 个 doc 文档大小 942KB内容按“安装前准备—补丁安装—安装后验证”组织指令清晰可直接对照执行。目前已有 130 人学习/下载。文档详述了关闭实例、完整备份、下载解压补丁包、配置 ORACLE_HOME 与 OPatch 环境变量、执行 opatch apply、确认 succeed 标记等关键操作同时介绍了数字补丁包应由小到大依次安装、安装完成后重启服务器并确认 Oracle 服务自动启动等要点并提供 opatch lsinventory、rollback、prereq 命令用于异常处理能够有效帮助读者规避打补丁失败与回滚风险适合需要快速上手补丁操作的数据库技术人员。1. 为什么 oracle 11.2.0.1 打补丁这件事这么容易翻车很多 DBA 第一次给 oracle 11.2.0.1 数据库打补丁时都是拿着一个补丁包就开始opatch apply结果补丁报错、数据库起不来、业务查询异常最后只能靠备份恢复。真正的问题多数不是补丁本身坏了而是这个版本的补丁链路比想象中长先要核对当前补丁基线再确认 OPatch 版本够不够新还要处理空间、备份、依赖补丁打完二进制补丁后还得补 SQL 脚本。这一整套动作少一步后面就是连锁反应。这篇文章按“先准备、再执行、后验证”的顺序把 11.2.0.1 打补丁的完整路径、常用命令和踩过的坑讲清楚适合负责生产库维护的 DBA也适合刚接手 11g 环境、准备做版本收敛的开发同学。2. 打补丁前的硬性准备版本核对、OPatch 与空间三件事打补丁最忌讳的就是拿到包就 apply。Oracle 的补丁体系里11.2.0.1 是一个很老的基线版本后续的 PSU、CPU、一次性补丁之间都有依赖关系跳过前置补丁、用错 OPatch、空间不够都会让流程直接中断。所以先把三件事查清楚再动手。2.1 确认当前基线v$version 与 registry$history 两条 SQL先确认你手上的数据库到底处于哪个版本状态。用 sysdba 登录后执行下面两条 SQL第一条看数据库版本号第二条看历史补丁记录。set linesize 120 select * from v$version; select action, namespace, version, comments, apply_date from registry$history order by apply_date;执行后要核实两件事数据库大版本必须是 11.2.0.1如果是 11.2.0.4 那对应的补丁逻辑完全不同registry$history 里能看到历史上已经打过的补丁编号。为什么要先查这个因为有些补丁要求前置补丁必须存在跳过了 OPatch 会直接报错。比如某个 PSU 补丁依赖之前的 CPU如果你没打apply 过程中会提示缺少组件。另一个原因是避免重复打补丁同样的补丁已经存在时再打一次会报冲突白白浪费时间。这里有个容易被忽略的细节registry$history只记录数据库层面的补丁历史不记录 OPatch 工具本身的版本。所以下面的检查要单独做。2.2 OPatch 版本与补丁目录两条命令看清单前置依赖11.2.0.1 环境里最常见的失败原因之一就是 OPatch 工具版本太旧。新补丁往往要求更高版本的 OPatch环境不满足时opatch apply很可能连检查都过不了。检查方式很简单$ORACLE_HOME/OPatch/opatch version如果版本不够先不要急着打补丁去资源平台下载对应平台的最新 p6880880 补丁包。替换 OPatch 的正确步骤是先把旧的 OPatch 目录改名备份再解压新的进去不要直接覆盖。mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak unzip p6880880_112000_platform.zip -d $ORACLE_HOME $ORACLE_HOME/OPatch/opatch version这一步我把 OPatch 单独拎出来讲是因为很多人会在网上搜到“更新 OPatch”的说法就直接覆盖结果旧目录里留存的历史记录全丢了后续排查反而更麻烦。先改名再替换万一新工具不适应环境还能退回去。OPatch 版本确认后把补丁包上传到服务器解压到一个独立目录。注意不要解压到 ORACLE_HOME 里面避免空间统计混乱。mkdir -p /u01/patch unzip /tmp/p补丁号_平台.zip -d /u01/patch ls -l /u01/patch/补丁号 cd /u01/patch/补丁号解压后的目录里一般会有 README 文件这是整个过程中最值得花时间读的东西。README 里会写明这个补丁的前置依赖、RAC 下的特殊要求、是否包含 SQL 变更、需要多少磁盘空间。很多人不做这一步结果到 apply 中间才发现前置补丁没装或者跑完了才意识到还有 SQL 脚本要执行。我一般的习惯是先用下面命令确认这个补丁是否已经存在$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 补丁号有输出说明已经打过这个补丁不用重复打没有输出再继续下一步。这一条命令也适用于打完后确认结果后面章节还会用到。2.3 备出后路RMAN 备份与参数文件备份的取舍打补丁本质上是在已有二进制和数据库对象上做变更不可能保证百分百成功。备份是唯一的后悔药。 常见的备份方案有两种RMAN 全备和冷备。RMAN 备份适合生产库备份过程中数据库可以继续服务但打完补丁发现要回滚时恢复时间会受备份策略影响冷备则适合小库或测试环境直接 shutdown 后拷贝数据文件恢复简单但停机时间长。rman target / RMAN backup database plus archivelog format /backup/rman/%d_%T_%U; RMAN backup current controlfile format /backup/rman/ctl_%T_%U;除数据文件和控制文件外参数文件也必须备份。11.2.0.1 默认使用 spfile打补丁过程中某些参数可能会被调整提前留一份 pfile 是最稳妥的。sqlplus / as sysdba SQL create pfile/home/oracle/spfile_$(date %Y%m%d).ora from spfile;备份的取舍要看窗口和风险。如果库只有几百 GB我倾向直接冷备比 RMAN 恢复更快如果库很大RMAN 全备加归档即可。但无论选哪种必须保证备份可被验证不光是命令执行成功最好单独把备份文件 list backup 一眼确认存在。备份这一步不做好后面的补丁流程就是赌运气。3. 补丁应用的四个标准动作关闭、apply、启动、跑 SQL在 11.2.0.1 上补丁应用的顺序基本是固定的先关闭数据库和监听再执行 opatch apply然后启动数据库最后执行 SQL 脚本。每一步都有前提条件遗漏任何一步都会造成问题。3.1 先让数据库安静停监听与 shutdown immediate打补丁期间不能有应用连接到数据库否则文件正在被占用apply 会失败或产生不可预期结果。所以第一步是停掉监听切断新连接。lsnrctl stop对于 RAC 环境还要考虑服务管理。可以通过 srvctl 逐个停止实例只停监听还不够因为 RAC 的实例会由集群软件自动拉起。srvctl stop instance -d 数据库名 -i 实例名然后把数据库关掉。单机环境直接进 sqlplus 执行 shutdown immediate 即可。sqlplus / as sysdba SQL shutdown immediate;shutdown immediate 会等待当前事务结束如果业务有大事务在跑这个命令可能等很久。最差的情况下才用 shutdown abort因为那会把恢复工作留到下次启动风险更高。 等数据库完全关闭后确认监听和实例的进程都已经消失再进入下一步。3.2 opatch apply 的执行与常见输出语义环境安静之后进入补丁解压目录执行 opatch apply。需要注意执行用户必须是 ORACLE_HOME 的属主一般是 oracle 用户。执行前再次确认环境变量PATH 必须包含 OPatch 目录。export ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1 export PATH$ORACLE_HOME/OPatch:$PATH cd /u01/patch/补丁号 $ORACLE_HOME/OPatch/opatch applyopatch apply 的输出会长一些关键是看开头、检查阶段和末尾这三个位置。开头会显示 OPatch 版本和正在应用的补丁号检查阶段会验证前置依赖、冲突补丁这一步如果出现错误就停止不会真正开始更新。末尾出现“Apply completed successfully”字样才算真正成功。所有日志也会写到 $ORACLE_HOME/cfgtoollogs/opatch/ 目录下所以 apply 失败时不用慌张去日志里搜 ERROR 关键字。有一点要注意opatch apply 不是一个原子操作。如果中途失败比如空间不足或权限错误ORACLE_HOME 里可能已经有一部分文件被替换部分旧文件被备份到 $ORACLE_HOME/OPatch/backup 目录。此时直接重新 apply 不一定能恢复现场需要先看日志按日志提示处理失败原因必要时先清理已产生的残留再重试。这个场景在第四章会具体展开。3.3 启动实例并执行 SQL 脚本区分 PSU 与 CPU 的脚本差异opatch apply 执行完只是二进制层面的补丁生效了。数据库内部的对象、数据字典版本还需要通过 SQL 脚本更新。这一步经常被遗漏也是很多环境打完补丁后应用报错“对象版本不一致”的原因。先启动数据库。根据 README 的要求判断是要普通启动还是 upgrade 模式。11.2.0.1 上的 PSU/CPU 补丁很多要求以 upgrade 模式启动因为脚本会更新数据字典和内部对象。sqlplus / as sysdba SQL startup upgrade;启动后执行 SQL 脚本。这里的关键是区分补丁类型PSU 补丁一般执行 catbundle.sqlCPU 补丁一般执行 catcpu.sql一次性补丁则要单独看 README有的补丁不需要 SQL 变更opatch apply 结束就算完事。sqlplus / as sysdba EOF spool /tmp/patch_apply.log ?/rdbms/admin/catbundle.sql psu apply spool off EOFcatbundle.sql 的执行参数里psu 表示补丁类型apply 表示应用。执行过程中会有大量输出最后会看到类似“Catalog Installation Complete”的提示。执行完日志后检查 spool 文件里有没有 ORA- 开头的报错有的话按错误处理没有就继续。脚本跑完后数据库处于 upgrade 模式需要重启一次回到正常状态。SQL shutdown immediate; SQL startup;这个重启动作同样不能省。很多环境打完补丁后直接对外提供服务数据库还留在 upgrade 模式业务会连不上或报内部错误。重启后立即查一下select open_mode from v$database;确认是 READ WRITE 再继续。4. 打补丁避坑指南五个高频故障与逐一修复这一章是实际运维中反复遇到的五个典型故障每一条都是真实场景里能对号入座的。按“现象、原因、解决”的顺序写遇到类似问题时可以直接照单操作。4.1 OPatch 版本过低OUI-67078 出现即停现象执行opatch apply后输出立刻报错关键信息包含 OUI-67078 或“OPatch version cannot be used”相关提示补丁完全没有开始应用。原因11.2.0.1 的历史比较久环境里的 OPatch 还是老版本而新补丁的元数据格式、校验逻辑依赖新版 OPatch。这不是补丁拒绝工作是工具本身不满足前置条件。解决按第二章里的步骤更新 OPatch先改名备份旧目录再解压新版然后重新执行opatch version确认。更新之后再跑 apply一般就能通过环境检查。 值得强调的是不要在报错后盲目强上有的补丁在 OPatch 版本旧的时候也能硬跑但应用后留下的元数据是损坏的后面做补丁回滚会无从下手。4.2 空间不足apply 中途失败的恢复现象opatch apply执行到一半终端输出“no space left on device”应用进程退出。此时 ORACLE_HOME 里可能已经有部分文件被替换补丁目录也没有完全清理干净。原因补丁包解压、运行时备份、日志写入都会消耗磁盘空间。很多人只看了补丁包本身的几个 GB没算 OPatch 的 backup 目录和 spool 日志空间预判不足。解决先看空间实际使用情况再决定清理方向。df -h /u01 du -sh $ORACLE_HOME/OPatch/backup du -sh /tmp/patch_apply.log /tmp/patch_apply*.log如果 backup 目录占了几 GB说明当前 ORACLE_HOME 已经被部分更新。此时不要直接再跑 apply正确的做法是把备份目录清理掉也不行因为旧文件还在那里等回滚时用。更稳妥的方式是先把当前 ORACLE_HOME 恢复成打补丁前的状态再重新打。恢复手段优先用第四章第 4.4 条里的备份恢复方案因为 apply 中途失败后的残留状态并不总是可回滚的。如果是 RAC 环境还有集群层面的文件一致性要求更需要从备份恢复而非手工清理。4.3 SQL 脚本报错ORA-04031 与字典版本不一致现象执行 catbundle.sql 或 catcpu.sql 中途报 ORA-04031意思是 shared pool 无法分配更多内存脚本中断或者脚本执行完了但后续查询数据字典时报“version mismatch”错误。原因前者多半是 shared_pool_size 在 upgrade 模式下不够用补丁脚本需要加载大量 PL/SQL 包和游标后者是脚本执行不完整或执行完没有正常重启数据库。解决先处理 ORA-04031。通常调整 shared_pool 后再重新执行脚本即可脚本本身支持重入不会重复应用已经完成的变更。sqlplus / as sysdba SQL alter system set shared_pool_size1G scopeboth; SQL alter system flush shared_pool;然后回到第三章的 SQL 脚本执行步骤重新跑一遍 catbundle.sql。跑完后确认 spool 日志尾部没有错误再 shutdown immediate 并正常启动。数据字典版本不一致的问题多数是因为上次脚本中途退出修复后重新执行脚本都能解决。如果仍然报 mismatch拿报错里的对象名去dba_objects里查确认是不是前置补丁没装导致的版本断层。4.4 回滚不彻底rollback 之后的第二次操作现象打完补丁后业务出现异常执行opatch rollback -id 补丁号显示 rollback 成功但数据库启动后问题依旧部分对象版本还是新补丁状态。原因二进制补丁回滚了但补丁里的 SQL 变更不会跟着回滚。比如 PSU/CPU 补丁的 SQL 脚本一旦执行对象已是新版本仅仅 rollback 二进制解决不了数据字典层面的变更。解决一定先看 README 的 Rollback 章节。里面会明确写哪些补丁支持回滚 SQL 变更、哪些不支持。不支持的回滚只能走备份恢复也就是打补丁之前做的那份 RMAN 备份或冷备。rman target / RMAN shutdown immediate; RMAN startup mount; RMAN restore database; RMAN recover database; RMAN alter database open;这个教训比较深刻执行补丁前要想清楚是否真的需要回滚路径。如果是小版本 PSU一般不建议执行回滚脚本直接 restore 数据库更干净。 回滚后还要重新执行一次opatch lsinventory确认补丁已经从清单里消失。4.5 RAC 环境漏掉节点版本不一致的连锁故障现象RAC 双节点环境只在 node1 上执行了 opatch applynode2 没有打数据库集群启动后实例间报版本不一致锁管理或消息通信异常。原因RAC 的所有节点必须处于同一个补丁基线只在部分节点打补丁会让集群层面的组件版本错位。有些 DBA 以为补丁只要打一次所有节点共享 ORACLE_HOME这依赖具体部署方式很多环境各节点有独立的 ORACLE_HOME必须逐节点操作。解决统一的处理思路是依次在每台节点上执行完整的补丁流程一个节点打完并确认无误后再操作下一个节点。每个节点都要经历停监听、shutdown、opatch apply、启动数据库、执行 SQL 脚本这些步骤SQL 脚本在其中一台节点执行即可但 opatch apply 必须每个节点都跑。 完成所有节点后用下面的命令确认所有节点补丁清单一致。srvctl status database -d 数据库名 $ORACLE_HOME/OPatch/opatch lsinventory如果出现节点二漏打的情况不要试图用复制目录覆盖的方式补救老老实实走一遍补丁流程。 RAC 场景最省心的做法其实是用 opatch auto它能一次性处理所有节点少数环境不支持时才逐个节点操作。5. 打完补丁后的三条验证路径与一项收尾习惯补丁打完了不代表任务结束。验证这一步大多数人做得太随意经常是看一眼 apply 成功就宣布收工。我一般会同时走三条验证路径。先查补丁是否真的进了清单在数据库层面看补丁历史再用一个真实业务查询做验证。命令分别如下。$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 补丁号select action, comments from registry$history where action like 补丁号% or comments like %补丁号%;这里要说明lsinventory 对应于二进制文件层面registry$history 对应于数据字典层面。两条都对上了才是真正的补丁成功。最后是红绿灯检查打开 alert log搜索 ORA-00600、ORA-07445 这类内部错误跑一个线上常用的查询或存储过程再执行一次dbms_stats.gather_table_stats看统计信息是否正常。这些都没问题才能放行给业务。收尾还有一件事我建议养成习惯把补丁包编号、应用日期、执行节点、跑了哪些 SQL 脚本、有没有回滚方案写进变更记录。下次再打补丁时先翻上一次的记录就能判断当前环境和上次差了几个补丁会不会因为补丁依赖出问题。 这个习惯说不上有多高级但已经不止一次帮我避免重复踩坑。希望帮到你。本文还有配套的精品资源点击获取