Oracle数据库PSU与BP补丁的区别是什么？

Oracle数据库的补丁体系里，PSU和BP这两个缩写经常出现在安全扫描报告、Oracle Support建议以及日常运维文档中。PSU是Patch Set Update的缩写，可以理解为Oracle按季度发布的累积补丁包，重点解决安全漏洞和少量关键Bug；BP是Bundle Patch的缩写，早期主要面向Windows平台和Exadata一体机，打包范围比PSU更宽，还可能包含平台相关的二进制修复。两者的安装工具通常都是OPatch，但在编号规则、适用场景和后续演进路径上存在明显差异。只有先搞清楚这些区别，才能在安全合规、版本稳定和业务连续性之间做出合理选择。

PSU与BP的定位和命名规则

PSU的定位非常清晰：它是Oracle针对数据库安全漏洞和关键缺陷推出的累积性补丁包。以12c为例，一个典型的PSU编号可能写作12.1.0.2.190416，其中最前面的12.1.0.2是数据库基础版本号，后面的190416表示该补丁发布于2019年4月16日。这种命名方式让管理员一眼就能看出补丁对应的数据库版本和发布月份。PSU是累积的，也就是说，2019年4月的PSU会包含此前所有PSU的修复内容，不需要从最早的PSU开始逐个安装，只需要在目标版本上安装最新的季度PSU即可。

BP的命名则带有更强的平台属性。例如，一个Windows平台的Bundle Patch可能写作12.1.0.2.160719 Database Bundle Patch for Windows，编号中同样带有日期，但会明确标注平台类型。在早期Oracle版本中，Windows平台上的某些问题并不能通过通用PSU解决，因为这些问题涉及Windows服务、注册表、文件权限等操作系统层面的差异。因此，Oracle专门针对Windows发布BP，把操作系统集成相关的修复也打包进去。Exadata一体机的BP则可能同时包含数据库节点和存储节点需要的修复，这一点是普通PSU无法覆盖的。

理解命名规则有助于快速判断补丁性质。如果补丁名称中带有Quarterly、Security、Patch Set Update，通常属于PSU系列；如果带有Bundle Patch、Windows、Exadata、Combo Patch等字样，则更接近BP或后续演进出来的组合补丁。实际下载补丁时，Oracle Support会根据数据库版本和平台自动推荐合适的补丁类型，但管理员仍然需要理解这些名称背后的含义，避免盲目安装。

PSU与BP在内容、平台和修复类型上的核心区别

PSU与BP最直观的区别在于补丁包含的内容范围。PSU以安全修复为主，同时包含少量经过严格验证的关键Bug修复。Oracle通常在每个季度发布一次PSU，时间点集中在1月、4月、7月和10月。PSU的修复项相对克制，目的是在保证数据库稳定性的前提下，尽快解决已经公开的安全漏洞。对于大多数只运行标准版或企业版数据库的环境来说，安装最新的PSU已经能够满足安全合规要求。

BP的修复范围则更广。除了安全漏洞，BP还会包含平台特定的功能修复、性能改进以及某些复杂Bug的解决方案。以Windows平台为例，普通PSU可能覆盖不了Oracle数据库与Windows服务交互时的罕见故障，但这些故障会导致监听器异常、实例挂起甚至数据文件写入失败。这种场景下，只有安装Windows Bundle Patch才能解决问题。Exadata一体机的BP更加特殊，它可能同时包含数据库软件、ASM实例、节点管理工具甚至存储服务器固件的协同修复，这种跨组件打包方式是PSU不具备的。

从发布节奏来看，PSU严格按季度发布，而BP的发布时间并不固定。BP通常在发现了重要平台缺陷或者多个Bug集中在某个平台爆发时才发布。这意味着BP不一定每个月或者每个季度都有，而是按需推出。不过，从12c开始，Oracle逐渐统一了补丁发布策略，BP和PSU的界限开始模糊，尤其是在18c、19c版本中，Quarterly Database Release Update已经取代了传统的PSU，而包含OJVM等组件的Combo Patch则在一定程度上继承了BP的宽覆盖特性。

安装方式方面，PSU和BP都依赖OPatch工具，但在某些BP场景下，Oracle会要求先升级OPatch版本，或者先安装OJVM PSU。管理员在下载补丁时，需要仔细阅读补丁包内的Readme文档，确认前置条件。如果忽略前置条件直接执行opatch apply，很可能因为Opatch版本过低或组件依赖不满足而失败，甚至导致数据库实例无法启动。

