ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > Oracle > Oracle DataGuard switchover切换一例

Oracle DataGuard switchover切换一例

原创 Oracle 作者：liupzmin 时间：2016-02-16 16:54:14 1 删除 编辑
Oracle DataGuard switchover切换一例

做DG的切换测试，发现了一些有趣的小问题，寥作记录

1.主库当时归档日志状态


2.备库当时归档日志状态

3.此时进行切换

主库的alert日志


  1. Tue Feb 16 14:55:15 2016
  2. ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
  3. ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 5441] (minstd)
  4. Waiting for all non-current ORLs to be archived...
  5. All non-current ORLs have been archived.
  6. Waiting for all FAL entries to be archived...
  7. All FAL entries have been archived.
  8. Waiting for potential Physical Standby switchover target to become synchronized...
  9. Active, synchronized Physical Standby switchover target has been identified
  10. Switchover End-Of-Redo Log thread 1 sequence 85 has been fixed
  11. Switchover: Primary highest seen SCN set to 0x0.0x101743
  12. ARCH: Noswitch archival of thread 1, sequence 85
  13. ARCH: End-Of-Redo Branch archival of thread 1 sequence 85
  14. ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
  15. ARCH: Standby redo logfile selected for thread 1 sequence 85 for destination LOG_ARCHIVE_DEST_2
  16. Archived Log entry 17 added for thread 1 sequence 85 ID 0x97bd9e7c dest 1:
  17. ARCH: Archiving is disabled due to current logfile archival
  18. Primary will check for some target standby to have received alls redo
  19. Final check for a synchronized target standby. Check will be made once.
  20. LOG_ARCHIVE_DEST_2 is a potential Physical Standby switchover target
  21. Active, synchronized target has been identified
  22. Target has also received all redo
这时主库做了一次日志切换，加入EOR标记，并传输日志到所有备库，然后检查确认所有备库全部接受到所有的redo

这时查询备库



85号日志确实已经收到并且应用，备库alert如下

  1. Tue Feb 16 14:52:22 2016
  2. Archived Log entry 19 added for thread 1 sequence 84 ID 0x97bd9e7c dest 1:
  3. Media Recovery Waiting for thread 1 sequence 85 (in transit)
  4. Recovery of Online Redo Log: Thread 1 Group 4 Seq 85 Reading mem 0
  5. Mem# 0: /u01/app/oradata/min/stdb_redo01.log
  6. Tue Feb 16 14:55:17 2016
  7. RFS[5]: Assigned to RFS process 7837
  8. RFS[5]: Selected log 4 for thread 1 sequence 85 dbid -1749202365 branch 903912515
  9. Tue Feb 16 14:55:17 2016
  10. Archived Log entry 20 added for thread 1 sequence 85 ID 0x97bd9e7c dest 1:
  11. Tue Feb 16 14:55:17 2016
  12. RFS[2]: Possible network disconnect with primary database
  13. Tue Feb 16 14:55:17 2016
  14. RFS[6]: Assigned to RFS process 7782
  15. RFS[6]: Possible network disconnect with primary database
  16. Tue Feb 16 14:55:17 2016
  17. RFS[1]: Possible network disconnect with primary database
  18. Tue Feb 16 14:55:17 2016
  19. RFS[7]: Assigned to RFS process 7835
  20. RFS[7]: Possible network disconnect with primary database
  21. Tue Feb 16 14:55:17 2016
  22. Resetting standby activation ID 2545786492 (0x97bd9e7c)
  23. Media Recovery End-Of-Redo indicator encountered
  24. Media Recovery Continuing
  25. Media Recovery Waiting for thread 1 sequence 86
收到85号日志之后，与主库失去联系，在应用85号日志的时候遇到EOR标记

备库切换为主库


