更新PSU的方式有多种，比如opatch auto、opatch apply

在这里，我们根据自述文件，采用opatch auto的方式更新PSU。

$ unzip -d

$ /OPatch/opatch version

检查安装前产品目录并保存，对比更新PSU后的产品目录，观察变化。

目录下有emocmrsp脚本。运行该脚本生成响应文件

?

对于这个ocm.rsp响应文件，有几个要点需要注意：

1.? ? ? 使用opatch auto方式更新PSU，需要把ocm.rsp存放在oracle用户可以访问的目录下，如/tmp。
? ? 可以看到ocm.rsp文件的属组是grid:oinstall。对于属组是oinstall的文件，oracle也应该正常访问才对，可以通过系统的ls命令验证。

下面会继续讲述自己遇到的这个“坑”，其实这是自己操作不规范造成的.

使用grid用户解压PSU文件

Unzip the patch as grid home owner.

Oracle的em对于数据库管理很方便。但是在更新PSU前，需要检查em的状态并关闭服务

使用root用户执行opatch auto 操作。首先操作节点1 ，非常顺利，可以下图看到更新的操作步骤。

1.? ? ? ?1.在log日志中观察，首先使用ocm.rsp文件设置参数，并做PSU补丁集的冲突检查

2.? ? ? ?2.检查通过后，停止RAC本节点实例

3.? ? ? ?3.本节点实例停止后，应用更新补丁24006111和23054319

4.? ? ? ?4.停止CRS集群服务

5.? ? ? ?5.CRS停止后，应用更新补丁24006111、23054319和22502505

6.? ? ? ?6.启动CRS集群服务

可以在log文件中看到opatch auto的详细过程。

接着，我们在使用同样的命令，在节点二执行

仔细查看，发现节点1提到的步骤3，也就是节点二的实例应用更新补丁集失败。

通过log文件可以查看到失败原因的详细内容

提示响应文件’ocmrf’ file 也就是ocm.rsp文件不存在。可以该文件明明是存在

这就是遇到问题，oracle用户对这个ocm.rsp文件无访问权限造成的。

仔细思考，为什么节点1可以执行完成，节点2不???以呢。对比文件目录，两个节点grid和oracle权限不对，节点1是755，节点2是700
.

针对这个问题，有两个解决方法：

1.? ? ? 修改节点2的grid用户权限为755?

2.? ? ? 保存响应文件ocm.rsp到目录/tmp下，grid和oracle都可以访问；或是其他具有访问权限的目录。

在这里，我们修改/home/grid权限为755，

再次执行opatch auto命令，节点2应用更新PSU成功。

Opatch apply -help 可以查看apply 参数的使用情况。

我们经常使用的命令? $ opatch apply? 以及$opatch apply -local，它们之间的区别在于

$ opatch apply? 对于集群环境，会提示是否准备patch所有节点

$opatch apply -local对于集群环境，则只会更新本节点