企业官网建设流程全解析

简介：本资源是Oracle 11.2.0.4数据库在Linux x86-64平台上的官方关键补丁包（Patch ID: p24436338），专为DBA及企业级数据库运维人员设计，用于修复已知安全漏洞、提升系统稳定性并优化高并发场景下的性能表现。压缩包为标准ZIP格式，体积达679.05MB，内含PatchSearch.xml（补丁元数据与安装指引）、核心补丁文件24436338等关键组件，涵盖OPatch可识别的二进制更新、脚本及校验信息，适用于生产环境热补丁部署前的验证与测试。目前已有205人下载学习，反映出该补丁在Oracle 11g长期维护阶段的实际应用热度。用户获取后可直接用于OPatch工具执行标准化安装，配套XML文件提供清晰的依赖说明与回滚路径，显著降低误操作风险；同时，补丁内容结构规范、版本标识明确，便于纳入企业级补丁管理流程，是保障Oracle 11.2.0.4系统持续合规与安全运行的重要支撑材料。

1. 这不是普通 ZIP 包：p24436338_112040_Linux-x86-64.zip 是 Oracle 官方发布的 Critical Patch Update（CPU）补丁，专用于修复 Oracle Database 11.2.0.4 在 Linux x86-64 平台上的高危安全漏洞与稳定性缺陷

你手头这个以p24436338_开头、带_Linux-x86-64.zip后缀的压缩包，绝不是某个论坛打包的“破解版”或“精简安装包”。它是 Oracle 官方通过 My Oracle Support（MOS）发布的正式 CPU 补丁编号——Patch 24436338，目标版本明确锁定为 Oracle Database 11.2.0.4，操作系统平台严格限定为 Linux x86-64（即主流的 CentOS/RHEL/Oracle Linux 6/7 的 64 位环境）。这个补丁解决的是 CVE-2017-3625、CVE-2017-3626 等多个被 CVSS 评分高达 9.8 的远程代码执行与权限提升漏洞，同时修复了 RAC 环境下节点间心跳超时误判、Data Guard 日志传输中断后无法自动重连等生产级“玄学”故障。它不提供新功能，也不改变数据库架构，但一旦漏打，你的 11.2.0.4 实例在未加固网络边界时，可能成为攻击者绕过应用层直接接管数据库服务器的跳板。适合正在维护老旧但尚未升级至 12c/19c 的核心 OLTP 系统的 DBA，或是需要通过等保三级/四级安全审计的运维团队——这不是“可选更新”，而是当前版本下必须落地的“后悔药”。

2. 补丁本质与适用性验证：确认它真能用在你的环境上，而不是打完才发现版本错配或平台不兼容

2.1 补丁编号解析：p24436338 是什么？为什么必须匹配 11.2.0.4？

Oracle 补丁编号p24436338中的p表示 Patch，24436338是 MOS 系统分配的唯一整数 ID。该 ID 对应的补丁元数据在 MOS 文档 Doc ID 24436338.1 中明确定义：

• 适用产品：Oracle Database Server – Enterprise Edition
• 适用版本：11.2.0.4.0（注意：不是 11.2.0.4.190101，也不是 11.2.0.4.200114，就是原始 GA 版本号 11.2.0.4.0）
• 平台限制：Linux x86-64（不支持 Linux IA64、Solaris SPARC 或 Windows）
• 补丁类型：Composite CPU（复合型季度安全更新），包含 12 个子补丁（sub-patch），覆盖 RDBMS、Oracle Net、XML DB、OLAP 等多个组件

提示：Oracle 11.2.0.4 自 2015 年起已进入 Extended Support 阶段，官方不再发布新特性，但每季度仍通过 CPU 补丁修复高危漏洞。p24436338 是 2017 年 1 月发布的 CPU，属于该版本生命周期中较早期但关键的一次更新。

2.2 验证本地数据库版本与平台：三步确认是否“对得上号”

在解压或运行 OPatch 前，必须用以下命令逐项核对，避免因小数点后版本号差异导致 OPatch 报错OPatch failed with error code 73：

# 步骤 1：确认数据库软件主版本（非实例版本） $ORACLE_HOME/OPatch/opatch version # 输出应为：OPatch Version: 11.2.0.3.20 或更高（p24436338 要求 OPatch ≥ 11.2.0.3.0） # 步骤 2：确认 $ORACLE_HOME 对应的数据库版本 $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep "Oracle Database" # 输出应严格匹配：Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production # 步骤 3：确认操作系统架构与内核 uname -m && cat /etc/redhat-release 2>/dev/null || cat /etc/os-release | grep PRETTY_NAME # 输出应为：x86_64 + "Red Hat Enterprise Linux Server release 6.9 (Santiago)" 或类似

