共计 1837 个字符，预计需要花费 5 分钟才能阅读完成。
更新 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.
下面会继续讲述自己遇到的这个“坑”，其实这是自己操作不规范造成的.
4、解压PSU
使用 grid 用户解压 PSU 文件
Unzip the patch as grid home owner.
$ unzip p24436338_112040_.zip5、关闭em
Oracle的 em 对于数据库管理很方便。但是在更新 PSU 前，需要检查 em 的状态并关闭服务
$ /bin/emctl stop dbconsole
6、应用PSU
使用 root 用户执行 opatch auto 操作。首先操作节点1 ，非常顺利，可以下图看到更新的操作步骤。
1.
2.
3.
4.
5.
6.
可以在 log 文件中看到 opatch auto 的详细过程。
接着，我们在使用同样的命令，在节点二执行
仔细查看，发现节点 1 提到的步骤3，也就是节点二的实例应用更新补丁集失败。
通过 log 文件可以查看到失败原因的详细内容
提示响应文件 ’ocmrf’file 也就是 ocm.rsp 文件不存在。可以该文件明明是存在
这就是遇到问题，oracle用户对这个 ocm.rsp 文件无访问权限造成的。
仔细思考，为什么节点 1 可以执行完成，节点 2 不���以呢。对比文件目录，两个节点 grid 和oracle权限不对，节点 1 是755，节点 2 是700
. 
针对这个问题，有两个解决方法：
1.
2.
在这里，我们修改 /home/grid 权限为755，
再次执行 opatch auto 命令，节点 2 应用更新 PSU 成功。
7、opatch apply命令
Opatch apply -help 可以查看 apply 参数的使用情况。
我们经常使用的命令
$ opatch apply
$opatch apply -local对于集群环境，则只会更新本节点
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-02/140645.htm
