DATAGUARD的角色转换服务。

 

　　Data Guard 配置包含一个数据库作为主角色以及一个或更多数据库作为备角色。典型地，每个数据库的角色不会更改。然而，如果Data Guard 是用于维护对主数据库停机响应的服务，你必须在配置中发起当前主数据库和一个备数据库之间的角色转换。要查看数据库的当前角色，查询V$DATABASE 视图中的DATABASE_ROLE 列。

　　在 Data Guard 配置中的备数据库的数量、位置、和类型（物理或逻辑），以及重做数据以哪种方式从主数据库传送到每个备数据库，决定了你用于响应主数据库停机可用的角色管理选项。

　　一、角色转换介绍

　　数据库操作于下面互斥的角色之一：主或备。Data Guard 允许你通过执行本章中描述的SQL 语句或通过使用任何一个Data Guard broker 界面，来动态更改这些角色。Oracle DataGuard 支持下述角色转换：

　　*   切换

　　允许主数据库切换角色到它的备数据库之一。在切换期间没有数据丢失。在切换之后，每个数据库继续以其新的角色参与在Data Guard 配置中。

　　*  故障转移

　　更改备数据库到主角色响应主数据库的故障。如果主数据库在故障之前没有操作在最大保护模式或最大可用性模式，可能发生数据丢失。如果在主和备数据库上都允许Flashback数据库，一旦故障的原因更正了，故障的数据库可用恢复作为新的主数据库的备库。

　　1、准备角色转换（故障转移或切换）

　　在开始任何角色转换之前，执行下述准备：

　　* 对每个数据库检查初始化参数是否正确配置。

　　* 检验将成为新的主数据库的备数据库是操作于 ARCHIVELOG 模式。

　　* 确保存在于备数据库的临时文件符合在主数据库上的临时文件。

　　* 删除任何在应用重做中的延迟，这可能会影响将会成为新的主数据库的备数据库。

　　* 检验在 Real Application Clusters 配置中的备数据库上除了一个RAC 实例以外都关闭。?

　　对于 Real Application Clusters 数据库，在角色转换过程中备数据库上只有一个RAC实例能联机。在开始角色转换之前关闭所有其它实例。然后，在角色转换完成后，将这些实例联机。

　　注：即使在切换期间备数据库上只有一个RAC 实例是打开的，所有其它备数据库实例在打开时，还将自动经历一个正确转换到它们的新角色的过程。

　　2、为角色转换选择目标备数据库

　　对于使用多个备数据库的 Data Guard 配置，当为角色转换选择目标备数据库时需要考虑许多因素。包括如下：

　　* 备数据库的本地性。

　　* 备数据库的能力（硬件规格——如 CPU 数目、可用I/O 带宽、等等）。

　　* 执行角色转换所需的时间。这受离备数据库后面多远（用重做数据的应用衡量），以及你有多大的灵活性（用应用可用性与数据丢失的折衷衡量）的影响。

　　Data Guard 提供了V$DATAGUARD_STATS 视图，能用于估计每个备数据库的生存能力，用备数据库中数据的流通衡量，以及如果所有可用的重做数据库应用到备数据库，执行角色转换所需的时间。例如：

　　SQL> COLUMN NAME FORMAT A18

　　SQL> COLUMN VALUE FORMAT A16

　　SQL> COLUMN TIME_COMPUTED FORMAT A24

　　SQL> SELECT * FROM V$DATAGUARD_STATS;

　　NAME                    VALUE           TIME_COMPUTED

　　------------------ ---------------- ------------------------

　　apply finish time +00 00:00:02.4 15-MAY-2005 10:32:49

　　second(1)

　　interval

　　apply lag           +00 0:00:04     15-MAY-2005 10:32:49

　　second(0)

　　interval

　　transport lag      +00 00:00:00    15-MAY-2005 10:32:49

　　second(0)

　　Interval