• 参数说明：
  • opatch version检查 OPatch 工具自身版本，若低于 11.2.0.3.0，需先单独下载并升级 OPatch（补丁编号 p6880880）；
  • lsinventory -detail读取$ORACLE_HOME/inventory/ContentsXML/comps.xml，比sqlplus / as sysdba查v$version更可靠，因后者反映的是实例启动时加载的版本，而补丁操作对象是$ORACLE_HOME目录下的二进制文件；
  • uname -m必须为x86_64，若为i386或i686则完全不兼容，强行解压会报cannot execute binary file。

2.3 解压与目录结构初检：识别补丁包内的真实内容

将p24436338_112040_Linux-x86-64.zip解压到临时目录（严禁直接解压到$ORACLE_HOME下）：

mkdir -p /tmp/patch_p24436338 unzip p24436338_112040_Linux-x86-64.zip -d /tmp/patch_p24436338 ls -l /tmp/patch_p24436338/

典型输出应包含：

drwxr-x--- 3 oracle oinstall 4096 Jan 10 2017 24436338/ # 主补丁目录 -rw-r----- 1 oracle oinstall 123 Jan 10 2017 README.txt # 官方说明（必读） -rw-r----- 1 oracle oinstall 4567 Jan 10 2017 patchmd.xml # 补丁元数据（含依赖校验）

进入24436338/目录后，关键文件有：

• etc/config/actions：定义补丁安装时执行的脚本动作（如停库、替换.so文件、重建字典视图）；
• files/lib/libnnz11.so：被替换的核心加密库（CVE-2017-3625 修复点）；
• files/rdbms/admin/catcpu.sql：需手动执行的 SQL 脚本（升级数据字典）；
• files/rdbms/admin/catbundle.sql：RAC 环境专用脚本（单实例无需）。

注意：该补丁不包含 OPatch 工具本身，也不修改$ORACLE_HOME/OPatch/目录。所有文件均按 Oracle 内部路径映射（如files/rdbms/→$ORACLE_HOME/rdbms/），OPatch 会自动完成路径映射。

3. 标准化安装流程：从预检查到静默应用，每一步都带参数含义与执行逻辑

3.1 预检查（Prereq）：用 OPatch 自动扫描环境风险

在应用补丁前，必须运行预检查，它会模拟安装过程并报告所有阻断性问题（如空间不足、进程占用、依赖缺失）：

cd /tmp/patch_p24436338/24436338 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./

• 参数说明：
  -ph ./指定当前目录为补丁路径（.表示相对路径，必须加斜杠）；
  CheckConflictAgainstOHWithDetail是 Oracle 推荐的预检策略，比CheckApplicable更严格，会检测文件级冲突（如libnnz11.so是否已被其他补丁修改）；
  若输出含Prereq check passed.则可继续；若出现Prereq check failed.，则需根据错误码（如OPatch failed with error code 25）查 MOS 文档。

逻辑说明：此命令实际调用$ORACLE_HOME/OPatch/perl/bin/perl执行./ocm/bin/emocmrsp，读取patchmd.xml中的<conflicts>节点，并对比$ORACLE_HOME/inventory/中已安装补丁记录。耗时约 2–5 分钟，期间不要中断。

3.2 停库与监听：为什么必须停？哪些进程不能漏？

p24436338 属于"Online Patch" 不支持类型，所有被修改的二进制文件（libnnz11.so,oracle,tnslsnr）均被数据库进程常驻内存映射，热更新会导致段错误（Segmentation Fault）。因此必须彻底停止：

# 停止所有数据库实例（RAC 环境需停全部节点） srvctl stop database -d ORCL # 停止监听（防止新连接涌入） srvctl stop listener # 强制清理残留进程（关键！） ps -ef | grep "ora_.*ORCL" | grep -v grep | awk '{print $2}' | xargs -r kill -9 ps -ef | grep tnslsnr | grep -v grep | awk '{print $2}' | xargs -r kill -9 # 验证无残留 lsof -p $(pgrep -f "oracleORCL") 2>/dev/null | grep libnnz11 # 应无输出

• 参数说明：
  srvctl stop database是 RAC 环境标准命令，单实例可用sqlplus / as sysdba <<EOF\nshutdown immediate;\nexit;\nEOF；
  xargs -r kill -9中-r参数确保当grep无结果时xargs不执行kill（避免误杀）；
  lsof验证是血泪经验：曾有案例因ora_mmon_ORCL进程残留导致补丁后库无法启动，lsof可直接看到libnnz11.so是否仍被映射。

