黑河市all1. 2026年Q1季度补丁整体情况与版本支持矩阵
1.1 季度补丁的发布节奏与2026年Q1的新变化
Oracle数据库的补丁发布一直保持着稳定的节奏，每年1月、4月、7月、10月的第三个星期二，官方会放出季度安全补丁（Critical Patch Update，简称CPU）。2026年Q1的窗口期就在1月20号前后，这一批补丁对所有处于支持期内的版本统一推送，涉及Database、Grid Infrastructure、Fusion Middleware、Java SE等多个产品线。对于做DBA和运维的人来说，这一天的关注度不亚于年终大促对电商工程师的意义——不追不行，追了又怕出问题。
2026年Q1这一轮补丁有几个值得注意的宏观变化。首先是版本支持矩阵进一步收窄，11g和12c的早期版本已经彻底退出扩展支持，这意味着还在跑老版本的环境，即便拿到补丁包也没有官方验证过，出了事只能自己兜底。其次，23ai作为新的长期支持版本，从2025年开始已经成为官方主推的升级目标，2026年Q1补丁里23ai相关的修复数量和密度明显高于其他版本。还有就是Oracle对季度补丁的拆分方式有了微调，数据库和网格基础设施（GI）的补丁包在部分版本上合并发布，这既是好事也是坑——合并包打起来方便，但回滚和排错的复杂度也跟着上去了。
我在实际维护中见过不少团队，一看到季度补丁就头大，拖着不打，一拖就是一年半载。结果就是等真的出了问题，翻MOS（My Oracle Support）查文档，发现人家早就修复了，但你的环境因为补丁落后根本没法直接应用。补丁这东西，跟上版本迭代的节奏，比攒着一次性大的要安全得多。
1.2 各版本补丁支持情况速查
整理了一下2026年Q1补丁发布时各主流版本的支持状态，方便对照自己的环境。注意，这里说的是数据库和GI的季度补丁，不含Java、WebLogic等外围组件。
| 版本 | 当前补丁级别 | 支持状态 | 说明 |
|---|---|---|---|
| 19c | 19.25及以上 | 扩展支持期，会持续提供季度补丁 | 存量最大的版本，DBA最熟悉的版本，补丁节奏稳定 |
| 21c | 21.12及以上 | 创新版本，支持期已结束 | 官方不再提供常规季度补丁，不建议生产环境继续使用 |
| 23ai | 23.6及以上 | 长期支持版本，主推目标 | 2026年重点更新对象，新功能和安全修复密集 |
| 12.2 | —— | 扩展支持结束后不再更新 | 强烈建议升级，补丁缺失风险极高 |
| 11.2 | —— | 已彻底停止支持 | 没有任何补丁来源，必须规划迁移 |
19c这个版本的生命力是真的强。从2019年发布到现在，已经走了六七年，依然是绝大多数企业的生产主力。它和23ai的关系就像老牌旗舰和新款顶配，19c胜在稳定、生态成熟、踩坑文档多，23ai则代表着未来要长期走的方向。如果你还在犹豫要不要上23ai，可以趁着2026年Q1补丁这个窗口，先在一套测试环境里装好23ai，打上最新的季度补丁，对比一下两边的行为和性能，做到心中有数。
1.3 补丁到底分几种，别再混为一谈
很多刚接触Oracle的新人，甚至不少做了一段时间运维的同事，对补丁这个事是有点含糊的。这里把Oracle常见的补丁类型一次性说清楚，避免后续操作时搞混。
季度安全补丁（CPU，Critical Patch Update），这是Oracle每个季度固定的安全补丁集，主要修安全漏洞和恶意攻击面。CPU是大家最熟悉也最不能拖的，因为安全漏洞往往直接暴露在公网入口，不像功能缺陷那样还给你缓冲时间。
发布更新（RU，Release Update），这个其实是我们平时打的最多的。RU是Oracle每年打包的一系列修复，既包含安全修复也包含功能缺陷修复，正常情况下每个季度更新一次版本号。CPU和RU的关系不是替代，而是RU里已经包含了当季的CPU修复内容，所以如果你打了完整的RU，就不需要再单独打CPU。
发布更新修订（RUR，Release Update Revision），这是RU的补充版本，用来修RU里引入的新问题，一般不会加新功能。如果你当前的RU版本遇到严重问题，又不想跨太大步子升级，可以考虑打一个RUR。
一次性补丁（One-Off Patch），也叫临时补丁，是针对特定Bug单独生成的修复包。这类补丁只解决特定问题，不会进季度包，适合个例情况。但要谨慎使用，因为一旦后续季度补丁和它冲突，反而会阻挡升级。
OJVM补丁，专门修Java Virtual Machine的漏洞。很多DBA容易忽略这个，其实OJVM的安全漏洞扫描经常被安全团队点名，而且OJVM补丁是在数据库停库状态下应用，和普通数据库补丁的流程不太一样。
日常运维中最常见的组合就是“季度RU + 必要的OJVM补丁 + 个别一次性补丁”，这套组合可以应对绝大多数场景。打补丁前确认清楚自己手头的是哪一种，不要拿着一次性补丁当季度包去打，很容易打出问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 补丁安装前的准备工作，这步决定成败
2.1 先看Readme和补丁说明，别急着解压
每次补丁发布后，MOS上会同步更新对应的文档，包括Patch Readme、补丁包说明、安装指导和已知问题列表。我见过太多翻车案例，原因都是同一个——没看Readme就动手。Readme看着一大段英文很枯燥，但里面包含了几个你绕不开的关键信息：适用的版本范围、前置条件、需要执行的SQL脚本、已知问题、以及对某些特殊环境的额外要求。
举个例子，某次季度补丁要求数据库的兼容性参数（COMPATIBLE）至少达到某个版本，如果你不查Readme直接打，补丁可能报错或者打了之后数据字典状态不对。再比如，有些补丁包需要先升级OPatch工具到特定版本，OPatch版本不对的话，一上来就是一团乱码报错。
我建议你在打补丁前，至少把Readme里这几部分仔细过一遍：Pre-Installation Requirements、Changes to Database Compatibility、SQL Commands to Run After Patching、Bugs Fixed、Known Issues。特别是Known Issues部分，如果你正好踩中了Oracle自己都知道的坑，那就要格外小心，可能需要同时安装额外的一次性补丁才能解决。
2.2 OPatch版本检查与升级
OPatch是Oracle补丁工具的老伙计，没有它，整个补丁安装过程寸步难行。不同版本的Oracle数据库对OPatch的最低版本要求不一样，19c一般要求13.9.4.2以上，23ai则要求更高的版本。每季度的补丁说明里都会标注本次补丁需要的OPatch最低版本，务必要对照检查。
检查方法很简单，在$ORACLE_HOME/OPatch目录下执行opatch version，就能看到当前OPatch的版本号。如果版本不够，需要到MOS上下载对应版本的OPatch工具包，覆盖安装到$ORACLE_HOME/OPatch目录。这里有个容易踩的坑：升级OPatch前要记得备份原来的OPatch目录，避免升级失败后没法恢复。我就是吃过这个亏的，有一次升级OPatch时网络中断导致文件不完整，原目录又被覆盖了，最后只能重新下载整个Oracle Home的补丁才救回来。
升级OPatch本身不难，但要注意$ORACLE_HOME的所有权归属。如果你是用root用户安装的Oracle，那OPatch目录的权限也是root的，需要用root来覆盖文件，然后再把权限改回oracle用户。这一步不能省，否则后续opatch apply会报权限错误。
2.3 备份、磁盘空间与环境巡检
打补丁之前不备份，等于在悬崖边开车。这句话我说过很多次，但每次季度补丁季还是有同事问我“能不能不备份直接打”。我的回答永远是：可以，但你要做好环境彻底起不来的准备。
对数据库服务器，备份的要点有这么几个：
- 数据库物理备份或快照：有条件的话做一次RMAN全备，或者快照虚拟机，这是最基本的兜底手段。
- spfile参数文件备份：
create pfile='/tmp/pfile_before_patch.ora' from spfile;，这一条命令几秒钟做完，但能让你在补丁后参数异常时迅速回到原始状态。 - Oracle Home目录的完整性记录：记录
opatch lsinventory的输出，并保存到外部文件，这能帮你定位补丁前后的差异。 - 数据字典备份：如果条件允许，做一次
expdp数据导出，特别是系统表空间的数据字典部分。
另外就是磁盘空间。补丁包本身可能只有几百MB，但解压、备份、应用过程中会占用大量临时空间，尤其是在$ORACLE_HOME所在文件系统上。我建议至少确保Oracle Home所在分区有10GB以上的可用空间，/tmp目录也有5GB以上空间。每次季度补丁季，我都要在打补丁前一晚专门跑一遍磁盘使用率检查，防止第二天一早操作时才发现空间不够，那就太尴尬了。
3. 实操过程：从opatch到SQL脚本全流程
3.1 单实例数据库补丁的完整操作
单实例环境打补丁是最基础的场景，也是RAC和Data Guard环境的前置基础。以19c环境打2026年Q1的季度RU为例，完整流程大致是这样的：
第一步，下载补丁包并解压。把补丁包上传到服务器后，用unzip解压到/u01/app/oracle/patch目录，解压后确认补丁目录的属主是oracle用户。
第二步，关闭监听和数据库实例。在打补丁前，要把数据库正常关闭。这一步要特别注意，补丁过程中数据库是处于不可用状态的，如果有业务在线，必须提前和业务方确认好维护窗口。
bash复制# 先关闭监听
lsnrctl stop
# 再用sqlplus关闭数据库
sqlplus / as sysdba
SQL> shutdown immediate;
SQL> exit;
第三步，切换到Oracle用户，执行opatch的预检查命令。opatch prereq会检查补丁是否可应用、是否存在冲突、环境是否满足要求，这一步一定要跑，不能跳过。
bash复制cd /u01/app/oracle/patch/37000000
$ORACLE_HOME/OPatch/opatch prereq CheckApplicable -ph .
第四步，正式应用补丁。这一步耗时较长，一般在10分钟到半小时之间，取决于服务器性能和补丁大小。命令执行过程中不要中断，也不要同时做其他数据库操作。
bash复制$ORACLE_HOME/OPatch/opatch apply
opatch apply的输出会显示应用进度和结果，最后会有OPatch succeeded的提示，如果看到失败或者警告，要仔细看错误信息再决定下一步。
第五步，启动监听并启动数据库实例。这时候数据库还处于需要执行SQL脚本的状态，不要急着让业务连上来。
bash复制lsnrctl start
sqlplus / as sysdba
SQL> startup;
第六步，执行SQL脚本。这一步是在补丁包中可能存在的postinstall.sql或者Readme里指定的脚本。在19c等版本中，通常需要执行catcon.pl脚本来更新数据字典。
bash复制cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -b post_patch -d $ORACLE_HOME/rdbms/admin post_patch.sql
执行完成后，检查脚本生成的日志文件，确认没有报错。然后重新编译所有失效对象：
bash复制sqlplus / as sysdba
SQL> @?/rdbms/admin/utlrp.sql
最后，做一次完整的验证。查询dba_registry_history来确认补丁已经记录在案，检查数据库的版本信息，再让业务做一轮冒烟测试。
3.2 Grid Infrastructure补丁怎么打
如果你用的是RAC或者装了Grid Infrastructure（GI）的环境，补丁时要额外小心，因为这里涉及两个Home：GI Home和数据库Home，两者都需要打补丁，顺序上一般建议先打GI再打数据库。
GI补丁有很多种方式，比如使用opatch auto配合GridHome补丁包，或者用opatch apply手动滚。从实际操作来看，opatch auto适合单节点或多节点环境下用root用户执行，它会自动处理大多数步骤，包括关闭和启动集群服务。RAC环境的滚动打补丁也是可以做的，每个节点挨个打，保留其他节点继续服务，不过前提是补丁包兼容滚动方式，这在Readme里会明确标注。
打GI补丁时有个容易忽视的点：需要在root用户下执行crsctl stop crs来停止集群服务，然后在所有节点都停止服务后再打补丁。如果部署了Data Guard或者使用了非默认的集群配置，还要注意补丁对OCR和Voting Disk的兼容性。总体来说，RAC环境打补丁一定要做好充分演练，先在测试环境的双节点上完整跑一遍，再上线生产，否则一旦补丁失败，整个集群的恢复成本远高于单实例。
3.3 补丁后要做的事：SQL脚本与验证
我发现一个挺常见的问题，就是有人打完opatch apply之后，看到提示成功，就以为大功告成了，结果数据库启动后一些存储过程报错，或者某个功能不正常。这往往是因为漏掉了补丁后必须执行的SQL脚本。
Oracle的季度RU补丁包里，通常会在$ORACLE_HOME/rdbms/admin下放一系列脚本，比如catbundle.sql、prvtrtyp.plb之类的。这些脚本的作用是同步更新数据字典中的元数据，把新版本的结构变化写入系统表空间。不跑这些脚本，数据字典的版本和二进制版本就不一致，运行中会出各种莫名其妙的问题。
具体跑哪些脚本，以补丁Readme为准。运行方式一般是：
bash复制$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -b catbundle -d $ORACLE_HOME/rdbms/admin catbundle.sql
脚本跑完后，检查日志里有没有ORA-错误，然后跑一遍utlrp.sql重编译失效对象。最后用以下SQL确认补丁版本已经生效：
sql复制SELECT * FROM dba_registry_history ORDER BY action_time DESC;
SELECT * FROM v$version;
这一步能直观看到当前数据库的PSU/RU级别，也是日常审计和安全检查时经常要提供的材料。
4. 常见问题与排查技巧实录
4.1 opatch执行前的报错有哪些
打补丁过程中最常见的报错，基本集中在opatch prereq阶段和opatch apply阶段。整理一些我实际遇到过的错误和排查思路：
报错：Prereq "checkApplicable" failed.
这个报错范围太广，需要看具体的失败原因。最常见的原因有几种：一是OPatch版本过低，需要升级；二是补丁包和数据库版本不匹配，比如你下载了23ai的补丁拿到19c上打，那必然报错；三是环境变量ORACLE_HOME、ORACLE_SID没有设置正确，导致补丁工具找不到目标实例。
报错：OPatch failed with error code 73
这个错误通常和文件权限有关。补丁包解压后，属主不是oracle用户，或者Oracle Home目录下某些文件权限不对。解决办法就是检查并修正目录和文件属主。很多情况下，一条chown -R oracle:oinstall /u01/app/oracle就能解决。
报错：The OPatch version is not compatible
这个很明确，就是OPatch版本不够。按Readme要求去下载对应版本的OPatch工具包，升级后重新执行。不要抱有侥幸心理去跳过版本检查，我试过一次强行忽略版本问题，结果补丁应用中途崩溃，来回折腾了一下午。
4.2 补丁冲突怎么处理
补丁冲突是让人头疼的问题，特别是环境里之前打过一些一次性补丁的情况下。Oracle的补丁机制要求当前环境里不能存在和待应用补丁修复相同问题的其他补丁，否则就会提示冲突。
最简单的办法是在opatch apply前，先用opatch prereq CheckConflictAgainstOHWithDetail来检查当前Home里已有的补丁和待应用补丁的冲突情况。如果发现冲突，可以选择：
- 先回滚掉冲突的旧一次性补丁：
opatch rollback -id 冲突补丁号。 - 或者在确认新补丁已经包含旧补丁修复内容后，直接先应用新补丁（但这需要官方明确说明兼容性，一般不建议自行判断）。
处理冲突的原则是：宁可多一点时间确认，也不要强行推进。我在处理过一次冲突时，因为没做充分测试，直接回滚了一个和生产故障相关的一次性补丁，结果新季度补丁打完之后，原故障又复发了，最后只能再申请一次性补丁修复。这个来回折腾很伤，也从侧面说明冲突处理前一定要先看清楚新旧补丁之间的修复范围是否真正覆盖。
4.3 打补丁失败怎么回滚
Oracle的补丁机制是支持回滚的，但回滚也是有条件的。如果你已经应用了补丁，并且在opatch apply之后还执行了更新数据字典的SQL脚本，那么简单执行opatch rollback就未必能完全恢复原状，因为数据字典的结构可能已经变化了。
所以，回滚的第一原则是：越早回滚，越干净。如果在opatch apply之后就发现问题，还没执行SQL脚本，马上执行以下命令回滚：
bash复制$ORACLE_HOME/OPatch/opatch rollback -id 补丁ID
回滚完成后重新启动数据库，验证版本恢复到补丁之前。
如果是在执行完SQL脚本之后才发现问题，这时候纯靠opatch rollback是不够的。你需要恢复数据库到补丁前的状态——这就是为什么补丁前备份如此重要。没有备份，就只能联系Oracle技术支持来评估修复方案，那个代价就非常大了。
我自己的经验是，每季度补丁前制定一个明确的回滚方案，包括备份策略、回滚步骤、验证清单，都写在一张纸上。这样一旦补丁过程中出现异常，不用临时头脑风暴，照着方案执行就行。
4.4 分享一下我平时踩过或见人踩过的坑
打补丁这些年，经历过太多翻车现场，挑几个值得说的分享出来，希望后来者能绕开。
坑一：跨越大版本打补丁。 有人生产环境还在19.10，看2026年Q1补丁发布了，想直接一步跳到19.25+。理论上可行，但实际上补丁包的应用范围往往只支持从某个特定基线版本开始，跨度过大可能导致opatch apply失败。正确做法是先检查补丁包支持的最低版本，必要时先升级到中间版本，再打最新季度补丁。我印象很深的一次，就是帮客户从19.11升到19.22，中间连续打了三个版本，每步都做验证，结果用了差不多两天，但全程没出问题。
坑二：打了数据库补丁，忘打OJVM。 数据库版本升级了，但OJVM还停留在很久以前的版本，安全扫描一跑，Java虚拟机漏洞一串一串的。OJVM补丁本身不影响业务连续性，但它在数据库运行状态下应用不了，必须在停库状态下装。所以一般我会把数据库补丁和OJVM补丁排在一起，在同一个维护窗口里处理。
坑三：不看patch的依赖关系。 有些补丁之间是有先后顺序的，比如Grid Infrastructure的补丁包要求数据库补丁先打，或者反过来。这个顺序在Readme中最前面就会写清楚，但很多人就是不仔细看。记住一条：开始动手之前，花半个小时把Readme全部读完，比打一半发现顺序错乱再回头重新来要划算得多。
坑四：清理“僵尸”补丁记录。 有时候你会遇到opatch lsinventory里显示补丁已应用，但实际数据库状态却看不出来，或者反过来，补丁打了但系统里找不到对应记录。这种情况大多是因为补丁应用后数据字典更新脚本没有执行成功，导致二进制版本和数据库版本脱节。处理办法就是重新执行对应版本的SQL更新脚本，确保两边一致。
坑五：忽略了参数文件的变化。 季度补丁有时会引入新的初始化参数或者调整某些参数的默认值，如果你用的是spfile，补丁后启动时可能会遇到参数不兼容的问题。建议打补丁前把spfile转成pfile存一份，补丁后如果启动异常，可以先用pfile启动再排查参数问题。
5. 写在最后的小建议
季度补丁这件事，看起来是例行公事，但其实最能体现一个DBA的功力。我从Oracle 10g时代就开始打补丁，到现在二十多年了，越来越觉得这件事的核心不是“怎么打”，而是“怎么准备”。准备足够充分，补丁过程本身就是按部就班；准备不充分，就会一路惊险。
我个人习惯是，每季度补丁发布后，先在测试环境完完整整跑一遍流程，记录每一步的耗时和输出，再对照生产环境的版本差异，评估风险。这一步花的时间不多，但能让你在生产操作时胸有成竹。另外，别忘了把每一季度的补丁记录维护在专门的文档里，包括补丁编号、应用时间、验证结果、以及遇到的问题和解决办法，长期积累下来，这就是团队最珍贵的运维资产。
补丁打了不代表万事大吉，打完之后的一周内，多关注alert日志、监控告警和性能指标，一旦发现异常尽早介入。我在一次补丁后第二天，发现某个核心SQL的执行计划因为统计信息变化而变差了，及时做了统计信息的重新收集才避免业务受影响。这种补丁后的“跟踪期”，我觉得应该和补丁本身一样重视起来。
希望这篇关于2026年Q1季度补丁的解析和实操经验，能帮你在下一个维护窗口到来时更从容一些。数据库这条路上，谨慎永远是第一位的。