简介这是Oracle数据库11.2.0.3版本的官方补丁集更新包补丁编号20760997面向Linux x86-64架构环境对应DATABASE PATCH SET UPDATE 11.2.0.3.15集中收录2015年7月关键补丁更新CPUJUL2015适合负责Oracle数据库日常运维与安全加固的DBA、系统管理员参考使用。压缩包整体约100.73MB包内包含补丁安装程序及配套校验文件可结合官方Patch Search说明进行核对与部署文件相关明细暂未提供具体构成以实际下载内容为准。目前已有290人查看该资源。作为包含CPU安全更新的补丁集该资源可帮助管理员快速补齐已知安全短板、规避潜在攻击风险同时修复特定错误以提升数据库稳定性与性能对保障生产环境安全合规、维持业务连续运行具有直接参考价值。1. 一个Oracle补丁压缩包能解决什么先学会读这串文件名某个周一的下午安全通告下来要求测试环境里的某套Oracle库尽快打上最新的oracle patch。下载链接给的是一个Linux x86-64平台下的压缩包文件名p20760997_112030_Linux-x86-64.zip。第一次接触补丁的A同学对着这串字符有点发懵这是补丁号还是版本号解压前能不能判断它能不能直接apply如果装到一半失败了还能不能退回去这串文件名其实已经回答了大部分问题p开头的是补丁编号112030代表11.2.0.3.0版本Linux-x86-64明确限定了操作系统平台和位数。对于在Linux服务器上日常维护11g R2数据库的DBA和运维工程师来说这基本是每隔一段时间就要做一次的工作——下载、识别、检查、apply、踩坑、收尾。这篇笔记我按自己拆过的一批补丁包的流程来写先教你看懂文件名和补丁类型再讲OPatch检查和安装命令最后把最容易翻车的几个场景单独列出来。新手照步骤走能装完一整套熟手可以直接跳到避坑那章看有没有你还没踩过的坑。2. 补丁编号与版本选型先读懂p20760997再决定装不装2.1 从文件名拆出补丁号、版本号与平台Oracle官方的补丁压缩包命名有一套固定的套路格式一般是p补丁号版本号平台.zip个别特殊补丁还会在平台后面追加额外的标识位。拿p20760997_112030_Linux-x86-64.zip拆开看各段字符的对应关系如下文件名片段含义解读p20760997补丁编号p后面的7位数字是Oracle内部唯一的补丁ID在官方文档里可以用它定位到对应的Bug编号和修复描述112030数据库版本对应11.2.0.3.0即11g R2的第三个补丁集级别Linux-x86-64操作系统平台64位Linux覆盖常见的企业发行版版本号112030需要稍微展开一下。Oracle的五位版本号通常写作11.2.0.3.0压缩包里为了缩短文件名直接写成了六位字符串112030。对应关系是前两位11是大版本号第三位2是主版本发布号第四位0是维护版本号后面两位03是补丁集级别最后一位0是组件或平台版本。这套规则在11g、12c乃至19c的补丁包里基本通用只是版本号位数可能从6位变成8位比如19c的版本段可能写为19000或者包含更多限定字符。拿到任何一个以p开头的zip第一件事永远先拆文件名确认平台和版本跟当前服务器一致别等解压完了才发现下成了Solaris或者AIX的包。我见过有人在生产服务器上把AIX平台的补丁包传上去解压时直接报文件损坏一脸茫然最后查下来是平台不匹配。补丁包里的文件在不同平台上是按各自平台二进制编译的跨平台解压要么解压不完整要么解压出来文件权限和链接全乱套。2.2 PSU、CPU与单补丁的选型区别补丁文件名的数字本身看不出它是单补丁还是PSU这个信息要解压后看README.html。先把三类补丁的概念理清楚因为它们的选择逻辑完全不同单补丁One-off Patch针对特定Bug的一次性修复补丁典型场景是某个查询报ORA-00600官方给一个特定补丁号安装后只改变这一个组件的二进制文件。PSUPatch Set Update按季度发布的补丁集更新包含一批安全修复和重要Bug修复是DBA最常打的一类安装时需要同时应用二进制和SQL脚本两部分。CPUCritical Patch Update安全漏洞补丁更新偏重漏洞修复后来发布节奏与PSU合并调整很多CPU修复内容被并入了PSU。选型的判断标准有三个。第一个是Oracle官方的安装建议安全类修复优先装包含安全内容的PSU或CPU不要只装一个所谓的“紧急单补丁”就完事第二个是当前版本是否在补丁适用范围内11.2.0.3的库只能找11.2.0.3的补丁拿11.2.0.4的PSU过来套前置检查阶段就会被拦下来第三个是部署架构有的补丁只针对RAC组件单实例环境装了没有意义反而增加二进制与配置不一致的风险。我在实际选择时一般的原则是测试环境先跑全套流程生产环境严格按照变更窗口来没有明确Bug需要修时不装单补丁优先选PSU。原因是单补丁往往没有经过大规模集成测试与现有PSU或其他单补丁的组合可能产生新的冲突。对于这份p20760997补丁包如果README里在Prerequisites小节标注了依赖某个前置PSU那就需要先确认前置补丁是否已安装这一步千万别跳过后面避坑章会专门讲。2.3 判断当前环境是否需要补丁三条命令搞定动手之前先确认当前数据库的真实版本和补丁基线不要靠印象办事。连上数据库执行SELECT version, banner FROM v$version WHERE banner LIKE Oracle%;SELECT patch_id, action, action_time, status FROM dba_registry_sqlpatch ORDER BY action_time DESC;第一段SQL查的是数据库软件的版本号返回11.2.0.3.0说明库在11.2.0.3基线第二段查的是已经应用过的SQL补丁记录可以看当前补丁基线到底走到了哪一步比如已经装过哪个季度的PSU。把这两条结果与补丁包README里的前置条件对照就能判断该不该装。注意dba_registry_sqlpatch视图在11.2.0.3之前的版本里可能不存在旧版本可以用opatch lsinventory来看补丁记录。我还会额外加一步查操作系统层面的基础库版本因为部分Oracle补丁依赖系统的glibc或某些动态库。在测试机上发现过这样一个情况二进制补丁apply过程一切正常数据库启动时报找不到libaio符号原因是服务器上glibc版本过低。所以在装补丁前顺手执行rpm -qa | grep glibc看一下基础库版本再与README系统要求对照有效避免装到一半才暴露的系统兼容问题。3. OPatch与前置检查动手前必须过的三道关3.1 OPatch版本核对补丁能不能装一半看工具OPatch是Oracle提供的补丁管理工具打补丁前必须保证它的版本满足补丁包的最低要求。这个要求通常写在README.html靠前位置的“OPatch Utility Information”一节。先看当前工具版本$ORACLE_HOME/OPatch/opatch version如果返回的版本号低于补丁要求的最低版本安装阶段最常见的报错是OPatch无法解析补丁元数据或者apply一开始就退出并提示所需工具版本不满足。解决办法是从官方渠道下载对应版本的OPatch工具解压后覆盖到$ORACLE_HOME/OPatch目录。覆盖前建议先备份原目录cd $ORACLE_HOME mv OPatch OPatch.bak.$(date %Y%m%d) unzip /tmp/p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME opatch version文件名里的p6880880是OPatch工具包的标准编号后面的112000表示适用于11.2.0.0及以上版本的数据库平台同样是Linux-x86-64。这里有一个不少新手容易搞混的点OPatch工具与数据库版本不是严格一一对应的11.2.0.3的库也可以使用更新版本的OPatch但反过来旧工具版本配合新补丁包就会出现兼容问题。校验工具版本这个动作我一般放在解压补丁包之后的第一时间因为这样发现问题可以马上退出流程不用等环境折腾半天再失败。3.2 数据库状态与磁盘空间检查装到一半卡住的源头数据库层面的检查有两个重点一个是实例是否运行另一个是磁盘空间。Oracle补丁apply阶段要替换大量二进制文件$ORACLE_HOME所在文件系统必须预留足够空间。经验值是保留补丁包大小的1.5倍以上保守就直接留2倍。曾经见过补丁包2GB磁盘剩余1.8GBapply到一半无法写入新文件整个补丁打了一半最后只能把目录恢复回去重新来。检查命令df -h $ORACLE_HOME sqlplus / as sysdba SQL select open_mode from v$database;第一段命令查文件系统剩余空间第二段查数据库的打开模式。单实例打补丁时要求实例正常关闭后再执行apply所以看到READ WRITE模式只说明当前正常最后还是要执行shutdown。RAC环境则要求各实例状态正常因为滚动安装中会依次重启实例如果某个实例已经处于异常状态集群层面的操作很可能失败。还有一个容易被监控脚本坑到的地方$ORACLE_HOME目录被其他进程占用。比如监控探针、备份脚本、日志采集器如果长时间占用了$ORACLE_HOME下的二进制文件opatch在替换文件时会报文件被占用或文本文件忙。用一个命令揪出占用进程lsof D $ORACLE_HOME/bin | head -20查到是哪一个进程之后确认不是数据库本身相关进程再决定是停掉还是临时调整监控范围。注意不要在生产环境直接kill看起来可疑的进程先ps看命令行确认是监控脚本再处理。3.3 README与冲突检查把补丁包的“潜规则”读清楚每个Oracle补丁包解压后都有一份README.html或README.txt里面包含补丁ID、适用版本、依赖的前置补丁、已知问题、安装步骤和回滚方法。我在拆补丁包时按顺序看四部分Prerequisites前置条件、Installing the Patch安装步骤、Post-Installation安装后动作、Known Issues已知问题。前置条件直接决定能不能装安装步骤决定怎么装安装后动作决定要不要跑SQL脚本已知问题则是避坑指南。前置检查和冲突检查可以直接用OPatch自带命令cd /tmp/p20760997 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./这条命令用于检查补丁与当前Oracle Home中已有补丁是否存在冲突。如果输出出现“DB Home”和“OH conflict”相关字样说明存在冲突项需要先决定是移除旧补丁还是确认两者能否并存。注意-ph ./表示补丁路径为当前目录执行前必须保证当前目录是解压后的补丁根目录。这里有一个很常见的误区只解压不切换目录在补丁包zip所在目录直接执行命令结果opatch报“Patch Location is invalid”。因为./指向的目录里没有补丁元数据文件opatch自然找不到。建议进入补丁子目录再执行例如cd /tmp/p20760997/20760997这个子目录里才是补丁的真正内容。4. 补丁安装与回滚完整流程核心命令与参数解析4.1 单实例环境停库、apply、启库三步走单实例数据库的补丁安装流程相对简单但每一步的顺序不能乱尤其不能图省事在数据库开着的情况下直接apply那样大概率在替换二进制文件时报错。下面是完整命令序列# 1. 解压补丁包并保持目录属主正确 cd /tmp unzip p20760997_112030_Linux-x86-64.zip chown -R oracle:oinstall /tmp/p20760997 # 2. 停止监听和数据库实例 lsnrctl stop sqlplus / as sysdba SQL shutdown immediate; SQL exit # 3. 进入补丁真实目录执行OPatch apply cd /tmp/p20760997/20760997 $ORACLE_HOME/OPatch/opatch apply # 4. 启动数据库并应用SQL部分README中有要求时执行 sqlplus / as sysdba SQL startup SQL ?/rdbms/admin/catbundle.sql PSU第一步解压后做chown非常关键。以oracle用户执行opatch时如果补丁目录属于root会出现权限不足或属主不一致的报错尤其当Oracle的umask配置比较严格时解压出来的文件可能是root属主直接导致读取补丁元数据失败。第二步先停监听再停库shutdown immediate会把未提交事务回滚避免损坏数据比shutdown abort安全得多。第三步进入的是补丁子目录20760997而不是解压后的顶层目录这是文件结构决定的p20760997目录下还套着若干子目录真正被opatch识别的元数据在扩展名为.xml的文件所在层级。opatch apply执行过程中如果环境变量没设置好会在启动阶段出现OPatch会话警告。检查环境变量用echo $ORACLE_HOME echo $ORACLE_SIDapply完成后不要急着启动业务先看README的Post-Installation部分是否要求执行SQL脚本。catbundle.sql是PSU类型补丁需要用到的SQL脚本作用是把数据库内部组件的版本元数据与二进制同步成一致状态。这一步漏掉会出现一个很典型的现象opatch显示应用成功但v$VERSION里的PSU版本号不更新安全扫描工具也识别不到补丁已生效。4.2 RAC环境滚动安装和一次性安装怎么选RAC环境的补丁安装有两条路一条是逐节点滚动安装另一条是所有节点停掉后并行安装。滚动安装的优势是业务不中断但前提是补丁本身支持滚动。如何判断支不支持README的滚动安装章节会明确说明另外opatch auto命令也会在安装前自动检查。# 在其中一个节点上执行以root用户执行 $ORACLE_HOME/OPatch/opatch auto /tmp/p20760997/20760997 -oh $ORACLE_HOMEopatch auto是给RAC环境使用的自动化安装命令它会把补丁内容依次部署到集群的各个节点并在需要时自动来回切换服务。执行时必须以root身份运行否则无权控制集群资源。如果不打算用auto也可以手动逐节点操作流程是把目标节点的实例和监听停掉在该节点上执行opatch apply然后启动实例和监听再把所有节点走一遍。RAC环境踩得最多的坑在滚动安装过程中正在应用补丁的节点上的实例被集群自动迁移到了其他节点使得当前节点上的实例并没有处于正常关闭状态。opatch apply检测到实例还在运行直接报错并要求手动关闭。手动滚动安装的正确顺序应该是先用srvctl stop instance -d 库名 -i 实例名确保实例停止再执行apply最后用srvctl start instance启动。不要用kill -9粗暴关闭进程那会让集群状态不一致。4.3 安装后必须做的三件事查库存、看SQL补丁、扫告警日志apply结束不等于事情干完。我给自己定的规矩是从三个角度确认补丁真的落位了。第一查OPatch库存视图$ORACLE_HOME/OPatch/opatch lsinventory | grep -A 8 Installed Top-level Products正常情况应该在输出里看到20760997这个补丁编号以及它的补丁描述和状态标记。如果看不到说明apply过程虽然没报错但补丁没有正确注册。第二确认SQL补丁是否生效SELECT patch_id, action, status FROM dba_registry_sqlpatch WHERE patch_id 20760997;第三看数据库告警日志路径一般在$ORACLE_BASE/diag/rdbms/sid/sid/trace/alert_sid.log。启动后观察有没有与补丁相关的新错误特别是ORA-00600、ORA-07445这类内部错误。它们在补丁更新后出现通常意味着补丁和已有组件不兼容需要进一步查MOS文档。4.4 回滚命令与参数错了怎么退回来补丁安装不是只能前进不能后退。如果apply之后业务系统出现严重回归比如某条核心SQL性能明显下降或者某个存储过程报错可以在确认是补丁引入的问题后执行回滚# 停库后执行回滚 lsnrctl stop sqlplus / as sysdba SQL shutdown immediate; SQL exit cd /tmp/p20760997/20760997 $ORACLE_HOME/OPatch/opatch rollback -id 20760997回滚命令中的-id指定的是补丁编号与文件名中p后面的数字一致。回滚完成后再启动数据库此时还需要考虑SQL脚本是否需要反向执行。部分PSU在回滚说明里会要求重新执行某个bundle脚本具体以该补丁README的Rollback章节为准。我在做回滚前一定会保存一份安装时的完整库存清单作为对比基线后面验证时能清楚地看到回滚是否彻底。5. 避坑指南Oracle补丁最容易翻车的五个场景5.1 现象opatch apply报“OPatchSessions are not allowed”第一次执行apply时OPatch直接拒绝错误信息大意是不允许在当前会话中执行。原因通常是当前用户通过SSH登录后su到oracle用户环境变量里残留了原来用户的ORACLE_HOME路径或者当前Shell会话不是登录Shell导致OPatch认为是非交互式会话。解决办法是干净地重新登录先退出当前SSH会话直接用oracle用户登录或者至少用su - oracle加载完整环境变量。登录后先执行env | grep ORA看看有没有残存的变量确认OK再执行opatch。这个现象在新环境里特别常见不是权限问题单纯是会话不干净。5.2 现象解压补丁包时报文件损坏或CRC校验错误解压到某个安装文件时出现CRC错误或者提示文件意外结束。多数情况下是zip文件从Windows下载后传输到Linux时使用了文本模式或者传输过程中文件被中断。还有一次遇到某个压缩包被人用压缩软件二次修改过虽然能解压但文件内容已不完整。解决办法在Linux服务器上直接下载补丁包不要中间倒手如果必须在Windows下载传输时用二进制模式上传后立即用md5sum对比官方校验值。补丁包文件较大传输后校验这一步不要省我一般会写一段简单的校验命令记录到变更单里md5sum p20760997_112030_Linux-x86-64.zip5.3 现象opatch lsinventory能看到补丁但v$VERSION版本号没变化这是最迷惑人的一种失败。二进制补丁确实装上了库存里也能看到20760997但数据库版本视图里的PSU版本没有更新。原因几乎都是漏掉了SQL脚本部分。补丁的二进制部分只替换了Oracle Home下的可执行文件和动态库数据库内部的数据字典版本必须靠catbundle.sql之类的脚本同步。解决办法是补跑SQL脚本然后重启数据库再查询。注意这里有一个小细节跑SQL脚本前要确认数据库已打开脚本执行过程中不要做DDL操作要给它一个干净的运行环境。跑完后再次执行SELECT * FROM dba_registry_sqlpatch WHERE patch_id 20760997;5.4 现象RAC滚动安装时实例漂移导致apply报错RAC环境手动逐节点安装时正在应用补丁的节点报“实例仍在运行”但该节点上明明已经执行过shutdown。原因是集群的节点可用性检查发现实例停止后自动把服务漂移到了其他节点而当前节点的集群资源状态里记录的是实例受管关闭后被重启。解决办法是在执行apply前用srvctl stop instance显式停止目标实例并确认状态为STOPPED而不是用SQL shutdown后不管半路状态。如果进一步用crsctl status resource看到实例资源处于ONLINE状态说明集群又把它拉起来了要排查为什么自动重启一般和集群的失败恢复策略有关。更省事的方式是直接用opatch auto让工具来处理实例和服务的往返切换。5.5 现象补丁冲突检查阶段报与已有补丁存在冲突opatch prereq CheckConflictAgainstOHWithDetail执行后输出里列出与当前已装补丁的冲突信息。原因通常有两种一是已经打过一个相同组件的单补丁二新补丁本身不建议与某些旧补丁并存。此时最忌讳的是强行apply。解决办法是先查看冲突的补丁ID确认该补丁是否还有保留价值。如果它修的问题已经被新补丁覆盖可以先回滚旧补丁再apply新补丁。回滚旧补丁的命令格式与新补丁回滚相同只是-id换成旧补丁编号。处理完冲突后重新执行冲突检查确认输出干净再进入apply。6. 验证补丁是否生效的三个技巧附回滚后悔药第一个技巧是用opatch lsinventory的详细模式过滤补丁编号确认二进制层面的安装情况$ORACLE_HOME/OPatch/opatch lsinventory -detail 21 | grep -i 20760997输出中能看到补丁的安装时间、装到哪个Oracle Home、是否属于基础版本补丁。这里的-detail参数会把每个补丁的下拉明细也打出来过滤之后能看到补丁对应的Bug列表方便和变更申请单里的修复内容做对照。第二个技巧是查数据字典里的SQL补丁记录确认SQL层面对齐SELECT patch_id, patch_type, action, status, action_time FROM dba_registry_sqlpatch WHERE patch_id 20760997;状态列显示SUCCESSaction_time是最近一次修改时间说明SQL脚本确实执行完成了。如果状态是STARTED或者显示为空说明SQL部分未完成需要回补。第三个技巧是做一次完整的安装前状态快照我给这个动作起名叫“后悔药”。在apply之前先把当前补丁库存和数据库版本信息都保存下来$ORACLE_HOME/OPatch/opatch lsinventory -detail pre_patch_lsinventory_$(date %Y%m%d).txt sqlplus / as sysdba SQL spool pre_patch_db_version.txt SQL SELECT * FROM v$version; SQL SELECT * FROM dba_registry_sqlpatch; SQL spool off这份快照在验证和回滚时都极其有用。验证时拿当前输出与快照diff能精确看到补丁加进来了哪些内容回滚时拿它当作目标状态能确认回滚后是不是恢复到了安装前。如果没有这份快照回滚完都不知道自己有没有彻底滚干净。从那以后我每次打Oracle补丁都强制走一遍这套流程确认文件名与平台版本核对OPatch工具版本跑冲突检查备份库存快照apply后分别查opatch输出和dba_registry_sqlpatch任何一步有疑问就先停下来查README而不是硬着头皮继续。这套习惯救过我至少两次一次是阻塞了错误平台的补丁包安装另一次是在SQL脚本漏执行前拦下了“补丁看似成功但版本没变”的隐患。希望帮到你。本文还有配套的精品资源点击获取
