Oracle 11g Active Dataguard Failover实验

Dataguard是Oracle官方推荐MAA架构的重要解决方案。目前RAC+Local Dataguard + Remote Dataguard已经成为行业界普遍使用的HA架构

Dataguard是Oracle官方推荐MAA架构的重要解决方案。目前RAC+Local Dataguard + Remote Dataguard已经成为行业界普遍使用的HA架构方式。无论对于RAC还是Dataguard，实现switchover和failover都是最常用的操作场景。
 
Failover是一种“unplanned”切换动作。通常是主库Primary出现软硬件故障问题，不能够继续对外提供数据访问服务，就需要强制性的断开Primary，使用Standby来充当数据访问点。11g的Active Data Guard中，Standby通常是作为Read Only With Apply状态进行工作，提供出一个只读的数据访问来源，模拟读写分离的架构方式。在进行Failover之后，Primary库实际上是退出了Oracle HA架构体系，成为游离对象。Standby在切换之后就成为新的Primary。这个过程就是角色切换。
 
Switchover动作是不会引起数据丢失的，Standby可以保证接受并且应用所有的Redo Log数据。而Failover则不好说，根据不同的保护模式（Protection Mode），一个事务在主库上面是否被commit，是取决于standby上是否接受和应用上日志数据。所以，在进行Failover的时候，是可能会丢数据的。我们作为DBA，需要考虑的是在Primary站点site允许的情况下（因为Primary故障情况不明），尽可能的保护数据，减少数据丢失（Gap）。
 
本篇主要进行Failover过程的实验演示。

相关参考:

Oracle Data Guard 重要配置参数

基于同一主机配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard （RAC+DG) 归档删除策略及脚本

Oracle Data Guard 的角色转换

Oracle Data Guard的日志FAL gap问题

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法

 

1、实验环境说明

 

我们依然使用ora11g和ora11gsy配对节点。Primary为ora11g，Standby为ora11gsy，两边版本均为11.2.0.4。

先启动ora11gsy，启动standby端。

 

[oracle@SimpleLinux ~]$ export ORACLE_SID=ora11gsy

[oracle@SimpleLinux ~]$ sqlplus /nolog

 

SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 21 21:27:28 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

 

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

 

Total System Global Area  372449280 bytes

Fixed Size                  1364732 bytes

Variable Size            331353348 bytes

Database Buffers          33554432 bytes

Redo Buffers                6176768 bytes

Database mounted.

Database opened.

 

启动apply过程。

 

--Standby端启动后默认为Read Only。

SQL> select open_mode from v$database;

 

OPEN_MODE

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

READ ONLY

 

SQL> alter database recover managed standby database using current logfile disconnect from session;
 
 

Database altered.

 

SQL> select open_mode from v$database;

 

OPEN_MODE

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

READ ONLY WITH APPLY

 

之后启动Primary端。

 

 

[oracle@SimpleLinux ~]$ env | grep ORACLE_SID

ORACLE_SID=ora11g

[oracle@SimpleLinux ~]$ sqlplus /nolog

 

SQL*Plus: Release 11.2.0.4.0 Production on Tue Apr 22 15:26:29 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

 

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

 

Total System Global Area  313860096 bytes

Fixed Size                  1364340 bytes

Variable Size            272633484 bytes

Database Buffers          33554432 bytes

Redo Buffers                6307840 bytes

Database mounted.

Database opened.

 

2、Failover实验

 

我们人工模拟Primary崩溃，，直接关闭。

 

SQL> shutdown abort

ORACLE instance shut down.

 

真实环境下，Primary的故障是多样的，现象也是多样的。最彻底的就是Primary站点直接失去联系，不能访问。这种情况出现并不多，但是也能出现。比如磁盘（非冗余）损坏、断电、地震天灾。最简单的情况也许是监听器停止工作需要重启、实例停止等等。
 
故障的多样，也就意味着恢复的机会是多样的。在11g里面，Oracle认为最理想的情况是，虽然Oracle数据库不能打开，但是可以启动到mount状态。

Mount状态之所以重要，就在于如果可以到这个阶段，控制文件control_file就可以读取到，归档日志和在线日志的位置、信息都可以读取到。这也就意味着最大可能性的进行数据恢复，避免数据损失。
 
在11g中，推出了日志手工flush的功能，来弥补日志数据没有传递的问题。

 

SQL> startup mount

ORACLE instance started.

 

Total System Global Area  313860096 bytes

Fixed Size                  1364340 bytes

Variable Size            272633484 bytes

Database Buffers          33554432 bytes

Redo Buffers                6307840 bytes

Database mounted.

 

进行日志刷新：

 

SQL> alter system flush redo to 'ora11gsy';

System altered.

 

此时，alert log中显示信息，将日志传递。

 

Tue Apr 22 15:31:00 2014

Resetting standby activation ID 4239920854 (0xfcb80ed6)

Tue Apr 22 15:31:00 2014

Archived Log entry 14 added for thread 1 sequence 27 ID 0xfcb80ed6 dest 1:

Media Recovery Waiting for thread 1 sequence 28

Tue Apr 22 15:31:00 2014

Standby switchover readiness check: Checking whether recoveryapplied all redo..

Physical Standby applied all the redo from the primary.

 

检查日志gap的问题，可以查看视图v$archive_gap。

 

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;

no rows selected

 

如果没有发现明显的gap现象，说明此次的failover不会有数据损失情况。在standby端，要进行关闭apply和结束应用动作。

 

 

SQL> alter database recover managed standby database cancel;

Database altered.

 

 

SQL> alter database recover managed standby database finish;

Database altered

 

 

SQL> select open_mode, switchover_status from v$database;

OPEN_MODE            SWITCHOVER_STATUS

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

READ ONLY            TO PRIMARY

 

注意：这个过程并不会经常成功执行，而且在10g这样的版本下也没有办法自动flush redo。解决的方法也是有的，就是从Primary目录中，将日志拷贝到Standby端，手工去加载。
 
 

更多详情见请继续阅读下一页的精彩内容：