企业官网建设流程全解析

简介：Oracle 11.2.0.3的GI（Grid Infrastructure）PSU补丁包、版本.15，适用于Linux x86-64平台，是数据库管理员维护Oracle高可用环境的稀缺资源。该补丁对应官方编号20996944，同时覆盖GI与DB组件，对集群管理、ASM、OCR及Voting Disk等核心模块带来安全修复与性能改进，适合需要将11.2.0.3环境更新到最终补丁层级的运维人员。压缩包为zip格式，大小约599.65MB，包内主要包含HTML/文本说明文档、OPatch使用的PatchSearch.xml及bundle.xml等配置，便于安装前核对补丁依赖与应用顺序。目前已有400人学习下载，属于Oracle老版本维护中较受关注的补丁集合。获取后可获得完整的补丁文件、官方说明与元数据，帮助规避安全漏洞并提升集群稳定性，安装时可结合自身环境做好备份与预检查。

1. 还在维护 11.2.0.3 的人，为什么必须正视这个补丁包

仍在生产环境维护 Oracle 11.2.0.3 RAC 的 DBA 都明白一个事实：升级申请不是被业务部门压着，就是被预算卡着，而安全审计的漏洞清单却每个月都在变。能做的只有一件事——把当前版本能打的补丁全部打完，而这个p20996944_112030_Linux-x86-64.zip就是 Oracle 11.2.0.3 上的最后一个 GI（包含 DB）的 PSU 补丁，版本号走到 .15 彻底停更。换句话说，如果你现在还在跑 11.2.0.3，且短期无法迁移，这篇文章讨论的就是你手里最后一张安全牌。接下来我从包结构、安装流程、验证手段到翻车记录，把这个包讲透。

2. 拆解 p20996944_112030：GI 与 DB patch 的边界在哪里

2.1 GI PSU 与 DB PSU：一张补丁包的两种身份

很多刚接触 Oracle 补丁体系的运维会混淆 GI 与 DB 的概念。GI 是 Grid Infrastructure，承载集群件、ASM 实例、CSS 守护进程；DB 则是数据库内核本身。PSU（Patch Set Update）是 Oracle 在一个大版本内发布的增量补丁集合，既修安全漏洞也修功能性 bug。本次标题里的这个包同时覆盖 GI 和 DB，意味着解压后的内容里既有集群组件的二进制修复，也有数据库内核的修复文件。

这个“包含”字眼在实际操作中有两层含义。第一层：这个 zip 包内同时放了两套 patch 文件，分别对应 GI home 和 DB home；第二层：这两套修复必须在两个不同的 ORACLE_HOME 里分别应用，不能指望一条命令同时搞定。常见做法是先打 GI home，再打 DB home，顺序不能反。

2.2 补丁包命名与检索规律

补丁包的文件名有固定格式：p<补丁号>_<版本号>_<平台>.zip。其中 20996944 是 MOS 上的补丁编号，也是检索一切相关文档的关键字；112030 表示这是 11.2.0.3 版本专用；Linux-x86-64 限定操作系统与芯片架构，x86_64 的 Linux 服务器只能选这个变体，不能拿 Solaris 或 AIX 的包替代。末尾的 .15 指的是该版本的第 15 个 PSU 序列，序号越靠后，包含的修复越多。

在 MOS 上检索时，直接输入补丁号即可命中下载页，而不要去翻 11.2.0.3 的总补丁列表。下载页里通常还附带 README 和安装说明，它们是比任何第三方攻略都权威的指导书，我后面讲的每一步，第一参照物都是那个 README。

2.3 一个容易踩的口头理解误区

“包含 DB”四个字容易让新手误以为只需在 GI home 上跑一次 opatch apply，DB 就自动完成修复了。但实际安装时，必须分别在两个 home 上各自执行 apply。它们对 ORACLE_HOME 的判断依据是当前用户的环境变量，而不是 zip 包自身的位置。也就是说，同一个 zip 包可以被 grid 用户引用一次、被 oracle 用户再引用一次，两次都合法，但打进去的对象完全不同。

所以规范的操作顺序是：先以 grid 用户身份在 GI home 打 GI 部分；再切换到 oracle 用户环境，在 DB home 打 DB 部分。如果你跳过第二步，只看 GI 的版本号变成 .15 就觉得完事，那数据库内核的安全漏洞一个都没补上，审计依然不会通过。

3. 打补丁前站：OPatch 版本、备份与冲突检查必做清单

3.1 升级 OPatch：比所有检查都先一步

