【博文推荐】Oracle DataGuard 学习之 DataGuard FailOver案例

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

本博文出自51CTO博客客居天涯博主,有任何问题请进入博主页面互动讨论!
博文地址:http://tiany.blog.51cto.com/513694/1617646


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备份恢复策略相同;

案例分析:

一、在主库端模拟数据库意外宕机

  1. 7scott@bjdb>conn /as sysdba 
  2. Connected. 
  3. sys@bjdb>alter system switch logfile; 
  4. System altered. 
  5. sys@bjdb>shutdown abort 
  6. ORACLE instance shut down. 

二、在备库端

1、查看切换信息

  1. 5sys@shdb>select name,database_role,switchover_status from v$database; 
  2. NAME DATABASE_ROLE SWITCHOVER_STATUS 
  3. --------- ---------------- -------------------- 
  4. TESTDB12 PHYSICAL STANDBY NOT ALLOWED 
  5. 可以看到此时备库处于无法切换状态 

2、直接切换

  1. sys@shdb>alter database commit to switchover to primary; 
  2. alert_log:(告警日志) 
  3. Fatal NI connect error 12514, connecting to: 
  4. (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=shsrv)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=shdb)(CID=(PROGRAM=oracle)(HOST=bjsrv)(USER=oracle)))) 
  5. VERSION INFORMATION: 
  6. TNS for Linux: Version 11.2.0.3.0 - Production 
  7. TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production 
  8. Time: 04-MAR-2015 21:25:13 
  9. Tracing not turned on. 
  10. Tns error struct: 
  11. ns main err code: 12564 
  12. TNS-12564: TNS:connection refused 
  13. ns secondary err code: 0 
  14. nt main err code: 0 
  15. nt secondary err code: 0 
  16. nt OS err code: 0 
  17. Error 12514 received logging on to the standby 
  18. FAL[client, MRP0]: Error 12514 connecting to shdb for fetching gap sequence 
  19. Wed Mar 04 21:26:00 2015 
  20. alter database commit to switchover to primary 
  21. ALTER DATABASE SWITCHOVER TO PRIMARY (TestDB12)  
  22. Maximum wait for role transition is 15 minutes.  
  23. Switchover: Media recovery is still active  
  24. Database not available for switchover  
  25. End-Of-REDO archived log file has not been recovered  
  26. Database not available for switchover  
  27. End-Of-REDO archived log file has not been recovered 
  28. Database not available for switchover 

