Oracle数据库补丁安装流程详解：从零到一的实践指南

Oracle数据库补丁安装流程详解：从零到一的实践指南

前言：为什么我们需要给数据库打补丁？

大家好！作为一名与Oracle数据库打了多年交道的DBA，我深知保持系统“健康”的重要性。你可以将给数据库打补丁想象成给你的手机系统或常用App进行版本更新。这些更新不仅仅是为了增加新功能，更关键的是为了修复已知的安全漏洞、解决潜在的性能问题，并增强系统的整体稳定性。

一个未经维护的数据库，就像一扇没有上锁的门，充满了未知的风险。因此，定期打补丁是每一位数据库管理员的基本功。

本文档的目标，就是为初学者拆解整个Oracle数据库补丁的安装流程。我们将把看似复杂的一连串命令行操作，转化为一系列清晰、易懂、可执行的步骤，帮助你从零到一，完整掌握这项核心技能。

--------------------------------------------------------------------------------

1. 准备阶段：上传与解压补丁包

在此部分，我们将完成所有准备工作，确保补丁文件就位并可供使用。这就像是做菜前的备菜环节，至关重要。

1.1. 上传补丁文件

首先，我们需要将下载到本地的补丁文件上传到目标数据库服务器上。这里我们使用sftp（安全文件传输协议），它能确保数据在传输过程中的安全性。

以下是在sftp会话中执行上传操作的关键命令：

sftp> cd /diaglog
sftp> put -r "D:\FFOutput\p38298204_190000_Linux-x86-64.zip"

• cd /diaglog：这条命令用于切换到服务器上的/diaglog目录，这是我们计划存放补丁包的位置。
• put -r "..."：这条命令将本地D:\FFOutput\路径下的补丁压缩包上传到服务器的当前目录。

当看到类似 100% 3918357KB... 的日志输出时，就代表文件已成功上传。

1.2. 设置权限

为了确保后续操作能顺利读写这些文件，我们需要设置正确的目录权限。通常这一步由root用户执行，为后续的grid或oracle用户准备好工作区。

chmod -R 777 /diaglog

教学重点: chmod -R 777 命令中的 777 是一个权限代码，意味着“任何人”都对这个目录及其下的所有文件拥有“读、写、执行”的全部权限。-R 参数表示递归地应用到所有子文件和子目录。

• 提醒：在测试环境中，为了操作便利，我们有时会使用777。但在生产环境中，这是极不安全的做法。届时，你应该根据实际用户（如grid、oracle）分配更严格、更精确的权限。

1.3. 创建目录与解压

为了保持服务器环境的整洁有序，最佳实践是为每个补丁创建一个专门的目录。我们先切换到grid用户，然后执行创建和解压操作。

[root@redhat76 ~]# su - grid
[grid@redhat76 diaglog]$ mkdir /u01/software/patch
[grid@redhat76 diaglog]$ unzip p38298204_190000_Linux-x86-64.zip -d /u01/software/patch

• mkdir 命令创建了一个名为 patch 的新目录。
• unzip ... -d ... 命令将补丁压缩包解压到我们刚刚创建的 /u01/software/patch 目录中。

注意：正如操作日志中特别提到的——“解压出来空间巨大，需要提示环境！”。Oracle的补丁包通常很大，在执行解压前，请务必确认目标磁盘有足够的剩余空间，避免因空间不足导致操作失败。

学习小结与过渡: 完成以上准备工作后，我们的补丁文件已经上传并解压到指定位置，万事俱备。接下来，我们将进入至关重要的预检查阶段，确保系统环境满足打补丁的要求。

--------------------------------------------------------------------------------

2. 预检阶段：更新工具与冲突检查

在此部分，我们将学习如何“三思而后行”，通过更新工具和检查冲突来避免潜在的安装问题。一个好的DBA从不打无准备之仗。

2.1. 理解补丁要求与更新OPatch工具

每个补丁包都会附带一个readme（说明）文件，其中包含了关键的安装信息。根据日志中的readme摘要，我们得知：

You must use the OPatch utility version 12.2.0.1.47 or later to apply this patch.

OPatch是Oracle官方提供的、专门用于应用和管理补丁的命令行工具。补丁的更新往往依赖于新版本的OPatch。因此，在打补丁前，第一步就是确保OPatch工具本身是最新或符合要求的。

更新OPatch的操作非常简单，就是将新的OPatch压缩包解压并覆盖到$ORACLE_HOME目录下。

