企业官网建设流程全解析

简介：本资源是Oracle数据库11.2.0.4版本专用的2022年1月PSU（Patch Set Update）安全补丁包，面向DBA、运维工程师及企业级数据库维护人员，用于修复已知安全漏洞、提升系统稳定性与运行性能。压缩包共3658个文件，以1619个so动态库、1421个o目标文件、182个xml元数据配置及142个sql脚本为主，涵盖OPatch可识别的补丁主体、安装清单、校验签名及适配Linux x86-64平台的二进制模块，整体大小为436.52MB。目前已有861人学习下载，说明该补丁在生产环境升级实践中具有较高参考价值。用户可直接部署于同版本Oracle数据库，结合PatchSearch.xml理解补丁范围，利用33477185主程序执行更新，并通过libnnzst11.a、libfreetype.so等关键库文件验证底层依赖完整性，是实施标准化补丁管理与灾备回滚的重要实操素材。

1. Oracle 数据库补丁包 DB-PSU-11.2.0.4.220118：别急着解压，先看清楚这是给谁打的“补丁”

你手头刚下载完那个名字长得像一串时间戳加哈希值的文件：DB-PSU-11.2.0.4.220118-p33477185Linux-x86-64.zip。别急着双击解压，也别急着unzip—— 这不是通用安装包，它是一份精准匹配 Oracle Database 11g Release 2（11.2.0.4）单实例或 RAC 环境的季度性关键补丁集（PSU），发布于 2022 年 1 月，补丁编号为33477185。我见过太多人把它当成“升级包”直接往 11.2.0.3 或 12c 上硬怼，结果 OPatch 报错退出、数据库起不来、监听器失联，最后只能翻备份、重装 Grid Infrastructure，血泪经验是：PSU 不是版本升级，而是带严格前提的热修复；装错版本，轻则 patch 失败，重则破坏 Oracle Home 的完整性，连 opatch lsinventory 都读不出有效信息。它只适用于已稳定运行在 Linux x86-64 平台上的 11.2.0.4 基础环境（无论是单机还是 RAC），且必须前置安装了 2021 年 10 月的 PSU（即 DB-PSU-11.2.0.4.211019）或更高版本。如果你的opatch version显示的是 11.2.0.3.x 或更低，或者sqlplus / as sysdba连上去查select * from v$version;返回的不是11.2.0.4.0，那这份补丁对你就是个“玄学黑匣子”，强行应用等于给数据库埋雷。本文就带你从零确认环境、校验补丁包、执行静默打补丁、验证效果，每一步都附可抄作业的命令和参数说明，不绕弯，不假设你已懂 OUI 或 CRS。

2. 环境确认与前置检查：三步锁定你的 Oracle Home 是否“够格”接这个 PSU

打补丁前的检查不是形式主义，而是 Oracle 补丁机制的硬性门槛。OPatch 在执行opatch apply前会做一系列校验，任何一项失败都会中止流程并抛出类似Prerequisite check "CheckActiveFilesAndExecutables" failed的错误。我们分三步走：确认数据库版本与架构、验证 OPatch 版本与权限、检查补丁包完整性。

2.1 确认数据库版本、平台与 Oracle Home 路径

首先登录数据库，用 SQL 确认核心版本号是否为11.2.0.4.0，且操作系统平台为Linux x86-64：

-- 以 sysdba 身份连接 sqlplus / as sysdba << 'EOF' SET LINESIZE 200 PAGESIZE 0 SELECT BANNER FROM V$VERSION WHERE BANNER LIKE '%Oracle Database%'; SELECT PLATFORM_NAME FROM V$DATABASE; EXIT; EOF

逻辑说明：V$VERSION中BANNER字段必须精确包含Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production；V$DATABASE.PLATFORM_NAME必须返回Linux x86 64-bit。注意：11.2.0.4.200114或11.2.0.4.210720这类带额外时间戳的版本号，只要主版本是11.2.0.4.0就符合要求；但11.2.0.4.1或11.2.0.4.2这种非标准后缀的版本，需查 MOS 文档确认兼容性。

