企业官网建设流程全解析

简介：这份Oracle 11.2.0.4补丁包面向仍在使用11g R2数据库的DBA与运维人员，用于在Windows x64平台集中修复安全漏洞、性能瓶颈与已知缺陷，是11.2.0.4的PSU最新累积更新。资源共463个文件，约637.5MB，核心包含142个jar、113个dll、21个exe等程序文件，以及大量properties、sh、bat、xml等配置与脚本，可支撑补丁安装、环境检查和日志验证；同时还附带OPatch补丁管理工具及其配套脚本，方便管理员对补丁进行安装、查询和卸载。已有2257人学习下载，适合正在维护Oracle 11g R2生产环境、需要跟进2022年10月安全修复的用户。借助该补丁包可获得完整的安全加固组件、性能优化项与维护工具链，尤其适用于尚未升级到12c或19c的Windows x64平台，帮助在过渡期内降低数据库运行风险，保持系统安全与稳定。

1. 2022.10.18 的 Win64 补丁包：Oracle 11.2.0.4 的最后防线

如果你手上还压着一批 Windows 64 位服务器上的 Oracle 11.2.0.4 数据库，那么 2022.10.18 这一天你没有理由不知道。这是 Oracle 按月发布的季度关键补丁更新（CPU）在 11.2.0.4 上的一个时间点，补丁包面向 MSWIN-x86-64 平台，解决的是从 TNS 服务到 PL/SQL 内部一堆高发漏洞和高负载下“说不清”的 ORA-00600。打过这个补丁，数据库还是 11.2.0.4，但行为会变得更稳，安全报告也更好写；不打，等审计和渗透测试发现漏洞时，你往往要在周末做一次没人愿意做的紧急变更。这篇文章就把 Win64 上这个补丁包的识别、应用、验证和回滚流程完整讲一遍，适合正在给生产库做季度维护、又不想被补丁细节坑一次的 DBA。

2. 补丁体系：PSU、CPU、RU 与 11.2.0.4 补丁包的目录识别

2.1 把 11.2.0.4 的三个“补丁家族”先对齐

很多刚接手 Oracle 维护的人会在 MOS 上看到一堆术语：CPU、PSU、RU、SPU、Bundle Patch。这张糊在一团，补丁还没打就先慌了。其实对 11.2.0.4 来说，你重点认识三样就够用。

CPU 是安全补丁集，全称 Critical Patch Update。Oracle 每年的一月、四月、七月、十月各发一批，2022.10.18 就是 2022 年第四季度的 CPU 发布日期。这类补丁覆盖面广，能打在跑得好好的生产库上，目的是堵漏洞而不是加功能。PSU 是补丁集更新，英文叫 Patch Set Update，是在 CPU 基础上又加了普通 Bugfix，比纯安全补丁“厚”一些。到了 12.2 之后 Oracle 改叫 Release Update，但 11.2.0.4 上你依然会看到大量以 PSU 命名的包。

还有一类特别容易混淆的叫“补丁包”，它不是一个独立补丁，而是把多个子补丁和一个 OPatch 工具打包成一个 zip。比如标题里说的“oracle11.2.0.4 补丁包”，下载下来往往是一个 zip，里面除了补丁文件，还有 README、prereq 脚本、一堆 pl 子目录。你不要看见里面有一个 patch 目录就以为只要把这个目录拷到服务器上执行，必须把整个 zip 解压后保持结构完整再交给 opatch 处理，否则运行到一半会报“Missing file”或者“Patch location does not exist”。

还有一层关系要分清：11.2.0.4 是一个 2013 年发布的终端版本号，Oracle 数据库 11.2.0.4 本身不会因为打了 2022.10.18 的补丁就变成 12c。补丁是“在同一个大版本上叠加修复”，数据字典里的版本号仍然显示 11.2.0.4。所以别拿这个补丁包去替换 19c 或 12c 的升级路径，这是两条路。