[grid@redhat76 diaglog]$ unzip p6880880_190000_Linux-x86-64.zip -d $ORACLE_HOME
Archive: p6880880_190000_Linux-x86-64.zip
replace /u01/app/19.4.0/grid/OPatch/oracle_common/modules/com.oracle.glcm.common-logging_1.6.5.0.jar? [y]es, [n]o, [A]ll, [N]one, [r]ename: A

在解压过程中，系统会提示是否replace（替换）已存在的文件。这是一个非常常见的交互，我们应该输入 A 并回车，代表 All（全部替换），以确保OPatch工具被完整更新。

2.2. 执行冲突检查

为什么冲突检查是必不可少的步骤？因为你的数据库环境中可能已经安装了其他补丁。此项检查能提前分析，新的补丁包是否与系统中已存在的补丁存在不兼容或冲突的情况，从而避免安装失败或引发更严重的问题。

我们使用opatch prereq CheckConflictAgainstOHWithDetail命令，针对补丁包内的每一个子补丁进行详细的冲突分析。

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/patch/38298204/38291812
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/patch/38298204/38322923
... (对所有子补丁执行检查)

如果所有检查都顺利通过且没有报告冲突，我们就可以安心地进行下一步了。

学习小结与过渡: 通过更新工具和细致的预先检查，我们为顺利安装补丁铺平了道路。现在，让我们开始核心的打补丁操作，首先从Grid Infrastructure（GI）环境入手。

--------------------------------------------------------------------------------

3. 核心操作一：为 Grid Infrastructure (GI) 打补丁

在此部分，我们将分两步完成对Oracle集群软件（Grid Infrastructure）的补丁升级。GI是数据库集群的基石，负责管理存储、网络和集群服务。

3.1. 模拟应用（Analyze）：安全第一的“演习”

在进行任何可能影响系统的重大变更前，进行一次“彩排”或“演习”是极其明智的选择。opatchauto apply -analyze命令正是为此而生。

这个命令不会对系统做任何实际更改。它只会完整地分析一遍打补丁的流程，并报告补丁是否可以被成功应用，以及可能遇到的问题。

[root@redhat76 patch]# /u01/app/19.4.0/grid/OPatch/opatchauto apply /u01/software/patch/38298204 -oh $ORACLE_HOME -analyze

当你在日志中看到如下信息时，代表“演习”成功，系统环境已准备就绪：

• Patch applicability verified successfully
• OPatchAuto successful.

核心洞察: -analyze参数是新手和专家都应遵守的最佳实践。它能以零风险的方式提前发现问题，是确保补丁安装过程平稳、可控的关键一步，能最大限度地降低操作风险。

3.2. 正式应用补丁

在确认模拟运行成功后，我们就可以充满信心地开始正式的补丁安装了。操作很简单，只需移除上一条命令中的-analyze参数即可。

[root@redhat76 patch]# /u01/app/19.4.0/grid/OPatch/opatchauto apply /u01/software/patch/38298204 -oh $ORACLE_HOME

补丁应用过程中，日志会显示几个关键阶段，理解它们有助于我们掌握进度。请注意日志中的原话：

1. Performing prepatch operations on CRS - bringing down CRS service on home ...: 准备阶段。日志明确指出正在关闭集群服务（CRS），为更新核心文件做准备。
2. Start applying binary patch on home ...: 核心阶段。这是真正将新的二进制文件（补丁内容）复制并应用到Grid环境的步骤。
3. Performing postpatch operations on CRS - starting CRS service on home ...: 收尾阶段。日志显示二进制文件更新完毕，工具正在重新启动集群服务，让系统恢复正常运行。

学习小结与过渡: 我们已经成功为Grid Infrastructure打上了补丁。接下来，我们将用类似的方法为数据库软件本身（Oracle Database Home）进行升级。

--------------------------------------------------------------------------------

4. 核心操作二：为 Oracle Database Home 打补丁

在此部分，我们将对数据库软件本身进行补丁安装。这个过程与为Grid打补丁非常相似，但我们需要关注其结果的细微差别。

4.1. 应用补丁

我们同样使用opatchauto apply命令。请注意，这里的-oh（Oracle Home）参数指向的是数据库软件的安装目录，而不是Grid的目录。

[root@redhat76 patch]# /u01/app/oracle/product/19.4/OPatch/opatchauto apply /u01/software/patch/38298204 -oh /u01/app/oracle/product/19.4

4.2. 解读应用结果：成功、跳过与警告

与GI环境不同的是，在为数据库软件打补丁时，日志的Summary部分可能会出现“成功应用”和“跳过”两种状态。