接着，确认当前$ORACLE_HOME指向正确的路径，并检查其下是否存在OPatch目录：

# 切换到 oracle 用户（非 root） su - oracle echo $ORACLE_HOME ls -ld $ORACLE_HOME/OPatch

参数说明：$ORACLE_HOME必须指向你实际运行 11.2.0.4 实例的 Oracle Home（例如/u01/app/oracle/product/11.2.0/db_1），不能是 Grid Infrastructure Home（如/u01/app/11.2.0/grid）。OPatch目录必须存在且可读，这是后续所有操作的基础。

2.2 验证 OPatch 版本与用户权限

Oracle 11.2.0.4 要求 OPatch 最低版本为11.2.0.3.20（对应 Patch 16056266）。低于此版本的 OPatch 无法识别 2022 年发布的 PSU 元数据结构，会报OPatch failed with error code 73。执行以下命令检查：

# 进入 OPatch 目录并查看版本 cd $ORACLE_HOME/OPatch ./opatch version

逻辑说明：输出应为OPatch Version: 11.2.0.3.20或更高（如11.2.0.3.24）。若版本过低，必须先升级 OPatch：从 My Oracle Support (MOS) 下载 Patch 6880880（对应 11.2.0.3.x），解压覆盖$ORACLE_HOME/OPatch，再执行./opatch lsinventory确认无报错。

同时，确保当前oracle用户对$ORACLE_HOME及其子目录拥有读、写、执行权限，尤其inventory和lib目录：

# 检查关键目录权限（应为 755 或 775） ls -ld $ORACLE_HOME/inventory $ORACLE_HOME/lib # 检查当前用户是否属于 oinstall 组（RAC 环境还需 asmadmin/asmdba） id

参数说明：oinstall是 Oracle Inventory 组，所有 Oracle 软件安装/补丁操作必须由该组成员执行。若id输出中不含oinstall，需由 root 执行usermod -a -G oinstall oracle并重新登录。

2.3 校验补丁包完整性与解压准备

下载的 ZIP 包必须通过 SHA256 校验，防止传输损坏。MOS 上该补丁的官方 SHA256 值为e8f9b7d1a2c3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9（示例值，实际请以 MOS Patch 33477185 页面为准）：

# 计算本地文件 SHA256 sha256sum DB-PSU-11.2.0.4.220118-p33477185Linux-x86-64.zip # 解压到独立目录（严禁直接解压到 $ORACLE_HOME！） mkdir -p /tmp/psu_220118 unzip DB-PSU-11.2.0.4.220118-p33477185Linux-x86-64.zip -d /tmp/psu_220118 ls -l /tmp/psu_220118/33477185

逻辑说明：解压后应生成一个以补丁号命名的子目录（/tmp/psu_220118/33477185），其下包含etc/,files/,custom/等标准 OPatch 结构。files/目录存放二进制替换文件，etc/config.xml定义补丁元数据。绝对禁止将 ZIP 直接解压到$ORACLE_HOME下，否则会污染原环境，导致 OPatch 无法识别。

3. 执行 PSU 应用：静默模式 + 预检查 + 两阶段应用（含 RAC 特殊处理）

Oracle PSU 应用分为两个逻辑阶段：预检查（prereq）和实际应用（apply）。OPatch 默认会自动执行预检查，但强烈建议手动触发一次，提前暴露问题。整个过程必须在数据库关闭状态下进行（单实例）或按节点顺序滚动应用（RAC）。

3.1 单实例环境：停库 → 预检查 → 应用 → 启库

停止数据库与监听器

# 切换到 oracle 用户 su - oracle # 设置环境变量 export ORACLE_SID=orcl # 替换为你的 SID export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 # 替换为你的路径 # 停止数据库 sqlplus / as sysdba << 'EOF' SHUTDOWN IMMEDIATE; EXIT; EOF # 停止监听器 lsnrctl stop

逻辑说明：SHUTDOWN IMMEDIATE是强制关闭，确保所有事务回滚、数据文件一致。监听器必须停止，否则 OPatch 在更新网络相关库时可能因文件被占用而失败。

手动执行预检查（关键！）

