Oracle实现高可用性的设计 （1）

2011/10/24 by Leave a Comment

学完本课后，应能完成以下工作：

  • 在环境中设计一个可用性最高的体系结构
  • 确定环境的最佳 RAC 和 Data Guard 拓扑结构
  • 在 RAC 环境中配置 Data Guard 代理配置文件
  • 确定要使用的最佳 ASM 配置
  • 以滚动方式修补您的 RAC 系统

计划外停机的原因

 

在设计高度可用的解决方案时，一个真正的挑战是检查和解决所有可能的停机原因。应考虑计划外停机和计划停机两方面的原因，这一点非常重要。本幻灯片中显示的方案对计划外故障进行了分类，它将故障分类为软件故障、硬件故障、人为错误和灾难。在每个类别标题的下方，列出了与该类别相关的可能的故障原因。

软件故障包括操作系统、数据库、中间件、应用程序和网络故障。其中任何组件发生故障都会导致系统故障。

硬件故障包括系统、外围设备、网络和电源故障。

人为错误是故障的主要原因，包括操作者、用户、数据库管理员和系统管理员的错误。另一种能够导致计划外停机的人为错误类型是蓄意破坏。

最后一类是灾难。这类故障虽然比较少见，但是会对企业造成非常严重的影响，因为这些故障会对运营产生持久的影响。灾难的可能原因包括火灾、洪水、地震、电源故障和爆炸。设计得当的高可用性解决方案应考虑到所有这些因素，尽可能避免计划外停机。

 

计划停机的原因

计划停机同样也可以中断运营，对于那些用户分布在多个时区中的国际性企业尤为如此，有时甚至会中断一整天。在这种情况下，设计一个能够将计划中断降低到最低的系统显得十分重要。如本幻灯片中的方案所示，计划停机的原因包括例行操作、定期维护和新部署。例行操作是指一些频繁的维护任务，包括备份、性能管理、用户管理、安全管理以及批处理操作。

定期维护（如安装补丁程序或重新配置系统）有时是更新数据库、应用程序、操作系统中间件或网络所必需的操作。

新部署是指对硬件、操作系统、数据库、应用程序、中间件或网络进行的重要升级。不仅应考虑执行升级的时间，还要考虑这些更改可能对应用程序整体产生的影响，这一点很重要。

 

Oracle 对停机的解决方案

计划外停机主要是由计算机故障或数据故障造成的，而计划停机主要是由数据更改或系统更改造成的：

  • RAC 可以提供最佳的性能、可扩展性和可用性。
  • 使用快速启动故障恢复可以限制数据库崩溃/恢复时间。数据库可以自行调整检查点处理，以保证所需的恢复时间目标。
  • ASM 会对数据库存储使用联机预配来提供更高的可用性。
  • 闪回能够快速解决人为错误。
  • Oracle Hardware Assisted Resilient Data (HARD) 是一个功能全面的程序，用于防止数据损坏。
  • Recovery Manager (RMAN) 自动执行数据库备份和恢复。数据恢复指导（不支持 RAC）可诊断数据故障并提供修复选项。
  • Data Guard 必须是任何 Oracle DB 灾难恢复计划的基础。
  • 相对于使用 SQL 应用的 Data Guard，Streams 的灵活性和功能都有所增强，因此需要更多的投资和专业知识来维护集成的高可用性解决方案。

 

  • 通过联机重新定义，Oracle DB 可以支持多种维护操作，而不必中断数据库运行或用户更新，也不必访问数据。
  • Oracle DB 会不断增强对动态重新配置的支持，使其适应所需的更改和硬件，而不会中断服务。
  • Oracle DB 将支持以滚动方式将补丁程序以及数据库软件升级应用到 RAC 系统的各个节点。

 

RAC 和 Data Guard 相互补充

RAC 和 Data Guard 可以协同工作以提供系统级、站点级和数据级的保护，从而在不丢失数据的前提下实现高级别的可用性和灾难恢复：

  • 由于可以自动地快速恢复故障（如节点故障和实例崩溃），RAC 可以解决系统故障。
  • 利用不共享磁盘的、能够一致地进行事务处理的主数据库和备用数据库，Data Guard 可以解决站点故障和数据保护问题，因而可以从站点灾难和数据损坏中进行恢复。

