简介针对甲骨文数据库11.2.0.3版本中网格基础设施GI与数据库组件的最终补丁集更新版本15面向Linux 64位平台是数据库管理员与系统运维人员维护集群、自动存储管理及数据库环境的重要资源。该补丁集成了自上一版本以来的安全修复、性能优化与常见问题解决方案覆盖集群注册表、表决盘等关键组件可降低已知故障风险提升系统高可用性。压缩包大小约599.65MB内含说明文档、补丁工具所需的XML配置清单以及独立补丁编号文件可帮助升级前核对依赖、规划操作顺序并辅助处理常见报错补丁应用过程中所需的关键信息基本都能在包内找到。目前已有398人学习下载适合需要为生产或测试环境完成最后一轮补丁升级的数据库技术人员参考。 前阵子在查一套老环境的补丁清单顺手翻到了p20996944这个编号。不少同行可能看到“Oracle 11.2.0.3”、“最后的GI PSU”这几个词就头疼一套跑了七八年的系统硬件和业务都指望着它到底还动不动补丁怎么动动了以后会不会出幺蛾子这些问题只有真正在机房里熬过夜的人才能体会。这篇就围绕这个最后的GI包含DBPSU补丁也就是p20996944_112030_Linux-x86-64.zip把它的来历、文件结构、打补丁的完整流程以及回滚和运维里容易被忽略的坑尽量讲明白。1. 为什么说这是11.2.0.3的“最后的GI PSU”1.1 从生命周期看这个补丁的意义Oracle 11.2.0.3这个版本在数据库圈子里几乎快成“活化石”了。Premier Support很早就结束Extended Support也已经走过收尾阶段。可现实是很多企业的核心库仍然跑在11.2.0.3上不是不想升级而是业务系统绑定的第三方组件、内部历史包袱让升级成本高到不敢动。在这种背景下Oracle在11.2.0.3维护末期发布的GI PSU就成了这些系统能拿到的最后一批“官方认证”修复。p20996944这个补丁包版本号.15涵盖Grid Infrastructure和RDBMS两部分组件是11.2.0.3主版本下最后发布的GI补丁之一。业内统称它为“最后的GI PSU”不是说以后再没有单体热补丁而是说常规的月度/季度PSU序列到这里就画上了句号。1.2 GI PSU和普通DB PSU的区别很多人容易混淆GI PSU和普通的数据库PSU。普通的DB PSU就是只针对数据库HomeRDBMS的补丁集合修的是SQL引擎、优化器、数据字典、RMAN、EXP/DP这些组件的问题。而GI PSU全称是Grid Infrastructure Patch Set Update它覆盖的范围要大得多除了数据库Home里的内容外还包括Clusterware集群件crsd、cssd、evmd进程ASM实例和ASM磁盘组管理Oracle Cluster RegistryOCR和表决盘相关逻辑监听器Listener在GI Home下的版本集群时间同步服务CTSS、GNS等附属组件所以你会看到p20996944这个zip解压后里面通常包含Grid和DB两个子目录。Grid目录对应GI Home的PatchDB目录对应RDBMS Home的Patch。实际打补丁时这两个Home要分别应用漏掉任何一个都不完整。1.3 为什么还值得写它你可能觉得既然已经这么老的版本了直接不补不就行了实际操作里还真不行。我遇到过不少场景等保测评要求列出系统补丁情况安全扫描要求修复已知高危漏洞新上线的监控工具要求数据库版本满足某个最低PSU基线。这时候p20996944就是11.2.0.3系统能交出的“最高分答案”。另外一个现实原因很多存量系统的GI Home和DB Home混装在同一套主机上运维团队想把补丁统一管理又不敢随便动集群所以对这套补丁的适用范围和实施细节需求特别高。这篇文章的核心就是把这套补丁从拿到手到打完收工的全过程拆开顺带把几个容易踩的坑标出来。2. 补丁文件与安装前环境核查2.1 解压与文件构成先从Oracle Support上下载p20996944_112030_Linux-x86-64.zip文件名里的112030对应11.2.0.3 Linux-x86-64对应平台。下载之后先别急着解压到生产机建议放到一个独立目录比如/u01/psu$ mkdir -p /u01/psu $ mv p20996944_112030_Linux-x86-64.zip /u01/psu/ $ cd /u01/psu $ unzip -q p20996944_112030_Linux-x86-64.zip解压完成后目录结构大致是20996944/主补丁目录20996944/GI Home或DB Home对应子目录之一另一个子目录可能带有类似“/rdbms”或“/grid”标识README.txt或类似命名的文档不同补丁包内部命名略有差异但核心逻辑一样一个子目录对应Grid Infrastructure Home的补丁另一个对应RDBMS Home的补丁。README文档一定要读里面会写明最低OPatch版本要求、应用顺序、已知问题。2.2 关键前置项OPatch版本与Inventory打补丁前最基础也最关键的一步是确认两个Home的OPatch版本。11.2.0.3时代的老补丁对OPatch版本要求相对宽松但p20996944属于晚期补丁要求通常不低于11.2.0.3.10或者更高版本具体以README为准。检查OPatch版本$ $GI_HOME/OPatch/opatch version $ $ORACLE_HOME/OPatch/opatch version如果版本不够需要先去下载对应平台的p6880880补丁包分别更新GI Home和DB Home里的OPatch工具。这一步很多人会漏尤其是GI Home因为DBA日常不常碰它。OPatch版本不匹配时打补丁会直接报“OPatch version must be”之类的错误提前检查能省掉很多折腾。Inventory的完整性也需要确认$ $GI_HOME/OPatch/opatch lsinventory -detail $ $ORACLE_HOME/OPatch/opatch lsinventory -detail看输出的Home路径、已安装补丁列表是否正常。如果之前有人手动删过补丁文件或者多次应用失败导致inventory脏了打新补丁时会遇到冲突检测失败。这时候需要先清理而不是硬着头皮继续。2.3 补丁冲突与依赖检查p20996944自身是累积型的PSU理论上包含之前PSU的修复内容。但环境里可能打过其他独立补丁one-off patch存在冲突风险。OPatch提供前置检查命令$ $GI_HOME/OPatch/opatch prereq CheckApplicable -phBaseDir /u01/psu/GI子目录 $ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/psu/DB子目录如果输出里有“Conflict”字样说明环境里已有补丁和这个PSU冲突。常见原因是有些DBA为了临时修复某个Bug打了一个one-off补丁而这个补丁后来被合并进了PSU于是冲突。处理方式一般是先回滚那个one-off补丁再打PSU具体以Oracle技术支持建议为准。磁盘空间也需要看一眼$ df -h /u01GI和DB两个Home解压和备份都需要空间建议至少留10GB以上余量否则中途才发现空间不足回退起来很被动。3. 正式实施GI PSU打补丁的完整链路3.1 准备阶段备份和停机决策打GI PSU最理想的方式是RAC滚动更新逐个节点滚动业务不中断。但很多老系统的维护窗口普遍安排在凌晨DBA也更倾向直接停所有节点一次性把GI和DB都打完这样操作链路最短、排错最容易。如果你的系统允许短暂停机建议用整体停机方案省心很多。停机前必须做的三件事备份OCR和表决盘$ $GI_HOME/bin/ocrconfig -export /backup/ocr_before_psu_$(date %Y%m%d).bak $ $GI_HOME/bin/crsctl query css votediskOCR的备份文件放到本地或共享存储都行保证能读到。表决盘不用拷贝文件但要把votedisk路径记录下来万一后续出现集群起不来可以用来排查。记录集群状态基线$ $GI_HOME/bin/crsctl stat res -t -init $ $GI_HOME/bin/crsctl stat res -t记录下各个资源的online/offline状态方便打完后对照确认没有资源异常。关闭数据库实例和集群$ srvctl stop database -d dbname $ $GI_HOME/bin/crsctl stop cluster -all $ $GI_HOME/bin/crsctl stop crs如果是单节点集群直接crsctl stop crs即可。3.2 应用GI Home补丁进入GI Home的补丁目录执行$ cd /u01/psu/GI子目录 $ $GI_HOME/OPatch/opatch applyopatch apply在应用前会再次做适用性检查看到“Patch applied successfully”字样才算成功。这里有个容易忽略的点老版本OPatch在apply过程中可能会尝试连接MetaLink现在叫My Oracle Support获取更新如果有外网隔离会出现连接超时的情况。解决方法是加参数$ $GI_HOME/OPatch/opatch apply -skip_subset -skip_duplicate不过这两个参数不是必须的关键是先确认库“是否和MetaLink连通”不连通时用本地模式反而更稳。实际执行时opatch会检查补丁是否已存在、是否冲突。如果不报错很快会进入root脚本阶段。这一步输出的末尾会提示需要在每个节点以root身份执行脚本# $GI_HOME/rdbms/install/rootadd_rdbms.sh # $GI_HOME/rdbms/install/root.sh不同补丁包提示的脚本名可能略有差异一般包括root.sh和rootadd_rdbms.sh这类。在RAC多节点环境里GI补丁打完一个节点后要等root脚本执行完毕再继续打下一个节点。不要所有节点一起并行打集群配置更新会打架。3.3 应用DB Home补丁GI Home打完并不代表数据库Home也打完了。p20996944这个补丁包里“包含DB”的意思就是DB Home也要分别应用对应的子补丁。这一步很容易被遗漏因为很多时候DBA看到GI Home已经成功就会误以为补丁完成。对每个节点的DB Home执行$ cd /u01/psu/DB子目录 $ $ORACLE_HOME/OPatch/opatch applyDB Home补丁应用后同样会提示执行root脚本。如果之前已经执行过一部分脚本会提示“has been applied”之类。DB Home的root脚本比GI的简单一般几秒就完成。3.4 启动集群与验证所有节点补丁都应用完成后启动集群$ $GI_HOME/bin/crsctl start crs $ $GI_HOME/bin/crsctl stat res -t -init等集群资源全部online后启动数据库$ srvctl start database -d dbname $ srvctl status database -d dbname验证两项关键内容第一OPatch的inventory里能看到新补丁记录$ $GI_HOME/OPatch/opatch lsinventory | grep 20996944 $ $ORACLE_HOME/OPatch/opatch lsinventory | grep 20996944第二ASM实例和监听状态正常$ $GI_HOME/bin/srvctl status asm $ $GI_HOME/bin/srvctl status listener $ lsnrctl status补丁应用后监听可能会因为GI组件更新而被重启如果业务侧应用依赖静态监听注册需要检查listener.ora配置是否还在是否需要重新注册服务。这是老系统打GI补丁后最常出现“库起来了但连不上”的原因。3.5 一个常见的监听问题有次给一套RAC打p20996944节点1的GI补丁应用完root脚本正常跑完节点2也顺利做完。启动集群后检查监听却发现节点1的LISTENER在GI里显示online但lsnrctl status看不到任何服务注册。查了半天发现是补丁刷新了listener.ora把原本手动添加的动态注册参数弄丢了。遇到这类问题不要急着重启监听。先对比打补丁前保存的listener.ora和当前文件确认需要补哪些内容再手动合并修改然后重载监听$ lsnrctl reload如果还是不行再考虑停止监听后用srvctl重新启动。这个案例说明打GI补丁前保留一张listener.ora的完整快照是多么值钱的习惯。4. 回滚与存量系统运维建议4.1 发现问题时的回滚流程补丁打完不代表万事大吉。实际运维中打完补丁后如果发现ASM磁盘组挂载异常、监听反复重启、集群资源状态异常需要在维护窗口内果断回滚。回滚GI PSU的基本思路是再次停库、停集群对GI Home执行回滚$ cd /u01/psu/GI子目录 $ $GI_HOME/OPatch/opatch rollback -phBaseDir $(pwd)执行root脚本回滚这一步会重置相关GI配置对DB Home执行回滚$ cd /u01/psu/DB子目录 $ $ORACLE_HOME/OPatch/opatch rollback -phBaseDir $(pwd)启动集群重新验证回滚本身不算复杂但耗时可能比打补丁还长因为会触发资源重新配置。更需要留意的是回滚前务必确认补丁包文件还在原路径并且inventory状态一致。如果中途误删了补丁目录回滚会找不到补丁文件那时候就真的进退两难了。4.2 存量系统的补丁策略建议给还在坚持运行11.2.0.3的同行几条实用建议补丁实施前把/research目录里的补丁文件、README、lsinventory输出、集群状态快照统一打包存档。一次维护窗口产生的变更记录可能在未来几次安全审计里反复用到。打补丁过程中尽量保证两个Home的补丁版本一致尤其不要只打GI不打DB或只打DB不打GI。GI和DB组件在运行时交互密切版本不一致会出现一些诡异的ORA报错。关注MOS上关于这个补丁的已知问题文档。p20996944发布后官方针对一些特定场景发布过后续补充说明比如某些存储环境下的ASM rebalance异常、特定网卡驱动下的集群通信问题。这些信息不一定写在补丁包README里需要额外检索。再有就是补丁打完后别急着把维护窗口关掉建议留出至少两小时的观察期观察alert日志和crsd日志有没有异常刷屏。很多补丁引发的问题不是立即爆发的而是运行一段时间后才显现比如内存缓存的细微变化、集群心跳超时参数被重置等。4.3 我的实际体会几年下来我给不少存量库补过这类末期PSU。最大的感受是越老的系统打补丁前越要“磨刀”。所谓磨刀不是把命令敲得多熟而是把环境摸透——GI Home路径、DB Home路径、OPatch版本、是否打过one-off补丁、监听配置有没有自定义内容、集群节点间的网络依赖这些细节任何一项没确认都可能让一个看似简单的补丁操作变成通宵排障现场。p20996944这个补丁本身对11.2.0.3来说确实称得上“善终”之作之后官方基本不再针对这个版本发布新的常规PSU。但对还在维护老库的人来说打完这个补丁并不意味着一劳永逸还需要继续关注Oracle Support上发布的后续安全公告结合具体漏洞情况决定是否需要申请额外的临时补丁。老系统运维就是这样没有一锤子买卖每一步都得留好退路、做好记录把变更风险控制在可预见的范围内。本文还有配套的精品资源点击获取