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

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

1 RAC 更新PSU

1、Opatch组件版本

要求version 11.2.0.3 or later. 下载合适的opatch 版本，解压替换掉$ORACLE_HOME原有的OPatch文件夹。

$ unzip -d

$ /OPatch/opatch version

2、检查oracle用户和grid用户的产品目录。

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

$ /OPatch/opatch lsinventory -detail -oh 

对于产品目录的检查分别在各个节点的oracle用户和grid用户下进行。在这里 ，只列举某一个节点oralce用户的检查结果的开始部分。

另外opatch prereq CheckConflictAgainstOHWithDetail进行冲突检查

3、OCM响应文件

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

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

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

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

4、解压PSU

使用grid用户解压PSU文件

Unzip the patch as grid home owner.

$ unzip p24436338_112040_.zip

5、关闭em

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

$ /bin/emctl stop dbconsole

6、应用PSU

使用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成功。

7、opatch apply命令

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

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

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

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