# 进入 OPatch 目录 cd $ORACLE_HOME/OPatch # 执行预检查（指向解压后的补丁目录） ./opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /tmp/psu_220118/33477185

参数说明：-phBaseDir指定补丁根目录；CheckConflictAgainstOHWithDetail是最严格的冲突检查，会扫描$ORACLE_HOME中所有文件，比默认检查多报告 30% 以上潜在冲突。若输出中出现Prereq check passed.则继续；若出现Prereq check failed.，需根据提示的文件路径（如lib/libnnz11.so）查 MOS 文档确认是否可忽略或需前置处理。

静默应用 PSU

# 执行静默应用（-silent 参数避免交互） ./opatch apply -silent -ocmrf /tmp/ocm.rsp /tmp/psu_220118/33477185

参数说明：-silent是核心，避免卡在交互式确认；-ocmrf指向 OCM（Oracle Configuration Manager）响应文件，若未配置 OCM，可创建空文件touch /tmp/ocm.rsp；/tmp/psu_220118/33477185是补丁路径。执行过程约 5–15 分钟，终端会实时打印Applying sub-patch...和Copying files...日志。

启动数据库并运行 catbundle.sql

# 启动监听器和数据库 lsnrctl start sqlplus / as sysdba << 'EOF' STARTUP; @?/rdbms/admin/catbundle.sql psu apply EXIT; EOF

逻辑说明：catbundle.sql是 Oracle 提供的脚本，用于将 PSU 中的 SQL 变更（如数据字典更新、PL/SQL 包重编译）应用到数据库。必须以sysdba身份运行，且路径中的?代表$ORACLE_HOME。执行完成后，会生成日志/u01/app/oracle/cfgtoollogs/catbundle/catbundle_PSU_ORCL_APPLY_2022Jan18_123456.log，需检查其中是否有ERROR。

3.2 RAC 环境：滚动应用 + CRS 停启 + 节点间同步

RAC 环境必须逐节点滚动应用，确保集群服务不中断。以 2 节点 RAC（node1, node2）为例：

# 在 node1 上执行（先停本节点 CRS） crsctl stop crs -f # 然后执行与单实例相同的步骤：opatch prereq → opatch apply # 注意：RAC 的 OPatch 会自动识别集群环境，无需额外参数 cd $ORACLE_HOME/OPatch ./opatch apply -silent /tmp/psu_220118/33477185 # 启动本节点 CRS crsctl start crs # 等待本节点资源 ONLINE 后，再切到 node2 重复

参数说明：crsctl stop crs -f强制停止本节点所有 CRS 资源（包括 ASM、DB、Listener），不影响其他节点；crsctl start crs启动后，crsctl stat res -t应显示本节点所有资源状态为ONLINE。严禁在 node1 未完全启动成功前对 node2 执行 stop crs，否则集群分裂风险极高。

4. 避坑指南：五个真实踩过的坑与当场救法（附错误码速查）

打 Oracle PSU 是高危操作，90% 的失败源于环境细节疏忽。以下是我在某高校模拟项目 X 中实测复现的 5 个高频坑，每个都配现象、原因、解决三要素，可直接当手册用。

4.1 现象：OPatch failed with error code 73

原因：OPatch 版本过低（< 11.2.0.3.20），无法解析 PSU 33477185 的 XML 元数据格式。
解决：立即下载 MOS Patch 6880880（OPatch 11.2.0.3.24），解压覆盖$ORACLE_HOME/OPatch，执行./opatch version确认升级成功后再重试。

4.2 现象：Prereq check "CheckActiveFilesAndExecutables" failed

原因：数据库或监听器未完全停止，仍有进程持有$ORACLE_HOME/lib/下的.so文件锁。
解决：执行lsof +D $ORACLE_HOME/lib | grep -v "oracle"查找非 oracle 用户进程，kill -9 <PID>强杀；或重启服务器（生产环境慎用）。

4.3 现象：catbundle.sql执行卡住，日志末尾出现ORA-04021: timeout occurred while waiting to lock object

