ITPub博客

首页 > 数据库 > Oracle > 使用Flashback让Failover数据库重新加入DG环境

使用Flashback让Failover数据库重新加入DG环境

Oracle 作者:lwitpub 时间:2014-12-17 18:01:14 0 删除 编辑

 

Oracle DGDataguard)是目前比较常见的数据库HA配置策略。通过实现Physical StandbyLogical Standby,可以实现数据冗余容错机制。防止在主库出现严重故障,不能支持服务的时候,没有快速的后备支持环境。

DG中,switchoverfailover是两个重要的概念,也是DG实现的核心。两者共同点都是PrimaryStandby角色切换,差异在于PlannedUnPlanned之分。Switchover关键点在于Planned,这个切换动作是在运维机构规划范围内的动作。比如,进行定期系统软硬件升级、设备维修等动作。而Failover是真正出现严重系统故障,如数据库宕机、软硬件故障导致的Primary不能支持服务,从而进行的切换动作。

根据不同的DG配置,switchoverfailover也是有差异的。理论上,Switchover是不会造成数据丢失的,Primary在切换之后也是在DG配置环境中,作为Standby存在的。但是Failover则不同,除了运行在最大保护(Maximum Protection)模式下,Primary突发的故障可能引起一部分Redo Log不能及时的传递到Standby端,切换之后很可能有数据损失的情况。更重要的是,Primary端在发生Failover之后,是不能够直接加入回DG配置的!也就是说,Failover之后,Primary实际上就是被“抛出”了DG环境。

那么,有什么方法实现Primary回到原有的环境呢?这个问题的困难在于保持PrimaryStandby一致。在正常情况下,PrimaryStandby之间是关联同步的,即使发生了Switchover,也在可控情况下。Failover过程中有数据的缺失,还有Primary修复问题。在目前流行版本(11g)中,有三个方法:

 

ü  环境重建:一种最简单的方法就是直接删除原来的Primary库,引用DG重建方法,重新搭建Standby端;

ü  RMAN备份恢复:如果Primary端保留过一份Failover之前的备份,则可以强制原来的Primary端恢复到进行Failover的时间点,之后作为Standby接收当前Primaryredo log传递,应用后可以跟上进度;

ü  Flashback Database恢复:Flashback技术是作为传统备份还原技术的补充,提供了更加便捷的恢复策略。使用flashback,可以将数据库恢复到failover之前的时间点。之后的过程和RMAN备份恢复策略相同;

 

本篇主要介绍使用Flashback恢复failover主库的过程。

 

1、环境介绍

 

笔者选择Oracle11g进行测试,具体版本为11.2.0.4DG已经搭建完成,主库实例名为ora11gstandby库名称为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配置。

 

2Flashback配置

 

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天。这个数字决定了闪回的时间范围,如果设置更长的时间,对应的闪回日志文件大小就会比较大一些。

 

3Primary主库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

 

之后,由于standbyora11gsy上面的归档日志路径原因,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过程完成。

 

4Primary重新加入

 

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环境的。这个过程往往需要一些辅助组建的配合。如RMANFlashback,都可以简化重回DG的过程时间。

 


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/628922/viewspace-1371314/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-05-08

  • 博文量
    107
  • 访问量
    395307