更新PSU的方式有多种，比如opatch auto、opatch apply
在这里，我们根据自述文件，采用opatch auto的方式更新PSU。
1 RAC 更新PSU
1、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对于集群环境，则只会更新本节点