从PSU/BP到Release Update的演进

Oracle在12.2版本之后对补丁命名体系进行了调整。传统的Database PSU逐渐被Database Release Update（RU）取代，而Bundle Patch则演进为Combo Patch或者Release Update Revision（RUR）。名称虽然变了，但核心思路仍然延续了PSU和BP的定位：RU相当于原来的PSU，关注季度安全修复；Combo Patch相当于原来的宽范围BP，同时包含数据库、OJVM、JDK等组件的修复。

下表列出了旧术语和新术语的大致对应关系：

对于19c及之后的版本，Oracle通常提供两种选择：Database Release Update和Database Release Update + OJVM。前者体积较小，只包含数据库核心修复；后者就是Combo Patch，额外包含OJVM组件修复。如果数据库中启用了Java虚拟机组件，或者安全扫描明确提示OJVM存在漏洞，那么就必须选择Combo Patch。如果OJVM没有被使用，也可以只安装RU，减少停机时间和补丁冲突风险。

实际选择补丁时，建议遵循以下思路：先确认数据库版本和平台，再到Oracle Support的补丁检索页面查看推荐补丁。如果扫描报告只列出数据库核心组件的漏洞，普通RU或PSU即可；如果报告中包含OJVM、JDK或者平台相关条目，则需要选择Combo Patch或对应的BP。在Exadata环境，还要额外关注是否发布了专用的Exadata Bundle Patch，这类补丁可能包含存储节点和InfiniBand相关修复，普通RU无法覆盖。

安装与验证时的注意事项

安装PSU或BP之前，必须做好环境检查和备份。首先要确认OPatch版本是否满足补丁包要求，可以使用以下命令查看当前OPatch版本：

# 查看OPatch版本
$ORACLE_HOME/OPatch/opatch version

# 查看已安装补丁列表
$ORACLE_HOME/OPatch/opatch lsinventory -detail

如果OPatch版本过低，需要先从Oracle Support下载新版本OPatch并升级。升级完成后，建议对数据库、网络配置文件以及Oracle Home做一次完整备份，尤其是Oracle Home下的库文件和配置文件。生产环境中，补丁安装失败最常见的恢复手段就是回退Oracle Home备份，如果缺少备份，可能会陷入非常被动的局面。

执行补丁安装前，需要停止数据库实例、监听器和相关服务。单实例环境可以使用sqlplus关闭数据库，再用lsnrctl停止监听；RAC环境则需要使用srvctl逐个节点停止服务。打完补丁后，不能只检查opatch lsinventory，还必须执行datapatch把补丁中的SQL变更应用到数据库中。示例命令如下：

# 进入OPatch目录执行datapatch
cd $ORACLE_HOME/OPatch
./datapatch -verbose

datapatch执行完成后，可以通过数据字典查看补丁的加载情况：

-- 查询补丁注册信息
SELECT PATCH_ID, PATCH_UID, STATUS, DESCRIPTION
FROM DBA_REGISTRY_SQLPATCH
ORDER BY ACTION_TIME DESC;

如果STATUS显示为SUCCESS，说明补丁中的SQL部分已经应用成功。如果出现FAILED，则需要查看datapatch日志，通常日志位于Oracle Home的cfgtoollogs目录下。常见失败原因包括补丁包不完整、组件版本不匹配或者数据库字典对象无效。解决完问题后，可以重新执行datapatch，Oracle会跳过已经成功应用的步骤，只处理失败部分。

对于Windows平台上的BP补丁，安装过程中还可能涉及服务重启和注册表更新。管理员需要确认补丁包中的Readme文档是否要求重启操作系统，以及重启后是否需要重新启动Oracle相关服务。Exadata环境则要特别关注补丁是否要求滚动安装，是否需要先升级存储节点，以及数据库节点和存储节点之间是否存在版本匹配要求。忽略这些平台特定步骤，往往是生产环境出现异常的直接原因。

补丁安装完成后，建议执行一轮简单的功能验证，包括数据库启停、监听连接、核心业务查询以及备份测试。只有确认实例可以正常打开、监听可以正常接受连接，并且业务查询没有异常，才能认为补丁安装成功。对待任何数据库补丁，都应当保持谨慎态度，尤其是在生产环境，打好补丁后的验证成本和业务影响，远比补丁安装本身更需要重视。

Oracle PSU补丁BP补丁补丁策略修改时间：2026-08-24 18:31:37