WINDOWS下的程序员出身，偶尔也写一些linux平台下小程序， 后转行数据库行业，专注于ORACLE和DB2的运维和优化。 同时也是ios移动开发者。欢迎志同道合的朋友一起研究技术。 数据库技术交流群：58308065，23618606
全部博文（599）
分类： Oracle
2009-12-08 13:09:18
作者：Porus Homi Havewala
了解现在为 Oracle DBA 提供的自动修补功能。
2009 年 9 月发布
一直以来，修补就是 Oracle DBA 的众多乐趣（或畏惧）之一。自从 Oracle 问世以来，补丁就一直由 Oracle Support 发布，由 DBA 下载（最初通过邮寄的软盘或 CD），然后应用到目标数据库 — 无论是修复小的数据库错误；应用安全修复程序；还是将数据库从一个补丁版本升级到另一个版本，例如从 7.3.2 升级到 7.3.4，从 8.1.5 升级到 8.1.6 或从 9.2.0.4 升级到 9.2.0.6。
由于现在 Oracle 每季度都发布重要补丁更新 (CPU)，而且数家公司都在试图针对其所有数据库强制应用 CPU 来作为其公司安全策略的一部分，因此 DBA 的责任就是确保其域内的无数个数据库以受控、及时的方式进行修补。
在 Oracle 应用产品中，修补具有全新的含义：Oracle 电子商务套件补丁集是数据库补丁集的一个超集；通常需要多个小时才能应用；并且在许多情况下，如果其工作进程失败，需要重新启动。这些工作进程对电子商务 PL/SQL 代码执行与补丁相关的并行更新，并且是应用大型补丁的首次多任务创新使用之一。但是这仍需要许多 DBA 彻夜不眠地工作，他们手动应用补丁并被迫不断检查错误，以免必须重新启动补丁。
Oracle 真正应用集群 (Oracle RAC) 随 Oracle9i 数据库一同提供。Oracle RAC 是 Oracle 的主动/主动集群数据库，因此补丁应用程序呈现一个新的维度 — 补丁必须在 Oracle 集群件级别应用到每个节点，然后在 Oracle 数据库级别增加手动步骤的复杂性。Oracle 集群件在 Linux 平台上可在 Oracle RAC 9i 中获得，在所有平台上可在 Oracle RAC 10g 中获得，因此 Oracle 集群件现在也包括在修补工作中。
所有这一切加之 DBA 域内的数据库数量不断增加 — 在许多中型和大型企业中，具有数百甚至数千个开发、测试和生产数据库，并且您采用的方法是以极其单调的方式重复费事的、手动的、令人厌烦的步骤，最终总会产生人为错误。自由思考的人脑从不喜欢机器般的千篇一律，因此迟早都会在重复的手动过程中有意识无意识地犯错误。事实是 DBA 不是机器。
总而言之，DBA 的未来充满单调沉闷，他们不断地进行着越来越多的乏味修补工作，直到 Oracle 企业管理器出现。使用 Oracle 企业管理器 10g 网格控制第 5 版中的全新界面和体系结构，首要目的是减轻全球 DBA 的管理负担。
Oracle 企业管理器网格控制通过简化和自动化许多 DBA 日常任务来实现此目的 — 性能管理（诊断和调优）；创建和执行计划的数据库备份；在操作系统和数据库级别执行计划的脚本；创建和使用 Oracle Data Guard 备用数据库；以及服务器、操作系统和数据库的受控配置管理。还可通过直接面对数据库修补的主要难题实现这一点，而数据库修补正是本文的主题。
要为您提供这些不同任务的最佳结果，必须正确构建 Oracle 企业管理器网格控制站点。有关概述，请参见“”，该文章解释了大型中央 Oracle 企业管理器网格控制站点如何管理和监视 600 到 700 个目标，包括数据库、服务器和监听器。
数据库修补功能最初在 Oracle 企业管理器网格控制第 2 版 (10.2.0.2) 中引入，是单独许可的 Oracle 企业管理器供应包的一个特性。本文基于东南亚一家大型金融机构的实际经验，解释了如何实施概念验证 (POC) 以使管理人员和 DBA 相信使用 Oracle 企业管理器网格控制对数千个数据库进行数据库补丁自动化所带来的好处。
这是 Oracle 企业管理器网格控制相比于非 Oracle 数据库管理工具所具有的最强优势之一 — 第三方工具在这一领域甚至无法与 Oracle 企业管理器网格控制相提并论。另外，您为什么还要使用 Oracle 产品之外的工具来管理 Oracle 数据库实例呢？
请考虑已经具有第 5 版补丁的 Oracle 企业管理器 10g 网格控制安装 (10.2.0.5.0)。控制台的主页如图 1 中所示：
您将立即注意到控制台上的信息性消息：
“The Patch Advisory information may be stale.My Oracle Support refresh job has not run successfully in 72 hours.”
单击作业链接 RefreshFromMyOracleSupport 进入作业活动屏幕，您会看到此作业计划每天运行一次。Oracle 企业管理器网格控制站点关闭了几天，因为它是 POC 站点。由于站点关闭，因此作业已经 72 小时未运行了。
此作业将下载 My Oracle Support 中提供的最新补丁建议、产品和产品版本的元数据。它还计算最新重要补丁更新的目标。您必须确保在尝试使用 Oracle 企业管理器网格控制进行任何修补之前运行此作业。要立即运行此作业，请创建副本。从 Job Activity 页面中的 Jobs 下选择 Refresh From My Oracle Support，并单击 Create Like。将这个新作业命名为 ONE-TIME REFRESH FROM MY ORACLE SUPPORT 并提交。作业状态显示此作业正在运行。它通过互联网连接到 My Oracle Support；将数个 XML 文件下载到目录 C:\MetalinkMetadataDump（用户可设置）中；并在几分钟之后完成，此后消息“The Patch Advisory Information may be stale”从 Oracle 企业管理器网格控制控制台的主页上消失 — 此信息已经由此作业更新。
如果 Oracle 企业管理器网格控制站点并未与 My Oracle Support 建立互联网连接（许多公司限制互联网访问），则可以执行脱机更新。OTN 上提供的“”文档中的常见问题解答 8“如果我的 OMS [Oracle 管理服务] 脱机或与互联网断开连接，我如何修补？”中对此进行了解释。
要了解如何执行此操作，可通过单击屏幕上角的 Setup 然后选择 Patching Setup 来查看修补设置。您将看到三个选项卡：
在第一个选项卡 My Oracle Support and Proxy Connection（参见图 2）上，输入到 My Oracle Support 的登录名。将补丁搜索 URL 设置为 Oracle 站点：单击 Test 按钮验证登录成功。
您可以选择直接连接到互联网，如果您的公司允许通过代理服务器连接到互联网，则选择 Manual Proxy Configuration，这将允许您针对 http 和 https 使用代理服务器主机。为每个服务器提供用户名和口令。最后，您可以通过显示的 URL 测试代理连接。
在第二个选项卡 Online and Offline Settings（参见图 3）上，您选择补丁建议的联机或脱机模式。Oracle 企业管理器网格控制服务器可能无法直接或通过代理访问互联网。脱机模式适用于此类情况。
首先必须将 XML 文件从互联网手动下载到工作站：
现在，您可以使用 Online and Offline Settings 选项卡将 XML 文件手动上载到 Oracle 管理服务元数据缓存中。上面显示的 URL 也显示在此选项卡上以供参考。单击 Upload 按钮。
随后，XML 文件将在 Metadata Dump 目录中，此目录也显示在此选项卡上。如果现在运行 RefreshFromMetalink 作业，它将使用这些 XML 文件，并且执行如同它连接到互联网时的操作。
某些公司并未应用最新 CPU。它们的策略可能是应用 Oracle 较早（如六个月之前）发布的 CPU。这是在作为本文示例的金融机构中实施的 POC 的一个重要要求。
原因是较早的 CPU 会更安全，因为其应用时间更长、适用范围更广，诸如此类的机构因其保守的安全策略，通常不愿意应用任何新的软件，包括补丁。
在上一部分描述的事例中，RefreshFromMetalink 作业使用下载的 XML 文件中的信息，这是最新信息，因此与最新 CPU 相关。补丁建议将因此建议最新 CPU 修补，这可能不是公司所希望的。
在这种情况下，建议定期下载 XML 文件，并将它们放在 DBA 工作站上手动创建的目录中或通用 DBA 网络目录中。然后，可以根据需要将它们上载到 Oracle 管理服务中，从而控制补丁建议实际考虑哪个 CPU。确保在 Setup -> Patching Setup 下将设置更改为 Offline in Online and Offline Settings。上载较旧的 XML 文件集将强制建议考虑相应的较旧 CPU 以满足 POC 的这一要求。
第三个选项卡是 Linux Patching Setup（参见图 4），您可以在其中使用 Oracle 坚不可摧的网络针对 Linux 服务器执行操作系统级 RPM 修补。（本文不讨论操作系统级修补。）
确认 RefreshFromMetalink 作业成功运行。在 Oracle 企业管理器网格控制控制台的主页上，单击 Patch Advisories，转至 RefreshFromMetalink 作业的计算结果，如图 5 中所示。
在 Patch Advisories 选项卡上，最新发现是 Critical Patch Update 2009，它影响四个不同的主目录。单击 Critical Patch Update 链接转至 My Oracle Support 中发布的补丁文档（当您提供您的登录详细信息之后）。
实际补丁号在 Interim Patches to Apply 部分中列出。在此部分中，您会看到通过“Critical Patch Update April 2009”建议用于 Oracle 数据库 11.1.0.6 的补丁是 8333655。在 My Oracle Support 文档中验证此补丁 — 此补丁号是用于 Windows 平台的正确编号。
其他选项卡 Affected Homes（参见图 6）和 Remedies（参见图 7）是相关的，使您能够在 Oracle 企业管理器网格控制目标中指定任一主目录；选择 Affected Homes；单击 Show Remedies 可从 Affected Homes 选项卡转至 Remedies 选项卡，并列出适用于此主目录的补丁（参见图 7）。
您可以看到，补丁 8333655 是用于 11.1.0 主目录的补救办法。在此选项卡上，单击 Show Remedy Details 转至 Remedy Details 屏幕（图 8）。
在此屏幕上，单击 Apply Selected Patch 启动补丁向导（图 9），此向导将引导您完成修补此主目录的步骤。
在补丁向导中，在为您提供的谨慎控制的步骤中，您必须首先选择补丁,选择目标,设置凭证，然后要求存放补丁（补丁下载到 Oracle 主目录的子目录中）或同时存放和应用补丁，计划整个作业，最后确认汇总屏幕上的详细信息（参见图 10）。
在此过程中，Oracle 要求您提供电子邮件地址，这样它可以通知您配置中的任何安全问题。然后计划作业。作业将根据您的设置（在适当的时间运行或者立即运行）启动其运行（参见图 11）。
您还会发现作业在 Oracle 企业管理器网格控制的 Jobs 选项卡上运行。它执行一系列步骤，例如下载和缓存补丁文件，然后将其存放到数据库中，查找 OPatch 实用程序以将补丁应用到数据库，关闭数据库，应用补丁，并启动数据库。最后，作业成功完成，修补了数据库。
然而，使用特定的方法安装补丁不是一个好主意 — CPU 建议到补丁向导的流程不是推荐的流程。这种修补数据库的方法仅适用于在单个数据库上应用单个补丁，灵活性或可自定义性不是很好，将来最终会被取代。
要使用诸如多个补丁应用、补丁流自定义、sudo 以及可插入认证模块 (PAM) 支持之类的高级特性，您必须使用功能极其强大的新部署过程功能（将在接下来的部分中讨论）。
强烈建议使用部署过程功能，因为它能够使用多个补丁在不同目标上修补多个主目录，并且还允许您自定义部署过程中包含的步骤。
要使用部署过程，可以从 CPU 建议中选择补丁号，单击 Patch 按钮，然后选取 Deployment Procedures。要使用部署过程，请从 Oracle 企业管理器网格控制控制台中选择 Deployments 选项卡。在 Patching 下，单击 Patching through Deployment Procedures（参见图 12）。将显示 Oracle 提供的部署过程列表（参见图 13），以及您可能通过仅复制一个过程并修改组成步骤而创建的所有自定义过程。
在第一种情况中，选择提供的 Patch Oracle Database 过程。单击 View 按钮查看部署过程中的步骤（参见图 14）。这是使用重要补丁更新、临时补丁和补丁集修补独立 Oracle 数据库安装的过程。但是，此过程不支持重大升级，例如从 11.1 升级到 11.2。
您在图 14 中可以看到，部署过程步骤包含各种活动，例如可选择性升级 OPatch 实用程序；存放补丁；启动 Oracle 企业管理器中断（以便此计划 停机不会引起警报）；停止数据库；应用补丁；在适用的情况下运行 root 脚本；以升级或迁移模式启动数据库；在适用的情况下应用 SQL 脚本（如果它是补丁集或 CPU）；应用 SQL 后脚本；停止数据库；重新启动数据库；应用更多的 SQL 脚本；停止中断；以及最后刷新主机配置集合 — 尤其注意最后一步。
单击 Schedule Deployment 将转至一系列向导页面（参见图 15），您需要在这些页面中指定要应用的软件更新（一个或多个）、部署的目标列表（一个或多个）、凭证、计划以及其他详细信息。
在第一个页面上，指定存放位置，默认设置为 %emd_root%/EMStage。如果此 Oracle 企业管理器网格控制安装位于 Windows 上，此位置为 C:\OracleHomes\agent10g\EMStage 目录。
在 Standalone Database Updates 部分中实际选择要应用的补丁。单击 Add 将显示一个屏幕（参见图 16），您可以在其中选择 Search My Oracle Support 或 Search Software Library，后者是已经直接从 My Oracle Support 下载或手动下载的补丁列表。（手动下载补丁将在本文后面部分介绍。）
选择版本和平台并单击 Go 按钮，将显示适用的补丁列表。在此列表上，您可以快速找到 8333655 补丁 — ORACLE 11G 11.1.0.6.0 PATCH 16 BUG FOR WINDOWS 32B — 我们在补丁建议中看到的 CPU 补丁。选择此补丁。
返回第一个页面，指定还应该升级 OPatch 实用程序。您还可以指定应该应用补丁的默认 SQL 脚本还是任何特定的 SQL 脚本。在下一个页面上，选择要修补的数据库目标。在此，您可以选择位于公司站点上的多个服务器上的多个数据库目标。
然后，下一个页面请求要向其发送安全更新和有关安全问题的信息的电子邮件地址，并要求 My Oracle Support 帐户口令。
之后，您需要为所有主目录和主机指定凭证，然后计划部署过程立即发生或以后发生。这使您能够通宵运行数个数据库的修补（开发或测试数据库上的修补经过正确测试之后）。
接受汇总页面后，将立即计划部署过程。单击部署过程以显示其运行步骤的状态（图 17）。
您可以通过转至 Deployments 选项卡，选择 Patching through Deployment Procedures，然后选择 Procedure Completion Status 来随时查看作业。您将看到正在运行的部署过程（参见图 18）。
请注意，当部署过程运行时，某些作业任务（例如升级 OPatch）也在 Oracle 企业管理器网格控制的 Jobs 选项卡上显示，它们作为单独的作业运行并完成。但是，主要部署过程作业仅在 Procedure Completion 状态屏幕上作为一个整体可见。
部署过程在 Unix 平台上的运行通常是成功的。然而，在 Windows 平台上的首次运行，部署过程运行的某些步骤显示已失败。例如，图 19 表明 Iterates over a list of Hosts 步骤已失败。
如果您探究下去，将能够看到哪里出现了故障。在此示例中，故障出现在 Apply Patches 步骤，输出日志（当您一直探究时，将显示此日志）显示如下：
Output Log Step is being run by operating system user : 'sisystemsporushh' Run privilege of the step is : Normal This is Provisioning Executor Script(Windows) … Directive Type is SUB_Perl … The output of the directive is: … Tue Jun 2 00:37:40 2009 - Found the metadata files; '8333655' is an Interim patch … Tue Jun 2 00:37:40 2009 - OPatch from 'C:/app/porushh/product/11.1.0/db_1/OPatch/opatch.pl' will be used to apply the Interim Patch. … Tue Jun 2 00:37:57 2009 - Invoking OPatch 11.1.0.6.6 … Following patches will be rolled back from Oracle Home on application of the patches in the given list : 7210195 … Do you want to proceed? [y|n] Y (auto-answered by -silent) User Responded with: Y OPatch continues with these patches: 8333655 Do you want to proceed? [y|n] Y (auto-answered by -silent) User Responded with: Y Running prerequisite checks... Prerequisite check "CheckActiveFilesAndExecutables" failed. The details are: Following files are active : C:\app\porushh\product\11.1.0\db_1\bin\oci.dll UtilSession failed: Prerequisite check "CheckActiveFilesAndExecutables" failed. … OPatch failed with error code = 73 Apply of Interim Patch(es) failed Tue Jun 2 00:37:57 2009 - Patching failed.
这表明 OPatch 已经失败，因为 11g 数据库主目录中的 oci.dll 文件被锁定。这是在 Windows 中进行修补时的常见问题 — 操作系统经常由于 Windows 性能原因而在内存中将 DLL 文件保存未指定的时间，即使在使用这些文件的程序已经终止后。（DLL 文件 是 Microsoft 的共享库概念的实施。）
我们的金融机构使用第三方实用程序 ProcessExplorer，它发现此文件已经由 Windows 进程 svchost（服务主机）锁定。多个 svchost 进程在运行。查看哪个 svchost 副本运行哪个服务涉及在命令窗口中使用 tasklist /svc。
最终有效的解决方案是在由部署过程停止数据库和监听器之后，使用另一个第三方实用程序 Unlocker 来解除 oci.dll 的锁定。确保您在进行解除锁定之前退出进程资源管理器，因为进程资源管理器本身将锁定其他 DLL。以下是金融机构使用的步骤：
部署过程的真正目的是自动化，因此可以并且应该避免手动调整此性质。这些问题被记录为已知问题，并且可以通过部署过程的灵活性处理它们。Oracle 使我们能够自定义部署过程，并且修改或添加更多的步骤。
部署过程的灵活性在特殊情况下很有用，这些特殊情况包括插入客户步骤（例如发送电子邮件）、在补丁应用程序之前添加备份、派生 cron 或通过变通方法处理已知问题。然而，这些不是典型要求。
在本文的第二部分中，部署过程将自定义为解决锁定 DLL 文件的 Windows 问题。
Oracle 企业管理器网格控制提供的部署过程灵活性很高，用于使用多个补丁修补 Oracle 数据库并自定义补丁流。正如本文前面所讨论的那样，Oracle 企业管理器网格控制中的 Patch Oracle Database 部署过程已经在 Apply Patches 步骤失败，因为操作系统 (Windows) 已经锁定 Oracle 主目录的 bin 子目录下的 oci.dll 文件。
在执行 Apply Patches 步骤之前，需要解除 oci.dll 文件的锁定。在命令行上使用第三方 Unlocker 实用程序来解除 oci.dll 的锁定的另一个命令是
cmd -c "c:; "\Program Files\Unlocker"\Unlocker C:\app\porushh\product\11.1.0\db_1\bin\oci.dll -S"
要将此步骤添加到实际修补流程中，可以执行以下操作：
选择 Deployments -> Patching through Deployment Procedures。在 Deployment Procedure Manager 下的过程列表中，选择预先提供的 Patch Oracle Database 过程，然后单击 Create Like，这使您能够创建自定义部署过程。
在自定义过程中，您可以更改各种内容，例如将触发通知的过程状态以及每个过程步骤的错误处理模式 — 无论是出现错误时停止还是出现错误时继续。此外，您可以在自定义过程中轻松删除步骤或插入步骤。
选择 Apply Patches 步骤，并单击 Insert 按钮。您现在可以添加 Unlock oci.dll in Windows 步骤以执行主机命令（参见图 20）。然后，单击 Save 按钮以保存整个新的自定义部署过程。
现在可以像以前那样计划自定义部署过程。它成功运行并应用补丁（参见图 21），而不会受到 Windows 锁定的干扰。我们看到 Unlock oci.dll in Windows 和 Apply Patches 步骤均已成功。
上文已经详细介绍了 Oracle 企业管理器网格控制中的部署过程的强大功能，通过自定义可以解决许多问题（例如 Windows 锁定），并且 Oracle 企业管理器网格控制成为真正功能强大的工具，可在大型公司设置中实现数据库补丁自动化。
现在，在 Oracle 主目录中的命令行上执行 OPatch 显示新应用的补丁已经在 Oracle 清单中注册：
C:\>cd \ C:\>set ORACLE_HOME=C:\app\porushh\product\11.1.0\db_1 C:\>set ORACLE_SID=FINPRD1 C:\>cd C:\app\porushh\product\11.1.0\db_1\BIN C:\app\porushh\product\11.1.0\db_1\BIN>opatch lsinventory Invoking OPatch 11.1.0.6.0 Oracle Interim Patch Installer version 11.1.0.6.0 Copyright (c) 2007, Oracle Corporation. All rights reserved. …. Installed Top-level Products (1): Oracle Database 11g 11.1.0.6.0 There are 1 products installed in this Oracle Home. Interim patches (1) : Patch 8333655 : applied on Tue Jun 02 16:21:48 SGT 2009 Created on 20 Mar 2009, 12:29:01 hrs US/Pacific Bugs fixed: ….. OPatch succeeded.
如果公司策略阻止 Oracle 企业管理器网格控制安装直接连接到 My Oracle Support 并下载实际 补丁，您可以选择将所需补丁手动下载到工作站，然后将其上载到 Oracle 企业管理器网格控制软件库和补丁缓存中。
此过程在 OTN 上的“”文档中的常见问题解答 8“如果我的 OMS 脱机或与互联网断开连接，我如何修补？”中有所记录。
您可以通过 Oracle 企业管理器网格控制控制台上的 Deployments 选项卡执行此操作。在 Patching 部分中，单击 View/Upload Patch。在显示的 Patch Cache 屏幕上，您会看到已经手动上载或从 My Oracle Support 自动下载的补丁列表。
要手动上载您没有看到的补丁，请单击 Upload Patch。在显示的屏幕（参见图 22）上，您必须手动填充补丁的所有详细信息。
如果您要上载 OPatch 补丁，请针对 Product Family 域选择 Oracle System Management Products，针对 Product 域选择 Universal Installer。对于数据库补丁（例如此 CPU），针对 Product Family 和 Product 都选择 Oracle Database。您可以看到此过程在“”文档中的常见问题解答 6“升级 OPatch 意味着什么？”中有所记录。
填充详细信息之后，单击 Upload 按钮。将上载补丁，现在补丁显示在软件库和补丁缓存列表中（参见图 23）。
从现在开始，当您计划部署过程并要选择应用的补丁时，您已经上载的补丁将在搜索软件库时显示。这样，您便获得与使用到 My Oracle Support 的直接连接相同的效果，而且只需几个额外的手动步骤，但您遵守了公司安全性的规则（使公司满意）。
要删除现有补丁，必须将其从补丁缓存列表（图 23 中所示）以及软件库中删除。要访问软件库，请转至 Deployments，在屏幕顶部的蓝色栏上单击 Provisioning 子选项卡。展开 Oracle Software Updates 以查看补丁组件。选择补丁组件并单击 Delete（参见图 24）。
然后，还必须从信息库中清除此组件，以便二进制文件不会继续占用文件系统上的空间。清除工具位于同一屏幕上的 Administration 选项卡中。
Oracle 企业管理器网格控制提供了一个与数据库修补相关的详尽报告集。在 Reports 选项卡上，查看 Oracle Home Patch Advisories 部分。“Applied Interim Patches”报告显示了跨所有主机目标在 Oracle 主目录上应用的临时补丁，并且包括最近在 POC 中应用的 CPU 补丁。此报告基于 Oracle 企业管理器网格控制信息库数据库中的 Oracle 企业管理器网格控制 MGMT$APPLIED_PATCHES 信息库视图。
但是，在 POC 的迭代测试中，发现当执行部署过程时，如果修补数据库的 Apply Patches 步骤完成，则 Oracle 企业管理器网格控制 MGMT$APPLIED_PATCHES 信息库视图不会使用应用的补丁进行更新，直到整个部署过程完成之后。
因此，如果部署过程中后面的步骤失败，整个作业将标记为失败，并且将不会更新 Oracle 企业管理器网格控制信息库“应用的补丁”视图，即使数据库本身已经修补（您可以通过在操作系统提示符下运行 opatch lsinventory 进行验证）。
POC 团队曾争论过视图是否应该在修补步骤完成后立即更新，而不是直到最后一步才更新。了解了部署过程及其与视图的交互方式之后，此问题才最终得以解决。
MGMT$APPLIED_PATCHES 视图从信息库中的以下四个表中收集信息：mgmt_inv_container con、mgmt_ecm_snapshot snap、mgmt_inv_patch patch 以及 mgmt_targets tgt。视图的定义如下：
CREATE OR REPLACE FORCE VIEW
"SYSMAN"."MGMT$APPLIED_PATCHES"
("PATCH", "BUGS", "INSTALLATION_TIME", "HOST", "HOME_LOCATION",
"HOME_NAME", "CONTAINER_GUID", "TARGET_GUID")
AS
SELECT
to_char(patch.id) as patch, ecm_util.concat_col('distinct BUG_NUMBER',
'mgmt_inv_patch_fixed_bug', 'PATCH_GUID = ''' || patch.patch_guid || '''',',') as bugs,
patch.timestamp as installation_time, tgt.target_name as host,
con.container_location as home_location, con.container_name as home_name,
con.container_guid, tgt.target_guid
FROM
mgmt_inv_container con,
mgmt_ecm_snapshot snap,
mgmt_inv_patch patch,
mgmt_targets tgt
WHERE
con.snapshot_guid = snap.snapshot_guid AND
snap.is_current = 'Y' AND
snap.snapshot_type = 'host_configuration' AND
con.container_guid = patch.container_guid AND
tgt.target_name = snap.target_name
WITH READ ONLY;
视图有一条 WHERE 子句“snap.is_current = 'Y' AND snap.snapshot_type = 'host_configuration'”。这表明为什么没有更新补丁信息：部署过程中的最后一步是 Host configuration collection。这最后一步负责刷新主机配置。如果前面的一个步骤失败，部署过程将停止并且永远不会达到最后一步，除非您将过程的后面步骤自定义为“continue on error”。默认值为“stop on error”。
还可以手动刷新主机配置 (Deployments -> Refresh Host Configuration)。否则，每 24 小时自动刷新一次。如果使用 OPatch 应用补丁 — 即，如果您要立即更新视图，则必须在 Oracle 企业管理器网格控制之外的 UNIX 或 DOS 提示符下手动运行 Refresh Host Configuration 作业，否则信息只有在 24 小时之后才可用于视图。
金融机构的 POC 测试之一指定如下：“检查 Oracle 企业管理器网格控制是否可以建议 9.2.0.x 数据库需要在应用 CPU 之前至少升级到 9.2.0.8。”这意味着如果要安装建议的 CPU（临时补丁），则测试需要知道 Oracle 企业管理器网格控制是否还将建议 CPU 需要 9.2.0.8 补丁集。
POC 团队安装 9.2.0.1，创建数据库，并将此数据库作为目标添加在 Oracle 企业管理器网格控制中。执行 RefreshFromMetalink 作业以确保关键补丁建议最新。
从 Oracle 企业管理器网格控制控制台主页中，在 Critical Patch Advisories for Oracle Homes 下单击 Patch Advisories。选择 Affected homes、Oracle9i 主目录，然后选择 Show Remedies。这将显示图 25 中所示的屏幕。
这表示补丁建议将建议在应用 4 月 CPU 之前升级到 9.2.0.8，从而满足此 POC 测试的要求。
POC 的最后一个要求是有关企业中任何主机上的每个 数据库上已应用临时补丁的报告。因为 Oracle Home Patch Advisories 部分中的报告显示在主机上的所有 Oracle 主目录上应用的补丁，POC 要求可能仅通过报告自定义来满足，这可在 Oracle 企业管理器网格控制中轻松实现。
提供的报告显示补丁、已修复的错误、安装时间、主机、主目录
以及平台，但是没有显示数据库，因为补丁实际在 Oracle 主目录级别而不是数据库级别。如果要添加数据库名称，可通过创建副本然后修改 SQL 语句来修改报告。例如，“Applied Interim Patches”报告使用以下可修改的 SQL 语句：
SELECT distinct
patch as PATCH,
bugs as BUGS,
installation_time as TIMESTAMP,
host as HOST,
home_location as HOME_DIRECTORY,
platform as PLATFORM
from mgmt$applied_patches patch,
mgmt$em_homes_platform home,
mgmt$target tgt
where home.HOME_ID = patch.CONTAINER_GUID
and patch.target_guid = tgt.target_guid
and patch.installation_time>MGMT_VIEW_UTIL.ADJUST_TZ(??EMIP_BIND_START_DATE??,??EMIP_BIND_TIMEZONE_REGION??,tgt.TIMEZONE_REGION)
and patch.installation_time<= MGMT_VIEW_UTIL.ADJUST_TZ(??EMIP_BIND_END_DATE??,??EMIP_BIND_TIMEZONE_REGION??,tgt.TIMEZONE_REGION)
您可以将此语句加入到 mgmt$target_components（它与 mgmt$applied_patches 具有相同的主目录），然后选择属于此主目录中的数据库的目标。
通过这种策略，将 Oracle 企业管理器网格控制自定义报告创建为“Applied Interim Patches (Customized - Database Level)”。以下是此报告中使用的 SQL：
SELECT distinct
patch as "Applied Interim Patch",
installation_time as "Time Applied",
tgtcomp.target_name as "Database Target Name",
patch.home_location as "Oracle Home Directory",
patch.home_name as "Oracle Home Name",
host as Host
from mgmt$applied_patches patch,
mgmt$em_homes_platform home,
mgmt$target tgt,
mgmt$target_components tgtcomp
where home.HOME_ID = patch.CONTAINER_GUID
and patch.target_guid = tgt.target_guid
and tgtcomp.home_name = patch.home_name
and tgtcomp.target_type = 'oracle_database'
and patch.installation_time>MGMT_VIEW_UTIL.ADJUST_TZ(??EMIP_BIND_START_DATE??,??EMIP_BIND_TIMEZONE_REGION??,tgt.TIMEZONE_REGION)
and patch.installation_time<= MGMT_VIEW_UTIL.ADJUST_TZ(??EMIP_BIND_END_DATE??,??EMIP_BIND_TIMEZONE_REGION??,tgt.TIMEZONE_REGION)
order by installation_time desc
报告中的列标题已经更改，报告定义中的样式化文本也已从 INSTR_APPLIED_PATCHES_ALL_HOSTS 更改为以下自定义行：
“The report shows the interim patches applied on Oracle Databases across all the hosts in the last 31 days.Use the time period selector to view the interim patches applied within a time-period.Thanks.”
运行这个新的自定义报告的结果如图 26 中所示。现在显示应用到每个数据库的临时补丁，因此满足 POC 要求。
POC 团队还创建了“Applied Interim Patches (Customized - Database Level and Select which Database)”报告，此报告还允许选择单个数据库。
以下是用于此报告的 SQL 语句：
SELECT distinct
patch as "Applied Interim Patch",
installation_time as "Time Applied",
tgtcomp.target_name as "Database Target Name",
patch.home_location as "Oracle Home Directory",
patch.home_name as "Oracle Home Name",
host as Host
from mgmt$applied_patches patch,
mgmt$em_homes_platform home,
mgmt$target tgt,
mgmt$target_components tgtcomp
where home.HOME_ID = patch.CONTAINER_GUID
and patch.target_guid = tgt.target_guid
and tgtcomp.home_name = patch.home_name
and tgtcomp.target_type = 'oracle_database'
and tgtcomp.target_guid = ??EMIP_BIND_TARGET_GUID??
and patch.installation_time>MGMT_VIEW_UTIL.ADJUST_TZ(??EMIP_BIND_START_DATE??,??EMIP_BIND_TIMEZONE_REGION??,tgt.TIMEZONE_REGION)
and patch.installation_time<= MGMT_VIEW_UTIL.ADJUST_TZ(??EMIP_BIND_END_DATE??,??EMIP_BIND_TIMEZONE_REGION??,tgt.TIMEZONE_REGION)
order by installation_time desc
选择数据库目标的行是
and tgtcomp.target_guid = ??EMIP_BIND_TARGET_GUID??
当执行此报告时，它使 DBA 能够从提供的数据库目标列表中选择数据库（图 27 中所示）。此报告现在将显示在指定时间段内仅应用到选定数据库的临时补丁。
这仅是可能在 Oracle 企业管理器网格控制报告中进行自定义的一个示例 — 不仅适用于数据库修补范围，而且还适用于所有其他类型的报告。
您还可以使用新的 Oracle SQL Developer Data Modeler。它可从 OTN ，当前作为独立实用程序安装，在不久的将来很有可能合并到新版本的 Oracle SQL Developer 中。（Oracle SQL Developer 会继续变得更加出色，就像 Oracle 企业管理器网格控制那样！）
Oracle SQL Developer Data Modeler 允许现有 Oracle 数据库实例的反向工程，并且您可以通过选择 File -> Import -> Data Dictionary 对其进行访问。这样，您可以从任一 Oracle9i 数据库、Oracle 数据库 10g 或 Oracle 数据库 11g 导入数据字典，或者甚至从 Microsoft SQL Server 2000 及 2005 数据库、DB2/390 7 及 8 数据库或 DB2/UDB 7 及 8 数据库导入数据字典。
使用 Oracle SQL Developer Data Modeler 在 Oracle 企业管理器网格控制信息库中，尤其在 MGMT$ 视图中对 SYSMAN 模式进行反向工程。然后，您可以了解什么信息以信息库数据模型的形式提供。
2009 年 7 月，Oracle 针对 Oracle 企业管理器 10.2.0.5 发布了一个新的一次性补丁。补丁号 8653501 引入了主要针对补丁自动化特性的修复。这个补丁可以从 My Oracle Support 下载并应用到网格控制 OMS 服务器。还应完成自述文件中的其他步骤。
补丁 8653501 引入了以下补丁自动化增强：
我们的金融机构的大型 DBA 团队过去常常针对数百个数据库手动执行所有数据库管理任务。团队成员对于 POC 向他们显示 Oracle 企业管理器网格控制如何可以帮助其执行持续补丁部署任务的时刻仍记忆犹新。
现在，Oracle 企业管理器网格控制中提供的用于数据库修补的部署过程非常成熟 — 它们使 DBA 能够从 My Oracle Support 中搜索用于任何版本的任何 Oracle 软件的补丁；将选定补丁下载到 Oracle 管理服务主机上的存放区中；然后使用提供的或自定义的部署过程在任何目标数据库上应用补丁。
可以使用 Oracle 企业管理器网格控制计划程序计划随时应用补丁。部署过程自动启动数据库中断（因此不生成警报），关闭数据库，应用补丁，然后再次启动数据库。针对为补丁应用程序选择的其他数据库重复相同的操作。
此外，可以针对以下情况自定义部署过程：需要添加其他步骤或决定不在出现错误时停止等。
DBA 已感受到，如果必须将补丁应用到数百个数据库，则使用部署过程会省去大量手动步骤。对于初学者，请考虑将手动下载的补丁通过 FTP/SCP 下载到数百个服务器所需的时间。
在 Oracle 企业管理器网格控制中，补丁下载一次并存储在中央 Oracle 管理服务主机上的软件组件库中。然后，在部署过程中将补丁自动发送到每个数据库目标主机，其中在目标主机上将补丁放在 Agent Home 下的补丁存放位置（%emd_root%/EMStage，其中 %emd_root% 是目标 Agent Home 位置）。然后从此存放区中，将补丁应用到此目标主机上的相应 Oracle 主目录。因此，部署过程甚至消除了根据需要将每个补丁通过 FTP/SCP 下载到每个服务器的手动工作。
这使 DBA 和管理人员相信 Oracle 已经针对至今在 Oracle 领域中进行修补的手动、冗长的任务，在 Oracle 企业管理器网格控制的 Oracle 供应和补丁自动化包中提供了大量功能。非常简单，这是下一代补丁管理。