11.2.0.3 时代自带的 OPatch 版本往往偏低，直接对高版本 PSU 执行 apply 会报版本不满足或 OPATCH-7200 错误。老 DBA 的习惯是先把 OPatch 升到 MOS 上对应 11.2 的最新版本，再动补丁包。这个步骤虽然朴素，却能省下大量排查时间。以我自己的经历，某个库就是在第一次 apply 时被 OPatch 版本卡住，浪费了一个完整的维护窗口。

升级流程是下载 OPatch 压缩包，先备份旧目录，再把新目录替换过去。注意环境变量必须指到当前实际使用的 ORACLE_HOME，否则替换错目录是常有的事。

# 以 grid 用户备份并升级 GI home 下的 OPatch cd $ORACLE_HOME mv OPatch OPatch_$(date +%Y%m%d_%H%M%S) unzip -q /stage/p6880880_latest.zip -d $ORACLE_HOME chown -R grid:oinstall $ORACLE_HOME/OPatch # 完成后确认版本 $ORACLE_HOME/OPatch/opatch version

这里的 p6880880 是 OPatch 工具在 MOS 上的通用补丁号，下载时同样需要选择与 11.2 版本匹配的最新迭代。替换后注意属主和权限，目录属主必须与 home 属主一致，否则后续执行会出现权限拒绝的诡异现象。升级完 GI home 的 OPatch 后，DB home 下也要重复一遍同样的操作，两个 home 的工具版本最好保持一致。

3.2 备份盘点：OCR、GI home 和数据库

打补丁前不做备份，等于把系统安全交给运气。对 11.2.0.3 RAC 来说，至少需要三条备份线：OCR / OLM 配置、GI home 目录、数据库本身。OCR 保存着集群和 ASM 的核心配置，一旦补丁过程中发生配置损坏，没有导出文件几乎是无法手工重建的。导出命令在 root 或 grid 用户下执行都可以，但输出文件要放到共享存储之外。

# 以 root 导出 OCR 配置 $GI_HOME/bin/ocrconfig -export /backup/ocr_$(date +%Y%m%d_%H%M%S).bak # 检查导出结果 $GI_HOME/bin/ocrcheck

数据库层面，如果条件允许，做一次完整的 RMAN 全备份最稳妥；如果时间窗口不够，至少要把控制文件、spfile 和最新的归档日志单独备份出来。GI home 的目录备份用 tar 打包到本地磁盘即可，注意要排除监听和日志目录下的临时文件，否则包会异常膨胀。备份的本质是给操作上后悔药，宁可多花半小时，不要在故障后花一晚上恢复。

3.3 冲突与预检：不想在维护窗口里翻车就多做两步

补丁冲突是最常见却又最容易被忽略的拦截条件。如果你的环境里此前打过某个 interim patch（一次性小补丁），而 PSU 的修复内容与之重叠，apply 会直接拒绝执行，并提示冲突文件。解决的方式是先用 opatch 做预检，把冲突消灭在维护窗口之前。11.2.0.3 的 OPatch 支持 prereq 参数，可以对比软件仓库中已有的补丁。

# 解压补丁包后的预检，注意 phBaseDir 指向的是解压后的实际补丁目录 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /stage/20996944/20996944 # 也可以直接做 dryRun，模拟 apply 但不实际写入 $ORACLE_HOME/OPatch/opatch apply -dryRun -phBaseDir /stage/20996944/20996944

两条命令的差别在于：prereq 只做冲突检查，dryRun 会执行更完整的 apply 前置模拟，包括空间检查、二进制可写性和依赖关系的校验。遇到空间不足，OPatch 会准确报出哪个目录缺多少 M，比你手工统计快得多。这两种预检都要在 grid 和 oracle 两个用户的 home 下分别跑一遍，缺一个环境，维护窗口内就会多一次心跳加速。

4. 实战安装：从解压到 opatch apply 的标准流程

4.1 解压补丁包与生成 OCM 响应文件

拿到 zip 后先不要急着在任意目录解压。规范做法是把它放到一个专门的补丁目录，例如/stage，解压后找到真正的补丁子目录。11.2 的补丁包解压后会有两级目录结构，外层是补丁号目录，内层才是 opatch 真正读取的 patch 目录，很多第一次操作的人把路径指错，导致 opatch 报“提供的路径不是有效补丁”。

# 在 grid 用户环境下解压 mkdir -p /stage/20996944 unzip -q p20996944_112030_Linux-x86-64.zip -d /stage/20996944 # 查看解压后的目录结构 ls -la /stage/20996944/20996944

