简介面向Linux平台运维人员与数据库管理员的资源包用于为Oracle 9.2.0.4环境提供安装或升级前的预检查与预处理支持适合需要部署或维护该版本数据库的中级技术人员。压缩包共2个文件包含一个shell脚本和一份说明文档整体仅1KB体积小巧但定位明确。脚本可在Red Hat Enterprise Linux 3等环境下执行帮助用户提前调整内核参数、依赖库等系统条件说明文档则解释用途与运行方法。目前已有108人学习该资源获取后可通过阅读说明、审阅脚本逻辑来掌握补丁前置条件为自己的环境部署提供参考。1. 补丁身份这不是普通压缩包干过 Oracle 9i 时代的 DBA对p3006854_9204_LINUX.zip这个名字应该不陌生。它不是普通压缩包而是 Oracle 9.2.0.4 在 Linux 上安装时一个非常著名的补丁包。当年在 RHEL 3/4 上装 9i跑到ctx组件 relink 阶段十有八九会报错这时候翻资料最后都会指向这个 zip。这篇内容就是讲清楚这个补丁是什么、为什么要打、具体怎么用以及我踩过的坑。1.1 文件名拆开看补丁文件名的格式是 Oracle 传统命名法补丁号_数据库版本_平台.zip。这个文件里每个片段都能对上号文件名片段含义p3006854Oracle Support 上的补丁号9204数据库版本 9.2.0.4LINUX目标平台是 LinuxzipOracle 发布的补丁压缩包格式补丁号不是随便编的在支持站点输入 3006854 就能直接定位这个补丁。9204 表示 9.2.0.4不是 9.0.4更不是 19c。看到这种文件名第一反应一定是去确认你的 Oracle 版本和操作系统版本版本对不上就硬打轻则白忙一场重则把环境弄坏。1.2 为什么 Oracle 9.2.0.4 在 Linux 上必须打它简单说这个补丁解决的是 Oracle 9i 在 RHEL 3/4 这类老 Linux 发行版上的链接兼容性问题。Oracle 9i 发布的时间比较早那个年代 Linux 的线程库还没有完全统一RHEL 3/4 默认启用了新的 NPTL 线程模型而 9i 的安装程序在 relink 阶段仍然按旧线程模型处理结果就是在ctx组件链接时报出一堆莫名其妙的 makefile 错误。打个比方相当于一个习惯用老接口的插件突然遇到一台新驱动的主机直接插上去识别不了必须加一个转接头。p3006854_9204_LINUX.zip就是这个转接头。它会把安装环境里的兼容参数调整到 Oracle 9i 能识别的状态常见操作就包括设置LD_ASSUME_KERNEL2.4.19这类老内核模拟参数让 glibc 切回旧线程模型继续工作。这个补丁只针对 9.2.0.4不是所有版本都能用。后面如果你遇到 Oracle 11g、19c 的安装问题别拿这个补丁去套两个时代的安装机制完全不同。2. 安装前准备环境和解压都不能马虎补丁虽然是一次性执行但前期的 Linux 环境准备如果做得糙后面一样会翻车。尤其是补丁需要在正确的用户、正确的权限下执行很多人都是在 root 和 oracle 用户之间来回切换时出问题的。2.1 新建 oracle 用户和组Oracle 安装规范要求不能用 root 跑runInstaller必须用专用用户。如果系统里还没有oracle用户先建好groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle passwd oracle这里把oinstall设为主组dba作为附加组是为了后面数据库安装时对不同目录和文件有足够的权限。-G dba这个细节很多人会漏漏了会导致安装过程中提示权限不足。2.2 先校验补丁包完整性从支持站点下载回来的 zip第一件事不是解压而是验完整性。常见方式是md5sum和unzip -t双管齐下md5sum p3006854_9204_LINUX.zip unzip -t p3006854_9204_LINUX.zipmd5sum的校验值应该和下载页面给出的值一致如果不一致说明文件下载过程有损坏换浏览器或重新下载就行。unzip -t会测试压缩包内的每个文件是否完整如果出现类似invalid zip archive: could not find eocd的提示基本可以断定文件没有传完整别急着强制修复直接重新下载最省事。验完再解压mkdir -p /home/oracle/patch cd /home/oracle/patch unzip -q /tmp/p3006854_9204_LINUX.zip ls -la解压后一般会得到一个脚本文件文件名通常就是补丁号3006854有些来源会给出带.sh后缀的版本。用ls -la看一眼确认文件是否具备执行权限。2.3 别忽略脚本执行权限从 Windows 上传到 Linux 的 zip解压后经常出现脚本没有执行权限的情况。遇到Permission denied时不要下意识以为补丁有问题先执行chmod x 3006854 2/dev/null如果文件名不是3006854就把ls看到的真实文件名填进去。这个操作很基础但确实是我见过最常见的“假报错”来源。3. 补丁应用实操从解压到验证这个补丁不是用 OPatch 打的它本质上是一个独立的 shell 脚本直接在安装数据库之前跑一遍就行。整个过程分三步解压、执行、验证。3.1 以 root 身份执行补丁脚本补丁脚本需要 root 权限因为可能会修改系统环境或者共享库路径。所以先切到 root再找脚本执行su - root cd /home/oracle/patch ./3006854如果你解压出来的脚本名是3006854.sh那就执行./3006854.sh执行过程中一般会输出几行提示看起来像是一段补丁安装说明。有些版本甚至不会打印太多内容静默就完成了。这时候不用慌只要没有报错就视为执行成功。注意不要用sh 3006854去跑除非你确认脚本本身能用 sh 解析。直接./执行最稳妥因为脚本内部可能依赖 bash 特性。3.2 验证补丁是否真正生效补丁脚本跑完最直接的效果是安装环境里多了兼容参数。很多老教程会让你手动检查env | grep LD_ASSUME_KERNEL如果输出类似LD_ASSUME_KERNEL2.4.19说明兼容参数已经生效。但也遇到过一种情况当前 shell 里没看到这个变量重新登录一次 oracle 用户再检查就出现了。原因很简单补丁可能修改的是用户环境文件并不会反向注入到已经打开的 shell 里。所以我的建议是跑完补丁后先退出所有 SSH 会话重新登录再开终端做后续安装。这一步能避免很多“明明打了补丁怎么还是报错”的怪问题。3.3 然后才轮到 runInstaller补丁是安装在runInstaller之前的准备动作。等你确认脚本执行成功、环境变量正常再从安装介质里启动安装./runInstaller安装过程中到了 relink 阶段之前会失败的ctx链接这时候就不会再卡住了。我当年第一次装 9i 时就是漏了这一步结果在ins_ctx.mk上反复报错折腾了一整天才发现是补丁没打。后来每次重建环境都会把“打补丁”和“跑安装程序”写进同一个操作单顺序绝不颠倒。4. 常见问题与排查实录老环境的问题往往不是一两个我把实际遇到过的和群里朋友踩过的坑整理成一个速查表方便按图索骥。错误现象原因处理方式unzip -t报 could not find eocdzip 包下载不完整或传输损坏重新下载核对 md5sumzip warning: not all files were readable压缩包权限异常或磁盘空间不足检查磁盘空间解压到本地目录./3006854: Permission denied脚本没有执行权限chmod x 3006854后重试relink 阶段仍然报 ins_ctx.mk 错误补丁脚本没生效或环境变量未加载重新登录 oracle 用户确认LD_ASSUME_KERNEL安装时提示版本不匹配拿 9204 补丁硬打其他版本核对数据库版本不要混用4.1 zip 包损坏的典型处理我遇到过下载三次都提示could not find eocd的情况一开始以为是网络问题后来发现是 FTP 传输时没有用二进制模式文件被转成了 ASCII导致 zip 头部信息损坏。如果是从 Windows 本地用 FTP 传到 Linux记得把传输模式切到 binary否则 Linux 这边一unzip就认不出来。4.2 补丁执行成功但链接还是失败这种问题通常发生在补丁执行后没有重新登录用户。补丁改了环境变量但当前 shell 还是旧环境runInstaller继承的就是旧变量。解决方式很简单logout su - oracle export LD_ASSUME_KERNEL2.4.19如果系统里已经设置了/etc/profile或~/.bash_profileexport 这步可以省但我实际经验是手动 export 一次最保险不影响后续安装。4.3 现在的新系统上要不要重新打这个补丁如果你是在现代 Linux 发行版上强行装 9.2.0.4那就不是打一个补丁能解决的。新版内核、新版 glibc 和旧数据库之间可能存在更深层的兼容问题我建议直接用虚拟机装一个对应年代的 RHEL 3/4 环境再按老流程操作。补丁解决的是当年系统上的已知问题不是万能钥匙。5. 从老补丁到新补丁补丁管理的通用经验虽然 9i 已经是非常老的数据库版本但这个补丁给我留下的几条经验放到现在的 19c、23ai 环境依然适用。第一zip 补丁包不是一个压缩文件那么简单。下载回来必须先验完整性再读 README确定补丁适用版本、适用操作系统最后才执行。我见过太多人拿到一个补丁就开始解压执行到一半才发现版本不对。看文件名、验 md5、读说明这三件事顺序不能乱。第二补丁命名规则几十年没变。看到pXXXXXXX_版本_平台.zip先拆补丁号、版本、平台三段再去支持站点搜索。现在 Oracle 19c 的补丁包也沿用了这套命名只是应用方式变成了opatch auto或者opatch apply原理和这个老补丁是相通的。第三老系统环境不要硬套新方法。有些数据库跑在旧系统上很多年出了问题第一反应是新找工具、新找补丁不如老老实实还原当年的安装场景。我手上还有一台 9i 老库每次重建测试环境还是用这套流程建用户、验补丁、执行脚本、重新登录、再跑安装。步骤看起来笨但每一步都知道自己在做什么。最后再分享一个小技巧这类老补丁的 zip 文件我建议单独存一个目录文件名不要随意改。因为补丁号、版本、平台都在文件名里哪天需要重新安装搜一下文件名就能快速定位到正确的补丁和操作记录。这个习惯帮我省了不少事。本文还有配套的精品资源点击获取
简介面向Linux平台运维人员与数据库管理员的资源包用于为Oracle 9.2.0.4环境提供安装或升级前的预检查与预处理支持适合需要部署或维护该版本数据库的中级技术人员。压缩包共2个文件包含一个shell脚本和一份说明文档整体仅1KB体积小巧但定位明确。脚本可在Red Hat Enterprise Linux 3等环境下执行帮助用户提前调整内核参数、依赖库等系统条件说明文档则解释用途与运行方法。目前已有108人学习该资源获取后可通过阅读说明、审阅脚本逻辑来掌握补丁前置条件为自己的环境部署提供参考。1. 补丁身份这不是普通压缩包干过 Oracle 9i 时代的 DBA对p3006854_9204_LINUX.zip这个名字应该不陌生。它不是普通压缩包而是 Oracle 9.2.0.4 在 Linux 上安装时一个非常著名的补丁包。当年在 RHEL 3/4 上装 9i跑到ctx组件 relink 阶段十有八九会报错这时候翻资料最后都会指向这个 zip。这篇内容就是讲清楚这个补丁是什么、为什么要打、具体怎么用以及我踩过的坑。1.1 文件名拆开看补丁文件名的格式是 Oracle 传统命名法补丁号_数据库版本_平台.zip。这个文件里每个片段都能对上号文件名片段含义p3006854Oracle Support 上的补丁号9204数据库版本 9.2.0.4LINUX目标平台是 LinuxzipOracle 发布的补丁压缩包格式补丁号不是随便编的在支持站点输入 3006854 就能直接定位这个补丁。9204 表示 9.2.0.4不是 9.0.4更不是 19c。看到这种文件名第一反应一定是去确认你的 Oracle 版本和操作系统版本版本对不上就硬打轻则白忙一场重则把环境弄坏。1.2 为什么 Oracle 9.2.0.4 在 Linux 上必须打它简单说这个补丁解决的是 Oracle 9i 在 RHEL 3/4 这类老 Linux 发行版上的链接兼容性问题。Oracle 9i 发布的时间比较早那个年代 Linux 的线程库还没有完全统一RHEL 3/4 默认启用了新的 NPTL 线程模型而 9i 的安装程序在 relink 阶段仍然按旧线程模型处理结果就是在ctx组件链接时报出一堆莫名其妙的 makefile 错误。打个比方相当于一个习惯用老接口的插件突然遇到一台新驱动的主机直接插上去识别不了必须加一个转接头。p3006854_9204_LINUX.zip就是这个转接头。它会把安装环境里的兼容参数调整到 Oracle 9i 能识别的状态常见操作就包括设置LD_ASSUME_KERNEL2.4.19这类老内核模拟参数让 glibc 切回旧线程模型继续工作。这个补丁只针对 9.2.0.4不是所有版本都能用。后面如果你遇到 Oracle 11g、19c 的安装问题别拿这个补丁去套两个时代的安装机制完全不同。2. 安装前准备环境和解压都不能马虎补丁虽然是一次性执行但前期的 Linux 环境准备如果做得糙后面一样会翻车。尤其是补丁需要在正确的用户、正确的权限下执行很多人都是在 root 和 oracle 用户之间来回切换时出问题的。2.1 新建 oracle 用户和组Oracle 安装规范要求不能用 root 跑runInstaller必须用专用用户。如果系统里还没有oracle用户先建好groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle passwd oracle这里把oinstall设为主组dba作为附加组是为了后面数据库安装时对不同目录和文件有足够的权限。-G dba这个细节很多人会漏漏了会导致安装过程中提示权限不足。2.2 先校验补丁包完整性从支持站点下载回来的 zip第一件事不是解压而是验完整性。常见方式是md5sum和unzip -t双管齐下md5sum p3006854_9204_LINUX.zip unzip -t p3006854_9204_LINUX.zipmd5sum的校验值应该和下载页面给出的值一致如果不一致说明文件下载过程有损坏换浏览器或重新下载就行。unzip -t会测试压缩包内的每个文件是否完整如果出现类似invalid zip archive: could not find eocd的提示基本可以断定文件没有传完整别急着强制修复直接重新下载最省事。验完再解压mkdir -p /home/oracle/patch cd /home/oracle/patch unzip -q /tmp/p3006854_9204_LINUX.zip ls -la解压后一般会得到一个脚本文件文件名通常就是补丁号3006854有些来源会给出带.sh后缀的版本。用ls -la看一眼确认文件是否具备执行权限。2.3 别忽略脚本执行权限从 Windows 上传到 Linux 的 zip解压后经常出现脚本没有执行权限的情况。遇到Permission denied时不要下意识以为补丁有问题先执行chmod x 3006854 2/dev/null如果文件名不是3006854就把ls看到的真实文件名填进去。这个操作很基础但确实是我见过最常见的“假报错”来源。3. 补丁应用实操从解压到验证这个补丁不是用 OPatch 打的它本质上是一个独立的 shell 脚本直接在安装数据库之前跑一遍就行。整个过程分三步解压、执行、验证。3.1 以 root 身份执行补丁脚本补丁脚本需要 root 权限因为可能会修改系统环境或者共享库路径。所以先切到 root再找脚本执行su - root cd /home/oracle/patch ./3006854如果你解压出来的脚本名是3006854.sh那就执行./3006854.sh执行过程中一般会输出几行提示看起来像是一段补丁安装说明。有些版本甚至不会打印太多内容静默就完成了。这时候不用慌只要没有报错就视为执行成功。注意不要用sh 3006854去跑除非你确认脚本本身能用 sh 解析。直接./执行最稳妥因为脚本内部可能依赖 bash 特性。3.2 验证补丁是否真正生效补丁脚本跑完最直接的效果是安装环境里多了兼容参数。很多老教程会让你手动检查env | grep LD_ASSUME_KERNEL如果输出类似LD_ASSUME_KERNEL2.4.19说明兼容参数已经生效。但也遇到过一种情况当前 shell 里没看到这个变量重新登录一次 oracle 用户再检查就出现了。原因很简单补丁可能修改的是用户环境文件并不会反向注入到已经打开的 shell 里。所以我的建议是跑完补丁后先退出所有 SSH 会话重新登录再开终端做后续安装。这一步能避免很多“明明打了补丁怎么还是报错”的怪问题。3.3 然后才轮到 runInstaller补丁是安装在runInstaller之前的准备动作。等你确认脚本执行成功、环境变量正常再从安装介质里启动安装./runInstaller安装过程中到了 relink 阶段之前会失败的ctx链接这时候就不会再卡住了。我当年第一次装 9i 时就是漏了这一步结果在ins_ctx.mk上反复报错折腾了一整天才发现是补丁没打。后来每次重建环境都会把“打补丁”和“跑安装程序”写进同一个操作单顺序绝不颠倒。4. 常见问题与排查实录老环境的问题往往不是一两个我把实际遇到过的和群里朋友踩过的坑整理成一个速查表方便按图索骥。错误现象原因处理方式unzip -t报 could not find eocdzip 包下载不完整或传输损坏重新下载核对 md5sumzip warning: not all files were readable压缩包权限异常或磁盘空间不足检查磁盘空间解压到本地目录./3006854: Permission denied脚本没有执行权限chmod x 3006854后重试relink 阶段仍然报 ins_ctx.mk 错误补丁脚本没生效或环境变量未加载重新登录 oracle 用户确认LD_ASSUME_KERNEL安装时提示版本不匹配拿 9204 补丁硬打其他版本核对数据库版本不要混用4.1 zip 包损坏的典型处理我遇到过下载三次都提示could not find eocd的情况一开始以为是网络问题后来发现是 FTP 传输时没有用二进制模式文件被转成了 ASCII导致 zip 头部信息损坏。如果是从 Windows 本地用 FTP 传到 Linux记得把传输模式切到 binary否则 Linux 这边一unzip就认不出来。4.2 补丁执行成功但链接还是失败这种问题通常发生在补丁执行后没有重新登录用户。补丁改了环境变量但当前 shell 还是旧环境runInstaller继承的就是旧变量。解决方式很简单logout su - oracle export LD_ASSUME_KERNEL2.4.19如果系统里已经设置了/etc/profile或~/.bash_profileexport 这步可以省但我实际经验是手动 export 一次最保险不影响后续安装。4.3 现在的新系统上要不要重新打这个补丁如果你是在现代 Linux 发行版上强行装 9.2.0.4那就不是打一个补丁能解决的。新版内核、新版 glibc 和旧数据库之间可能存在更深层的兼容问题我建议直接用虚拟机装一个对应年代的 RHEL 3/4 环境再按老流程操作。补丁解决的是当年系统上的已知问题不是万能钥匙。5. 从老补丁到新补丁补丁管理的通用经验虽然 9i 已经是非常老的数据库版本但这个补丁给我留下的几条经验放到现在的 19c、23ai 环境依然适用。第一zip 补丁包不是一个压缩文件那么简单。下载回来必须先验完整性再读 README确定补丁适用版本、适用操作系统最后才执行。我见过太多人拿到一个补丁就开始解压执行到一半才发现版本不对。看文件名、验 md5、读说明这三件事顺序不能乱。第二补丁命名规则几十年没变。看到pXXXXXXX_版本_平台.zip先拆补丁号、版本、平台三段再去支持站点搜索。现在 Oracle 19c 的补丁包也沿用了这套命名只是应用方式变成了opatch auto或者opatch apply原理和这个老补丁是相通的。第三老系统环境不要硬套新方法。有些数据库跑在旧系统上很多年出了问题第一反应是新找工具、新找补丁不如老老实实还原当年的安装场景。我手上还有一台 9i 老库每次重建测试环境还是用这套流程建用户、验补丁、执行脚本、重新登录、再跑安装。步骤看起来笨但每一步都知道自己在做什么。最后再分享一个小技巧这类老补丁的 zip 文件我建议单独存一个目录文件名不要随意改。因为补丁号、版本、平台都在文件名里哪天需要重新安装搜一下文件名就能快速定位到正确的补丁和操作记录。这个习惯帮我省了不少事。本文还有配套的精品资源点击获取
