Oracle Data Guard 的角色转换

  1. 云栖社区>
  2. 博客>
  3. 正文

Oracle Data Guard 的角色转换

老牛的博客 2013-06-17 21:51:37 浏览534
展开阅读全文

实验环境:OEL+Oracle11.2.0.3+physical standby

众所周知,Data Guard已经是现今标准的主流容灾方案,由于日志传递对于网络适应程度强,且可以采用同步实时的传递方式和异步延迟的传递方式,甚至可以成为远程的异地容灾方案。不管用于何种用途,DG都免不了要进行角色转换,即将standby 数据库切换为primary数据库,角色转换分为:switchover和failover两种;两种区别从三个角度来对比:

(1)、使用场合不同:Switchover 用于有准备的、计划之中的切换,通常是系统升级、数据迁移等常态任务;Failover用于意料之外的突发情况,比如异常掉电、自然灾难等等。

(2)、数据丢失程度不同:Switchover不会丢失数据,Failover通常意味着有部分数据丢失。

(3)、善后处理的不同:Switchover之后Dataguard环境不会被破坏,任然有Primary、Standby两种角色的系统存在。但是Failover之后,Dataguard环境就会被破坏,必须需要重建。

一、Switchover

因为Switchover这种转化是有DBA主动、人为触发的,所以Switchover的步骤都是标准化的。Switchover流程是从Primary Database开始,终止于Standby Database。

Switchover步骤如下:

1 在主库端检查数据库可切换状态

SQL> select switchover_status from v$database;   

SWITCHOVER_STATUS:TO STANDBY 表示可以正常切换.

如果SWITCHOVER_STATUS 的值为SESSIONS ACTIVE,表示当前有会话处于ACTIVE状态

2 开始主库正常切换

如果SWITCHOVER_STATUS 的值为TO STANDBY:

SQL>alter database commit to switchover to physical standby; 
Database altered.

如果SWITCHOVER_STATUS 的值为SESSIONS ACTIVE:

SQL>alter database commit to switchover to physical standby with session shutdown; 
Database altered.

当 Primary Database 收到这条命令后,会发生这几件事情:

(1)、这条命令执行完毕之后,主库上就不会产生Redo,所有DML相关的Cursor都会失效,用户也将不能再执行事务。

(2)、每个日志线程的当前日志被归档,并在接下来的每个Thread新的日志头记录一个特殊的切换标准EOR(End of Redo),然后再次归档,其结果就是把EOR发送给所有Standby Database,Primary Database 转换成了Standby。

(3)、在这个旧的Primary Database 上,MRP(Managed Recovery Process)进程会自动启动,并应用最后一个归档日志,也就是EOR这个日志,一旦这个EOR应用完成,数据库就会Dismounted,并必须启动成一个Standby Database。

3 重启先前的主库

SQL> SHUTDOWN IMMEDIATE;(11g有时候要shutdown abort才行,不然报错)

SQL> startup mount;

4 这时候到备份库 在备库验证可切换状态

SQL>select switchover_status from v$database;

SWITCHOVER_STATUS

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

TO_PRIMARY

1 row selected

5 将目标备库转换为主库

如果SWITCHOVER_STATUS 的值为TO STANDBY 则:

SQL> alter database commit to switchover to primary; 
Database altered.

如果SWITCHOVER_STATUS 的值为SESSIONS ACTIVE 则:

SQL>alter database commit to switchover  to primary with session shutdown; 
Database altered.

执行完这个命令后,Standby Database 的控制文件也从Standby 控制文件转换成标准的控制文件了,接下来数据库就可以open database,打开成业务数据库了。

6 重启目标备库

SQL> shutdown immediate;

SQL> startup;

7 先前主库启动日志传送进程

SQL> alter database recover managed standby database disconnect;

8 检查主备库角色状态:

select switchover_status,database_role from v$database;

至此,一个完整的Switchover 完成角色互换,可以正常使用了。


二、Failover

一旦主数据库发生Crash(比如异常掉电、硬件故障),短时间内无法恢复运行,这时为了尽快的把业务恢复正常,通常需要执行failover操作,将Standby数据库强制打开。Failover 通常意味着有一定的数据丢失,而数据丢失问题在Primary Database 是 RAC 时表现的尤为突出,需要重点关注。

Failover步骤如下:

1 停止应用日志:

SQL> recover managed standby database cancel;
Media recovery complete.

2 强制结束日志应用,执行下面命令:

SQL> alter database recover managed standby database finish [force]; 
Database altered.

这个force是可选项,这个命令是告诉Standby Database的MRP,不要再等待Redo了,并尽可能多的应用现有的Redo记录,并要模拟一个Switchover命令。force参数的作用是关闭PFS进程,否则MRP进程看到RFS进程还存在,就会认为对应的Primary Database还是正常的,就不会允许进程failover,11g中,force参数成了缺省的参数,同时force参数也被取消了。

一旦finish命令完成,DG的数据保护模式就会降级到Maximun Performance,不论原来是什么保护级别。


3 进行正常的switchover:

SQL> alter database commit to switchover to primary with session shutdown; 
Database altered.

4 open数据库。

SQL>alter database open;

在打开数据库时,这个新的Primary Database 会尝试去连接Standby Database(也就是那个出了故障的Primary Database),因此打开过程会挂起一段时间,当尝试几次后,最终会打开数据库,这时数据库的保护级别就是Maximun Performance的,以后需要手工将其提升为其他级别。


网友评论

登录后评论
0/500
评论
老牛的博客
+ 关注