Oracle DG（Dataguard）是目前比较常见的数据库HA配置策略。通过实现Physical Standby和Logical Standby，可以实现数据冗余容错机制。防止在主库出现严重故障，不能支持服务的时候，没有快速的后备支持环境。
在DG中，switchover和failover是两个重要的概念，也是DG实现的核心。两者共同点都是Primary和Standby角色切换，差异在于Planned和UnPlanned之分。Switchover关键点在于Planned，这个切换动作是在运维机构规划范围内的动作。比如，进行定期系统软硬件升级、设备维修等动作。而Failover是真正出现严重系统故障，如数据库宕机、软硬件故障导致的Primary不能支持服务，从而进行的切换动作。
根据不同的DG配置，switchover和failover也是有差异的。理论上，Switchover是不会造成数据丢失的，Primary在切换之后也是在DG配置环境中，作为Standby存在的。但是Failover则不同，除了运行在最大保护（Maximum Protection）模式下，Primary突发的故障可能引起一部分Redo Log不能及时的传递到Standby端，切换之后很可能有数据损失的情况。更重要的是，Primary端在发生Failover之后，是不能够直接加入回DG配置的！也就是说，Failover之后，Primary实际上就是被“抛出”了DG环境。
那么，有什么方法实现Primary回到原有的环境呢？这个问题的困难在于保持Primary和Standby一致。在正常情况下，Primary和Standby之间是关联同步的，即使发生了Switchover，也在可控情况下。Failover过程中有数据的缺失，还有Primary修复问题。在目前流行版本（11g）中，有三个方法：
ü 环境重建：一种最简单的方法就是直接删除原来的Primary库，引用DG重建方法，重新搭建Standby端；
ü RMAN备份恢复：如果Primary端保留过一份Failover之前的备份，则可以强制原来的Primary端恢复到进行Failover的时间点，之后作为Standby接收当前Primary的redo log传递，应用后可以跟上进度；
ü Flashback Database恢复：Flashback技术是作为传统备份还原技术的补充，提供了更加便捷的恢复策略。使用flashback，可以将数据库恢复到failover之前的时间点。之后的过程和RMAN备份恢复策略相同；
本篇主要介绍使用Flashback恢复failover主库的过程。
1、环境介绍
笔者选择Oracle11g进行测试，具体版本为11.2.0.4。DG已经搭建完成，主库实例名为ora11g，standby库名称为ora11gsy。
由于环境所限，两台实例在相同服务器上。
[root@SimpleLinux ~]# su - oracle
[oracle@SimpleLinux ~]$ ps -ef | grep pmon
oracle 1655 1 0 12:20 ? 00:00:03 ora_pmon_ora11g
oracle 1891 1 0 12:30 ? 00:00:03 ora_pmon_ora11gsy
oracle 2635 2604 1 14:01 pts/0 00:00:00 grep pmon
两台实例角色关系和配置关系正常。
--ora11g
SQL> select name, open_mode, database_role, flashback_on from v$database;
NAME OPEN_MODE DATABASE_ROLE FLASHBACK_ON
--------- -------------------- ---------------- ------------------
ORA11G READ WRITE PRIMARY NO
--ora11gsy
SQL> select name, open_mode, database_role, flashback_on from v$database;
NAME OPEN_MODE DATABASE_ROLE FLASHBACK_ON
--------- -------------------- ---------------- ------------------
ORA11G READ ONLY WITH APPLY PHYSICAL STANDBY NO
下面首先进行Primary端的flashback database配置。
2、Flashback配置
在Primary端进行flashback配置，确保闪回日志时间范围。首先需要完全关闭数据库，进入mount状态配置。
[oracle@SimpleLinux ~]$ env | grep ORACLE_SID
ORACLE_SID=ora11g
[oracle@SimpleLinux ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun Jun 15 14:07:22 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
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.
启动flashback database，查看闪回信息情况。
SQL> alter database flashback on;
Database altered.
SQL> alter database open;
Database altered.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
flashback失效信息，通过查看v$flashback_database_log字段可以确认最远的闪回时间。
SQL> select oldest_flashback_scn, oldest_flashback_time from v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME
-------------------- ---------------------
779669 15-六月-14 14:08:42
SQL> show parameter flashback
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
参数db_flashback_retention_target控制闪回时间范围，数字单位是分钟，默认为1天。这个数字决定了闪回的时间范围，如果设置更长的时间，对应的闪回日志文件大小就会比较大一些。
3、Primary主库Failover过程
模仿主库Primary突然宕机，失去联系。
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
ora11g
SQL> shutdown abort;
ORACLE instance shut down.
Standby端进行单独的角色切换。注意：在实际的场景中，进行failover的原因是很多的，Oracle出现故障的场景也有所差异。不同的故障场景是会决定是否出现数据丢失的。
--在standby端进行
SQL> select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
SQL> alter database recover managed standby database cancel;
Database altered
SQL> alter database recover managed standby database finish;
Database altered
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY PHYSICAL STANDBY
如果上面操作顺利进行，没有额外错误报出。说明这个过程中没有数据损失情况发生，也就意味着虽然发生了failover，但是不会有数据损失。
切换角色到Primary。
SQL> alter database commit to switchover to primary with session shutdown;
Database altered
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
MOUNTED PRIMARY
SQL> alter database open;
Database altered
之后，由于standby端ora11gsy上面的归档日志路径原因，alert log中报错如下：
Sun Jun 15 14:23:06 2014
Error 1041 received logging on to the standby
FAL[server, ARC3]: Error 1041 creating remote archivelog file 'ora11g'
FAL[server, ARC3]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance ora11gsy - Archival Error. Archiver continuing.
查询路径情况：
SQL> col dest_name for a20;
SQL> select dest_id, dest_name, status, type from v$archive_dest_status;
DEST_ID DEST_NAME STATUS TYPE
---------- -------------------- --------- --------------
1 LOG_ARCHIVE_DEST_1 VALID LOCAL
2 LOG_ARCHIVE_DEST_2 ERROR UNKNOWN
3 LOG_ARCHIVE_DEST_3 INACTIVE LOCAL
为避免问题反复出现，临时性的将路径设置为defer，阻止反复的数据传输动作。
SQL> alter system set log_archive_dest_state_2='defer';
System altered
SQL> select dest_id, dest_name, status, type from v$archive_dest_status;
DEST_ID DEST_NAME STATUS TYPE
---------- -------------------- --------- --------------
1 LOG_ARCHIVE_DEST_1 VALID LOCAL
2 LOG_ARCHIVE_DEST_2 DEFERRED UNKNOWN
Failover过程完成。
4、Primary重新加入
Failover后的Primary数据库，实际上已经失去了和DG的关联，如果Primary故障严重，是难以保障对应的归档数据可以顺利传输的。
如果希望Primary重新回到DG环境，关键就是恢复的时间点。要求Primary回到Standby切换角色的那个时间点，理论上就可以“延续”操作。
在ora11gsy端，查看v$database视图，可以看到这个库成为primary的具体时间。
SQL> select STANDBY_BECAME_PRIMARY_SCN from v$database;
STANDBY_BECAME_PRIMARY_SCN
--------------------------
780222
为了测试数据，特建立数据表T，判断同步情况。
SQL> create table t as select * from dba_objects where rownum<1000;
Table created
SQL> select count(*) from t;
COUNT(*)
----------
999
进行一系列的日志切换。
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
780959
SQL> alter system switch logfile;
System altered
SQL> alter system switch logfile;
System altered
SQL> alter system switch logfile;
System altered
原主库启动，进入mount后，进行flashback操作，回到指定时间点。
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup mount;
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.
SQL> flashback database to scn 780222
2 ;
Flashback complete.
注意：重新加入的原Primary是不能回复角色的，而是只能先成为Standby角色。应用后续的日志达到同步。
SQL> alter database convert to physical standby;
Database altered.
SQL> select open_mode, database_role from v$database;
select open_mode, database_role from v$database
*
ERROR at line 1:
ORA-01507: database not mounted
启动数据库，确定角色情况。
SQL> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount;
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.
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
MOUNTED PHYSICAL STANDBY
在主库端，启动archive log传输动作。
SQL> alter system set log_archive_dest_state_2='enable';
System altered
SQL> select dest_id, dest_name, status, type from v$archive_dest_status;
DEST_ID DEST_NAME STATUS TYPE
---------- -------------------- --------- --------------
1 LOG_ARCHIVE_DEST_1 VALID LOCAL
2 LOG_ARCHIVE_DEST_2 VALID PHYSICAL
3 LOG_ARCHIVE_DEST_3 INACTIVE LOCAL
4 LOG_ARCHIVE_DEST_4 INACTIVE LOCAL
启动日志应用，可以查看逐步应用动作。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
SQL> select recid, name, sequence#, applied from v$archived_log where recid>33;
RECID NAME SEQUENCE# APPLIED
---------- -------------------------------------------------------------------------------- ---------- ---------
34 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_3_9sthd1k2_.a 3 NO
35 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_4_9sthd39c_.a 4 NO
36 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_5_9sthd8fp_.a 5 NO
37 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_6_9sthp1qt_.a 6 NO
38 ora11g 6 YES
39 ora11g 29 YES
40 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_7_9sthpky0_.a 7 NO
41 ora11g 1 YES
42 ora11g 2 YES
43 ora11g 3 YES
44 ora11g 4 YES
45 ora11g 5 YES
46 ora11g 7 YES
47 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_8_9sthzxml_.a 8 NO
48 ora11g 8 NO
15 rows selected
在ora11g上，也可以确定创建数据表T的情况了。
SQL> select count(*) from t;
select count(*) from t
ORA-01219: 数据库未打开: 仅允许在固定表/视图中查询
SQL> alter database recover managed standby database cancel ;
Database altered
SQL> alter database open;
Database altered
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY PHYSICAL STANDBY
SQL> select count(*) from t;
COUNT(*)
----------
999
实验成功！
5、结论
Oracle DG在发生Failover之后，当主库解决问题，是不可以直接回到DG环境的。这个过程往往需要一些辅助组建的配合。如RMAN、Flashback，都可以简化重回DG的过程时间。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-1184082/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/17203031/viewspace-1184082/
扫一扫
1502
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
