Oracle 11.2.0.4 RAC 更新GI PSU （p24436338_112040_Linux-x86-64.zip）

更新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响应文件

默认的情况是需要手动生成ocm响应文件。在grid用户的$ORACLE_HOME/OPatch/ocm/bin目录下有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

下面是更新PSU的步骤，并继续讲述自己在上面提到的“坑”。使用root用户执行opatch auto 操作。首先操作节点1 ，非常顺利，可以下图看到更新的操作步骤。
1. 1.在log日志中观察，首先使用ocm.rsp文件设置参数，并做PSU补丁集的冲突检查2. 2.检查通过后，停止RAC本节点实例3. 3.本节点实例停止后，应用更新补丁24006111和230543194. 4.停止CRS集群服务5. 5.CRS停止后，应用更新补丁24006111、23054319和225025056. 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对于集群环境，则只会更新本节点更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址