注：与使用 SQL 应用的 Data Guard 不同，使用 Oracle Streams 可以在副本上进行更新，并对不同数据库版本的异构平台提供支持。因此，Oracle Streams 可提供一种最快的升级数据库和迁移平台的方法。

 

可用性最高的体系结构

 

RAC 和 Data Guard 为数据库 MAA 解决方案提供了基础。MAA 提供了一个最全面的体系结构，用于缩短因计划中断而导致的停机时间，还会防止和检测计划外的断电，并从该情况中进行恢复。建议的 MAA 包含两个相同的站点。主站点包含 RAC 数据库，辅助站点包含 RAC 中的物理备用数据库和逻辑备用数据库。建议使用相同的站点配置，以确保在进行故障转移或切换后性能不会受到影响。此外，使用对称站点还可使两个站点间的进程和过程保持一致，从而使操作任务更易于执行和维护。

本图显示了相同配置的站点。每个站点都由冗余组件和冗余的路由机制组成，这样即使在发生故障时，也始终可以满足请求。大多数中断情况都是在本地解决的，因而客户机请求始终被路由到负责生产的站点。

如果由于发生严重的中断而执行了故障转移或切换操作，则客户机请求将被路由到另一个负责生产的站点。每个站点都包含一组应用程序服务器或中间层服务器。负责生产的站点将包含一个生产数据库，并使用 RAC 来防止主机故障和实例故障。备用站点将包含一个备用数据库和一个由 Data Guard 管理的逻辑备用数据库。Data Guard 的故障转移和切换功能允许两个站点互换角色。
注：有关详细信息，请参阅以下 Web 站点：http://otn.oracle.com/deploy/availability/htdocs/maa.htm

RAC 和 Data Guard 拓扑结构

  • 在所有站点上运行对称配置的 RAC：

–实例数目相同

–服务首选项相同

  • 在所有站点上运行不对称配置的 RAC：

–实例数目不同

–服务首选项不同

  • 对 RAC 和单一实例的组合进行不对称配置：

–所有站点在 Oracle Clusterware 下运行

–一些单实例站点不在 Oracle Clusterware 下运行

 

可以配置备用数据库以保护 RAC 环境中的主数据库。一般情况下所有类型的组合都会得到支持。例如，可以让主数据库在 RAC 下运行，而让备用数据库作为单实例数据库运行。还可以让主数据库和备用数据库都在 RAC 下运行。

本幻灯片解释了对称环境和不对称环境之间的区别。

如果要创建运行 RAC 的对称环境，则所有数据库的实例数和服务首选项都要相同。作为 DBA，需要以对称方式进行手动配置来确保上述条件得到满足。

但是，如果要受益于 Oracle Clusterware 和 Data Guard 代理的紧密集成，则应确保主站点和辅助站点都在 Oracle Clusterware 下运行，并且两个站点都定义了相同的服务。

注：从 Oracle Database 11g 发行版开始，Data Guard 配置中的主数据库和备用数据库可以具有不同的 CPU 体系结构、操作系统（例如，仅对此组合不提供 EM 支持的物理备用数据库使用 Windows 和 Linux）、操作系统二进制（32 位和 64 位）和 Oracle DB 二进制（32 位和 64 位）。有关最新功能和限制，请参阅 https://metalink.oracle.com/ 上的 Metalink 技术注释 413484.1。

 

 

RAC 和 Data Guard 体系结构

 

尽管完全可以使用“RAC 对单实例的 Data Guard (DG)”配置，但是也可以使用“RAC 对 RAC 的 DG”配置。在此模式下，虽然有多个备用实例可以从主数据库接收重做数据，但只有一个备用实例可以应用由主实例生成的重做数据流。