3、关闭standby MPR进程

  1. 35sys@shdb>ALTER DATABASE RECOVER managed standby database finish; 
  2. ALTER DATABASE RECOVER managed standby database finish  
  3. Terminal Recovery: request posted (TestDB12)  
  4. Wed Mar 04 21:34:34 2015 
  5. Begin: Standby Redo Logfile archival  
  6. End: Standby Redo Logfile archival  
  7. Terminal Recovery timestamp is '03/04/2015 21:34:34'  
  8. Terminal Recovery: applying standby redo logs.  
  9. Terminal Recovery: thread 1 seq# 34 redo required 
  10. Media Recovery Waiting for thread 1 sequence 34 
  11. Terminal Recovery: End-Of-Redo log allocation  
  12. Terminal Recovery: standby redo logfile 4 created '/dsk4/arch_bj/arch_1_0_820054583.log'  
  13. This standby redo logfile is being created as part of the  
  14. failover operation. This standby redo logfile should be  
  15. deleted after the switchover to primary operation completes.  
  16. Media Recovery Log /dsk4/arch_bj/arch_1_0_820054583.log 
  17. Terminal Recovery: log 4 reserved for thread 1 sequence 34  
  18. Recovery of Online Redo Log: Thread 1 Group 4 Seq 34 Reading mem 0 
  19. Mem# 0: /dsk4/arch_bj/arch_1_0_820054583.log 
  20. Identified End-Of-Redo (failover) for thread 1 sequence 34 at SCN 0xffff.ffffffff 
  21. Incomplete Recovery applied until change 1234252 time 03/04/2015 21:23:43
  22. MRP0: Media Recovery Complete (TestDB12)  
  23. Terminal Recovery: successful completion  
  24. Wed Mar 04 21:34:35 2015 
  25. ARCH: Archival stopped, error occurred. Will continue retrying 
  26. ORACLE Instance TestDB12 - Archival Error 
  27. ORA-16014: log 4 sequence# 34 not archived, no available destinations 
  28. ORA-00312: online log 4 thread 1'/dsk4/arch_bj/arch_1_0_820054583.log' 
  29. Forcing ARSCN to IRSCN for TR 0:1234252
  30. Attempt to set limbo arscn 0:1234252 irscn 0:1234252 
  31. Resetting standby activation ID 2865247982 (0xaac836ee 
  32. MRP0: Background Media Recovery process shutdown (TestDB12) 
  33. Terminal Recovery: completion detected (TestDB12) 
  34. Completed: ALTER DATABASE RECOVER managed standby database finish 

4、切换数据库到Primary

  1. sys@shdb>select status from v$instance; 
  2. STATUS 
  3. ------------ 
  4. OPEN 
  5. sys@shdb>select name,database_role,switchover_status from v$database; 
  6. NAME DATABASE_ROLE SWITCHOVER_STATUS  
  7. --------- ---------------- --------------------  
  8. TESTDB12 PHYSICAL STANDBY TO PRIMARY  
  9. sys@shdb>alter database commit to switchover to primary;  
  10. Database altered.  
  11. sys@shdb>alter database open;  
  12. Database altered.  
  13. 告警日志:  
  14. alter database commit to switchover to primary  
  15. ALTER DATABASE SWITCHOVER TO PRIMARY (TestDB12)  
  16. Maximum wait for role transition is 15 minutes.  
  17. All dispatchers and shared servers shutdown  
  18. CLOSE: killing server sessions.  
  19. CLOSE: all sessions shutdown successfully.  
  20. Wed Mar 04 21:35:47 2015  
  21. SMON: disabling cache recovery 
  22. Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/bjdb/TestDB12/trace/TestDB12_ora_3146.trc 
  23. Standby terminal recovery start SCN: 1234251  
  24. RESETLOGS after incomplete recovery UNTIL CHANGE 1234252  
  25. Online log /dsk2/oradata/bjdb/redo01b.log: Thread 1 Group 1 was previously cleared 
  26. Online log /dsk1/oradata/bjdb/redo01a.log: Thread 1 Group 1 was previously cleared  
  27. Online log /dsk2/oradata/bjdb/redo02b.log: Thread 1 Group 2 was previously cleared 
  28. Online log /dsk1/oradata/bjdb/redo02a.log: Thread 1 Group 2 was previously cleared 
  29. Online log /dsk2/oradata/bjdb/redo03b.log: Thread 1 Group 3 was previously cleared 
  30. Online log /dsk1/oradata/bjdb/redo03a.log: Thread 1 Group 3 was previously cleared 
  31. Standby became primary SCN: 1234250 
  32. Wed Mar 04 21:35:47 2015 
  33. Setting recovery target incarnation to 3  
  34. AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file. 
  35. Switchover: Complete - Database mounted as primary 
  36. Completed: alter database commit to switchover to primary 

三、原主库修复后,开机

  1. sys@bjdb>startup  
  2. ORACLE instance started.  
  3. Total System Global Area 442601472 bytes  
  4. Fixed Size 2229184 bytes  
  5. Variable Size 281021504 bytes  
  6. Database Buffers 155189248 bytes 
  7. Redo Buffers 4161536 bytes  
  8. Database mounted.  
  9. Database opened.  
  10. sys@bjdb>select name,database_role,switchover_status from v$database; 
  11. NAME DATABASE_ROLE SWITCHOVER_STATUS  
  12. --------- ---------------- -------------------- 
  13. TESTDB12 PRIMARY FAILED DESTINATION 

现在原来的主库被修复后,整个DataGuara架构已经被破坏了,所以必须把原来的主库构建成新的备库,重新恢复DataGuard的环境。

四、重新构建DataGuard

  1. 1sys@bjdb>select name,database_role from v$database; 

NAME DATABASE_ROLE

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

TESTDB12 PHYSICAL STANDBY

 

责任编辑:Ophira 来源: 51CTO
相关推荐

2021-12-27 09:15:16

Oracle数据库后端开发

2009-07-03 09:44:30

Oracle Data

2011-07-05 16:18:14

DataGuardSTANDBY

2015-09-29 10:26:51

pythonlogging模块

2021-11-08 08:29:57

Oracle数据库后端开发

2017-07-04 15:45:30

数据库RACWindows平台

2015-05-15 10:04:28

localhost

2014-10-15 11:40:44

LNMP搭建LNMP

2015-06-17 09:34:09

软件定义存储 云存储

2015-07-01 10:25:07

Docker开源项目容器

2015-06-15 13:06:23

项目项目经验

2014-12-12 10:46:55

Azure地缘组affinitygro

2014-10-23 09:47:28

安全运维Iperf

2010-01-18 09:03:15

Dataguard配置

2015-07-29 13:46:27

OpenStackIcehouse私有云实战部署

2015-04-21 09:28:58

ockerdocker监控平台监控

2014-12-01 10:33:51

Python

2015-07-03 11:26:07

MySQL高可用架MHA

2014-12-23 11:23:14

DRBDHeartbeatNFS

2015-04-17 11:17:15

大数据大数据择业
点赞
收藏

51CTO技术栈公众号