首先,在功能许可的情况下,忽视掉RDBMS部分的修补是安全,例如,如果群件修补不会影响到10.1.0.5的oracle RDBMS的运行环境,简单的跳过应用于10.1.0.5的RDBMS部分,RDBMS部分包括主要用于修补针对于数据库的管理组件,以及群件客户端组件.因为它不能很容易确定修补补丁所需的RDBMS环境,无论何时,补丁的README总是包含这条信息.
因此以上的例子中可以使用10.2.0.2的群件补丁,并应用到CRS环境,RDBMS环境和ASM环境,由于以上原因,RDBMS将会跳过(它是10.1.0.5);
如果一个修补补丁的RDBMS是必须的,Opatch将会请求一个10.1.0.5版本,这个补丁也会包含两个部分(位于top/root目录的群件部分,位于’server’目录的RDMBS部分),在我们的例子中,只有’server’部分能够应用到10.1.0.5的RDBMS环境中,群件部分将不会安装,因为我们已经有了一个更新版本的群件,在这种情况下将会跳过群件部分只执行RDBMS部分,大多数情况下,这个操作类似于:
Unix/Linux:
$ opatch apply custom/server/<bugnum> -local -oh <RDBMS_HOME>
Windows:
C:\> opatch apply custom\server\<bugnum> -local -oh <RDBMS_HOME>
对于以上的例子,下载一次性补丁10.1.0.5,只应用RDBMS部分到RDBMS的环境中.
始终记得,群件补丁包含两部分(Clusterware & RDBMS),不要企图修改Opatch,也不要安装一个不争取的安装包或共享包或对象文件到一个不匹配的版本中,例如,一个10.2.0.2的修补补丁不能安装到一个10.2.0.1的oracle环境中.
只要遵循以上步骤就能正确安装.
如果一次性补丁包含了不止一个的修补补丁,README中将会描述那个文件将会影响群件环境,那些将会影响RDBMS环境,可以帮助我们决定能否安全跳过一个RDBMS部分,另外,在大多数情况下,忽视掉RDBMS部分也是安全的,因为漏洞不会影响到更老的版本,或者是消费者在一定的承受范围内愿意忍受这样的软件缺陷.
以上讨论也适用于绑定了修补程序(包含一个RDBMS部分)的oracle群件,例如,安装一个10.2.0.2版本RDBMS部分,把它绑定到10.1.0.5的RDBMS环境中时不可能的,执行以上例子中相同的步骤来决定RDBMS修补程序对于RDBMS的环境关联性,如果有必要的话,也可以决定一个老的版本的RDBMS环境是否是必须的,大多数情况下是不必要的或者可有可无
全文：http://bbs.landingbj.com/t-0-197681-1.html
原载于：联动北方