2.2 从补丁包文件名和目录结构识别批号与平台

在 Windows 64 位上下载 11.2.0.4 补丁，文件名通常遵循一个固定套路：补丁编号 + _112040 + 平台标识 + .zip。其中 112040 就是 11.2.0.4 的内部版本格式，平台标识 MSWIN-x86-64 代表 Microsoft Windows 64-bit，注意和 Linux 的 Linux-x86-64 区分开。

有的朋友把补丁包拷到目标机之后直接双击 zip 用 WinRAR 解压，然后到处找 setup.exe。这是第一个认知偏差：Oracle 补丁包没有安装包，它等待的是一套命令行工具 opatch。你真正要做的不是“安装”，而是“应用”。所以拿到补丁包后，先打开一个管理员命令行窗口，用 dir 看一下顶层内容。一个标准补丁包应该包含下面这些基础组件。

我一般是这样检查解压结果的。

cd /d D:\oracle_patch\oct2022 dir /b REM 期望看到 README.txt、patch、etc、OPatch 等目录或文件

说明：dir /b 只显示文件名，不显示详细时间，能快速确认目录结构。如果解压后看不到 patch 子目录，说明解压中间出了问题，最常见的元凶是文件名过长导致的中途失败。这时候不要继续打补丁，删掉重解。补丁的 README.txt 是第一个要读的，不是证明，而是里面写了这个补丁的最低 OPatch 版本、是否包含 SQL 变更、应用前是否需要跑其他预检查脚本。

你还可以进一步看 patch 目录下有没有一个叫 files 的子目录，这个目录保存了真正的二进制文件、动态链接库和 Java 类。如果 files 目录是空的，说明这个补丁只是元数据补丁，实际变更全部靠 SQL 脚本完成，这种补丁更要小心，因为二进制回滚时数据库字典状态不会跟着回滚。

2.3 打补丁前先把当前版本和 OPatch 版本对齐

opatch 是补丁应用系统的执行入口，但你不能随手拿一个 opatch 就去打 2022 年的补丁。11.2.0.4 在官方原版安装目录里带的 OPatch 版本通常很老，可能是 11.2.0.3.x 甚至更早。新补丁的 README 往往写着“Minimum OPatch version: X”。你不核对，直接跑 opatch apply，十有八九会收到一条类似“OPatch version should be 11.2.0.3.36 or higher”的报错。

在 Windows 上，先设置环境变量，再做两件事：查 opatch 版本和当前已安装补丁。下面这段是标准动作。

set ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 set PATH=%ORACLE_HOME%\OPatch;%PATH% opatch version opatch lsinventory -detail | findstr /i "patch"

参数说明：ORACLE_HOME 必须指向 64 位 11.2.0.4 的安装目录，不要把它设成客户端安装目录，也不要设成 Grid 目录，否则 opatch 会拿着错误的家目录去找补丁日志。opatch version 输出的第三行会给出 OPatch 版本号，如果它低于补丁要求，请先在 MOS 上下载兼容的 OPatch 工具，把它解压到%ORACLE_HOME%\OPatch，替换前最好把原目录改名留底。opatch lsinventory -detail 显示当前已安装补丁，这里的“pacth”是 Windows 下 findstr 大小写不敏感的搜索词，你也会看到像 PSU、CPU 这样的标识。

不要在这里直接跳过，很多人在生产库上翻车就是因为 lsinventory 显示出来的补丁里已经包含了一个重叠的子补丁，opatch 检测到冲突后拒绝执行。你提前看两眼，至少心里有数。

3. Win64 上从停止服务到 opatch apply 的最小可执行路径

3.1 备份和完整检查清单：避免文件锁

Windows 上打补丁最难受的一件事是文件锁。Oracle 的二进制文件一旦被服务占用，opatch 在替换时就会因为拒绝访问而中断。所以第一步不是解压，而是把 Oracle 相关服务全部停止。我见过有人只停了 list 的监听器，然后打开数据库服务，run 了一下 opatch，结果 apply 到 40% 时在替换 oracle.exe 时挂住。

