企业官网建设流程全解析

简介：针对甲骨文数据库11.2.0.3版本中网格基础设施（GI）与数据库组件的最终补丁集更新（版本15），面向Linux 64位平台，是数据库管理员与系统运维人员维护集群、自动存储管理及数据库环境的重要资源。该补丁集成了自上一版本以来的安全修复、性能优化与常见问题解决方案，覆盖集群注册表、表决盘等关键组件，可降低已知故障风险，提升系统高可用性。压缩包大小约599.65MB，内含说明文档、补丁工具所需的XML配置清单以及独立补丁编号文件，可帮助升级前核对依赖、规划操作顺序，并辅助处理常见报错，补丁应用过程中所需的关键信息基本都能在包内找到。目前已有398人学习下载，适合需要为生产或测试环境完成最后一轮补丁升级的数据库技术人员参考。 前阵子在查一套老环境的补丁清单，顺手翻到了p20996944这个编号。不少同行可能看到“Oracle 11.2.0.3”、“最后的GI PSU”这几个词就头疼，一套跑了七八年的系统，硬件和业务都指望着它，到底还动不动补丁，怎么动，动了以后会不会出幺蛾子，这些问题只有真正在机房里熬过夜的人才能体会。这篇就围绕这个最后的GI（包含DB）PSU补丁，也就是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，就是只针对数据库Home（RDBMS）的补丁集合，修的是SQL引擎、优化器、数据字典、RMAN、EXP/DP这些组件的问题。而GI PSU，全称是Grid Infrastructure Patch Set Update，它覆盖的范围要大得多，除了数据库Home里的内容外，还包括：

• Clusterware集群件（crsd、cssd、evmd进程）
• ASM实例和ASM磁盘组管理
• Oracle Cluster Registry（OCR）和表决盘相关逻辑
• 监听器（Listener）在GI Home下的版本
• 集群时间同步服务（CTSS）、GNS等附属组件

所以你会看到，p20996944这个zip解压后，里面通常包含Grid和DB两个子目录。Grid目录对应GI Home的Patch，DB目录对应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 /u01

GI和DB两个Home解压和备份都需要空间，建议至少留10GB以上余量，否则中途才发现空间不足，回退起来很被动。

3. 正式实施：GI PSU打补丁的完整链路

3.1 准备阶段：备份和停机决策

打GI PSU最理想的方式是RAC滚动更新，逐个节点滚动，业务不中断。但很多老系统的维护窗口普遍安排在凌晨，DBA也更倾向直接停所有节点，一次性把GI和DB都打完，这样操作链路最短、排错最容易。如果你的系统允许短暂停机，建议用整体停机方案，省心很多。

停机前必须做的三件事：

1. 备份OCR和表决盘

$ $GI_HOME/bin/ocrconfig -export /backup/ocr_before_psu_$(date +%Y%m%d).bak $ $GI_HOME/bin/crsctl query css votedisk

OCR的备份文件放到本地或共享存储都行，保证能读到。表决盘不用拷贝文件，但要把votedisk路径记录下来，万一后续出现集群起不来，可以用来排查。

2. 记录集群状态基线

$ $GI_HOME/bin/crsctl stat res -t -init $ $GI_HOME/bin/crsctl stat res -t

记录下各个资源的online/offline状态，方便打完后对照，确认没有资源异常。

3. 关闭数据库实例和集群

$ 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 apply

opatch 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 apply

DB 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的基本思路是：

1. 再次停库、停集群
2. 对GI Home执行回滚：

$ cd /u01/psu/<GI子目录> $ $GI_HOME/OPatch/opatch rollback -phBaseDir $(pwd)

3. 执行root脚本回滚（这一步会重置相关GI配置）
4. 对DB Home执行回滚：

$ cd /u01/psu/<DB子目录> $ $ORACLE_HOME/OPatch/opatch rollback -phBaseDir $(pwd)

5. 启动集群，重新验证

回滚本身不算复杂，但耗时可能比打补丁还长，因为会触发资源重新配置。更需要留意的，是回滚前务必确认补丁包文件还在原路径，并且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上发布的后续安全公告，结合具体漏洞情况，决定是否需要申请额外的临时补丁。老系统运维就是这样，没有一锤子买卖，每一步都得留好退路、做好记录，把变更风险控制在可预见的范围内。

本文还有配套的精品资源，点击获取