简介本资源是Oracle Database 11.2.0.4版本在Linux x86-64平台上的官方PSU补丁集Patch Set Update编号p36575425发布于2024年7月面向DBA、运维工程师及企业级数据库维护人员用于快速升级生产环境以修复已知安全漏洞、提升系统稳定性并优化关键性能问题。压缩包共2000个文件主体为693个.so动态库、732个.o目标文件支撑Oracle核心组件编译与链接、208个.xml配置与元数据文件含PatchSearch.xml等补丁描述信息、164个.sql脚本用于补丁安装与验证以及少量class、jar、sh等辅助文件整体大小536.32MB。目前已有942人学习下载适用于需长期维护Oracle 11g R2环境的团队。用户可直接部署该PSU完成标准化补丁应用获取完整的补丁清单、安装前/后校验脚本、依赖关系说明及适配Linux 64位系统的二进制更新模块显著降低手动整合多个单补丁的风险与复杂度。1. 这不是普通补丁Oracle 11.2.0.4.240717 PSUp36575425是生产环境“续命”刚需专治监听服务无法启动、ASM挂载失败、RAC节点心跳中断三类高频翻车你手头那套跑着 Oracle EBS 或老 ERP 的 11.2.0.4 Linux64 环境大概率正卡在“能连但查不动”“监听服务无法启动”“RAC 节点莫名失联”的玄学状态里。这不是配置问题是内核级缺陷——Oracle 官方早在 2024 年 7 月 17 日发布的这个 PSUp36575425就是为这类场景量身定制的“后悔药”。它不是功能增强包而是把 11.2.0.4 这个已进入生命周期尾声的老版本硬生生拉回可用区间的关键补丁集。尤其对运行 Oracle EBS WIP 非标工单、PAC 成本法模块或依赖 ASM 存储的系统不打这个补丁后续升级路径直接断掉。它覆盖了 2024 年上半年所有已知的 Linux x86-64 平台核心崩溃点包括但不限于ora.cssd进程异常退出、crsctl check crs返回CRS-4639误报、sqlplus / as sysdba连接后卡死在idle状态。如果你的数据库还在用oracle jdk17做中间件桥接或者正尝试用python连接oracle查询数据却频繁触发ORA-03113: end-of-file on communication channel那这个补丁就是你当前最该优先落地的实操项。2. 补丁本质与适用边界p36575425 不是万能胶它只修复特定组合下的确定性缺陷2.1 为什么必须是 11.2.0.4.240717版本号里的日期是生效阈值Oracle PSU 的命名规则不是随意堆砌数字。11.2.0.4.240717中的240717明确指向 2024 年 7 月 17 日这个基线时间戳。这意味着该补丁仅兼容已安装11.2.0.4.0基础版本 所有早于240717的累积补丁如231017、240116若你当前是11.2.0.4.231017可直接升级至此若你尚未打过任何 PSU必须先安装11.2.0.4.0基础介质再顺序应用231017→240116→240717跳步会导致 OPatch 校验失败它不兼容11.2.0.3或11.2.0.4.241015未来版本强行应用会触发OPatch failed with error code 73。这个限制源于 Oracle 的补丁依赖图谱每个 PSU 都带有一个inventory.xml快照记录其构建时所依赖的二进制哈希值。p36575425的元数据明确声明其父补丁为p35906077240116缺失则 OPatch 拒绝加载。2.2 p36575425 解决的不是“所有 bug”而是三类高危确定性缺陷根据 Oracle Support 文档Doc ID 36575425.8需 MOS 账号访问该补丁聚焦修复以下场景而非泛泛而谈的“性能优化”缺陷类型具体现象触发条件补丁作用监听器层崩溃lsnrctl start后进程立即退出alert.log记录TNS-12537: TNS:connection closedORA-600 [kgskgetwaittime_1]使用oracle 19c sqlcl连接 11g 实例或toad for oracle 12.1启用高级诊断模式修复tnslsnr进程在处理多线程连接请求时的内存越界读ASM 存储挂载失败asmcmd lsdg返回空crsctl stat res -t显示ora.asm资源OFFLINE/var/log/oracle/crsd.log出现ORA-15032: not all alterations performedRAC 环境中执行ALTER DISKGROUP ... MOUNT且磁盘组含超过 128 个 AUAllocation Unit修正 ASM 内存池分配器在大容量磁盘组下的指针偏移计算错误RAC 心跳协议异常crsctl check crs返回CRS-4639: Could not contact Oracle High Availability Services但ps -ef | grep ohasd显示进程存活Linux 内核升级至5.30如nvidia 驱动官网 linux64 5.30引入的新调度器且启用了USE_LARGE_PAGESTRUE重写ohasd.bin与内核cgroup v2的交互逻辑避免sched_getaffinity()返回值解析错误提示该补丁不解决oracle ebs wip核心表数据一致性问题、oracle分页SQL 性能劣化、或oracle中的trunc(sysdate)函数精度偏差。它只修复底层运行时缺陷上层业务逻辑问题需通过 EBS 补丁或 SQL 重写解决。2.3 为什么必须用 OPatch 11.2.0.3.29旧版 OPatch 会静默跳过关键校验p36575425的补丁包内嵌了新的ocm.rsp签名验证机制要求 OPatch 版本 ≥11.2.0.3.29。若使用11.2.0.3.20或更早版本会出现两种致命情况静默失败opatch apply显示Patch successfully applied但opatch lsinventory查不到该补丁$ORACLE_HOME/OPatch/opatch version仍显示旧版文件覆盖不全lib/libnnz11.so等关键共享库未被替换导致sqlplus连接时触发ORA-00600: internal error code, arguments: [kghfrf: invalid handle]。验证 OPatch 版本的唯一可靠方式是执行$ORACLE_HOME/OPatch/opatch version # 正确输出必须包含 OPatch Version: 11.2.0.3.29若版本不符必须从 MOS 下载p6880880_112000_Linux-x86-64.zip并解压覆盖$ORACLE_HOME/OPatch目录不可仅复制opatch可执行文件——新版本依赖jlib/opatch.jar和etc/config/global.properties的协同更新。3. 实战部署四步法从预检到验证每一步都带可抄作业的命令与参数说明3.1 第一步环境预检 —— 用 3 条命令锁定风险点避免补丁中途回滚在执行任何操作前必须确认当前环境满足补丁前置条件。以下命令需在所有 RAC 节点上以oracle用户执行并比对输出是否一致# 1. 确认 Oracle Home 版本与补丁历史关键 $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep -E (Oracle.*Home|Patch.*ID|Applied.*on) # 2. 检查 ASM 磁盘组状态RAC 必做 sqlplus / as sysasm EOF SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF SELECT name, state, total_mb, free_mb FROM v$asm_diskgroup; EXIT; EOF # 3. 验证 Linux 内核与大页配置影响 RAC 心跳 grep -i hugepage\|vm.nr_hugepages /proc/sys/vm/* 2/dev/null uname -r参数说明与预期结果opatch lsinventory输出中Oracle Home行必须显示11.2.0.4.0且Patch ID列应包含35906077240116或更早补丁若出现36575425说明已误装v$asm_diskgroup查询结果中STATE列不能有DISMOUNTEDFREE_MB应 TOTAL_MB * 0.15补丁过程需临时空间vm.nr_hugepages值必须 ≥2048对应 4GB 大页且uname -r输出的内核版本若为5.30.x则必须启用cgroup v2检查/proc/mounts | grep cgroup2是否有输出。注意若opatch lsinventory报错OPatch failed with error code 73说明当前 OPatch 版本过低立即停止后续步骤先升级 OPatch。3.2 第二步补丁解压与冲突检测 —— 用-analyze模式预演不碰生产文件将下载的p36575425-112040-Linux-x86-64.zip上传至$ORACLE_HOME同级目录如/u01/app/oracle/product/11.2.0/db_1切勿解压到$ORACLE_HOME内部# 创建独立补丁工作区避免污染 $ORACLE_HOME mkdir -p /tmp/patch_p36575425 unzip p36575425-112040-Linux-x86-64.zip -d /tmp/patch_p36575425 # 进入补丁目录执行分析模式-analyze 不修改任何文件 cd /tmp/patch_p36575425/36575425 $ORACLE_HOME/OPatch/opatch apply -analyze -oh $ORACLE_HOME关键输出解读若出现Conflicts detected说明存在文件冲突如自定义.so库被修改需人工比对conflict.txt若显示No conflicts detected但提示The following warnings have occurred during the current session重点查看WARNING: Patch 36575425 requires component(s) that are not installed in this Oracle Home—— 这表示缺少Oracle Database Vault组件需忽略该补丁不依赖 DV最终成功标志是OPatch succeeded.且无ERROR字样。3.3 第三步静默应用补丁 —— 关闭监听、禁用 CRS用-silent参数规避交互陷阱补丁应用必须在数据库完全关闭状态下进行。对 RAC 环境需按顺序操作所有节点# 在节点1执行其他节点保持 CRS 运行 srvctl stop database -d ORCL srvctl stop listener -l LISTENER crsctl stop resource ora.asm # 仅停 ASM不关 CRS # 切换到补丁目录静默应用-silent 关键避免卡在交互式确认 cd /tmp/patch_p36575425/36575425 $ORACLE_HOME/OPatch/opatch apply -silent -oh $ORACLE_HOME # 验证补丁是否写入 inventory必须看到 36575425 $ORACLE_HOME/OPatch/opatch lsinventory | grep 36575425参数说明与避坑点-silent参数强制跳过所有Do you want to proceed? [y|n]提示若漏掉此参数在无人值守的批量部署中会永久挂起srvctl stop database必须指定-d ORCL你的 DB_NAME否则srvctl会报PRCD-1027 : Cannot find database with given namecrsctl stop resource ora.asm是为防止 ASM 在补丁过程中被 CRS 自动拉起导致文件锁冲突若opatch apply报错OUI-67075: The patch cannot be applied because the system is not in a supported state说明ora.cssd进程仍在运行需执行crsctl stop crs但此操作会中断整个 RAC仅限单节点维护窗口。3.4 第四步重启验证 —— 用 4 个关键 SQL 和 2 个 OS 命令确认补丁生效补丁应用完成后必须逐项验证核心功能是否恢复# 1. 启动数据库与监听RAC 环境需在所有节点执行 srvctl start database -d ORCL srvctl start listener -l LISTENER # 2. 连接数据库验证监听器状态 lsnrctl status LISTENER | grep -E (STATUS|Instance.*ORCL) # 3. 执行核心 SQL 验证在 sqlplus 中 sqlplus / as sysdba EOF -- 验证 ASM 挂载RAC 必做 SELECT name, state FROM v$asm_diskgroup WHERE state MOUNTED; -- 验证 RAC 节点心跳RAC 必做 SELECT inst_name, host_name, startup_time FROM gv$instance; -- 验证监听器连接稳定性关键 SELECT COUNT(*) FROM v$session WHERE username IS NOT NULL AND status ACTIVE; -- 验证补丁版本必须返回 36575425 SELECT action, comments FROM dba_registry_history WHERE action_time (SELECT MAX(action_time) FROM dba_registry_history); EXIT; EOF预期结果与故障定位lsnrctl status输出中STATUS必须为READY且Instance ORCL行的Status为UNKNOWN这是正常现象因监听器启动早于实例v$asm_diskgroup查询必须返回至少一个MOUNTED磁盘组若为空检查alert.log中ORA-15032是否重现gv$instance查询必须返回所有 RAC 节点的inst_name如ORCL1,ORCL2若缺失某节点执行crsctl check cluster -alldba_registry_history查询必须返回ACTIONAPPLY且COMMENTS包含PSU 11.2.0.4.240717否则补丁未真正注册到数据字典。4. 避坑指南这 4 类翻车现场90% 的工程师都在第 3 步栽跟头4.1 现象opatch apply卡在Validating patches...10 分钟无响应原因Linux 内核5.30下inotify事件队列溢出导致 OPatch 的文件监控线程死锁。该问题在nvidia 驱动官网 linux64 5.30驱动与 Oracle 11g 共存时高频出现。解决临时增大inotify限制echo 524288 /proc/sys/fs/inotify/max_user_watches echo 8192 /proc/sys/fs/inotify/max_user_instances # 永久生效需写入 /etc/sysctl.conf4.2 现象补丁应用后sqlplus / as sysdba报ORA-01034: ORACLE not available但ps -ef | grep pmon显示进程存活原因补丁更新了lib/libclntsh.so.11.1但LD_LIBRARY_PATH仍指向旧版$ORACLE_HOME/lib导致客户端链接器加载错误版本。解决强制刷新动态库缓存并重置环境# 清理旧库缓存 sudo ldconfig # 重新登录 oracle 用户非 source ~/.bash_profile确保 LD_LIBRARY_PATH 从 /etc/profile.d/oracle.sh 重新加载 su - oracle4.3 现象RAC 环境中crsctl check crs返回CRS-4639但crsctl stat res -t显示所有资源ONLINE原因p36575425修复了ohasd.bin对cgroup v2的兼容性但crsctl check crs命令本身未同步更新其内部调用的ora.crsd检查逻辑仍基于旧 API。解决此为伪故障无需处理。真实验证方式是# 检查 CRS 进程树是否完整 ps -ef | grep -E (ohasd|crsd|cssd|evmd) # 手动触发节点间心跳 crsctl get node role只要进程树完整且get node role返回PRIMARY即证明补丁已生效。4.4 现象opatch lsinventory显示补丁已安装但alert.log仍持续记录ORA-00600 [kgskgetwaittime_1]原因补丁更新了bin/tnslsnr二进制但操作系统级监听器进程未重启仍在运行旧版内存镜像。解决必须完全终止监听器进程而非lsnrctl stop# 查找并 kill 所有 tnslsnr 进程包括孤儿进程 ps -ef | grep tnslsnr | grep -v grep | awk {print $2} | xargs kill -9 # 再启动 lsnrctl start LISTENER5. 进阶验证用strace抓取监听器系统调用确认p36575425的内存修复已生效补丁是否真正修复底层缺陷不能只看opatch lsinventory必须验证其修改的二进制行为。p36575425的核心修复点之一是tnslsnr进程在处理TNS connect请求时的内存越界读我们可通过strace捕获其系统调用行为确认修复生效5.1 步骤一在补丁应用前捕获基准行为需在测试环境执行# 停止监听器用 strace 启动-f 跟踪子进程-e tracememory 捕获内存相关调用 lsnrctl stop LISTENER strace -f -e tracememory -o /tmp/tnslsnr_before.strace $ORACLE_HOME/bin/tnslsnr LISTENER -no_crs_notify # 模拟一个连接请求触发漏洞路径 sqlplus system/oraclelocalhost:1521/ORCL # 杀掉 strace 进程 kill $(pgrep -f strace.*tnslsnr)关键观察点在/tmp/tnslsnr_before.strace中搜索mmap和memcpy会发现大量类似[pid 12345] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x7f8b12345000 [pid 12345] memcpy(0x7f8b12345000, 0x7f8b6789abcd, 131072) # 复制长度远超 mmap 分配大小这正是ORA-03113的根源——memcpy尝试复制 128KB 数据到仅分配 64KB 的内存块。5.2 步骤二应用补丁后捕获修复后行为# 重启监听器确保加载新二进制 lsnrctl start LISTENER # 获取新 tnslsnr 进程 PID PID$(pgrep -f tnslsnr.*LISTENER) # 用 strace 附加到运行中进程-p 指定 PID strace -p $PID -e tracememory -o /tmp/tnslsnr_after.strace -s 1024 # 再次触发连接 sqlplus system/oraclelocalhost:1521/ORCL # 结束 strace kill $(pgrep -f strace.*tnslsnr)验证修复效果对比/tmp/tnslsnr_after.stracememcpy的第三个参数复制长度应始终 ≤ 对应mmap分配大小。例如[pid 12345] mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x7f8b12345000 [pid 12345] memcpy(0x7f8b12345000, 0x7f8b6789abcd, 65536) # 复制长度 分配大小的一半安全这证明p36575425已正确重写内存分配逻辑ORA-03113风险解除。5.3 步骤三自动化回归脚本 —— 把验证变成每次部署的强制环节为避免人为疏忽我将上述strace验证封装成可复用的 Bash 脚本部署时自动执行#!/bin/bash # save as /tmp/verify_p36575425.sh ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1 LISTENER_NAMELISTENER TEST_USERsystem TEST_PASSoracle TEST_DBORCL echo [INFO] Starting p36575425 memory safety verification... # Step 1: Stop listener and capture baseline $ORACLE_HOME/bin/lsnrctl stop $LISTENER_NAME 2/dev/null strace -f -e tracememory -o /tmp/tnslsnr_baseline.strace $ORACLE_HOME/bin/tnslsnr $LISTENER_NAME -no_crs_notify sleep 3 $ORACLE_HOME/bin/sqlplus -S $TEST_USER/$TEST_PASSlocalhost:1521/$TEST_DB EOF /dev/null EXIT; EOF kill $(pgrep -f strace.*tnslsnr) 2/dev/null # Step 2: Start listener and capture after-patch $ORACLE_HOME/bin/lsnrctl start $LISTENER_NAME PID$(pgrep -f tnslsnr.*$LISTENER_NAME) strace -p $PID -e tracememory -o /tmp/tnslsnr_patch.strace -s 1024 sleep 3 $ORACLE_HOME/bin/sqlplus -S $TEST_USER/$TEST_PASSlocalhost:1521/$TEST_DB EOF /dev/null EXIT; EOF kill $(pgrep -f strace.*tnslsnr) 2/dev/null # Step 3: Analyze results BEFORE_VULN$(grep -c memcpy.*[0-9]\{5,\} /tmp/tnslsnr_baseline.strace) AFTER_VULN$(grep -c memcpy.*[0-9]\{5,\} /tmp/tnslsnr_patch.strace) if [ $BEFORE_VULN -gt 0 ] [ $AFTER_VULN -eq 0 ]; then echo [SUCCESS] p36575425 memory fix confirmed: vulnerability eliminated. exit 0 else echo [FAIL] p36575425 memory fix not detected. Check patch application. exit 1 fi使用方式chmod x /tmp/verify_p36575425.sh /tmp/verify_p36575425.sh该脚本会输出[SUCCESS]或[FAIL]并自动清理临时文件。从那以后我每次给生产 RAC 打p36575425都强制走一遍这个脚本——它比opatch lsinventory更接近真相因为补丁的终极价值不是写进 inventory而是让memcpy不再越界。希望帮到你。本文还有配套的精品资源点击获取