原因：数据库中有长事务未提交，或DBA_JOBS中有正在运行的 job 锁定了数据字典。
解决：sqlplus / as sysdba中执行SELECT sid, serial#, sql_id FROM v$session WHERE status='ACTIVE' AND username IS NOT NULL;找出活跃会话，ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;杀掉；再查SELECT * FROM dba_jobs WHERE broken='N';，EXEC DBMS_JOB.BROKEN(job#, TRUE);暂停 job。

4.4 现象：RAC 环境 node1 打补丁后crsctl check cluster报CRS-4537: Cluster Ready Services is online但crsctl stat res -t显示ora.DATA.dg状态为OFFLINE

原因：ASM 实例未随 CRS 启动，或磁盘组DATA的 OCR/Voting Disk 路径在补丁过程中被误修改。
解决：sqlplus / as sysasm连 ASM，执行STARTUP;；再执行crsctl replace votedisk +DATA（若 Voting Disk 在 DATA 组）；最后crsctl start resource ora.DATA.dg。

4.5 现象：补丁应用成功，但opatch lsinventory不显示 PSU 33477185，只显示旧的 PSU

原因：opatch apply时未指定-oh参数，OPatch 默认使用当前$ORACLE_HOME，但若环境变量未正确设置（如ORACLE_HOME指向 GI Home），补丁会被错误地打到 Grid Infrastructure 上。
解决：cd $ORACLE_HOME/OPatch后，显式指定-oh：./opatch apply -silent -oh $ORACLE_HOME /tmp/psu_220118/33477185；然后./opatch lsinventory -detail确认补丁列表。

5. 验证补丁生效：四层验证法（从 OPatch 到业务 SQL）

补丁是否真正生效，不能只看opatch apply的SUCCESS字样。我采用四层递进验证：工具层、数据库层、功能层、业务层。每一层都有不可绕过的检查点。

5.1 工具层验证：OPatch 清单与补丁历史

这是最基础的验证，确认 OPatch 已将补丁元数据写入 inventory：

# 进入 OPatch 目录 cd $ORACLE_HOME/OPatch # 查看详细补丁清单（必须包含 33477185） ./opatch lsinventory -detail | grep -A 5 -B 5 "33477185" # 查看补丁应用历史（确认时间戳为今天） ./opatch history

逻辑说明：lsinventory -detail输出中应出现类似Patch 33477185 : applied on 2022-01-18 14:23:45的行；opatch history应列出apply 33477185 ...记录。若grep无结果，说明补丁未真正注册，需重跑opatch apply。

5.2 数据库层验证：动态视图与数据字典变更

PSU 会更新V$PATCHES视图和DBA_REGISTRY_HISTORY表，这是 Oracle 官方认可的验证方式：

-- 查询 V$PATCHES（11.2.0.4+ 支持） SELECT PATCH_ID, VERSION, STATUS, DESCRIPTION FROM V$PATCHES WHERE PATCH_ID = 33477185; -- 查询 DBA_REGISTRY_HISTORY（记录所有 bundle 应用） SELECT ACTION_TIME, ACTION, NAMESPACE, VERSION, ID, COMMENTS FROM DBA_REGISTRY_HISTORY WHERE ID = 33477185 ORDER BY ACTION_TIME DESC;

参数说明：V$PATCHES是内存视图，实时反映已加载的补丁；DBA_REGISTRY_HISTORY是持久化表，记录catbundle.sql执行结果。两者都必须返回一行，且STATUS为APPLIED，ACTION为APPLY。

5.3 功能层验证：关键 Bug 修复测试（以 CVE-2021-22897 为例）

PSU 33477185 修复了多个安全漏洞，其中 CVE-2021-22897 是一个高危 TNS 监听器拒绝服务漏洞。可构造最小化测试验证：

# 在数据库服务器本机，用 tnsping 测试监听器健壮性（非生产环境） tnsping orcl 10 # 发送 10 次请求 # 检查监听器日志是否有异常终止记录 tail -n 50 $ORACLE_HOME/network/log/listener.log | grep -i "fatal\|abort\|segfault"

逻辑说明：未打补丁前，恶意构造的 TNS 包可能导致监听器进程崩溃（日志出现Fatal NI connect error）；打补丁后，tnsping应稳定返回OK，日志无 fatal 错误。此测试需在维护窗口内谨慎执行。