解压后必须确认目录内包含etc、files等标准结构，并存在README.txt。这个目录就是后面所有 opatch 命令的-phBaseDir指向对象。OCM 响应文件是 Oracle 配置管理器的应答文件，用于替代交互式输入。标准做法是从任一已存在的同类文件复制或通过 MOS 下载模板，填上站点信息即可，apply 时用-ocmrf参数引用它。

4.2 GI Home 打补丁：以 grid 用户执行第一个 apply

GI 部分的打补丁是整个维护窗口的核心步骤。执行前要确认节点间的补丁状态差异，Opatch 会自动识别 RAC 环境，但如果你打算滚动执行，还必须先看 README 是否支持 rolling。11.2.0.3 的 GI PSU 通常支持滚动，但包含 DB 的整包升级不建议滚动，因为 DB 部分的 apply 不支持滚动模式，硬要拆开会造成两节点补丁级别暂时不一致，给后续问题排查增加变量。

# 以 grid 用户执行，切换到 GI home 的环境变量 export ORACLE_HOME=/u01/app/11.2.0/grid export PATH=$ORACLE_HOME/bin:$PATH cd $ORACLE_HOME/OPatch ./opatch apply -ocmrf /stage/ocm.rsp -phBaseDir /stage/20996944/20996944

apply 执行期间，OPatch 会依次读取补丁文件、克隆目录、更新 inventory，耗时通常在 20 到 40 分钟之间，取决于存储性能。期间不要并行执行其他运维操作，尤其不要手动启停集群服务。如果补丁内容涉及 ACFS 驱动更新，OPatch 会输出提示，要求你用 root 执行生成的脚本，此时按提示切换用户执行即可，不要跳过。

4.3 DB Home 打补丁：同一个 zip 的第二站

GI home 打完并确认无误后，切换到 oracle 用户，把 ORACLE_HOME 指向数据库 home，再用同一个 zip 包执行第二次 apply。这一次针对的是数据库内核的修复文件。执行前同样先做一次 dryRun，确认 DB home 下的 OPatch 版本与 GI home 一致，然后进入正式 apply。

# 以 oracle 用户执行，ORACLE_HOME 切换为数据库 home export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch apply -ocmrf /stage/ocm.rsp -phBaseDir /stage/20996944/20996944

这次 apply 完成后，数据库 home 的 opatch lsinventory 输出里就能看到对应 PSU 条目。注意这里不会立即改变数据库字典内的版本信息，还需要最后一步 datapatch。如果你只做到 lsinventory 显示 .15 就觉得收工，后遗症是数据字典里的REGISTRY_SQLPATCH仍是旧版本，后续业务若触发了已修复的 bug，问题依旧会出现。

4.4 运行 datapatch：把版本号真正落进数据字典

datapatch 是 11.2.0.3 之后负责把补丁的 SQL 部分写入数据库的工具，它读取补丁清单中的postinstall脚本，在实例上执行 SQL 变更。这一步必须在数据库处于 open 或至少 mount 状态下执行，且 ORACLE_SID 必须指向正被维护的实例。常见做法是在两节点的第一节点上执行，它会自动把 SQL 应用到所有实例相关的字典变更。

# 以 oracle 用户执行，先确认 SID 正确 export ORACLE_SID=ORCL cd $ORACLE_HOME/OPatch ./datapatch -verbose

datapatch 执行完毕后会输出每一条 SQL 的应用状态，若有失败项会打印具体语句和错误信息。这时不要直接重跑，先看错误是权限问题还是对象已存在，前者需要检查执行用户权限，后者通常意味着之前已部分应用过，可以直接跳过。全部成功后，数据库的版本号才算真正走到了 .15。

5. 打补丁避坑：五条真实环境的翻车记录

5.1 OPatch 版本不满足，apply 第一轮就失败

现象：执行 opatch apply 后立即报错，提示 OPatch 版本过低或与补丁要求的最低版本不匹配，整个维护窗口被迫推迟到下一轮。原因：补丁包 release 时间晚于当前 OPatch 工具版本，OPatch 本身不具备向后兼容性。解决：在维护窗口前提前完成升级，并把opatch version的输出与补丁 README 中的最低版本要求逐字核对。我曾经因为在两节点只升级了其中一个的 OPatch，导致第二个节点 apply 报错，白白多花了一个小时。

5.2 打完 GI 补丁后 OCR 不一致告警

