程序師世界是廣大編程愛好者互助、分享、學習的平台，程序師世界有你更精彩！
設為首頁 加入收藏
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle教程 >> 【博文推薦】Oracle DataGuard 學習之 DataGuard FailOver案例

【博文推薦】Oracle DataGuard 學習之 DataGuard FailOver案例

編輯：Oracle教程

【博文推薦】Oracle DataGuard 學習之 DataGuard FailOver案例


本博文出自Bkjia博客客居天涯博主，有任何問題請進入博主頁面互動討論！
博文地址：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

  1. 上一頁:
  2. 下一頁:
Oracle教程
Oracel小結

Oracel小結 delete 和 trunca
toadfororacle，格式化配置備份FmtPlus.opt

toadfororacle，格式化配置備份FmtPlus.o
Oracle數據庫row_number()over統計前15名企業，wm_concat(casewhenthen)行轉列

Oracle數據庫row_number()over統計前15
Oracle免費的便捷Web應用開發框架二則(1)

Oracle免費的便捷Web應用開發框架二則(1) APEX
oracle client ORA-12541: TNS: 無監聽程序，ora-12541tns

oracle client ORA-12541: TNS:

Oracle升級_oracle10g版本由10.2.0.1.0升級為10.2.0.4.0（即CPU升級）

Oracle升級_oracle10g版本由10.2.0.1.
相關文章
閱讀排行榜
oracle學習之數據庫數據保存成文件，oracle數據庫 Oracle技術_字符串處理_截取文件名或擴展名 Oracle密碼忘記簡單處理辦法 ORACLE等待事件: log file parallel write，oracleparallel Oracle用法、函數備忘記錄，oracle用法函數備忘 Oracle 12.1.0.2 New Feature翻譯學習【In-Memory column store內存列存儲】【原創】，12.1.0.2in-memory 隨機獲取oracle數據庫中的任意一行數據(rownum)示例介紹，oraclerownum oracle的Spool命令 [Oracle]分析函數（4）-OrderBy字句 Oracle中查詢、禁用、啟用、刪除表外鍵 與B樹索引相關的執行計劃
熱門圖文
innodb 庫的備份注意點（由phpmyadmin引起的解決方案） MSSQL2005 INSERT,UPDATE,DELETE 之OUTPUT子句使用實例 MySQL忘記密碼處理方法解決辦法 MySQL數據庫中修改密碼方法總結 mysql重置密碼 sql server中的decimal或者numeric的精度問題 Oracle數據庫的性能的完全保護的措施 Oracle SQL語句優化技術分析
欄目導航
關於Oracle數據庫Oracle數據庫基礎Oracle教程
Copyright © 程式師世界 All Rights Reserved