可以使用多种方式设置“RAC 对 RAC 的 DG”配置，本幻灯片显示了一种可能的均衡配置情况，即每个主实例都使用备用重做日志文件将其重做数据流发送到相应的备用实例。另外，每个主实例还可以将其重做数据流只发送到一个备用实例，而此备用实例也可以将此数据流应用到备用数据库。但是，使用幻灯片中显示的配置可以获得性能方面的好处。例如，假定主实例的重做生成率太高以至于备用端上的单个接收实例无法处理时，就可使用这种配置。进一步假设主数据库使用的是 SYNC 重做传输模式。如果备用数据库上的单个接收实例跟不上主数据库，则主数据库的进度将受到备用数据库的限制。如果负载分布在备用数据库上的多个接收实例中，则不太可能发生这种情况。

如果备用数据库跟得上主数据库，则另一种方法是只使用一个备用实例来接收和应用完整的重做数据流。例如，可以对主实例进行设置，以远程归档为相同的 Oracle Net 服务名。

 

接下来就可以配置其中一个备用节点来处理该服务。之后此实例将从主数据库中接收和应用重做数据。如果需要在该节点上进行维护，则可以在该节点上停止该服务，然后在另一个节点上启动它。此方法使主实例更独立于备用配置，因为这些主实例没有被配置成向某个特定实例发送重做数据。

注：有关详细信息，请参阅《Oracle Data Guard Concepts and Administration》指南。

 

Data Guard 代理 (DGB) 和 Oracle Clusterware (OC) 集成

  • OC 管理站点内的 HA 操作。
  • OC 管理站点内的计划 HA 操作。
  • OC 通知何时需要人工干预。
  • DBA 接收通知。
  • DBA 决定使用 DGB 进行故障转移或切换。
  • DGB 管理站点间的计划 HA 操作。
  • DGB 从 OC 处接收站点间的故障转移、切换以及保护模式更改：

–DMON 通知 OC 停止并禁用站点，保留所有实例或一个实例。

–DMON 通知 OC 根据 DG 站点的角色启用和启动站点。

 

 

DGB 与 Oracle Clusterware 紧密集成在一起。Oracle Clusterware 将管理单个实例，为指定的集群数据库提供无人值守的高可用性。DGB 将在 Data Guard 配置中管理单个数据库（以集群或其它方式），以便在 Oracle Clusterware 无法维持主数据库的可用性时提供灾难恢复。

例如，Oracle Clusterware 会为无法恢复的数据库组和服务组发布 NOT_RESTARTING 事件。这些事件可以通过 Oracle Enterprise Manager、ONS 和服务器端调出获得。作为 DBA，在接收这些事件时，可以决定修改并重新启动主站点，也可以调用 DGB 进行故障转移（如果没有使用快速启动故障转移）。

DGB 可以与 Oracle Clusterware 协同工作，在主数据库上将服务可用性临时挂起，并完成这两个数据库的实际角色更改，在此期间，必要时 Oracle Clusterware 将使用 DGB 正确地重新启动实例，然后在新的主数据库上恢复服务可用性。代理将负责管理基础 Data Guard 配置及其数据库角色，而 Oracle Clusterware 则负责管理取决于这些角色的服务可用性。依靠 Oracle Clusterware 管理服务可用性的应用程序在角色更改时只能在 Data Guard 配置中看到临时暂挂的服务

 

 

快速启动故障转移：概览

  • 快速启动故障转移将对备用数据库实施自动故障转移：

–由站点、主机、存储、数据文件立即脱机或网络故障所触发

–处理并补充 RAC 服务器故障转移

  • 故障转移会在数秒内完成（< 20 秒）

–与集群故障转移类似

  • 原始生产站点在恢复后会自动重新加入配置
  • 由观察程序进程自动进行监视：

–将其放在不同数据中心上的不同服务器中

–Oracle Enterprise Manager 可以在发生故障时将其重新启动

–通过 Oracle Client Administrator 安装

 

快速启动故障转移是 Oracle Data Guard 10g 发行版 2 的一项功能，可以在主数据库丢失时自动、快速并可靠地故障转移到指定的同步备用数据库，无需人工干预即可执行故障转移。此外，在快速启动故障转移之后，原始主数据库在重新连接到配置时，会自动重新配置为新的备用数据库。这样，Data Guard 便可以尽快地在配置中恢复灾难保护。