现象：全部 apply 成功后，crsctl stat res -t显示部分资源异常，ocrcheck报告配置与二进制版本不一致。原因：GI PSU 在节点间轮流应用时，若某一个节点提前重启了集群服务，而另一个节点还没打补丁，会导致 OCR 记录的版本信息和实际二进制对不上。解决：严格按 README 的步骤顺序执行，若非必要不要做滚动升级；打完所有节点后按规范依次重启集群，让 OCR 同步新版本。重启前务必确认所有节点的 patch 都已应用完毕。

5.3 datapatch 连接实例失败，报 ORACLE_SID 错误

现象：执行 datapatch 时提示无法连接到实例或找不到 SID，但数据库明明在运行。原因：当前 shell 的 ORACLE_SID 与实测实例名不一致，或数据库处于 restricted 模式。解决：先用ps -ef | grep smon查看实际实例名，再 export 正确 SID；若实例是 restricted，用 sqlplus 登录执行alter system disable restricted session;后再运行 datapatch。这个小坑能让熟手都怀疑人生，但它就是环境变量的问题，跟补丁本身无关。

5.4 apply 后 lsinventory 仍是 .14，补丁像没打一样

现象：apply 全程无报错，但 lsinventory 输出里看不到新 PSU 条目，查opatch lsinventory -detail才发现 apply 作用在了一个空的临时目录。原因：-phBaseDir指向了解压后的外层目录，而不是内层真正的补丁目录，OPatch 静默地读取了另一个子目录中的补丁定义。解决：apply 前用ls /stage/20996944/20996944确认存在 files 目录，再执行。这个检查值不值钱？值，它避免了一次“成功”的假操作。

5.5 数据库补丁级别与 GI 不一致，审计又被卡

现象：GI home 已显示 .15，但 v$version 和数据字典仍是旧版本。原因：只执行了 GI home 的 apply，跳过了 DB home 的第二次 apply 和 datapatch。解决：把 4.3 和 4.4 当成不可分割的整体，任何一步缺失都会导致这种半吊子状态。这类问题在审计阶段最头疼，因为报表里只会写“数据库版本未达标”，排查起来却要翻两个 home 的 inventory。

6. 打完补丁别急着收工：datapatch 与 SQL 变更的验证技巧

6.1 版本三板斧：别只信一个输出

验证补丁是否成功，不能只看 opatch lsinventory 一个结果，三处输出必须同时确认。第一处是 GI home 的 lsinventory，第二处是 DB home 的 lsinventory，第三处是数据库字典内的版本记录。只看前两个，无法确认 SQL 变更是否已生效；只看第三个，无法确认二进制是否已替换。

-- 检查数据字典内的补丁记录 SELECT PATCH_ID, PATCH_TYPE, ACTION, STATUS, ACTION_TIME FROM DBA_REGISTRY_SQLPATCH WHERE PATCH_ID = 20996944 ORDER BY ACTION_TIME;

这条 SQL 是判断 SQL 变更落地的最终证据。如果返回多条记录，注意看 ACTION 字段，APPLY 且 STATUS 为 SUCCESS 才是正确状态。若有 FAILED 记录，就要翻看 datapatch 的输出日志，定位具体是哪条脚本没跑完。

6.2 巡检基线：把补丁状态写进日常

打完补丁后的第一周，我建议每天看一次 alert 日志，重点抓 ORA-600 和 ORA-7445 两类内部错误。11.2.0.3 这种快被 Oracle 遗忘的版本，新补丁引入的问题虽然少，但并非不可能。把以下查询存成脚本，放进巡检清单里，每次版本变更后对比一次，比临上线才查靠谱得多。

-- 对比两个 home 的补丁级别 SELECT 'GI', PATCH_ID, ACTION, STATUS FROM DBA_REGISTRY_SQLPATCH UNION ALL SELECT 'DB', TO_NUMBER(REGEXP_SUBSTR(comments, '[0-9]+')), 'INSTALLED', 'SUCCESS' FROM v$version WHERE banner LIKE 'Oracle Database 11g%';

6.3 我的习惯：一次补丁一次档案

这些年打过的补丁不少，我养成的最实用习惯是：每次 patch 后把三个版本的输出截图或存文本归档，起名带上补丁号和日期，放进共享目录。等审计来查时，翻出文件夹就能把整个链讲清楚。这个习惯在 11.2.0.3 这种老库上尤其重要，因为补丁路径不可复现，查一次少一次。希望你也能在动手前把归档目录建好，打完顺手存个档——老库维护，细节决定生死，希望这些经验能帮到你少走一趟弯路。

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