3.3 应用补丁（Apply）：静默模式与日志留存策略

使用-silent参数避免交互式提示，并重定向日志便于回溯：

$ORACLE_HOME/OPatch/opatch apply -silent -oh $ORACLE_HOME -phBase /tmp/patch_p24436338/ > /tmp/patch_p24436338/apply.log 2>&1

• 参数说明：
  -silent：跳过所有Do you want to proceed? [y|n]提示，适合脚本化；
  -oh $ORACLE_HOME：显式指定 Oracle Home，防止 OPatch 误读环境变量；
  -phBase /tmp/patch_p24436338/：指向补丁根目录（含24436338/子目录），而非子目录本身；
  > apply.log 2>&1：将 stdout 与 stderr 合并写入日志，避免关键错误被忽略。

逻辑说明：OPatch 会按patchmd.xml中<actions>顺序执行：

1. 备份原文件（如libnnz11.so→libnnz11.so.orig）；
2. 复制新文件到$ORACLE_HOME/lib/；
3. 设置文件权限（chmod 755）；
4. 更新$ORACLE_HOME/inventory/中的补丁注册表。
   全程约 8–12 分钟，期间$ORACLE_HOME目录不可被其他进程访问。

3.4 数据字典升级：catcpu.sql 必须手动执行

补丁仅更新二进制，数据字典变更需 DBA 显式执行 SQL：

sqlplus / as sysdba <<'EOF' SET ECHO ON SPOOL /tmp/patch_p24436338/catcpu.log @?/rdbms/admin/catcpu.sql @?/rdbms/admin/utlrp.sql SPOOL OFF EXIT; EOF

• 参数说明：
  @?/rdbms/admin/catcpu.sql中?代表$ORACLE_HOME，确保路径正确；
  catcpu.sql是 CPU 补丁专用字典脚本，会更新SYS.REGISTRY$表并执行DBMS_REGISTRY_SYS.CPU_SCHEMA_INVALIDATE；
  utlrp.sql重新编译所有失效对象（补丁后约 5–10% 的 PL/SQL 包会失效）；
  SPOOL记录完整执行过程，便于审计。

注意：此步骤必须在数据库 MOUNT 状态下执行（startup mount即可），无需 OPEN。若实例已 OPEN，需先shutdown immediate再startup mount。

4. 避坑指南：五个真实翻车现场与对应解法，来自某高校核心教务库的血泪复盘

4.1 现象：OPatch 报错OPatch failed with error code 73

原因：$ORACLE_HOME下存在oraInst.loc文件，但其指向的 inventory 目录（如/u01/app/oraInventory）权限为750，且oinstall组无读取权。OPatch 在读取 inventory 时因权限不足失败。
解决：

chmod 755 /u01/app/oraInventory chmod -R 755 /u01/app/oraInventory/ContentsXML/ chown -R oracle:oinstall /u01/app/oraInventory

4.2 现象：补丁应用成功，但重启库时报ORA-00704: bootstrap process failure

原因：catcpu.sql未在 MOUNT 状态执行，而是在 OPEN 状态下运行，导致bootstrap$字典表被异常修改。
解决：

• 立即shutdown abort；
• 启动到NOMOUNT，执行recover database（需归档日志）；
• 若无归档，从最近 RMAN 备份恢复SYSTEM表空间；
• 预防：永远在startup mount后执行catcpu.sql，并在脚本开头加SELECT status FROM v$instance;确认状态。

4.3 现象：监听启动失败，日志报TNS-12547: TNS:lost contact

原因：补丁更新了$ORACLE_HOME/lib/libnnz11.so，但tnslsnr进程仍链接旧版libnnz11.so（因LD_LIBRARY_PATH缓存或ldconfig未刷新）。
解决：

# 清理共享库缓存 sudo /sbin/ldconfig -v | grep nnz # 若输出含旧路径，执行 sudo /sbin/ldconfig $ORACLE_HOME/lib # 重启监听 srvctl start listener

4.4 现象：RAC 环境单节点打补丁后，crsctl check cluster报CRS-4537: Cluster Ready Services is online但crsctl stat res -t显示ora.orcl.db为OFFLINE

原因：补丁未在所有 RAC 节点统一应用，ora.orcl.db资源依赖的ora.asm或ora.cssd组件版本不一致，CRS 拒绝启动。
解决：

• 在所有节点重复 3.1–3.3 步骤（包括opatch prereq）；
• 执行crsctl stop crs后crsctl start crs强制同步集群状态；
• 切记：RAC 补丁必须所有节点opatch lsinventory输出完全一致。

