接手一套老旧的Oracle 11g单库环境最躲不开的运维操作就是打PSU补丁。这里说的Oracle 11g绝大多数场景都是11.2.0.4因为这个版本是11gR2最后一个长期维护的release而PSU全称是Patch Set Update可以理解成Oracle官方每个季度打包好的一批安全修复加高影响Bug修复。单库环境相比RAC集群来说没有多节点和共享存储的牵扯补丁安装路径要清爽很多但该踩的坑一个都不少。这篇内容我尽量把整套流程从准备到收尾讲清楚包括为什么有些步骤必须做、有些命令输出怎么读、以及我实际动手时遇到过的问题。适合正在维护11g单库的DBA也适合第一次被安排去打补丁、对着MOS文档有些不知所措的运维同学。1. 动手之前先把打补丁这件事想明白1.1 为什么11g数据库必须持续打PSU很多人觉得数据库能正常跑就别动它。这个想法在业务稳定期可以理解但对于Oracle 11g这种已经停止免费Premier Support的老版本来说不动的代价往往比动一下更高。Oracle官方对11.2.0.4的PSU更新持续了很多年哪怕在Extended Support期间也还在按季度发布安全补丁。PSU里面装的不只是安全漏洞修复还有大量在高并发、特定SQL形态下才会触发的内部Bug修复。我自己遇到过的情况是某套库在某些时段出现奇怪的cursor: pin S等待排查半天最后在MOS上搜索发现对应Bug在某个PSU里被修复了。从那时候起我对打PSU这件事的态度就变成了只要条件允许跟上官方季度补丁节奏宁可花一个维护窗口做一次预防性维护也别等线上出问题再救火。单库环境其实很适合做这个事没有RAC那么多约束一个停机窗口就能完成大部分操作。1.2 单库环境与RAC环境的本质差异我开始接触Oracle补丁的时候先看的是RAC环境文档结果被一堆节点、滚动更新、集群资源的概念搞得头大。后来在单库环境里操作一次才意识到两者的复杂度差距非常大。单库环境只有一个ORACLE_HOME一套数据库实例没有CRS资源、没有ASM磁盘组跨节点的顾虑。补丁安装的位置就是本机ORACLE_HOME安装过程中只需要保证实例停止或者处于指定状态。而RAC环境如果是共享ORACLE_HOME补丁需要所有节点串行处理如果是非共享每个节点都要单独打。再加上滚动更新要逐节点停实例、逐节点验证工作量完全是单库的好几倍。所以接到单库打PSU的任务心态上可以先放松一点。流程框架就是备份、升级OPatch、检测冲突、正式apply、跑SQL脚本、验证。没有集群层面的并行约束。1.3 先确认当前环境和目标补丁版本不要拿到一个补丁包就急着apply。第一步永远是确认当前数据库和ORACLE_HOME状态。你至少要知道当前版本号、已经装过哪些补丁、OPatch工具版本是否满足要求。确认数据库版本SELECT * FROM v$version;确认ORACLE_HOME里已经装的补丁$ORACLE_HOME/OPatch/opatch lsinventory这一步的输出非常关键它会列出当前oracle home里的所有补丁信息。拿到这个清单你才能判断新PSU和已有补丁之间有没有冲突。同时通过MOS或者补丁README确认你下载的PSU编号是不是适用于11.2.0.4以及对OPatch工具的最低版本要求。我当时实际操作时目标补丁目录名是31537677这里用它做示例实际以你从MOS下载的补丁号为准安装前我先看了一眼当前OPatch版本发现10.2版本太老连prereq检查都有问题所以直接先做了OPatch升级。2. 安装前准备做扎实后面才省心2.1 备份不是万能的但没备份是万万不能的单库环境打PSU风险集中在ORACLE_HOME的二进制文件变更和数据字典脚本的更新上。备份策略我一般分三层来做。第一层是数据库数据文件的备份。最直接的方式是用RMAN做一次全备如果条件允许连同归档日志一起备份。虽然PSU补丁正常情况下不动数据文件但后续datapatch阶段如果执行数据字典脚本时出现意外如果需要做不完全恢复备份就是保命符。第二层是ORACLE_HOME的备份。这一步很多资料里提得不够细。ORACLE_HOME备份不需要连数据文件一起拷那太占空间。只需要把$ORACLE_HOME整个目录用tar打包到另外的文件系统即可注意软链接要保留。命令大致是tar -czpf /backup/oracle_home_$(date %Y%m%d).tar.gz /u01/app/oracle/product/11.2.0/dbhome_1压缩过程可能耗时我当时用了大概30分钟取决于ORACLE_HOME的大小。注意备份ORACLE_HOME的时候建议数据库处于停止状态否则文件正在被占用备份出来的内容可能不完整。第三层是OPatch自身的备份。OPatch升级和打补丁的过程中会修改OPatch目录所以升级前先把它复制一份cp -rp $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak_$(date %Y%m%d)这三层备份做完后面不管遇到什么问题至少都有后路。2.2 OPatch版本升级最容易忽略但最关键Oracle在不同时期发布的PSU对OPatch版本有最低要求。如果OPatch版本不够opatch apply可能直接报错或者prereq检查信息不准确。升级OPatch本身不复杂但有一个细节容易踩坑替换OPatch前必须备份旧版本否则新OPatch和现有补丁信息不兼容时想回退都麻烦。查看当前OPatch版本$ORACLE_HOME/OPatch/opatch version升级OPatch时先从MOS上下载对应版本的OPatch包通常是p6880880开头的zip文件。解压后把里面的OPatch目录内容覆盖到$ORACLE_HOME/OPatch下unzip -o p6880880_112000_Linux-x86-64.zip -d /tmp/opatch_update cp -rf /tmp/opatch_update/OPatch/* $ORACLE_HOME/OPatch/覆盖后再次确认版本$ORACLE_HOME/OPatch/opatch version另外要注意权限问题。如果ORACLE_HOME属主是oracle用户那所有操作都要用oracle用户执行不要用root也不要用sudo否则很容易产生文件属主不一致的问题后面opatch可能因为权限不够无法写入。2.3 补丁包解压和README阅读不能省从MOS下载下来的补丁包一般是zip文件。解压到独立的目录比如/u01/psu/31537677不要在ORACLE_HOME里直接解压避免造成文件混乱。解压后第一步是看README。README里包含了非常多的关键信息包括适用版本、对OPatch的最低要求、安装步骤、是否有额外的SQL脚本需要执行、回滚方式等。很多人打补丁失败都是因为跳过了README按照网上搜到的教程照搬操作。实际上不同时间点的PSU安装步骤可能有细微差别比如有的补丁要求在mount状态下执行脚本有的要求open状态有的不需要跑数仓脚本。READ ME才是唯一可信的SOP。3. 正式安装PSU补丁的完整实操过程3.1 先做冲突检测别让apply成了突袭战补丁冲突检测这个步骤我见过有人跳过理由是想直接试一把失败了大不了回滚。我的建议是千万别这么干。冲突检测只需要几十秒能直观告诉你当前ORACLE_HOME里已有的补丁和新PSU之间是否有重叠或冲突。以我那次31537677补丁为例操作命令是cd $ORACLE_HOME $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/psu/31537677如果输出包含类似“No conflict”的信息说明没有冲突可以放心继续。如果有错误或警告需要逐个确认。常见的冲突场景包括ORACLE_HOME里已经装了某个单独的Patch而新PSU里包含了相同模块的修复导致补丁编号重叠又或者是之前打过的小补丁在这个PSU里已经作为基础补丁包含进去了需要先移除旧补丁。这一步输出的日志保存在$ORACLE_HOME/cfgtoollogs/opatch/目录下检查时也可以直接看日志文件来确认冲突详情。3.2 数据库的关闭与opatch apply执行正式apply前数据库要关闭。单库环境比较纯粹直接sqlplus / as sysdba SQL shutdown immediate;如果是RAC环境这一步骤还需要逐节点处理单库就是一步到位。关闭数据库后确认监听也停止或至少数据库状态为DOWN避免连接请求持续进入。然后设置好环境变量确保ORACLE_HOME、PATH中包含$ORACLE_HOME/OPatchexport ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$ORACLE_HOME/bin:$PATH执行安装命令cd $ORACLE_HOME $ORACLE_HOME/OPatch/opatch apply /u01/psu/31537677执行过程中opatch会先做各种本地检查然后开始更新二进制文件。整个过程根据补丁大小和服务器IO能力可能需要10到30分钟。期间不要开其他工具去动ORACLE_HOME目录不要中断终端。opatch apply的日志默认会写到当前目录下的opatch_日期时间.log文件如果中途有任何问题这个日志是排查的第一手资料。我记得那次apply完成后返回信息显示“OPatch succeeded”但这不是终点。数据库还没起来数据字典也还没动真正的关键阶段还在后面。3.3 数据字典更新不跑脚本等于没打完这是整个PSU安装过程中最容易被忽略、也最容易出麻烦的一步。PSU补丁里通常包含两类内容一类是二进制文件替换另一类是数据字典、存储过程相关的SQL脚本。前者的作用是在ORACLE_HOME层面修复问题后者的作用是修改数据库内部对象让数据库行为和新的二进制保持匹配。在11.2.0.4环境中大部分较新的PSU都可以使用datapatch工具来自动执行数据字典更新。操作步骤是先把数据库启动到open状态sqlplus / as sysdba SQL startup;然后执行$ORACLE_HOME/OPatch/datapatch -verbosedatapatch会去识别当前数据库版本以及ORACLE_HOME里新注册的补丁检查哪些补丁需要跑SQL脚本然后自动执行。执行完成后它会生成日志通常在$ORACLE_HOME/OPatch/datapatch_日期.log里面有类似“Patching component”的说明。有一点要特别注意datapatch要求数据库处于open状态并且当前用户有SYSDBA权限。如果数据库只启动到mountdatapatch会报错或者直接不干活。我当时还见过一种情况数据库版本和ORACLE_HOME中的补丁版本不完全匹配datapatch会提示某些组件版本不一致这时候需要先检查数据库组件版本必要时手动跑一遍udump或相关脚本。如果补丁README中明确说明需要手动执行catbundle.sql而不是使用datapatch那就按README来。在11.2.0.4早期PSU中这种方式更常见一些。手动执行的关键是顺序不能乱、脚本不能漏执行过程中要持续观察日志输出。3.4 安装后的验证与信息归档补丁apply成功、数据字典更新完成后不能直接宣布收工。我的习惯是把它当作一次完整的上线变更来对待有明确的checklist。第一确认补丁已正确注册在ORACLE_HOME中$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 31537677如果输出里能看到补丁编号说明二进制层面已注册成功。第二确认数据库侧补丁信息。在11.2.0.4中已经可以通过DBA_REGISTRY_SQLPATCH查询SELECT PATCH_ID, PATCH_TYPE, ACTION, STATUS, DESCRIPTION FROM DBA_REGISTRY_SQLPATCH;如果有记录且状态为SUCCESS说明数据字典层面的补丁也已生效。第三检查alert日志看是否有ORA-错误、内部错误。常见的是某些数据库包在补丁后被重新编译如果依赖顺序有问题启动时可能会报错。可以查询无效对象SELECT owner, object_name, object_type, status FROM dba_objects WHERE status INVALID ORDER BY owner, object_name;如果出现无效对象先结合补丁说明判断是否为预期行为。很多时候数据字典更新后内部包会重新编译无效对象列表需要经过一段缓冲时间后自动恢复如果持久不恢复则需要手动编译?/rdbms/admin/utlrp.sql最后把opatch lsinventory的完整输出保存到本地文档作为这一轮补丁基线。下次不管是排查问题还是打新补丁这份清单都能帮你快速定位当前库处于什么补丁水平。4. 常见问题与排查技巧实录4.1 opatch prereq报错不满足、有冲突我遇到过的报错主要分两类。一类是OPatch版本太低系统直接提示需要升级OPatch到某个版本以上这时候回到2.2节的处理流程。另一类是冲突检测输出ERROR提示ORACLE_HOME中已有补丁和新的PSU冲突。处理冲突的时候最忌讳的是直接强装。opatch apply有个force选项但它不会真正解决冲突只是跳过检查可能会把ORACLE_HOME弄成半新的状态数据库启动都变得不可控。正确做法是把已有补丁的情况梳理清楚如果旧补丁是可回滚的并且新PSU已经包含了它的修复内容就先回滚旧补丁再安装新PSU。如果旧的补丁无法回滚需要联系Oracle支持或者在MOS上确认是否存在替换方案。4.2 磁盘空间不足这个是单库环境打补丁时特别容易忽略的问题。ORACLE_HOME目录所在文件系统在安装过程中不仅需要放补丁包解压内容还要保存opatch的备份文件。opatch apply时会把被替换的二进制文件先备份到$ORACLE_HOME/.opatchbackup目录补丁大一点备份目录可能占用好几GB。如果空间不够apply会中途失败而且失败后opatch可能还尝试回滚回滚过程中空间不足就更麻烦了。所以打补丁前先用df -h $ORACLE_HOME du -sh /u01/psu/31537677看一下剩余空间和解压补丁占用的空间至少保证ORACLE_HOME所在文件系统有3到5GB的剩余空间比较稳妥。如果空间紧张可以清掉ORACLE_HOME下的旧trace文件、旧的tar包、过期的日志文件再重新检查空间。4.3 datapatch执行失败或没有任何反应datapatch执行失败常见有两个原因。一个是数据库没有处于open状态我之前已经说过这里再强调一次。另外一个原因是ORACLE_HOME环境变量没有正确设置导致datapatch找错了oracle home。如果datapatch执行后日志里没有任何内容多半是shell环境有问题。可以先试着执行$ORACLE_HOME/OPatch/datapatch -help如果能正常输出帮助信息说明工具本身没问题。如果报类似“无法识别命令”优先检查ORACLE_HOME路径、权限和环境变量。还有一种情况是数据库刚启动datapatch去查询DBA_REGISTRY_SQLPATCH时发现组件状态不对比如某些组件版本和补丁预期不一致。这种问题最稳妥的办法是把数据库完全关闭重新启动确保实例状态稳定后再跑datapatch。4.4 安装完成后应用侧报错补丁装完数据库也正常启动但业务侧或应用连接池报出奇怪的错误比如存储过程失效、包状态异常。这些不少情况下和PSU本身无关而是数据库内部对象需要重新编译或者应用缓存了旧的游标信息。遇到这种情况先看数据库alert日志确认是否存在ORA-04068等错误然后查询无效对象并执行utlrp。如果无效对象非常多可能是数据库升级脚本没有完全执行完需要回头检查datapatch日志。另外建议在打补丁完成后通知应用团队刷新连接池很多诡异问题在重建连接后自然消失。4.5 补丁回滚方案如果安装后数据库无法正常启动或者某个核心功能异常影响业务就需要快速回滚。单库环境的回滚比RAC简单但也要按步骤来。先关闭数据库然后执行opatch rollback。比如回滚31537677$ORACLE_HOME/OPatch/opatch rollback -id 31537677opatch rollback会根据补丁安装时保留的备份文件恢复原来的二进制文件。回滚完成后重新启动数据库再一次执行datapatch因为二进制回到旧版本后数据字典也需要相应回退到旧补丁状态。这一步很容易忘如果忘了跑数据库可能出现补丁版本不一致的情况表面看库里已经没有任何新补丁的记录但实际上部分数据字典对象还是新状态时间久了容易埋雷。5. 给单库环境维护者的建议清单打PSU补丁这件事真正难的从来不是命令本身而是前期的盘点和后期的验证。结合我的实际经验整理几条建议给大家参考。第一不要依赖记忆要建文档。每次打完补丁马上把opatch lsinventory输出、datapatch日志、alert日志里关键告警信息存到运维档案中。这样半年后再来一次升级直接对照旧记录就知道差距在哪里既能快速判断是否还有未打的补丁也能在补丁出现问题时精准定位引入点。第二养成先测试再生产的习惯。如果条件允许先在测试环境用同样的版本、同样的补丁包执行一遍。很多时候你以为自己很熟练了但实际环境中的不变量、初始化参数、磁盘空间、第三方工具可能带来各种变量。一套测试库跑通心情完全不一样。第三别忽略心态和沟通。单库环境打补丁虽然技术面不复杂但它有停机窗口影响业务。提前和业务侧、应用侧沟通清楚窗口时间确认备份完成后再动手遇到意外不要慌张回滚预案写在纸上操作步骤就能稳。我个人习惯是准备一个操作时间表把每个动作的预估时间、负责人、验证标准写清楚执行一项勾一项减少人为疏漏。我在实际维护中最大的体会是补丁安装真正的成本不在那几个小时的停机而在事前是否充分准备、事后是否认真验证。只要把备份、冲突检查、数据字典更新、验证这些环节老老实实走完Oracle 11g单库环境的PSU补丁安装其实是一套非常成熟、可靠的操作流程。希望这篇内容能帮你把这条路走得更顺。