典型的 Windows 服务名有多个，你可以按下面顺序操作。

net stop OracleServiceORCL net stop OracleOraDb11g_home1TNSListener net stop OracleJobSchedulerORCL net stop OracleMTSRecoveryService REM 用任务列表确认没有残留的 oracle 进程 tasklist | findstr /i "oracle"

参数说明：OracleServiceORCL 是数据库实例对应的本地 Windows 服务，ORCL 换成你自己的实例名。OracleOraDb11g_home1TNSListener 是监听服务，名字里的 dbhome_1 你们也可能叫 dbhome_1，取决于安装目录名称。如果 tasklist 的 output 里还有 oracle.exe 或 sqlplus.exe，别急着打补丁，可能还有某个 PL/SQL 客户端通过本地连接挂在进程里。

服务停止后，补一个数据库物理备份。虽然补丁只改软件目录，理论上不动数据文件，但生产环境没有后悔药，所以该备份还是得备份。下面用 RMAN 做一个简化的全库备份。

rman target / <<EOF BACKUP DATABASE PLUS ARCHIVELOG FORMAT 'E:\backup\oct2022\db_%T_%U.bak'; EOF

说明：这里用 heredoc 是方便公众号阅读，实际 Windows cmd 下建议把脚本写到一个 rman_backup_cmd.txt 文件里再执行rman target / @rman_backup_cmd.txt。%T 会被 RMAN 展开成日期，%U 是唯一编号。如果你的库有上千 GB，全量备份时间太长，至少把控制文件和数据文件做一次 level 0 plus archivelog；不想用 RMAN，用ALTER TABLESPACE ... BEGIN BACKUP配合系统复制也能兜底，但复杂度会高很多。

接下来备份 ORACLE_HOME。别用 copy 命令，Windows 下长短路径和 ACL 很容易丢，推荐 robocopy。

robocopy "%ORACLE_HOME%" "E:\backup\oct2022\dbhome_before_patch" /E /COPYALL /R:0 /W:0

参数说明：/E 复制所有子目录，/COPYALL 复制文件数据、属性、时间戳和 ACL，/R:0 表示失败不重试，/W:0 表示失败不等待。因为 Oracle 服务已经停止，这个备份应该在几分钟内结束。如果你的 ORACLE_HOME 里有几十 GB 的 trace 文件，可以先跳过\log目录，但别跳过\rdbms、\bin、\OPatch。

最后备份一下 inventory，它记录补丁清单。不备份 inventory，后面一旦 opatch 写到一半失败，你连恢复过的 home 都没法重新进入 opatch 状态。

xcopy "C:\Program Files\Oracle\Inventory" "E:\backup\oct2022\inventory_before" /E /H /R /K /Y

说明：Inventory 的默认位置在 C:\Program Files\Oracle\Inventory，也有的机器在 C:\Program Files (x86)\Oracle\Inventory，你可以在注册表HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\INST_LOCATIONS下确认。这一步虽然简单，但能救命。

3.2 用 OPatch 应用补丁：实际安装的主体力

备份做干净以后，开始应用补丁。请务必用“管理员身份运行”的 cmd，不要用普通用户，否则后面操作注册表和 Inventory 会失败。

先把补丁包解压到一个短路径下，路径里不要带中文、空格和括号。我常用 D:\osp\p20221018 这类短目录，然后设置环境变量。

set ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 set PATCH_DIR=D:\osp\p20221018 set ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 cd /d "%ORACLE_HOME%\OPatch"

这里把 ORACLE_HOME 设置两遍不是笔误。第一遍给后续 opatch 用，第二遍为了覆盖可能的系统 PATH 里残留的 Oracle Client 路径，确保环境变量优先级正确。

接下来执行 prereq 检查。Oracle 官方推荐先做一次预检，避免直接 apply 到一半才发现问题。