状态 (Status)	补丁号 (Patch ID) & 原因 (Reason)
成功应用	38291812, 38322923
跳过	38311528, 36758186, 38380425

跳过原因: 日志中给出了明确的解释：Reason: This patch is not applicable to this specified target type - "rac_database"。 这对初学者是一个非常重要的知识点：一个大的补丁包（如GI Release Update）里可能包含了针对不同组件（如ACFS文件系统、OCW集群件、数据库核心等）的子补丁。opatchauto工具非常智能，它会自动识别当前操作的环境类型（这里是数据库软件），并只安装适用于当前环境的补丁，而自动跳过不相关的部分。 回顾 5.1 节中 Grid Home 的补丁列表，你会发现这些被跳过的补丁 (如 38311528 for ACFS 和 38380425 for TOMCAT) 正是成功安装在 Grid 环境中的。这完美地展示了 opatchauto 是如何为不同环境“量身定制”补丁应用的。

此外，我们还需要留意日志末尾的[WARNING]信息：

[WARNING] The database instance 'orcl1' from '/u01/app/oracle/product/19.4', in host'redhat76' is not running. SQL changes, if any, will not be applied.

这条警告告诉我们，由于在打补丁时数据库实例没有运行，任何需要通过执行SQL脚本来完成的变更都未能应用。这提示我们，在整个操作结束后，可能需要根据readme文件的指引，手动登录数据库执行额外的SQL脚本来完成最后的步骤。

学习小结与过渡: 两个核心环境的补丁均已应用完毕。但我们的工作还没结束，最后一步是进行验证，确保一切都已正确更新。

--------------------------------------------------------------------------------

5. 验证阶段：确认补丁安装成功

在此部分，我们将学习如何使用命令来检查补丁是否已正确记录在系统中，并通过登录数据库来做最终的确认。

5.1. 检查已安装补丁列表

opatch lspatches命令是检查当前ORACLE_HOME下所有已安装补丁列表的权威方式。我们需要分别在grid用户和oracle用户下执行此命令，以验证两个环境的补丁情况。

Grid Home 补丁列表:

[grid@redhat76 ~]$ $ORACLE_HOME/OPatch/opatch lspatches
38380425;TOMCAT RELEASE UPDATE 19.0.0.0.0 (38380425)
38322923;OCW RELEASE UPDATE 19.29.0.0.0 (38322923)
38311528;ACFS RELEASE UPDATE 19.29.0.0.0 (38311528)
38291812;Database Release Update : 19.29.0.0.251021 (38291812)
36758186;DBWLM RELEASE UPDATE 19.0.0.0.0 (36758186)

Database Home 补丁列表:

[oracle@redhat76 ~]$ $ORACLE_HOME/OPatch/opatch lspatches
38322923;OCW RELEASE UPDATE 19.29.0.0.0 (38322923)
38291812;Database Release Update : 19.29.0.0.251021 (38291812)

通过对比这两个列表，你可以直观地看到每个环境中都应用了哪些具体的补丁，与我们在第4部分解读的结果完全一致。

5.2. 登录数据库最终确认

最直接、最可靠的验证方式，就是登录到数据库内部，查看它自己报告的版本号。

[oracle@redhat76 ~]$ export ORACLE_SID=orcl
[oracle@redhat76 ~]$ sqlplus / as sysdba

成功登录后，系统会显示完整的欢迎信息和版本号。请特别关注Version信息：

这个版本号 19.29.0.0.0 正好与我们应用的核心数据库补丁 38291812（其描述为 Database Release Update : 19.29.0.0.251021）相对应。这雄辩地证明了数据库核心已经成功升级到了新版本。至此，整个补丁安装工作圆满完成！

--------------------------------------------------------------------------------

总结

恭喜你！通过以上步骤，我们完整地走了一遍Oracle数据库的补丁安装流程。现在，让我们回顾一下这四个核心阶段：

1. 准备：上传文件、设置权限、创建目录并解压。
2. 预检：阅读说明、更新OPatch工具、执行冲突检查。
3. 应用：先使用-analyze进行安全演习，然后正式为Grid和Database环境应用补丁。
4. 验证：使用opatch lspatches检查补丁列表，最后登录数据库确认版本号。

理论结合实践是掌握技能的最佳途径。希望这份分解指南能帮助你建立信心。请记住，在任何生产环境中进行操作前，务必在测试环境中进行充分的演练，并确保你已经有了可靠的数据备份！