快速启动故障转移用在 Data Guard 配置中，受 Data Guard 代理的控制，可以使用 DGMGRL 或 Oracle Enterprise Manager 10g Grid Control 进行管理。快速启动故障转移配置中有三个基本参与者：

  • 主数据库，可以是 RAC 数据库。
  • 目标备用数据库，在快速启动故障转移后将变成新的主数据库。
  • 快速启动故障转移观察程序，是合并到 DGMGRL 客户机中的一个独立进程，能够持续监视主数据库和目标备用数据库是否出现了可能的故障情况。基本规则是：在这
    三个参与者中，可以互相进行通信的任何两个参与者都会确定快速启动故障转移的结果。此外，仅在确保不会丢失任何数据的情况下才能进行快速启动故障转移。

 

为了满足灾难恢复要求，应在不同于主数据中心和备用数据中心的位置中安装观察程序。如果指定的观察程序发生故障，则 Oracle Enterprise Manager 可以检测到故障，并且可以将其配置为自动在同一主机上重新启动观察程序。

可以通过安装 Oracle Client Administrator（从 Oracle Universal Installer 中选择“Administrator（管理员）”选项）来安装观察程序。安装 Oracle Client Administrator 将生成一个小型覆盖区，因为观察程序系统上没有包括 Oracle 实例。如果使用了 Oracle Enterprise Manager，则也应在观察程序系统上安装 Oracle Enterprise Manager Agent。

 

Data Guard 代理配置文件

将为每个数据库维护 Data Guard 代理 (DGB) 配置文件的两个副本，以便始终保留一个最后得到的有效配置状态记录。第一次启动代理时，将自动创建配置文件，并使用默认的路径名和特定于操作系统的文件名对其进行命名。

使用 RAC 环境时，DGB 配置文件必须由同一数据库的所有实例所共享。可以通过为该数据库设置以下初始化参数来改写默认的路径名和文件名：DG_BROKER_CONFIG_FILE1、DG_BROKER_CONFIG_FILE2。

可以使用三个可能的选项来共享这些文件：

  • 集群文件系统
  • 裸设备
  • ASM

本幻灯片中的示例说明了一个案例，它将这些文件存储在一个名为 DG1 的 ASM 磁盘组中。还假定您已在 DG1 中创建了一个名为 RACDB 的目录。

 

实时查询物理备用数据库

由于其相对简单、性能较高并提供高级别的数据保护，Data Guard 重做应用（物理备用数据库）已被证明是一种灾难恢复的常用解决方案。从 Oracle Database 11g 开始，重做应用活动期间只能以只读模式打开物理备用数据库。这表示，在需要进行故障转移时可根据最新物理备用数据库在不影响数据保护或延长恢复时间的情况下，运行查询和报表。这样每个物理备用数据库都能够支持生产性使用，甚至在使用备用角色时也是如此。要启用实时查询，请在只读模式下打开数据库，然后发出 ALTER DATABASE RECOVER MANAGED STANDBY 语句。实时查询可提供一个最终的高可用性解决方案，因为它：

  • 对应用程序完全是透明的。
  • 在主数据库和备用数据库上支持 Oracle RAC。尽管重做应用只能在一个 Oracle RAC 实例上运行，但当重做应用在一个实例上运行期间，您可以在只读模式下运行所有实例。
  • 启用查询以返回与主数据库最新结果非常相近的事务处理一致结果。
  • 使您可以使用快速启动故障转移在主数据库出现故障时执行自动快速故障转移。

注：在主数据库和物理备用数据库上 COMPATIBLE 参数必须设置为 11.0.0。

 

Hardware Assisted Resilient Data

 

数据损坏是一种会引起长期中断的问题。目前，检测由 Oracle DB 外的软件或硬件（如 I/O 子系统）引起的损坏的主要方法是 Oracle DB 校验和。但是，在将块通过卷管理器传送至操作系统，然后再传送到磁盘后，Oracle DB 自身将无法再检查正在执行写入的块是否仍然正确。

随着磁盘技术的复杂性的增加，以及如存储区网络 (SAN) 这样的配置变得更常见，主机处理器和物理主轴之间的层数也在持续增多。层数增多后，出现问题的机会也增加了。使用 HARD 计划，存储设备可以验证数据库块的校验和信息。如果经验证在写入操作结束时和写入操作开始时，该块完全相同，则安全性级别将有所提高。