新主库alert

  1. ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
  2. ALTER DATABASE SWITCHOVER TO PRIMARY (min)
  3. Maximum wait for role transition is 15 minutes.
  4. All dispatchers and shared servers shutdown
  5. CLOSE: killing server sessions.
  6. CLOSE: all sessions shutdown successfully.
  7. Tue Feb 16 15:00:29 2016
  8. SMON: disabling cache recovery
  9. Backup controlfile written to trace file /home/oracle/app/oracle/diag/rdbms/min/min/trace/min_ora_7726.trc
  10. SwitchOver after complete recovery through change 1054531
  11. Online log /u01/app/oradata/min/redo01.log: Thread 1 Group 1 was previously cleared
  12. Online log /u01/app/oradata/min/redo02.log: Thread 1 Group 2 was previously cleared
  13. Online log /u01/app/oradata/min/redo03.log: Thread 1 Group 3 was previously cleared
  14. Standby became primary SCN: 1054529
  15. AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
  16. Switchover: Complete - Database mounted as primary
  17. Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
  18. Tue Feb 16 15:00:42 2016
  19. alter database open
  20. Tue Feb 16 15:00:42 2016
  21. Assigning activation ID 2545831887 (0x97be4fcf)
  22. Thread 1 advanced to log sequence 87 (thread open)
  23. Tue Feb 16 15:00:42 2016
  24. ARC8: Becoming the 'no SRL' ARCH
  25. Thread 1 opened at log sequence 87
  26. Current log# 2 seq# 87 mem# 0: /u01/app/oradata/min/redo02.log
  27. Successful open of redo thread 1
  28. MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
  29. Tue Feb 16 15:00:42 2016
  30. ARC9: Becoming the 'no SRL' ARCH
  31. Tue Feb 16 15:00:42 2016
  32. ARCa: Becoming the 'no SRL' ARCH
  33. Tue Feb 16 15:00:42 2016
  34. SMON: enabling cache recovery
  35. Archived Log entry 21 added for thread 1 sequence 86 ID 0x97be4fcf dest 1:
  36. Tue Feb 16 15:00:42 2016
  37. ARCt: Becoming the 'no SRL' ARCH
  38. Tue Feb 16 15:00:42 2016
  39. NSA2 started with pid=18, OS id=7850
  40. [7726] Successfully onlined Undo Tablespace 2.
  41. Undo initialization finished serial:0 start:86759444 end:86759474 diff:30 (0 seconds)
  42. Dictionary check beginning
  43. Dictionary check complete
  44. Verifying file header compatibility for 11g tablespace encryption..
  45. Verifying 11g file header compatibility for tablespace encryption completed
  46. SMON: enabling tx recovery
  47. Database Characterset is ZHS16GBK
  48. Starting background process SMCO
  49. Tue Feb 16 15:00:42 2016
  50. idle dispatcher 'D000' terminated, pid = (17, 1)
  51. ARCt: Standby redo logfile selected for thread 1 sequence 86 for destination LOG_ARCHIVE_DEST_2
  52. Tue Feb 16 15:00:42 2016
  53. SMCO started with pid=50, OS id=7852
  54. No Resource Manager plan active
  55. Starting background process QMNC
  56. Tue Feb 16 15:00:42 2016
  57. QMNC started with pid=52, OS id=7856
  58. LOGSTDBY: Validating controlfile with logical metadata
  59. LOGSTDBY: Validation complete
  60. Completed: alter database open
  61. Tue Feb 16 15:00:43 2016
  62. ARC0: Becoming the 'no SRL' ARCH
  63. Tue Feb 16 15:00:43 2016
  64. ARC1: Becoming the 'no SRL' ARCH
  65. ARC0: Archive log rejected (thread 1 sequence 86) at host 'minstd'
  66. FAL[server, ARC0]: FAL archive failed, see trace file.
  67. ARCH: FAL archive failed. Archiver continuing
  68. ORACLE Instance min - Archival Error. Archiver continuing.
  69. Thread 1 advanced to log sequence 88 (LGWR switch)
  70. Current log# 3 seq# 88 mem# 0: /u01/app/oradata/min/redo03.log
  71. Tue Feb 16 15:00:45 2016
  72. ARC2: Becoming the 'no SRL' ARCH
  73. Archived Log entry 23 added for thread 1 sequence 87 ID 0x97be4fcf dest 1:
  74. Tue Feb 16 15:00:45 2016
  75. ARC3: Becoming the 'no SRL' ARCH
  76. ARC3: Standby redo logfile selected for thread 1 sequence 87 for destination LOG_ARCHIVE_DEST_2
  77. ******************************************************************
  78. LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
  79. ******************************************************************
  80. LNS: Standby redo logfile selected for thread 1 sequence 88 for destination LOG_ARCHIVE_DEST_2
  81. Tue Feb 16 15:01:05 2016
  82. ARCr: Becoming the 'no SRL' ARCH
