切换分为switchover和failover,前者是无损切换,不会丢失数据,而后者则有可能会丢失数据,并且切换后原primary 数据库也不再是该data guard 配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同
角色转换前的准备工作
检查各数据库的初始化参数,主要确认对不同角色相关的初始化参数都进行了正确的配置。
确保可能成为primary 数据库的standby 服务器已经处于archivelog 模式。
确保standby 数据库的临时文件存在并匹配primary 数据库的临时文件
确保standby 数据库的RAC 实例只有一个处于open 状态。(对于rac 结构的standby 数据库,在角
色转换时只能有一个实例startup。其它rac 实例必须统统shutdown,待角色转换结束后再startup)
Switchover:
无损转换,通常是用户手动触发或者有计划的让其自动触发,比如硬件升级啦,软件升级啦之类的。
通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段,第一步, primary 数据库转换为
standby 角色,第二步,standby 数据库(之一)转换为primary 角色,primary 和standby 只是简单的角色互换.
Failover:
不可预知原因导致primary 数据库故障并且短期内不能恢复就需要failover。
在执行failover 之前,尽可能将原primary 数据库的可用redo 都复制到standby 数据库。
注意,如果要转换角色的standby 处于maximum protection 模式,需要你首先将其切换为maximum
performance模式.转换standby 数据库到MAXIMIZE PERFORMANCE 执行下列SQL 即可:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
等standby 切换为新的primary 之后,你可以再随意更改数据库的保护模式。
maximum protection 模式需要确保绝无数据丢失,因此其对于提交事务对应的redo 数据一致性要求非常高,
另外,如果处于maximum protection 模式下primary 数据库仍然与standby 数据库有数据传输,此时alter
database 语句更改standby 数据库保护模式会失败,这也是由maximum protection 模式特性决定的。
下面演示failover的过程:
一物理standby的failover
注意几点:
failover 之后,原primary 数据库默认不再是data guard 配置的一部分。
多数情况下,其它逻辑/物理standby 数据库不直接参与failover 的过程,
因此这些数据库不需要做任何操作。
某些情况下,新的primary 数据库配置之后,需要重新创建其它所有的standby 数据库。
另外,如果待转换角色的standby 处于maximum protection 或maximum availability 模式的话,
归档日志应该是连续存在的.
一般情况下failover 都是表示primary 数据库瘫痪,因此这种类型的切换基本上不需
要primary数据库做什么操作。
1、检查归档文件是否连续
查询待转换standby 数据库的V$ARCHIVE_GAP 视图,确认归档文件是否连接:
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
未选定行
如果返回的有记录,按照列出的记录号复制对应的归档文件到待转换的standby 服务器。这一步非常重
要,必须确保所有已生成的归档文件均已存在于standby 服务器,不然可能会数据不一致造成转换时报错。
文件复制之后,通过下列命令将其加入数据字典:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filejytest1';
2、检查归档文件是否完整
分别在primary/standby 执行下列语句:
SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
该语句取得当前数据库各线程已归档文件最大序号,如果primary 与standby 最大序号不相同,必须将
多出的序号对应的归档文件复制到待转换的standby 服务器。不过既然是failover,有可能primary 数据库此时已经无法打开,甚至无法访问.
3、启动failover执行下列语句:
SQL> alter database recover managed standby database finish force;
数据库已更改。
FORCE 关键字将会停止当前活动的RFS 进程,以便立刻执行failover。
剩下的步骤就与前面switchover 很相似了
4、切换物理standby 角色为primary
SQL> alter database commit to switchover to primary;
数据库已更改。
5、启动新的primary 数据库。
如果当前数据库已mount,直接open 即可,如果处于read-only 模式,需要首先shutdown immediate,然
后再直接startup。
SQL> alter database open;
数据库已更改
角色转换工作完成。剩下的是补救措施(针对原primary 数据库),由于此时primary 数据库已经不再是
data guard配置的一部分,我们需要做的就是尝试看看能否恢复原primary数据库,将其改造为新的standby
服务器。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26015009/viewspace-750526/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26015009/viewspace-750526/