opatch prereq CheckApplicable -invPtrLoc "C:\Program Files\Oracle\Inventory\ContentsXML\oraInst.loc" -ph "%PATCH_DIR%"

参数说明：-ph 表示 patch home，也就是解压后的补丁目录。如果输出里出现 "CheckApplicable completed successfully"，再执行正式 apply。

opatch apply "%PATCH_DIR%" -invPtrLoc "C:\Program Files\Oracle\Inventory\ContentsXML\oraInst.loc"

apply 的过程会有持续输出，会看到 "Copying files"、"Updating inventory" 这些阶段。期间不要开 Oracle 企业管理器，也不要用 PL/SQL Developer 连数据库，Windows 下高并发读文件可能让替换过程出现共享冲突。等跑到 "OPatch succeeded" 之后再继续。

这里你可能会困惑：怎么 opatch 没让我输数据库用户名密码？因为 11.2.0.4 的补丁包含两类内容：一类是立即生效的二进制变更，由 opatch 写盘；另一类是延迟生效的 SQL 变更，需要在后面的步骤里以 DBA 身份登入实例去执行。只跑 opatch apply 不代表补丁已经完全生效，很多人就是死在这一步。

3.3 应用后的数据库补丁：catbundle.sql 和 utlrp.sql

opatch apply 成功后，先把服务启动起来，然后进入数据库执行 SQL。这个动作叫“数据字典更新”。

net start OracleOraDb11g_home1TNSListener net start OracleServiceORCL sqlplus / as sysdba

如果本机 sqlplus 不在 PATH 里，请先 cd 到%ORACLE_HOME%\bin。在 sqlplus 里执行下面这段。

STARTUP; @?/rdbms/admin/catbundle.sql cpu apply @?/rdbms/admin/utlrp.sql EXIT;

逻辑说明：catbundle.sql 是 11.2.0.4 在 Windows 平台执行 CPU/PSU SQL 的标准入口。cpu apply告诉它把当前补丁包内携带的 SQL 组件应用到数据字典。注意这里不能用冒号替代，不能只执行@?/rdbms/admin/catbundle.sql，必须带上 cpu 和 apply 两个参数。utlrp.sql 是重新编译无效对象的固定脚本，补丁替换了一些包，必然导致部分包的状态变成 invalid，跑一下可以把它们重编译。这个过程通常需要几分钟到十几分钟，取决于数据库大小。

执行完 catbundle 后，使用下面的 SQL 确认补丁在数据库层落地。

col ACTION_TIME format a20 col COMMENTS format a40 set lines 200 SELECT ACTION_TIME, ACTION, COMMENTS FROM registry$history ORDER BY ACTION_TIME DESC;

输出里那条 ACTION 为 APPLY、COMMENTS 带 PSU 字样或 CPU 批次的记录，就是这次补丁在数据字典层面的证据。回到操作系统，再用opatch lsinventory确认二进制层面也一致。

4. Win64 打补丁避坑：监听器、内存、包状态和旧 JDBC 驱动的四个现场

4.1 监听器服务无法启动：OracleOraDb11g_home1TNSListener 报错 1053

现象很简单：补丁打完后，数据库服务能起来，但net start OracleOraDb11g_home1TNSListener始终报“服务没有及时响应启动或控制请求”，错误代码往往是 Windows 的 1053。有人以为是补丁把监听器删了，于是重装监听，结果越弄越乱。

原因多半不是补丁本身，而是环境变量串扰。Windows 上环境变量 PATH 里如果同时存在 Oracle Client 11.2.0.4 和 Oracle Home 12c，补丁应用时会改掉注册表里的 ORACLE_HOME 顺序，监听器解析 listener.ora 时找不到对应的 tnsnames.ora，或者因为权限不够拒绝读取 “C:\Program Files\Oracle\Inventory” 下的网络配置。

