|
Data Guard 配置包含一个数据库作为主角色以及一个或更多数据库作为备角色典型地每个数据库的角色不会更改然而如果Data Guard 是用于维护对主数据库停机响应的服务你必须在配置中发起当前主数据库和一个备数据库之间的角色转换要查看数据库的当前角色查询V$DATABASE 视图中的DATABASE_ROLE 列 在 Data Guard 配置中的备数据库的数量位置和类型（物理或逻辑）以及重做数据以哪种方式从主数据库传送到每个备数据库决定了你用于响应主数据库停机可用的角色管理选项 一角色转换介绍 数据库操作于下面互斥的角色之一主或备Data Guard 允许你通过执行本章中描述的SQL 语句或通过使用任何一个Data Guard broker 界面来动态更改这些角色Oracle DataGuard 支持下述角色转换 * 切换 允许主数据库切换角色到它的备数据库之一在切换期间没有数据丢失在切换之后每个数据库继续以其新的角色参与在Data Guard 配置中 * 故障转移 更改备数据库到主角色响应主数据库的故障如果主数据库在故障之前没有操作在最大保护模式或最大可用性模式可能发生数据丢失如果在主和备数据库上都允许Flashback数据库一旦故障的原因更正了故障的数据库可用恢复作为新的主数据库的备库 准备角色转换（故障转移或切换） 在开始任何角色转换之前执行下述准备 * 对每个数据库检查初始化参数是否正确配置 * 检验将成为新的主数据库的备数据库是操作于 ARCHIVELOG 模式 * 确保存在于备数据库的临时文件符合在主数据库上的临时文件 * 删除任何在应用重做中的延迟这可能会影响将会成为新的主数据库的备数据库 * 检验在 Real Application Clusters 配置中的备数据库上除了一个RAC 实例以外都关闭? 对于 Real Application Clusters 数据库在角色转换过程中备数据库上只有一个RAC实例能联机在开始角色转换之前关闭所有其它实例然后在角色转换完成后将这些实例联机 注即使在切换期间备数据库上只有一个RAC 实例是打开的所有其它备数据库实例在打开时还将自动经历一个正确转换到它们的新角色的过程 为角色转换选择目标备数据库 对于使用多个备数据库的 Data Guard 配置当为角色转换选择目标备数据库时需要考虑许多因素包括如下 * 备数据库的本地性 * 备数据库的能力（硬件规格——如 CPU 数目可用I/O 带宽等等） * 执行角色转换所需的时间这受离备数据库后面多远（用重做数据的应用衡量）以及你有多大的灵活性（用应用可用性与数据丢失的折衷衡量）的影响 Data Guard 提供了V$DATAGUARD_STATS 视图能用于估计每个备数据库的生存能力用备数据库中数据的流通衡量以及如果所有可用的重做数据库应用到备数据库执行角色转换所需的时间例如 SQL> COLUMN NAME FORMAT A SQL> COLUMN VALUE FORMAT A SQL> COLUMN TIME_COMPUTED FORMAT A SQL> SELECT * FROM V$DATAGUARD_STATS; NAME VALUE TIME_COMPUTED apply finish time + :: MAY :: second() interval apply lag + :: MAY :: second() interval transport lag + :: MAY :: second() Interval 这显示了对于这个备数据库没有传输延迟日志应用服务没有应用在过去的 秒中生成的重做（apply lag）日志应用服务将使用 秒来完成应用未应用的重做（apply finishtime）在每个统计的时间在TIME_COMPUTED 列中显示如果配置包含物理和逻辑备数据库考虑选择物理备数据库作为目标备数据库向物理备数据库的切换或故障转移是更可取的因为在角色转换完成后配置中的所有数据库对于新的主数据库作为备数据库是可行的然而切换或故障转移到逻辑备数据库将会使其它物理备数据库对于原主数据库无效然后在能够重允许物理备数据库之前你将需要从新的主数据库的备份重建物理备数据库 切换 切换典型地用于在计划的停机期间减少主数据库宕机时间如操作系统或硬件升级或Oracle 数据库软件和补丁集的滚动升级 切换以两个阶段发生在第一个阶段现有的主数据库经历向备角色的转换在第二个阶段备数据库经历向主角色的转换 图 显示了在数据库角色切换前的两站点Data Guard 配置主数据库位于SanFrancisco备数据库位于Boston
图 在切换前的Data Guard 配置 图 显示了在原主数据库切换到备数据库后但是在原备数据库成为新的主数据库之前的Data Guard 环境在这个步骤Data Guard 配置临时有两个备数据库
图 在切换到新的主数据库之前的备数据库 图 显示了在切换发生后的Data Guard 环境原备数据库成为新的主数据库主数 据库现在位于Boston备数据库现在位于San Francisco
图 切换后的Data Guard 环境 准备切换 确保满足步骤一列出的先决条件另外下面的先决条件必须对切换满足 * 对于包含物理备数据库的切换检验主数据库实例是否打开和备数据库实例是否安装 * 你计划更改到主角色的备数据库在你开始切换之前必须是安装的理想地物理备数据库在数据库角色在切换时也将活动地应用重做如果物理备数据库打开用于只读访问时切换还将发生但是需要额外的时间 * 对于包含逻辑备数据库的切换检验主和备数据库实例是否打开以及 SQL 应用是否活动 对于包含在 Real Applications Cluster 中的主数据库的切换除了一个实例以外所有实例都必须关闭一旦切换成功执行你能将所有其它实例联机 当数据库从一个角色转换到另一个DB_ROLE_CHANGE 系统事件会触发你能写一个触发器关联这个系统事件以在切换发生后管理任务当数据库第一次在切换过后打开时该事件触发不管其新的角色（就是说不管切换导致其第一次作为主数据库作为逻辑备或作为只读模式中的物理备而打开）你能查询V$DATABASE 视图的DATABASE_ROLE列来确定数据库的当前角色 故障转移 只有当主数据库变得不可用并且没有可能在合理的时间期间内还原以提供服务才典型地会使用故障转移在故障转移期间执行的特定操作基于在故障转移中包括的是逻辑或物理备数据库在故障转移的时候Data Guard 配置的状态和用于开始故障转移使用的特定SQL 语句而不同 图 显示了从San Francisco 的主数据库故障转移到Boston 的物理备数据库的故障转移的结果
图 故障转移到备数据库 准备故障转移 如果可能在执行故障转移之前你应该传递尽可能多的可用的和未应用的主数据库重做数据到备数据库 确保满足在 步骤一准备角色转换（故障转移或切换）中列出的先决条件另外对于故障转移下面的先决条件必须满足 * 如果故障转移中包括当前运行在最大保护模式的备数据库首先通过在备数据库上执行下面面语句将其置于最大性能模式 SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; 然后如果有合适的备数据库可用你能在故障转移完成之后在新的主数据库上重新设置期望的保护模式 这是必须的因为你不能故障转移到一个处于最大保护模式中的备数据库另外如果处于最大保护模式中的主数据库还与备数据库有活动联系执行ALTER DATABASE 语句来更改备数据库从最大保护模式到最大性能模式将不会成功因为故障转移将原主数据库从Data Guard 配置中删除了所以这些特性服务于保护操作于最大保护模式中的主数据库不受非故意的故障转移的影响 |