4.5 现象：补丁后应用连接报ORA-28040: No matching authentication protocol

原因：libnnz11.so升级后，sqlnet.ora中SQLNET.ALLOWED_LOGON_VERSION_SERVER=8与新协议不兼容（p24436338 强制要求最低11）。
解决：

echo "SQLNET.ALLOWED_LOGON_VERSION_SERVER=11" >> $ORACLE_HOME/network/admin/sqlnet.ora echo "SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11" >> $ORACLE_HOME/network/admin/sqlnet.ora srvctl stop listener && srvctl start listener

提示：此参数影响所有客户端，若存在 Oracle 10g 客户端，需同步升级客户端或临时设为10（不推荐，牺牲安全性）。

5. 验证与回归测试：用四类 SQL 和一个 Shell 脚本确认补丁真正生效

5.1 验证补丁注册：确认 OPatch 已写入 inventory

$ORACLE_HOME/OPatch/opatch lsinventory -detail | grep -A 5 "24436338"

预期输出必须包含：

Patch level: 24436338 Patch description: "Database Patch Set Update : 11.2.0.4.170117 (24436338)" Applied on: 10-JAN-2017 00:00:00

若只显示Patch description: "Critical Patch Update"而无具体编号，则补丁未注册成功，需检查apply.log中Copying files...是否完成。

5.2 验证二进制文件：确认libnnz11.so已更新

# 获取文件 MD5（Oracle 官方公布值为 a1b2c3d4e5f6...） md5sum $ORACLE_HOME/lib/libnnz11.so # 检查文件时间戳是否为补丁应用时间 ls -la --time-style=long-iso $ORACLE_HOME/lib/libnnz11.so # 验证符号表是否含新函数（CVE 修复特征） nm -D $ORACLE_HOME/lib/libnnz11.so | grep -i "ssl_v3_client_hello\|tls1_check_serverhello_tlsext"

• 参数说明：
  nm -D列出动态符号，ssl_v3_client_hello是 CVE-2017-3625 修复后新增的 SSL/TLS 握手校验函数；
  若nm输出为空，说明文件未被替换，需检查apply.log中Copying file libnnz11.so行。

5.3 验证数据字典：确认REGISTRY$表记录补丁

SELECT action, namespace, version, id, bundle_series FROM dba_registry_history WHERE id = '24436338' AND action = 'APPLY'; -- 应返回一行，bundle_series 为 'CPU' SELECT * FROM registry$history WHERE action = 'CPU' ORDER BY when;

注意：dba_registry_history记录的是catcpu.sql执行结果，registry$history是底层基表，二者应一致。若前者无记录而后者有，说明catcpu.sql未成功提交。

5.4 回归测试脚本：一个 Bash 脚本能跑通的最小验证集

将以下内容保存为validate_p24436338.sh，赋予执行权后运行：

#!/bin/bash # 验证目标：1) 库可正常启停 2) 监听可接受连接 3) 加密连接可用 4) 字典视图可查询 export ORACLE_SID=ORCL export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH # 1) 启停测试 sqlplus / as sysdba <<'EOF' >/dev/null 2>&1 startup mount; shutdown immediate; EOF if [ $? -ne 0 ]; then echo "FAIL: DB startup/shutdown"; exit 1; fi # 2) 监听连通性 tnsping ORCL >/dev/null 2>&1 if [ $? -ne 0 ]; then echo "FAIL: tnsping failed"; exit 1; fi # 3) 加密连接测试（需 sqlnet.ora 启用 SSL） sqlplus system/password@ORCL <<'EOF' >/dev/null 2>&1 SELECT 1 FROM dual; EOF if [ $? -ne 0 ]; then echo "FAIL: encrypted connection"; exit 1; fi # 4) 字典查询 sqlplus / as sysdba <<'EOF' >/dev/null 2>&1 SELECT COUNT(*) FROM v$session; EOF if [ $? -ne 0 ]; then echo "FAIL: dictionary query"; exit 1; fi echo "PASS: All validation checks completed."

• 逻辑说明：该脚本模拟真实业务链路——DB 启停是基础，tnsping验证网络层，sqlplus连接验证协议层，v$session查询验证内核层。任一环节失败即终止，避免带病上线。

从那以后我每次给 11.2.0.4 打 CPU 补丁，都强制走一遍这个四步验证脚本，哪怕只是测试库。因为有一次跳过验证，上线后第三天凌晨监控告警ORA-28040，排查发现是sqlnet.ora参数没同步，而那个参数在apply.log里根本不会体现——补丁只管二进制，不管配置文件。希望帮到你。

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