默认情况下，Oracle DB 会自动将校验和信息添加到其块中。这些校验和可由存储设备验证（如果启用了此功能）。如果发现存储设备损坏了块，则设备将记录 I/O 损坏，或者取消 I/O 并将错误报告给实例。

注：在存储设备端启用校验和验证的方式是供应商特定的。本幻灯片中给出的示例使用了 EMC Symmetrix 存储。

 

Oracle Clusterware 滚动升级

  1. unzip p….zip
  2. Disk1 目录中的 runInstaller：

–选择 Oracle Clusterware 主目录安装。

–选择所有节点。

–安装。

  1. 逐一在每个节点上重复以下命令：

–crsctl stop crs

–<crs 主目录>/install/root….sh

 

 

Oracle Clusterware 的所有升级都可以滚动方式执行。此幻灯片描述了操作过程。

在安装新软件后，需要执行步骤 3 中描述的两个命令（按照顺序一次一个节点地执行）。此图显示了停止并运行相应的 root….sh 脚本后的配置演变。

 

 

集群 ASM 滚动升级

1.升级 Oracle Clusterware

2.在一个 ASM 实例中执行以下命令：

ALTER SYSTEM START ROLLING MIGRATION TO 11.2.0.0.0;  

3.逐一在每个节点上重复以下步骤：

a.关闭数据库实例。

b.关闭 ASM 实例。

c.使用 OUI 升级 ASM 软件。

d.重新启动 Oracle Clusterware 和所有相应资源。

4.在一个 ASM 实例中执行以下命令：

ALTER SYSTEM STOP ROLLING MIGRATION;  

 

从 Oracle Database 11g （以及更高发行版）开始，所有 ASM 的升级都可以滚动方式执行。ASM 滚动升级使您可以独立地升级或修补集群 ASM 节点，而不会影响数据库的可用性。幻灯片说明了如何执行从 11.1.0.6 到 11.2.0.0 的假定 ASM 滚动升级。

要执行滚动升级，必须准备相应的环境。如果正在使用 Oracle Clusterware，则在启动 ASM 滚动升级前，必须将 Oracle Clusterware 完全升级到下一个补丁程序或发行版本。

在节点上修补或升级 ASM 软件前，必须将 ASM 集群置于滚动升级模式。这样，便可以开始升级并在多版本软件模式下操作您的环境了。步骤 2 演示了此过程。可以从集群的任意 ASM 实例部分运行此语句。从中运行此语句的实例将验证为目标版本指定的值是否与当前安装的软件版本相兼容。升级开始时，集群 ASM 环境的行为会发生变化，在 ASM 实例上只允许执行以下操作。

  • 装载和卸装磁盘组
  • 对数据库文件执行打开、关闭、调整大小和删除操作
  • 对固定视图和固定程序包进行有限访问

在集群 ASM 环境处于滚动升级模式时，Oracle 会禁用所有全局视图。

您可以使用以下 SQL 功能查询集群 ASM 环境的状态：

SELECT SYS_CONTEXT(‘sys_cluster_properties’, ‘cluster_state’) FROM DUAL;

启动滚动查询后，可逐一对每个节点执行以下操作：

  • 关闭各个 ASM 实例。
  • 使用 OUI 执行软件升级。
  • 节点启动时，已更新的 ASM 实例可以重新加入集群。

将集群 ASM 环境中的所有节点都移植到最新的软件版本，可以按幻灯片中步骤 4 所示，在一个 ASM 实例中结束滚动升级模式。

如果集群 ASM 环境中的所有实例都停止运行，则当任一 ASM 实例重新启动时，重新启动的实例不会处在滚动升级模式。要在实例重新启动后执行升级，必须重新运行命令以重新启动滚动升级操作。

注：在 ASM 实例处于滚动升级模式时，如果某个磁盘脱机，则该磁盘将保持脱机状态，直到滚动升级结束。此外，删除磁盘的计时器会停止，直到 ASM 集群退出滚动升级模式。

 

补丁程序和 RAC 环境

 

 

将补丁程序应用到 RAC 安装是一个使用 OUI 的简单过程。OUI 可以跟踪多个 ORACLE_HOME 部署。这种智能功能会防止应用可能具有破坏性或相冲突的补丁程序集。

