资讯详情

资讯详情

Oracle 19c OPatch 升级指南:p6880880 替换与避坑

简介本资源为Oracle 19c数据库官方补丁包p6880880_190000的Linux x86-64版本面向需要维护Oracle 19c实例的DBA与运维工程师用于修复已知缺陷、提升数据库性能与安全性。压缩包共496个文件约115.39MB以jar、so、properties、pl、sh等为主涵盖OPatch补丁管理工具、Java运行组件、平台适配脚本与配置模板可完成补丁的安装、校验与回滚。其中OPatch相关脚本与datapatch工具是核心配合readme与license说明便于在Linux环境中按标准流程应用更新。目前已有2010人浏览学习适合具备一定Oracle基础、需要跟进官方补丁节奏的技术人员参考帮助快速定位补丁内容、理解目录结构并完成版本维护。1. 拿到 p6880880_190000 这个包先搞清楚它到底解决什么问题如果你在 Linux x86-64 上装过 Oracle 19c大概率在某个环节被一个报错拦住过INS-13001环境不满足最低要求或者libnsl.so.1: cannot open shared object file又或者 runInstaller 图形界面根本起不来。p6880880_190000_Linux-x86-64.zip 就是冲这些场景来的——它是 Oracle 19c 在 Linux x86-64 平台上的 OPatch 工具包版本号 19.0.0.0.0用来替换 ORACLE_HOME 里那个老掉牙的 OPatch 目录。很多人第一次看到这个文件名会懵p6880880 是补丁号190000 对应 19cLinux-x86-64 是平台标识。它不装数据库不建实例只干一件事——把打补丁的工具链升到能识别 19c 补丁的水平。适合谁正在部署 19c RAC 或单机、准备上 RU 补丁、或者被 OPatch 版本过低卡住的 DBA。如果你只是装完库就不动了这个包可以先放一边但只要涉及补丁它就是绕不开的前置动作。2. OPatch 在 19c 里的角色为什么不能拿旧版本硬扛2.1 OPatch 与 Oracle Home 的绑定关系OPatch 不是一个独立运行的工具它必须和具体的 ORACLE_HOME 绑定。每个 ORACLE_HOME 下都有自己的$ORACLE_HOME/OPatch目录里面放着opatch可执行文件、opatch.pl、jlib、oui等组件。19c 的补丁格式和 11g、12c 有本质区别19c 的 RU 补丁包里带的是patch_top结构OPatch 需要能解析etc/config/inventory.xml里的HOME_TYPE和PATCH_TYPE字段。旧版 OPatch比如 12.2 自带的 12.2.0.1.16遇到 19c 的补丁会直接报OPatch failed with error code 73提示The opatch Component check failed。这不是补丁坏了是工具不认识新格式。常见做法是先确认当前 OPatch 版本再决定是否替换。查版本用# 切换到 oracle 用户设置好 ORACLE_HOME 和 PATH export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$PATH # 查看当前 OPatch 版本 opatch version如果输出低于19.0.0.0.0比如12.2.0.1.16那就需要替换。注意opatch version读的是$ORACLE_HOME/OPatch/version.txt不是环境变量里的某个全局版本。所以哪怕你系统里装了多个 Oracle Home每个 Home 的 OPatch 都是独立的替换时别搞错目录。2.2 为什么必须用 19.0.0.0.0 这个特定版本p6880880 这个补丁号对应的是 OPatch 19.0.0.0.0 的通用版本Oracle 后续又出了 19.0.0.0.1、19.0.0.0.2 等小版本但 19.0.0.0.0 是 19c 初始发布时的基线版本。它的核心变化是支持了-apply时的-oh参数校验、支持了-analyze对 19c RU 的预检查、以及修复了 12c OPatch 在读取oraclehomeproducts.xml时的内存泄漏。如果你直接拿 12c 的 OPatch 去 apply 19c 的 RU大概率在Prerequisite check CheckActiveFilesAndExecutables这一步挂掉因为旧版 OPatch 不会去检查$ORACLE_HOME/bin/oracle的进程占用状态。替换步骤本身不复杂但顺序错了会翻车。正确流程是# 1. 备份原 OPatch 目录血泪经验别跳过这步 cd $ORACLE_HOME mv OPatch OPatch.bak_$(date %Y%m%d) # 2. 解压新 OPatch 包到 ORACLE_HOME unzip /tmp/p6880880_190000_Linux-x86-64.zip -d $ORACLE_HOME # 3. 确认解压后目录名是 OPatch不是 p6880880 ls -ld $ORACLE_HOME/OPatch # 4. 修正属主和权限 chown -R oracle:oinstall $ORACLE_HOME/OPatch chmod -R 775 $ORACLE_HOME/OPatch # 5. 验证版本 $ORACLE_HOME/OPatch/opatch version逻辑说明第 1 步的备份目录名带了日期方便回滚时区分第 2 步的-d参数直接指定 ORACLE_HOME解压后会自动生成OPatch目录但有些压缩包解压出来是p6880880目录需要手动改名第 4 步的权限必须是oracle:oinstall否则 opatch 执行时会报Permission denied或Cannot create lock file。参数上chmod 775是 Oracle 官方建议值别图省事给 777会触发安全检查告警。3. 替换 OPatch 的完整操作与参数校验3.1 替换前的环境检查清单在动手替换之前有几项检查必须做否则替换完可能连库都起不来。第一确认$ORACLE_HOME下没有正在运行的 opatch 进程用ps -ef | grep opatch查第二确认$ORACLE_HOME/.patch_storage目录存在且可写这个目录记录补丁历史OPatch 19.0.0.0.0 会往里面写patch_metadata第三确认inventory位置用cat /etc/oraInst.loc看inventory_loc指向哪里通常是在/u01/app/oraInventory替换 OPatch 不会动 inventory但后续 apply 补丁会读它。还有一个容易被忽略的点如果 ORACLE_HOME 是共享的比如 RAC 环境每个节点的 OPatch 都要单独替换不能只换一个节点就以为全局生效。RAC 下 OPatch 是本地文件不通过 OCR 同步。3.2 解压与目录结构核对解压 p6880880_190000_Linux-x86-64.zip 后标准目录结构应该是OPatch/ ├── opatch ├── opatch.pl ├── version.txt ├── jlib/ ├── oui/ ├── docs/ └── etc/其中version.txt内容应该是19.0.0.0.0opatch是可执行 shell 脚本opatch.pl是 Perl 主程序。如果解压出来发现少了jlib或oui说明压缩包不完整别硬着头皮用重新下载。核对命令# 检查关键文件是否存在 for f in opatch opatch.pl version.txt jlib oui; do if [ -e $ORACLE_HOME/OPatch/$f ]; then echo OK: $f else echo MISSING: $f fi done # 查看版本文件内容 cat $ORACLE_HOME/OPatch/version.txt逻辑说明这个循环检查的是 OPatch 运行的最小依赖集缺任何一个都会导致opatch命令报错。version.txt必须显示19.0.0.0.0如果显示其他版本号说明解压错了包或者目录被覆盖混了。3.3 用 opatch lsinventory 验证替换结果替换完成后不要急着打补丁先用lsinventory验证 OPatch 能否正常读取 inventory$ORACLE_HOME/OPatch/opatch lsinventory -detail正常输出会列出当前 ORACLE_HOME 已安装的组件和补丁。如果报Oracle Home is not registered或Inventory is not accessible说明 inventory 指向有问题检查/etc/oraInst.loc里的inventory_loc路径是否存在、权限是否正确。另一个常见报错是OPatch cannot find the Central Inventory这时候需要加-invPtrLoc参数手动指定$ORACLE_HOME/OPatch/opatch lsinventory -invPtrLoc /etc/oraInst.loc参数说明-invPtrLoc告诉 OPatch 去哪里读 inventory 指针文件默认是/etc/oraInst.loc但如果系统里有多个 Oracle 产品这个文件可能被改过。-detail会输出更详细的组件列表包括每个组件的版本和补丁号方便确认 19c 的 RU 是否已经打上。4. 避坑与排查替换 OPatch 时最容易翻车的五个点4.1 现象opatch 命令报Cannot create lock file原因$ORACLE_HOME/OPatch目录权限不对或者$ORACLE_HOME/.patch_storage不可写。OPatch 在执行时会尝试在.patch_storage下创建opatch_lock文件如果 oracle 用户没有写权限直接失败。解决确认.patch_storage属主是 oracle:oinstall权限至少 775。如果目录不存在手动创建并赋权mkdir -p $ORACLE_HOME/.patch_storage chown oracle:oinstall $ORACLE_HOME/.patch_storage chmod 775 $ORACLE_HOME/.patch_storage4.2 现象替换后opatch version显示的还是旧版本原因PATH 里优先命中了其他 ORACLE_HOME 的 opatch或者 shell 缓存了旧路径。which opatch查一下实际调用的是哪个。解决用绝对路径执行$ORACLE_HOME/OPatch/opatch version如果绝对路径显示新版本而opatch version显示旧版本说明 PATH 顺序有问题。调整 PATH 把当前 ORACLE_HOME 的 OPatch 放最前面或者直接hash -r清缓存。4.3 现象apply 补丁时卡在CheckActiveFilesAndExecutables原因有 Oracle 进程正在运行OPatch 检测到$ORACLE_HOME/bin/oracle被占用。19c 的 OPatch 对这个检查比旧版严格得多哪怕是一个空闲的 sqlplus 会话也会触发。解决停掉所有相关进程包括监听、数据库实例、ASM 实例。RAC 环境下要用srvctl stop home停整个 Home而不是只停数据库。确认无进程后再 apply。4.4 现象解压后 OPatch 目录里文件属主变成 root原因用 root 用户解压了 zip 包或者unzip时没加-o覆盖导致新旧文件混杂。解决重新用 oracle 用户解压或者解压后统一chown -R oracle:oinstall。注意不要用 root 去执行 opatchOracle 明确不支持 root 运行 OPatch会报OPatch should not be run as root。4.5 现象lsinventory输出里 ORACLE_HOME 路径不对原因inventory 里注册的 ORACLE_HOME 和当前实际路径不一致常见于克隆或迁移过的环境。解决用-oh参数显式指定当前 ORACLE_HOME$ORACLE_HOME/OPatch/opatch lsinventory -oh $ORACLE_HOME如果还是不对需要检查/u01/app/oraInventory/ContentsXML/inventory.xml里的HOME条目手动修正或重新注册。这个操作风险较高建议先备份 inventory.xml。5. 进阶技巧用 OPatch 做补丁冲突预检与回滚5.1 用opatch prereq做补丁前置检查在正式 apply 之前可以用prereq子命令做一次干跑检查补丁是否和当前环境冲突。这个命令不会修改任何文件只读检查# 假设补丁包已解压到 /tmp/6880880 cd /tmp/6880880 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./参数说明CheckConflictAgainstOHWithDetail是检查补丁与当前 ORACLE_HOME 的冲突详情-ph ./指定补丁目录。输出会列出冲突的补丁号和文件路径。如果显示No conflict说明可以安全 apply如果有冲突需要先回滚冲突补丁或选择其他 RU 版本。5.2 用opatch rollback回滚已打补丁如果补丁打完后数据库起不来或者出现性能回退可以用 rollback 回滚。前提是.patch_storage里保留了补丁的原始文件# 查看已打补丁列表 $ORACLE_HOME/OPatch/opatch lspatches # 回滚指定补丁号 $ORACLE_HOME/OPatch/opatch rollback -id 6880880逻辑说明lspatches列出的是当前 ORACLE_HOME 已应用的补丁每个补丁有一个 ID。rollback -id会从.patch_storage里读取原始文件并还原。注意回滚后需要重新编译无效对象用utlrp.sql跑一遍。另外如果补丁是 RU 且包含了数据库字典变更回滚后可能需要重新执行catbundle.sql具体看补丁说明。5.3 多 ORACLE_HOME 环境下的 OPatch 管理一台机器上如果有多个 ORACLE_HOME比如 11g 和 19c 共存每个 Home 的 OPatch 都要单独维护。我一般会写一个检查脚本定期核对所有 Home 的 OPatch 版本#!/bin/bash # 检查所有 ORACLE_HOME 的 OPatch 版本 for oh in $(cat /etc/oratab | grep -v ^# | cut -d: -f2 | sort -u); do if [ -x $oh/OPatch/opatch ]; then ver$($oh/OPatch/opatch version 2/dev/null | grep -oP \d\.\d\.\d\.\d\.\d) echo $oh $ver fi done这个脚本从/etc/oratab读取所有 ORACLE_HOME逐个执行opatch version并提取版本号。输出可以快速看出哪个 Home 的 OPatch 需要升级。注意/etc/oratab里可能包含已删除的 Home 路径脚本里加了-x判断可执行文件是否存在避免报错。从那以后我每次替换 OPatch 都强制走一遍「备份 → 解压 → 改属主 → 绝对路径验证 → lsinventory 确认」这五步少一步都可能在后半夜被叫起来救火。希望帮到你。本文还有配套的精品资源点击获取
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →