企业管理器网格控制OMS的补丁和处理冲突的最佳实践

适用于：

目的：
本文件的目的是提供应用补丁程序的最佳实践（一次性的修补程序或补丁集更新）网格控制Oracle管理服务器（OMS）上的管理员。

在补丁程序安装或取消安装不正确或不完整的步骤将导致在库包和托管的OMS的ORACLE_HOME文件系统的镜像不一致。这可能会导致不可预知的结果，有时是难得来跟踪的。

范围和应用
本文档的读者主要是网格的控制管理员。
企业管理器网格控制OMS的修补和处理冲突的最佳实践
问题描述
许多OMS端的补丁由两部分组成：

1．  适用于企业管理的J2EE Web应用程序的一些变化（通常是Java代码）
2。有些变化（一般SQL或PL / SQL代码）要通过一个SQLNET连接到企业管理系统信息库中应用从OMS的ORACLE_HOME。
一次性的修补程序应用于与opatch命令。 opatch工具奠定了在OMS的Oracle Home的修补文件。
潜在的SQL或PL / SQL脚本，post_install_script.sql要对库用户手动执行从OMS的ORACLE_HOME通过一个SQLNET连接，为每个修补程序自述文件中的步骤。
一是回滚OMS的修补程序已在库中的改变时，需要采取特别的护理。在opatch回滚的修补程序的Java的一部分，但不回滚内的资料库本身的变化。这通常是通过对仓库运行的脚本post_deinstall_script.sql SYSMAN。

当opatch检测补丁冲突并且系统管理员同意opatch自行回滚并且应用一个新补丁，这回滚部分变得相当重要。由于opatch是不能够自动回滚资源库变化，这就有一定的几率是的仓库处于一个不一致的状态，在比较注册在清单的补丁包的时候。但并非总是如此。一些参考：

示例

为了说明这个问题，让我们用一个例子。

让我们看补丁8904195。这是大的MLR.class文件，诸如一些SQL文件

basic_loader_pkgbody.sql. 修补程序附带的自述文件给出了两个应用此修补程序的步骤：

1．    opatch申请

2．    运行post_install_script.sql，以SYSMAN的身份登录到库。

让我们考虑这个补丁已经安装在仓库的情况下。 “opatch lsinventory细节”的摘录显示:

现在，让我们在这种环境下应用10.2.0.5.1PSU补丁8864918。由于10.2.0.5.1PSU是一个相当大的补丁，因为它是不包含的所有修复补丁8904195，申请命令“opatch”将检测这两个补丁之间的冲突。

opatch检测10.2.0.5.1是一些已经安装了修补程序的一个超集，并计划推出他们回来。这不是一个的问题，因为这些一次性的修补程序包括在PSU这不会产生内库不一致。
此行是冲突报告：

补丁（ES）[8904195]冲突的补丁目前正在安装[8864918]。
如果用户回复N（否），opatch停止和系统不会改变。
如果用户回复Y（是），然后opatch回滚补丁8904195，并安装，而不是补丁8864918。
注意：这不会自动创建一个名为上述两个修补程序合并补丁。

当opatch回滚补丁8904195，它不执行需要手动的脚本post_deinstall_script.sql，这个补丁附带，但只回滚从OMS的Oracle Home的修补文件。通过下面的补丁8864918自述，，用户将执行对资源库的post_install_script.sql，并可能会失败，无效的对象。即使不失败的无效对象，资料库是不相符的相比，在文件系统中的补丁。再次，这种不一致是透明的，容易产生潜在的不可预知的表现并且问题很难被追踪。

要解决上述问题：

1．    opatch回滚回滚补丁8864918。
2。运行补丁8864918附带的post_deintall_script.sql
3。运行补丁8904195附带的post_deintall_script.sql。有没有需要重新运行opatch回滚，因为补丁8904195从文件系统已经推出。
4。再次申请补丁opatch申请8864918
5。运行补丁8864918附带的post_install_script.sql
这个时候，不应该有任何无效的对象了，在库和补丁是一致的。
建议

1．  请务必参阅修补程序自述文件，而应用或删除一个补丁的指示。确保按照指示完成所有的手动步骤。
2。大多数OMS补丁程序可能有一个手动执行post_install_script.sql的第一步，附带库中的数据库补丁，SYSMAN用户。预计脚本来修改一些档案资料库和用于此修改。SQL文件中的对象将被复制到的opatch。因此，它是非常必要的环境变量设置正确的sqlplus拿起从正确的SQL文件。的：
A）如果OMS和库都是同一台机器上，然后
- 设置环境变量：

     B）如果OMS和库是在不同的机器上：
- 创建一个/网络/ ADMIN下的tnsnames.ora
- 创建一个TNS别名，指向存储库数据库，在tnsnames.ora
- 设置下列变量：

如果SQLPLUS是调用一些其他的Oracle主目录，然后post_install_script.sql脚本失败/成功，取决于可用性。SQL文件，它需要执行。即使成功，它最终将破坏资源库通过创建不正确的包，与OMS版本不兼容。
4。在一个多OMS设置，post_install_script.sql或post_deinstall_script.sql需要只执行一次。
5。如果检测到冲突，应用补丁时，并不适用于它。联系Oracle支持，以获得一个意见。

6。下面的流程图说明了建议的步骤：
只要有可能，我们建议冲突的前期和联系Oracle支持合并补丁检查，如果检测到冲突。一个非常有趣的命令检查的冲突，不应用此修补程序的最新版本的opatch。这就是：
opatch习得条件CheckConflictAgainstOHWithDetail- phBaseDir
在此命令的更多细节，可以发现在Note458485.1
如果此命令不会报告任何冲突，那么它是安全的，适用于存储在目录中的补丁。
如果报告的冲突，而不是：
一），如果你可以等待运用这个新的补丁，请联系Oracle支持和要求合并带来的所有修复的补丁。确保包括opatch命令完成以上输出。然后申请合并补丁一经面世。
B）如果您不能等待，确实需要适用于这个新的补丁，然后手动回滚所有冲突的修补程序，按照他们的自述，然后才能申请新的补丁。这将避免任何不一致。

7。如果需要opatch回滚修补程序？
如果你还是回答“是”，“你要继续”，虽然opatch发现了一些冲突的问题，然后有一些补丁不会回滚正确的机会。那么解决的办法是：
*回滚补丁目前应用（说修补程序A），以下的自述所有的手动步骤
*每个补丁报告冲突与修补程序A的运行post_deinstall_script.sql
*重新申请一个补丁，包括手动步骤。
其他注意事项
1。这个问题是不特定的PSU。它可以发生之间接触的库文件任何补丁程序。由于电源是相当大的，冲突的机会是较高的，这就是为什么这种情况下，更可能发生与PSU。
2。并非所有OMS补丁程序程序包含的文件，需要对仓库运行。但是，甲骨文仍然强烈建议仔细阅读每一个特定的安装/卸载说明的修补程序自述文件。
3。本说明中描述的修补潜在问题可能会发生，每当有opatch后执行手动步骤。我们说明了最常见的情况与运行SQL脚本后opatch的问题，但事实上，任何手动步骤可能会导致问题，如果不手动回滚恢复。
参考文献

显示附件附件

显示相关信息

产品

关键词：