在本幻灯片的示例中，一个补丁程序集被应用到了集群数据库中全部三个节点上的 /u01/app/oracle/product/db_1 Oracle 主目录。虽然是在 ex0043 上执行安装，但可以选择任意节点执行此任务。通过 OUI 添加补丁程序集所必须执行的步骤实际上与安装新版本程序的步骤相同，但必须将目录更改为 $ORACLE_HOME/bin。启动 OUI 后，请执行下列步骤：

  1. 选择“Installation from a stage location（从登台区安装）”，然后在“Welcome（欢迎使用）”屏幕上输入相应的补丁程序集源。
  2. 在“Node Selection（节点选择）”屏幕上选择需要添加补丁程序的节点，并确保这些节点全部可用。本例中，三个节点全部被选中，因为三个节点上全部安装了 /u01/app/oracle/product/db_1。
  3. 检查“Summary（概要）”屏幕，确认是否满足每个节点的空间要求。
  4. 继续进行安装并以常规方式监视进度。

OUI 会自动管理安装进度，包括将文件复制到远程节点，就像处理 Oracle Clusterware 和数据库二进制安装一样。

 

产品清单锁

  • OUI 会在节点中存储的产品清单上部署一个定时锁。
  • 此锁可以防止安装更改同时供另一个安装使用的清单。
  • 如果检测到冲突，第二个安装就会暂停，并显示以下消息：

“Unable to acquire a writer lock on nodes ex0044. Restart the install after verifying that there is no OUI session on any of the selected nodes.”

 

 

OUI 有了一项改进，即可以防止具有潜在破坏性的并行安装。此机制还包含对节点中存储的产品清单的定时锁。启动多个并行安装时，OUI 将显示与本幻灯片中所示信息类似的错误消息。在重试之前必须取消安装并等待相冲突的安装完成。

虽然此机制可用于所有安装类型，但如果在示例集群中尝试并行安装补丁程序集，则应查看其运行情况。开始时请使用与先前方案相同的配置。

假设在 ex0043 上启动一个补丁程序集安装，以更新节点 ex0044 和 ex0045 上的 ORACLE_HOME2。在此安装仍运行时，在 ex0044 上启动另一个补丁程序集安装，以更新该节点上的 ORACLE_HOME3。这两个安装能否成功？只要没有任何其它问题（例如节点停机或互连停止），这些进程就不会互相冲突，所以会成功。但如果在 ex0044 上启动补丁程序集安装以更新 ORACLE_HOME3，然后在安装了此 Oracle 主目录的所有节点上为 ORACLE_HOME2 启动并行的补丁程序集安装（使用 ex0044 和 ex0043），则会发生什么情况？在本例中，第二个安装会失败，并显示错误，这是因为 ex0044 上的产品清单已由 ORACLE_HOME3 的补丁程序集安装锁定。

 

 

OPatch 对 RAC 的支持：概览

  • OPatch 支持四种不同的方法：

–修补所有节点：Stop all/Patch all/Start all

–尽可能减少停机时间：Stop/Patch all but one, Stop last, Start all down, Patch last/Start last

–滚动修补：一次一个地执行 Stop/Patch/Start

–本地修补：仅一个 Stop/Patch/Start

  • OPatch 如何选择使用的方法：

If (users specify -local | –local_node)

      patching mechanism = Local

else if (users specify –minimize_downtime)

     patching mechanism = Min. Downtime

     else if (patch is a rolling patch)

          patching mechanism = Rolling

          else  patching mechanism = All-node

 

在 RAC 环境中 OPatch 支持 4 种不同的修补方法：

  • 作为单一实例修补 RAC（修补所有节点）：在这种模式中，OPatch 先将补丁程序应用到本地节点，然后将补丁程序传播到所有其它节点，最后更新产品清单。在整个修补过程中，所有实例都被关闭。
  • 使用最短停机时间策略修补 RAC（最短停机时间修补方式）：在这种模式中，OPatch 将修补本地节点，请求用户提供节点的子集，并首先修补这些节点。修补了初始的节点子集后，OPatch 将补丁程序传播到其它节点，并最终更新产品清单。停机时间发生在第二个节点子集关闭与已修补的初始节点子集启动之间。
  • 使用滚动策略修补 RAC（滚动修补）：使用这种方法将没有停机时间。修补和启动每个节点时会启动并运行所有其它节点，而不会对系统产生任何干扰。
  • 上面讨论的几种 OPatch 策略都假定所有节点是同时进行修补的。此外，也可以使用 –local 或 –local_node 关键字，在不同时间单独修补每个节点，这样将只修补本地节点或远程节点。

