当前位置:Gxlcms > mysql > Oracle11gDataGuard之角色转换

Oracle11gDataGuard之角色转换

时间:2021-07-01 10:21:17 帮助过:62人阅读

1.1 简介 Data Guard配置包括1个primary角色的数据库和1个或者多个standby角色的数据库,数据库的角色我们可以通过V$DATABASE中DATABASE_ROLE字段来获得。 另外,Data Guard配置中standby库的数量、位置、备库类型以及redo data从主库传到备库的方式,决定了

1.1 简介

Data Guard配置包括1个primary角色的数据库和1个或者多个standby角色的数据库,数据库的角色我们可以通过V$DATABASE中DATABASE_ROLE字段来获得。

另外,Data Guard配置中standby库的数量、位置、备库类型以及redo data从主库传到备库的方式,决定了主库发生停机故障时能采用的角色管理方案。

当数据库运行于Data Guard中primary或者standby这样互斥的角色时,可以通过SQL语句或者Data Guard broker图形界面来动态的更改它们的角色,Data Guard支持的角色转换有Switchover和Failover。

  • Switchover

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

  • Failover

Failover用于更改备库到主库角色以响应原主库的故障,如果主库在故障之前没有运行在最大保护模式或最大可用性模式下,可能发生数据丢失。如果在主、备库都允许闪回数据库,只要故障解决了,原主库可恢复作为新主库的备库。

1.1.1 角色转换准备工作

角色转换前,需要做好以下工作:

1.确保主备库已经正确配置

关于Data Guard 配置的参数、归档模式、standby日志等的配置参详http://blog.csdn.net/u010257584/article/details/51140030,这里略过,standby库的LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_STATE_n必须配置,这样角色转换后,才能接收从新的primary库传过来的REDO数据。

2.查询V$ARCHIVE_DEST_STATUS,确保standby库没有REDO传输错误以及REDO GAPS,比如查询LOG_ARCHIVE_DEST_2:

SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID =2;


当STATUS的值为VALID、GAP_STATUS为NOGAP方可进行下一步。

3.确保主备库的临时文件一致。

4.删除重做应用的所有延迟,因为这可能会影响备库转为主库角色。

5.RAC主库转为物理备库,务必先只保留其中一个RAC实例为OPEN状态,其他的实例都关闭,其他关闭的实例待转换结束后可以重新联机。

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

7.对于运行在real-time查询模式下的物理备库,执行角色转换之前,可以将备库的所有实例启动到mounted而不是open状态,这样可以实现最快的角色转换,并且能在角色转换之前完全终止所有连接到物理备库的用户会话。

1.1.2 选择角色转换的目标备库

对于多备库的Data Guard配置,角色转换时选择目标备库需要考虑诸多因素,包括:

1.备库的位置与备库类型

2.备库的能力(硬件规格,如CPU数目、可用I/O带宽等)

3.执行角色转换所需的时间,这受备库重做数据的应用快慢,以及数据丢失情况下应用程序的可用性。

角色转换目标备库的类型决定了转换后配置中其他备库的角色。对于physical备库,其中一个备库转为primary角色,配置中所有的其他的备库都将变成新primary角色的备库。而对于logical备库,其中一个备库转为primary角色,配置中所有的其他的备库都将变成新的primary角色的备库但是该配置中的物理备库将继续作为旧的primary主库的备库而不保护新的主库。对于后一种情形,如果进行Switchover或者Failover切换回原始主库,那么当前新主库的所有备库将变回原始的角色状态。综上所述,对于包含物理与逻辑备库的配置中,物理备库是最佳的角色转换目标。

Data Guard提供了V$DATAGUARD_STATS视图,该视图包括每个备库的数据流量估值、执行角色转换所需的时间(当所有redo数据都已应用到备库)。

例如:

SQL> COLUMN NAME FORMAT A24

SQL> COLUMN VALUE FORMAT A16  
   
SQL> COLUMN DATUM_TIME FORMAT A24

SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;

查询结果显示,备库接收并应用了主库传来的所有的redo数据。transport lag、apply lag的值是通过主库传来的redo数据估算的,如果主备库之间的连接出现过中断,那么这个值就没有意义。transport lag、apply lag对应的DATUM_TIME列的值如果没有变化,表明它们没有被更新,已经无意义,很可能是因为主备库之间的通信出现了中断。

1.1.3 Switchover

Switchover通常用于减少计划内的中断过程中主库的停机时间,比如操作系统或者软件的升级,以及Oracle数据库软件或者补丁的滚动升级。

Switchover分为2个阶段,第一阶段,现有的主库转换为备库角色;第二阶段,备库转为主库角色。

如下,主库为San Francisco,备库为Boston,转换前的data guard配置:

当原始主库已转换为备库,但原始备库还未转为新的主库,Data Guard环境如下:

当原始备库转换成新的主库,也就是主库变成了Boston,备库变成了San Francisco,Data Guard环境如下:

Switchover之前,以下2点必须满足:

  • 对于物理备库的切换,确保主库是打开的,而且备库的REDO应用处于active状态的;
  • 对于逻辑备库的切换,确保主备库的实例都是打开的,并且SQL应用时active状态。

1.1.4 Failovers

当主库不可用,并且不可能在一个合理的时间内恢复它,Failovers就派上了用场。Failover执行的具体操作取决于是否有逻辑与物理备库涉及的故障、故障转移时Data Guard的配置状态,以及启动Failover时具体的SQL语句。

Failover San Francisco主库到物理备库Boston,结果如下:

再进行failover之前,如果可以,尽可能将所有可用而未被应用的主库redo数据传至备库。

failover角色转换其他的前提条件如下:

  • 如果备库运行在最大保护模式下,请先更改为最佳性能模式:

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

转换结束后,可以根据需要重新设置备库运行模式。

转换备库的运行模式是因为备库运行在最大保护模式下不能进行failover操作,另外,如果主库运行在最大保护模式下,并且和备库还在通信的状态下,更改备库到最佳性能模式的SQL操作将不能成功。因为failover操作将主库移出了dataguard配置,这些特性意在保护运行在最大保护模式下的主库免受意料之外的failover操作。

1.1.5 角色转换触发器

当发生角色转换时,系统事件DB_ROLE_CHANGE将触发。如果角色转换时数据库在open状态或者角色转换时数据库是关闭的、那么下一次数据库open时,该系统事件都将被立即触发。

当角色变化发生时,DB_ROLE_CHANGE系统事件可以用来触发并执行一系列的操作。

本文参阅Oracle官方文档翻译,不足之处欢迎批评指正害羞

人气教程排行