Oracle 19c RU补丁前必做：OPatch升级实战与避坑指南

简介面向Oracle 19c数据库在Linux环境下的运维需求此资源是官方OPatch补丁应用工具包编号p6880880-230000适用于DBA完成补丁安装、卸载与清单验证等日常维护工作。压缩包共495个文件体积121.72MB以jar、so、sh、properties等类型为主包含补丁程序、动态链接库及配置脚本覆盖OPatch核心组件与附属工具链目录结构清晰便于按需取用。已有955人学习下载。借助该资源可系统了解补丁生命周期管理流程包括补丁兼容性检查、Oracle Home配置、补丁应用与回滚等关键环节编号规则与My Oracle Support文档相互对应结合包内md说明与模板文件能加深对Oracle补丁机制的理解为生产库安全、稳定运行提供有力支撑。无论是初次接触补丁管理的新手还是需要规范化运维的团队均可从中获得实用参考。 上个季度给一套 19c 数据库打 RU 补丁卡在了最前面的预检环节——opatch apply直接报“当前 OPatch 版本不满足要求”。这套库是从 19.3 一路升级上来的补丁没少打唯独 Opatch 这个“打补丁的工具”本身一直没升级版本停留在 12.2.0.1.21。Oracle 每个季度的 RU 补丁 README 里都会写清楚最低 Opatch 版本要求版本不够就是不够绕不过去。要往下去就得先把 Opatch 更新到 p6880880-230000-Linux-x86-64.zip 对应的版本。这篇就把这次在 Linux x86-64 环境下升级 Opatch、完成 oracle19c 补丁应用的过程完整写一遍。包括 Opatch 和 p6880880 到底是什么关系、替换前要确认哪些环境条件、具体操作步骤和验证方法以及几个我踩过之后印象很深的坑。无论你是第一次接触 19c 补丁的新手还是想确认自己操作姿势有没有问题的运维老手这篇都可以做个参考。1. Opatch 和 p6880880先分清这两个概念1.1 Opatch 是“打补丁的工具”不是补丁本身Opatch 是 Oracle 数据库自带的补丁管理工具位于$ORACLE_HOME/OPatch目录。它负责补丁的安装、回滚和清单维护。数据库补丁RU、CPU、one-off patch 之类是“内容”Opatch 是承载这些内容的“工具”。工具老了内容再新也装不进去。实际运维里有一个很常见的误区DBA 会仔细维护数据库小版本、跟踪季度 RU却很少主动升级 Opatch 本身。因为平时它不怎么“出镜”只有当补丁预检失败时才意识到版本已经落后很多。Oracle 官方会在每个 RU 的 README 里明确列出该补丁要求的最低 Opatch 版本如果你连这个前提都不满足opatch apply的预检阶段直接就会失败连安装流程都走不到。Opatch 工具本身由一组脚本和 Java 程序组成核心是OPatch.jar。更新 Opatch 时替换的是整套工具目录不是单独换一个文件。1.2 p6880880 文件名怎么拆解p6880880 是 Oracle 官网上 Opatch 更新包的统一补丁号。在 My Oracle Support 里搜 6880880就能找到对应不同数据库版本、不同平台的 Opatch 更新包。文件名p6880880-230000-Linux-x86-64.zip部分渠道用下划线分隔写成p6880880_230000_Linux-x86-64.zip可以拆成三部分看p6880880Opatch 工具更新包的补丁号各平台通用。230000发布批次标识可以粗略理解为 2023 年对应的某次打包。具体对应 Opatch 内部哪个版本号解压后执行opatch version就能看到。Linux-x86-64平台标识只适用于 Linux x86_64 架构。这个 zip 解压后就是一个完整的OPatch目录覆盖到$ORACLE_HOME下就完成了工具升级。需要特别注意的是不同数据库大版本使用的 Opatch 主版本不同。19c 和 21c 用的是 12.2.0.1.x 系列的 Opatch 主版本11.2 用的是另一套。下载时一定要选对数据库版本对应的更新包不能拿 11.2 的 Opatch 包直接往 19c 上盖。2. 替换前必须确认的环境与版本条件2.1 当前 Opatch 版本和补丁要求先对一遍替换之前先确认现状su - oracle source ~/.bash_profile # 确认 ORACLE_HOME 等环境变量已生效 cd $ORACLE_HOME/OPatch ./opatch version输出类似OPatch Version: 12.2.0.1.21然后去准备应用的 RU 补丁 README 里查最低 Opatch 版本要求。比如某些 2023 年的 19c RU 要求 Opatch 不低于 12.2.0.1.33。如果当前版本低于要求就需要升级 Opatch。这一步很容易被跳过。很多同行拿到 RU 补丁解压完直接就跑opatch apply遇到版本报错才回头翻 README。提前花十秒查一下版本能省大量返工时间。另外注意一点Opatch 版本也不是越高越好一切以补丁 README 里的要求为准。比如 p6880880-230000 解压后的版本如果明显高于 RU 要求没问题但如果反向操作拿一个老旧 Opatch 包去给新 RU 用大概率会失败。2.2 权限、属主、环境变量一个都不能少Opatch 升级是往$ORACLE_HOME/OPatch目录写入文件所以下面这几点必须确认必须使用 oracle 安装用户执行不要用 root。检查$ORACLE_HOME/OPatch的属主是否为 oracle:oinstall。确认$ORACLE_HOME所在分区有足够空间建议预留 1-2GB。确认环境变量ORACLE_HOME、ORACLE_SID已经正确设置。有个隐蔽问题值得单独提一下如果之前有人用 root 用户解压过补丁包OPatch目录下可能混入 root 属主的文件。这时候opatch apply会报 Permission denied排查起来很绕。建议先执行ls -ld $ORACLE_HOME/OPatch如果属主不对直接修正chown -R oracle:oinstall $ORACLE_HOME/OPatch还有一个场景是 RAC 多节点环境。Opatch 的升级必须在每个节点上都执行不能只在第一个节点更新完就继续。否则后续在备用节点上跑补丁时会报 Opatch 版本不一致或者清单不一致处理起来非常尴尬。2.3 下载后先做校验别急着解压p6880880 这类 Opatch 包一般在 MOS 上下载。下载页面会提供文件校验值通常是 SHA-1下载完建议核对sha1sum p6880880_230000_Linux-x86-64.zip把输出和 MOS 页面上给出的值比对。这一步最容易忽略但 zip 文件损坏往往在解压阶段才会暴露如果拖到opatch apply阶段才发现“找不到某个类文件”之类的问题定位起来就很费劲。3. 替换 Opatch 的步骤和验证3.1 备份先做再谈覆盖虽然 Opatch 更新包整体比较稳定但每个数据库环境都有差异万一下载的包有问题或者操作失误备份是唯一的后悔药。cd $ORACLE_HOME cp -rp OPatch OPatch_bak_$(date %Y%m%d)备份目录不用永久保留但建议至少保留到本次补丁全部打完、数据库验证正常之后。因为如果 RU 应用失败需要回滚有些回滚步骤依赖原来的 Opatch 版本。3.2 解压覆盖更推荐在临时目录先解压替换 Opatch 有两种常见方式。方式一直接在$ORACLE_HOME下解压覆盖简单直接cd $ORACLE_HOME unzip -o /tmp/p6880880_230000_Linux-x86-64.zip方式二先解压到临时目录确认文件完整后再替换mkdir -p /tmp/opatch_extract cd /tmp/opatch_extract unzip /tmp/p6880880_230000_Linux-x86-64.zip cp -rp OPatch $ORACLE_HOME/OPatch_new mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak_$(date %Y%m%d) mv $ORACLE_HOME/OPatch_new $ORACLE_HOME/OPatch我平时更习惯用方式二。好处是可以先看看解压出来的目录结构确认opatch脚本和 jar 包都在再动$ORACLE_HOME。另外在临时目录解压时如果发现 zip 损坏也能及时止损不会污染主目录。解压完成后可以顺手给opatch脚本补一个执行权限防止某些环境下 zip 解压后丢掉了可执行位chmod x $ORACLE_HOME/OPatch/opatch3.3 版本和清单双重验证替换完成后先确认版本cd $ORACLE_HOME/OPatch ./opatch version版本号比之前高就说明升级成功。接着再跑一次清单命令./opatch lsinventory这个命令会扫描当前 Oracle 主目录已安装的补丁清单。它能正常输出说明 Opatch 能正确读取补丁清单新旧补丁的元数据没有损坏。如果lsinventory报错或者显示空清单先别急着继续打 RU检查 OPatch 目录属主和权限再确认$ORACLE_HOME/inventory没有被误动。Opatch 升级只覆盖工具本身正常情况下不会影响已安装的补丁清单。4. 用新 Opatch 给 19c 数据库打 RU 补丁4.1 准备 RU 补丁包Opatch 升级完成后回到最初的目标给 19c 数据库应用 RU 补丁。假设下载好的 RU 补丁包是p12345678_190000_Linux-x86-64.zip解压到/u01/app/Patch/RU_2023/目录下。这里有两条规范动作解压前核对文件校验值。用 oracle 用户解压避免 root 属主问题。解压后进入补丁目录先做冲突检查cd /u01/app/Patch/RU_2023/12345678 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./这个命令会检查当前环境中已安装的补丁与新补丁是否存在冲突。如果输出提示没有冲突再进入 apply 阶段。4.2 单机环境先停库再 opatch apply单机环境下RU 补丁一般建议先停库再 applyREADME 里也会写明。停库操作sqlplus / as sysdba SQL shutdown immediate;然后执行$ORACLE_HOME/OPatch/opatch apply看到OPatch succeeded的输出说明二进制补丁部分完成了。这里解释一下为什么要求停库RU 补丁需要替换数据库软件目录里的二进制文件。如果不关闭实例运行中的进程还在使用旧文件很容易出现 apply 中途失败或者运行中的进程行为异常。RAC 环境可以用opatch auto或者分节点滚动方式但单机环境老老实实停库最稳。4.3 别漏掉 datapatch 这一步很多人以为opatch apply成功就万事大吉了。其实 Oracle 的 RU 补丁分两层第一层是二进制补丁第二层是数据字典和 SQL 对象的变更。第二层在 19c 里通过 datapatch 工具完成cd $ORACLE_HOME/OPatch ./datapatch -verbosedatapatch 会自动连接本机实例逐项应用补丁中记录的 SQL 变更。这个过程可能跑几分钟到半小时取决于补丁包含的对象数量和数据量。如果 datapatch 报了 SQL 错误优先检查三点数据库是否处于 OPEN 状态、是否有无效对象残留、是否有并发会话阻塞。4.4 验证补丁注册与无效对象确认补丁注册情况set linesize 200 col action format a20 col status format a12 select version, action, status, description from dba_registry_sqlpatch order by action_time;这个视图记录了历次 SQL patch 的应用情况。看到最新 RU 补丁条目 status 为 SUCCESS说明数据字典阶段完成。再查一下无效对象select owner, object_type, count(*) from dba_objects where status INVALID group by owner, object_type;如果有因补丁升级产生的无效对象执行?/rdbms/admin/utlrp.sqlutlrp 会以并行方式重编译无效对象。跑完再查一遍确认无效对象数量回落到正常水平。5. 这次实战踩过的坑和排查思路5.1 几个真实报错和处理过程这次升级过程中遇到/排查过的问题整理成了一张表方便对照报错现象可能原因处理方式opatch apply 预检失败提示 OPatch 版本过低Opatch 工具版本不符合 RU 补丁要求先升级 Opatch 到 p6880880-230000 对应版本再重新跑预检解压后文件属主是 root或 opatch 执行权限不对用 root 解压补丁包改用 oracle 用户解压或 chown -R oracle:oinstall 修正datapatch -verbose 无法连接数据库数据库未 OPEN或 ORACLE_SID 环境变量不对先确认实例已启动再检查 ORACLE_SIDopatch lsinventory 显示空清单ORACLE_HOME 指向错误目录或当前用户权限不足检查echo $ORACLE_HOME确认指向正确安装目录unzip 提示 zip 损坏下载文件不完整或校验值不符重新下载核对 SHA-1遇到这些报错时先别急着怀疑补丁包。按照我排查的顺序优先检查环境变量、属主、版本匹配这三个因素占了 80% 的问题来源。另外专门说一句不要试图跳过预检。RU 补丁的预检里包含版本匹配、冲突检测、系统依赖检查如果强行忽略预检apply 中途挂在某个检查项上现场清理起来要麻烦得多。5.2 几点实操建议第一把 Opatch 版本核对放进每次 RU 前的固定动作清单。不是每次都需要升级 Opatch但每次 RU 前都应该花一分钟核对版本要求。这个要求在 README 里写得清清楚楚与其等预检失败再返工不如提前规避。第二备份目录命名带上日期。OPatch_bak_$(date %Y%m%d)这种命名方式比OPatch_backup.tar强得多。过几个月回看你还能知道这个备份是哪天留下的、对应哪次补丁操作。第三把 opatch 的日志保存下来。opatch apply默认会把日志写到$ORACLE_HOME/cfgtoollogs/opatch/目录下。出问题时把日志和现场信息一起整理好能大幅缩短问题定位时间。第四RAC 环境不要偷懒。19c RAC 打 RU 时Opatch 必须在每个节点升级RU 的 apply 也要在每个节点执行或者使用opatch auto按滚动方式处理。我见过只在一个节点升级 Opatch另一个节点 apply 时直接报版本不一致的案例来回折腾的时间比自己按规范步骤走一遍多得多。最后说一个这次实践印象最深的体会Opatch 和数据库补丁一个是工具一个是内容。工具不更新内容处理得再好也白搭。很多人把opatch apply的成败押在一次性的运气上实际上大部分预检失败只要提前看一眼版本就能避免。我现在的习惯是每个季度 RU 公告出来后先花十分钟把这个库的 Opatch 版本和补丁要求对一遍再安排后续操作省下的返工时间远不止这十分钟。本文还有配套的精品资源点击获取