解决办法：先不要重装监听，用管理员 cmd 执行lsnrctl start，注意它输出的错误路径。再检查 TNS_ADMIN 环境变量是否还指向原目录。如果 TNS_ADMIN 被改到了不存在的路径，执行set TNS_ADMIN=C:\app\oracle\product\11.2.0\dbhome_1\network\admin，然后到服务管理器里重启。另一种常见原因是 Windows 防火墙把 TCP 1521 端口挡住，同时 listener.ora 里又写死了 HOST 为旧机器名，补丁更新后机器名或 IP 变化，监听器绑定失败。解决方法是把 listener.ora 里的 HOST 改成 0.0.0.0，并确认防火墙允许 oracle.exe 监听 1521 端口。

4.2 opatch apply 跑到一半提示 Java heap space 或 OutOfMemoryError

这是 11.2.0.4 在 Windows 64 位上的经典翻车点。现象是 opatch 输出一堆日志，然后突然报 java.lang.OutOfMemoryError: Java heap space，补丁退出，Inventory 里留下一个“半应用”状态。

原因有两个：一是补丁包较大，旧 OPatch 默认的 JVM 堆太小；二是你机器本身页面文件不足，Windows 上 java.exe 创建大对象数组时内存申请失败。遇到这个坑，先别急着做回滚或重打，先修 OPatch 的启动参数。

在 cmd 里执行下面的环境变量设置，然后再重复 opatch apply。

set _JAVA_OPTIONS=-Xmx1024M -Xms256M opatch apply "%PATCH_DIR%" -invPtrLoc "C:\Program Files\Oracle\Inventory\ContentsXML\oraInst.loc"

参数说明：_JAVA_OPTIONS 会被 Java 虚拟机自动读入，其中 -Xmx1024M 把最大堆扩到 1GB，-Xms256M 指定初始堆。如果你的补丁目录本身超过 500MB，建议再加一个 -XX:MaxMetaspaceSize=256M。如果扩到 1GB 仍然报错，看看系统是否打开了超过 2GB 的用户态内存限制，必要时到系统属性的“高级系统设置”里把虚拟内存加大。

处理完以后，重新执行opatch apply时如果提示补丁已部分存在，不要乱删 Inventory。正确做法是继续用opatch apply -force重新覆盖，前提是你已经完整跑过一次 prereq。

4.3 补丁后 PL/SQL 包状态被丢弃，业务会话报 ORA-04068

这种现象在高并发生产环境特别常见：补丁当天一切正常，第二天早上业务连接池里的某个会话第一次调用包时报 “ORA-04068: existing state of packages has been discarded”。原因是包在编译期间被置为 invalid，补丁重新编译后，旧会话里缓存的包状态没有刷新。数据库补丁、尤其是那些改了 DBMS 包的补丁，几乎都会触发这个问题。

解决思路分两步。第一步是运行 utlrp.sql，把所有 invalid 对象重新编译一遍，这一步你在 3.3 节已经做过。第二步更重要，是要在业务不忙时让连接池刷新会话。对 Oracle 来说，可以执行ALTER SYSTEM FLUSH SHARED_POOL，但这条操作对性能冲击大，生产库不推荐；更稳妥的是在应用侧将连接池最小空闲连接数改为 0，并等待旧会话被回收。

预防也很简单：打补丁前记录一下当前 dba_objects 里 invalid 数量，打补丁后对比。如果 from 0 to 几百，不要慌，执行完 utlrp 后重新查询确认归零即可。真正让人翻车的不是 ORA-04068 本身，而是应用侧没做重试，导致当时在跑的第一笔业务直接失败。

4.4 Kettle 或旧 JDBC 驱动连库报版本错，oracle 服务却正常

打补丁后，有时数据库、监听器都正常，SQL*Plus 也能登进去，但 Kettle 任务忽然连不上，报“Invalid Oracle URL”或者“ORA-28040: No matching authentication protocol”。这是因为 Kettle 项目里的 ojdbc6.jar 还是 11.2.0.4 早期版本，而补丁更新了数据库的安全参数。Oracle 11.2.0.4 在后续补丁中增强了对认证协议的校验，旧驱动和新的 sqlnet.ora 安全设置不匹配。