新主库打开的时候向主库传输86号日志被拒绝，这里我猜测是一个gap检测的问题，至于为何报错，暂时没搞清楚，我觉得出现了FAL应该是备库检测到gap来请求日志的，但为何拒绝不甚清楚，而在新备库的日志却发现是接受成功的


  1. Tue Feb 16 15:00:42 2016
  2. Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/archive
  3. RFS[1]: Assigned to RFS process 5901
  4. RFS[1]: Selected log 4 for thread 1 sequence 86 dbid -1749202365 branch 903912515
  5. Tue Feb 16 15:00:42 2016
  6. Archived Log entry 19 added for thread 1 sequence 86 ID 0x97be4fcf dest 1:
  7. Tue Feb 16 15:00:45 2016
  8. RFS[2]: Assigned to RFS process 5905
  9. RFS[2]: Selected log 4 for thread 1 sequence 87 dbid -1749202365 branch 903912515
  10. Tue Feb 16 15:00:45 2016
  11. Archived Log entry 20 added for thread 1 sequence 87 ID 0x97be4fcf dest 1:
  12. Tue Feb 16 15:00:45 2016
  13. Primary database is in MAXIMUM PERFORMANCE mode
  14. RFS[3]: Assigned to RFS process 5907
  15. RFS[3]: Selected log 4 for thread 1 sequence 88 dbid -1749202365 branch 903912515
  16. Tue Feb 16 15:01:36 2016
  17. ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE disconnect
  18. Attempt to start background Managed Standby Recovery process (minstd)
  19. Tue Feb 16 15:01:36 2016
  20. MRP0 started with pid=55, OS id=5923
  21. MRP0: Background Managed Standby Recovery process started (minstd)
  22. started logmerger process
可见86，87已经接收到了

下一刻便开始正常传输了，主库日志信息如下：

  1. Tue Feb 16 15:00:45 2016
  2. ARC3: Becoming the 'no SRL' ARCH
  3. ARC3: Standby redo logfile selected for thread 1 sequence 87 for destination LOG_ARCHIVE_DEST_2
  4. ******************************************************************
  5. LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
  6. ******************************************************************
  7. LNS: Standby redo logfile selected for thread 1 sequence 88 for destination LOG_ARCHIVE_DEST_2
  8. Tue Feb 16 15:01:05 2016
  9. ARCr: Becoming the 'no SRL' ARCH
有一个归档目的地2激活的提示，难道是一开始未激活？

此时再来看一下归档日志信息
新主库：

备库归档目的地86，97两个日志的FAL都是yes，而且在新主库查看切换期间产生的84，85两个日志的applied状态为yes，而在新备库（原主库）查询84，85在新主库（原备库）的applied状态却为NO，很有意思的一个现象

新备库:


总结：

1.switchover前后每个主库角色都会切换1次日志（本次实验为准，并不绝对）
2.新主库产生的前2个日志是以FAL方式传输到备库
3.在原主库查询switcover之前产生的两个日志的applied状态时为NO，而在新的主库（原备库）查询日志的应用状态是为YES的

关于本文中提到的FAL报错的问题，希望广大DBA朋友帮助解惑，如文中还有其他错误之处，还望批评指正

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

1
0
上一篇： strace解决sqlplus登陆缓慢的问题一例
下一篇： ORA-31617 unable to open dump file for write
请登录后发表评论 登录
全部评论
liupzmin

注册时间：2014-05-17

  • 博文量
    29
  • 访问量
    117423

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593