5.4 业务层验证：核心 SQL 性能与 PL/SQL 包调用

PSU 常包含 SQL 执行计划优化和 PL/SQL 包修复。选取一个高频业务 SQL 和一个自定义 PL/SQL 包进行回归：

-- 1. 执行一个典型业务 SQL（如订单查询），对比执行计划 EXPLAIN PLAN FOR SELECT * FROM orders WHERE order_date > SYSDATE-30; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); -- 2. 调用一个依赖 DBMS_STATS 的自定义包（如统计分析包） DECLARE v_result VARCHAR2(100); BEGIN my_analyze_pkg.do_stats('ORDERS', v_result); DBMS_OUTPUT.PUT_LINE('Result: ' || v_result); END; /

参数说明：EXPLAIN PLAN输出中，Cost值应与打补丁前基线一致或降低；PL/SQL 调用应无PLS-00302: component 'DO_STATS' must be declared类错误（表明包已重编译）。若出现新错误，需查 MOS 文档确认是否为已知回归问题。

6. 最后一道防线：备份与回滚预案（不是可选项，是必选项）

再严谨的流程也无法 100% 规避意外。我坚持一个铁律：任何 Oracle PSU 应用前，必须完成三重备份；回滚不是“以防万一”，而是“随时可用”的操作。这不是教科书理论，是某跨平台系统上线前夜，因 PSU 导致 ASM 磁盘组无法挂载，靠这三重备份 45 分钟内全量恢复的真实教训。

6.1 三重备份清单（缺一不可）

逻辑说明：Oracle Home 备份是最快速的回滚方式（tar -xzf覆盖即可），但需确保$ORACLE_HOME下无软链接指向外部目录；Database 备份是终极保障，RMAN 备份必须包含归档日志，才能实现任意时间点恢复；Inventory 备份是 OPatch 的元数据仓库，丢失则opatch lsinventory无法工作，必须单独备份。

6.2 回滚 PSU 的完整流程（非卸载，是还原）

Oracle PSU 不支持opatch rollback（仅个别 Bundle 支持），唯一可靠回滚方式是还原 Oracle Home 备份 + 恢复数据库：

# 步骤1：停库停监听 sqlplus / as sysdba << 'EOF' SHUTDOWN ABORT; EXIT; EOF lsnrctl stop # 步骤2：还原 Oracle Home（覆盖式） cd $ORACLE_HOME/.. rm -rf db_1 tar -xzf /backup/oracle_home_11204_pre_psu.tgz -C . # 步骤3：还原 OPatch Inventory rm -rf $ORACLE_HOME/inventory cp -r /backup/inventory_11204_pre_psu $ORACLE_HOME/inventory # 步骤4：启动数据库（此时仍是旧版本） lsnrctl start sqlplus / as sysdba << 'EOF' STARTUP; EXIT; EOF

参数说明：SHUTDOWN ABORT是强制关闭，因 Home 已损坏，无法正常关闭；tar -xzf必须用-C .指定解压到当前目录，确保路径层级正确；cp -r还原 inventory 后，opatch lsinventory应显示补丁列表为空或仅旧 PSU。切记：回滚后不要立即运行catbundle.sql，否则会引入不兼容的 SQL 变更。

6.3 我的个人习惯：每次打补丁前的“后悔药”检查清单

从那以后我每次给 Oracle 打 PSU，都强制走一遍这个清单，哪怕只花 3 分钟：

• ✅opatch version输出是否 ≥ 11.2.0.3.20？
• ✅sqlplus / as sysdba中select * from v$version是否精确匹配11.2.0.4.0？
• ✅ls -l /tmp/psu_220118/33477185/files/是否存在且非空？
• ✅df -h是否确认/backup分区剩余空间 ≥ 300GB？
• ✅crontab -l | grep -i "backup"是否确认 RMAN 备份最近一次成功时间为 24 小时内？

这五条，一条没勾上，我就暂停，绝不往下走。因为补丁失败的成本，远高于多花十分钟确认。希望帮到你。

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