解决办法里，最省事的是在 sqlnet.ora 里加一行兼容设置，但这是临时的。更推荐的长期做法是升级项目依赖里的 ojdbc6.jar 到 11.2.0.4 对应的 12.1 或 11.2.0.4 后续小版本。注意，Kettle 的 lib 目录下可能有两个 ojdbc 开头的 jar，如果你把 19c 的 ojdbc8.jar 也放进去，会连 class 冲突一起炸。这里有一个判断标准：Oracle 11.2.0.4 数据库，优先选 ojdbc6.jar 或 ojdbc7.jar，不要为了“最新”去放 ojdbc8.jar。

如果你正在使用 PL/SQL Developer 或 DBeaver 连接，也会在第一步建立连接时受到同样影响。DBeaver 自带的驱动经常是较新的 ojdbc8，连 11.2.0.4 反而可能触发协议问题，这时需要在 DBeaver 连接配置里手动指定 ojdbc6.jar。

4.5 补丁日志目录磁盘满，opatch 产生缺失文件错误

最后要提的是 Windows 系统盘空间被日志塞满的问题。Oracle 的 opatch 默认把日志写在%ORACLE_HOME%\cfgtoollogs\opatch\和%TEMP%下。有些服务器的 C 盘本来只剩几百 MB，补丁业务流程又产生了大量 trace，opatch apply 在写日志时会写盘失败，表现却是“Could not copy file to OPatch\backup”。

遇到这种情况，先dir C:\Windows\Temp看临时文件是不是积了几 GB，删掉能清的文件；再检查%ORACLE_HOME%\cfgtoollogs\opatch下有没有上季度留下的旧日志，归档到别的盘。清出空间后，不要马上重跑 apply，先看opatch lsinventory当前补丁状态，如果补丁没有在 Inventory 里登记，可以再跑一次 apply；如果已经登记了，就不要再盲目 apply，否则会得到 “Already Applied” 或 “Missing dependency”。

5. 验证与回滚：用 registry$history 和 opatch rollback 把补丁做成可逆操作

5.1 lsinventory 和 registry$history 双重验证

打完补丁后，验证不是随便点两下业务页面。你必须在操作系统层和数据库层各留一条证据，否则后面审计说不清。操作系统层用 opatch 查看补丁清单。

set ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 %ORACLE_HOME%\OPatch\opatch lsinventory -detail -invPtrLoc "C:\Program Files\Oracle\Inventory\ContentsXML\oraInst.loc" | findstr /i "2022.10.18"

说明：如果补丁包来自 2022.10.18 批次，输出里会出现对应补丁编号和发布日期。有的补丁包名带批次注释，但不会带“2022.10.18”这种明文，实际输出里你会看到 CPUOCT2022 等简写。别单纯找字符串，而是看补丁 ID 是否与你下载的 ID 一致。

数据库层要查 registry$history，这条 SQL 你之前已经跑过，验证阶段再跑一次，注意关注是否有 MULTIPLE APPLY 的记录。

SELECT TO_CHAR(ACTION_TIME, 'YYYY-MM-DD HH24:MI:SS') AS action_time, ACTION, NAMESPACE, VERSION, COMMENTS FROM sys.registry$history ORDER BY ACTION_TIME;

这段输出的重要性在于，如果补丁里有 SQL 变更，ACTION 会是 APPLY，COMMENTS 会写明 PSU 或 CPU。你看到和补丁 ID 对应的一条记录后，才算数据库层真正完成。如果这里查到两条相同补丁 ID 的 APPLY，说明之前因为内存不足中断后重跑过，不影响结果，但你要注意记录回滚路径时选最后一条。

5.2 回滚的三条路线和各自边界

补丁没有后悔药，但也不是完全不能回滚。对 11.2.0.4 的 Win64 补丁包，我一般看到三条路线。

第一条是只回滚软件层。用 opatch rollback 把二进制恢复成补丁前状态。

%ORACLE_HOME%\OPatch\opatch rollback -id <补丁ID> -invPtrLoc "C:\Program Files\Oracle\Inventory\ContentsXML\oraInst.loc"

这条命令只适合不含 SQL 变更的普通补丁。如果补丁包里带着 catbundle 要执行的 SQL，那数据库字典里已经改了，单靠 opatch rollback 会把软件和字典状态搞成“两头对不上”。

第二条是回滚软件层后，再运行对应的数据库层回滚脚本。这种方式主要用于官方明确支持“完整回滚”的 PSU 或 CPU，操作方式是：先 opatch rollback 二进制，然后重启数据库，再执行和 catbundle 配套的 rollback 脚本。但 11.2.0.4 的很多补丁并没有提供反向 SQL，或者提供的反向脚本要特定补丁编号，如果你手上的补丁包没有 rollback 子目录，就不要硬试。

第三条是我的保底做法：直接用 3.1 节做的备份恢复。先恢复 ORACLE_HOME 备份，再恢复 Inventory 备份，最后用 RMAN 备份恢复数据库到补丁前的时间点。这套方案最慢，但最确定。补丁时间本身不长，真正痛的是数据库备份恢复所需的下线时间。所以我会在打补丁前刻意确认数据库是运行在归档模式，并且备份一定是可以 restore 的。

5.3 检查无效对象和补丁后的实际会话

验证阶段最后一项是无效对象。虽然 3.3 节里跑过 utlrp.sql，但大型生产库在 catbundle 之后还会有一些动态对象因为并发而失效，必须再查一次。

SELECT owner, object_type, status, COUNT(*) FROM dba_objects WHERE status <> 'VALID' GROUP BY owner, object_type, status ORDER BY owner, object_type;

如果查出来的结果仍有很多，尤其是 SYS 下的包和视图，再跑一次@?/rdbms/admin/utlrp.sql。注意跑的时候不要在应用侧做 DDL，否则又会制造新的 invalid。等这条 SQL 的输出变成 “PL/SQL procedure successfully completed” 后，找一个业务账号从 SQL*Plus 做一次真正的会话连接，执行一条简单查询，确认没有 ORA-04068 或 ORA-00942。到这里，补丁才算真正打完了。

6. 我的补丁操作手册和三个强迫症习惯

每次打完补丁，我都会在本地保留一个“补丁操作记录表”，它不是 MOS 要求，而是我给自己留的后路。这张表只有七八个字段，但信息量足够让一个完全没参与的人，在半年后帮你做回滚。

除了这张表，我还有三个强迫症习惯。第一个是打死不在生产库的“第一次”打补丁，先在测试机上把 2022.10.18 这个补丁完整跑一遍，包括 catbundle 和 utlrp，记录实际耗时。第二个是在补丁前关掉所有 Windows 下的 Oracle 相关服务，哪怕只是后台的 Enterprise Manager，我不接受“应该没人用”的判断，只接受 tasklist 输出为空的事实。第三个是每次 opatch apply 之前，都先把 ORACLE_HOME 里原来的 OPatch 目录改名留底，而不是覆盖，这样才能保证回滚路径完整。

这些习惯看起来琐碎，但每次救我的都是它们。曾经有一次补丁在 Windows 上报 1053 监听错误，我花了一个小时排查，最后发现只是 TNS_ADMIN 被环境变量串了；还有一次 catbundle 没有执行，结果补丁在数据字典里根本没有记录，被审计打回重做。从那以后我宁愿多花半小时记一条白纸黑字的日志，也不再用大脑记补丁状态。

希望这篇 Win64 下 Oracle 11.2.0.4 补丁包的实操笔记能帮到你。下一次遇到补丁包，记得先看 README、再备份、最后 opatch，别急着点确定。

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