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数据都已应用到备库)。
例如:
<pre dir="ltr">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官方文档翻译,不足之处欢迎批评指正!