执行 opatch apply 命令时，本幻灯片将显示使用的方法。

注：目前，OPatch 将共享文件系统视为单实例修补。这意味着 OPatch 无法在这种情况下利用滚动修补，因为所有节点都必须被关闭。

 

使用 RAC 滚动升级补丁程序

 

 

仅被标记为与滚动升级相兼容的单个补丁程序支持此方法。
使用滚动 RAC 修补时，已修补的节点和未修补的节点可以同时协同操作。这意味着只有一个节点在进行修补时不能使用。

使用 OPATCH 工具应用滚动 RAC 补丁程序，系统会提示您停止要修补的节点上的实例。首先修补本地节点，然后系统将要求您从列表中选择下一个要修补的节点。修补每个节点时，系统会提示用户何时重新启动已修补的节点比较安全。此循环（提示节点、停止节点上的实例、修补节点以及重新启动实例）一直继续到您停止了该循环或者修补完了所有节点为止。将补丁程序下载到节点后，需要先将其解压缩才能应用。可以检查 Patch_number/etc/config/inventory 文件以确定补丁程序是否标记为滚动的可升级程序。在接近该文件结尾处，一定能看到以下标记：<online_rac_installable>true</online_rac_installable>

需要强调的是，尽管通过滚动补丁程序升级可以在将补丁程序传播到其它节点之前，测试该补丁程序，但最好在测试环境中测试补丁程序，而不要在生产系统上直接进行测试。

注：一些组件无法每次更改一个节点。典型的示例就是数据字典。因为只有一个数据字典，所以需要关闭所有实例。在这些情况下，Oracle Data Guard 和物理备用数据库是推荐使用的解决方案。当然，使用联机修补是用于避免在联机补丁程序可用时停机的建议解决方案。

 

下载并安装补丁程序更新

请参阅 OracleMetaLink Web 站点，查找安装所必需的补丁程序更新。

要下载必需的补丁程序更新，请执行以下操作：

  1. 使用 Web 浏览器登录 OracleMetaLink Web 站点：http://metalink.oracle.com。
  2. 在 OracleMetaLink 主页上单击“Patches and Updates（修补程序与更新）”。
  3. 在“Patches & Updates（补丁程序与更新）”页上，单击“Advanced Search（高级
    搜索）”。
  4. 在“Advanced Search（高级搜索）”页上单击“Product or Product Family（产品或产品系列）”字段旁边的搜索图标。
  5. 在“Search（搜索）”字段中输入 RDBMS Server 并单击“Go（开始）”。在“Results（结果）”标题下选择“RDBMS Server”，然后单击“Select（选择）”。RDBMS Server 将显示在“Product or Product Family（产品或产品系列）”字段中。当前发行版将显示在“Release（发行版）”字段中。

 

下载并安装补丁程序更新

  1. 从“Platform（平台）”或“Language（语言）”字段中的列表内选择平台，然后
    单击“Go（开始）”。任何可用的补丁程序更新都将显示在“Results（结果）”
    标题下。
  2. 单击要下载的补丁程序的编号。
  3. 在“Patchset（补丁程序集）”页上单击“View README（查看自述文件）”，并阅读显示的页面。“README（自述文件）”页中将包含有关补丁程序集的信息，以及如何将补丁程序应用到安装中。
  4. 返回“Patchset（补丁程序集）”页面，单击“Download（下载）”，然后将文件保存在系统中。
  5. 使用随 Oracle Database 10g 提供的 unzip 实用程序解压缩从 OracleMetaLink 下载的 Oracle 补丁程序更新。此解压缩实用程序位于 $ORACLE_HOME/bin 目录中。

 

Filed Under: Oracle

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号