　　这显示了对于这个备数据库，没有传输延迟，日志应用服务没有应用在过去的 4 秒中生成的重做（apply lag），日志应用服务将使用2.4 秒来完成应用未应用的重做（apply finishtime）。在每个统计的时间在TIME_COMPUTED 列中显示。如果配置包含物理和逻辑备数据库，考虑选择物理备数据库作为目标备数据库。向物理备数据库的切换或故障转移是更可取的，因为在角色转换完成后，配置中的所有数据库对于新的主数据库作为备数据库是可行的。然而切换或故障转移到逻辑备数据库将会使其它物理备数据库对于原主数据库无效。然后在能够重允许物理备数据库之前，你将需要从新的主数据库的备份重建物理备数据库。

　　3、切换

　　切换典型地用于在计划的停机期间减少主数据库宕机时间，如操作系统或硬件升级，或Oracle 数据库软件和补丁集的滚动升级。

　　切换以两个阶段发生。在第一个阶段，现有的主数据库经历向备角色的转换。在第二个阶段，备数据库经历向主角色的转换。

　　图 1 显示了在数据库角色切换前的两站点Data Guard 配置。主数据库位于SanFrancisco，备数据库位于Boston。

图 1 在切换前的Data Guard 配置

 

　图 2 显示了在原主数据库切换到备数据库后，但是在原备数据库成为新的主数据库之前的Data Guard 环境。在这个步骤，Data Guard 配置临时有两个备数据库。

图 2 在切换到新的主数据库之前的备数据库

　　图 3 显示了在切换发生后的Data Guard 环境。原备数据库成为新的主数据库。主数

　　据库现在位于Boston，备数据库现在位于San Francisco。

图 3 切换后的Data Guard 环境

　　准备切换

　　确保满足步骤一列出的先决条件，另外，下面的先决条件必须对切换满足：

　　* 对于包含物理备数据库的切换，检验主数据库实例是否打开和备数据库实例是否安装。

　　* 你计划更改到主角色的备数据库在你开始切换之前必须是安装的。理想地，物理备数据库在数据库角色在切换时也将活动地应用重做。如果物理备数据库打开用于只读访问时，切换还将发生，但是需要额外的时间。

　　* 对于包含逻辑备数据库的切换，检验主和备数据库实例是否打开以及 SQL 应用是否活动。

　　对于包含在 Real Applications Cluster 中的主数据库的切换，除了一个实例以外所有实例都必须关闭。一旦切换成功执行，你能将所有其它实例联机。

　　当数据库从一个角色转换到另一个，DB_ROLE_CHANGE 系统事件会触发。你能写一个触发器关联这个系统事件，以在切换发生后管理任务。当数据库第一次在切换过后打开时该事件触发，不管其新的角色（就是说，不管切换导致其第一次作为主数据库、作为逻辑备、或作为只读模式中的物理备而打开）。你能查询V$DATABASE 视图的DATABASE_ROLE列来确定数据库的当前角色。

　　4、故障转移

　　只有当主数据库变得不可用，并且没有可能在合理的时间期间内还原以提供服务，才典型地会使用故障转移。在故障转移期间执行的特定操作基于在故障转移中包括的是逻辑或物理备数据库，在故障转移的时候Data Guard 配置的状态，和用于开始故障转移使用的特定SQL 语句而不同。

　　图 4 显示了从San Francisco 的主数据库故障转移到Boston 的物理备数据库的故障转移的结果。

图 4 故障转移到备数据库

　　准备故障转移

　　如果可能，在执行故障转移之前，你应该传递尽可能多的可用的和未应用的主数据库重做数据到备数据库。

　　确保满足在 步骤一“准备角色转换（故障转移或切换）”中列出的先决条件。另外，对于故障转移，下面的先决条件必须满足：

　　* 如果故障转移中包括当前运行在最大保护模式的备数据库，首先通过在备数据库上执行下面面语句将其置于最大性能模式：

　　SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

　　然后，如果有合适的备数据库可用，你能在故障转移完成之后在新的主数据库上重新设置期望的保护模式。

　　这是必须的，因为你不能故障转移到一个处于最大保护模式中的备数据库。另外，如果处于最大保护模式中的主数据库还与备数据库有活动联系，执行ALTER DATABASE 语句来更改备数据库从最大保护模式到最大性能模式将不会成功。因为故障转移将原主数据库从Data Guard 配置中删除了，所以这些特性服务于保护操作于最大保护模式中的主数据库不受非故意的故障转移的影响。