Dataguard的强制切换

简介: 【前言】Dataguard的从库一般情况下都是出于数据的抽取和查询的作用的,但是万一在主库发生故障的情况下就需要切换到备库了。而这种故障的切换往往又是灾难性的情况:比如主库的服务器根本就起不来了,没有办法进行正常的切换,就需要强制的把从库切换成主库了。

【前言】Dataguard的从库一般情况下都是出于数据的抽取和查询的作用的,但是万一在主库发生故障的情况下就需要切换到备库了。而这种故障的切换往往又是灾难性的情况:比如主库的服务器根本就起不来了,没有办法进行正常的切换,就需要强制的把从库切换成主库了。

 

【操作步骤】这个时候主库根本是操作不了的,所以只需在从库执行以下操作

【1】停止应用恢复模式

alter database recover managed standby database finish;

 

【2】从库切换成主库

alter database commit to switchover to primary;

 

【3】启动数据库

Alter database open;

 

【4】检查备库的状态

select open_mode,database_role from v$database;

OPEN_MODE       DATABASE_ROLE--------------      ---------------------- OPEN                 PRIMARY

 

【其他】切换完成后,就需要更改应用的连接IP地址和相关的一系列的连接(DBLINK等其他接口),如果再规划的时候就把这部分的内容考虑过去的话,那么就减少了很多切换后的工作。

如果服务器的IP地址不变的话,那么就可以节省很多的工作了。这就需要前期的规划:通过负载均衡设置一个虚拟ip,当服务器发生故障后,切换虚拟ip对应的实体ip就好了。如果没有这个硬件的话,通过软件也是可以实现的比如:keepalived工具等。

 

附:切换日志

  1. alter database recover managed standby database finish 停止应用进行日志的恢复
  2. Attempt to do a Terminal Recovery (DE2)
  3. Media Recovery Start: Managed Standby Recovery (DE2)
  4. started logmerger process
  5. Wed Mar 29 10:21:35 2017
  6. Managed Standby Recovery not using Real Time Apply
  7. Parallel Media Recovery started with 8 slaves
  8. Media Recovery Log /oracle/DE2/oraarch/DE2arch/1_565_912333510.dbf
  9. Media Recovery Waiting for thread 1 sequence 566 (in transit)
  10. krsv_proc_kill: Killing 4 processes (all RFS, wait for I/O)
  11. Begin: Standby Redo Logfile archival
  12. End: Standby Redo Logfile archival
  13. Terminal Recovery timestamp is '03/29/2017 10:21:43'
  14. Terminal Recovery: applying standby redo logs.
  15. Terminal Recovery: thread 1 seq# 566 redo required
  16. Terminal Recovery:
  17. Recovery of Online Redo Log: Thread 1 Group 14 Seq 566 Reading mem 0
  18. Mem# 0: /oracle/DE2/mirrlogA/sredo14.log
  19. Identified End-Of-Redo (failover) for thread 1 sequence 566 at SCN 0xffff.ffffffff
  20. Wed Mar 29 10:21:48 2017
  21. Incomplete Recovery applied until change 21240383491 time 03/29/2017 10:27:41
  22. Wed Mar 29 10:21:48 2017
  23. Media Recovery Complete (DE2)
  24. Terminal Recovery: successful completion
  25. Forcing ARSCN to IRSCN for TR 4:4060514307
  26. Attempt to set limbo arscn 4:4060514307 irscn 4:4060514307
  27. Resetting standby activation ID 1489765315 (0x58cc03c3)
  28. Wed Mar 29 10:21:51 2017
  29. ARCH: Archival stopped, error occurred. Will continue retrying
  30. ORACLE Instance DE2 - Archival Error
  31. ORA-16014: log 14 sequence# 566 not archived, no available destinations
  32. ORA-00312: online log 14 thread 1: '/oracle/DE2/mirrlogA/sredo14.log'
  33. Completed: alter database recover managed standby database finish 完成日志的应用
  34. Wed Mar 29 10:22:12 2017
  35. alter database commit to switchover to primary 从库切换成主库
  36. ALTER DATABASE SWITCHOVER TO PRIMARY (DE2)
  37. Maximum wait for role transition is 15 minutes.
  38. CLOSE: killing server sessions.
  39. CLOSE: all sessions shutdown successfully.
  40. Wed Mar 29 10:22:12 2017
  41. SMON: disabling cache recovery
  42. Backup controlfile written to trace file /oracle/DE2/saptrace/diag/rdbms/de2dg/DE2/trace/DE2_ora_9961494.trc
  43. Standby terminal recovery start SCN: 21240295534
  44. RESETLOGS after incomplete recovery UNTIL CHANGE 21240383491 重建redolog
  45. Online log /oracle/DE2/mirrlogB/log_g15m1.dbf: Thread 1 Group 5 was previously cleared
  46. Online log /oracle/DE2/mirrlogB/log_g15m2.dbf: Thread 1 Group 5 was previously cleared
  47. Online log /oracle/DE2/mirrlogA/log_g16m1.dbf: Thread 1 Group 6 was previously cleared
  48. Online log /oracle/DE2/mirrlogA/log_g16m2.dbf: Thread 1 Group 6 was previously cleared
  49. Online log /oracle/DE2/mirrlogB/log_g17m2.dbf: Thread 1 Group 7 was previously cleared
  50. Online log /oracle/DE2/mirrlogB/log_g17m1.dbf: Thread 1 Group 7 was previously cleared
  51. Online log /oracle/DE2/mirrlogA/log_g18m2.dbf: Thread 1 Group 8 was previously cleared
  52. Online log /oracle/DE2/mirrlogA/log_g18m1.dbf: Thread 1 Group 8 was previously cleared
  53. Standby became primary SCN: 21240295533
  54. Wed Mar 29 10:22:13 2017
  55. Setting recovery target incarnation to 3
  56. Switchover: Complete - Database mounted as primary
  57. Completed: alter database commit to switchover to primary 完成切换
  58. Wed Mar 29 10:22:37 2017
  59. alter database open
  60. Data Guard Broker initializing...
  61. Data Guard Broker initialization complete
  62. Data Guard: verifying database primary role...
目录
打赏
0
0
0
0
7
分享
相关文章
PG内核解读-第2节PostgreSQL体系结构
本文整理自阿里云数据库开源社区Maintainer于巍(花名漠雪),在PostgreSQL数据库内核解读系列的分享。本篇内容主要分为三个部分: 1. PostgreSQL系统表 2. PostgreSQL初始化、启动、查询流程 3. PostgreSQL辅助进程
PG内核解读-第2节PostgreSQL体系结构
Python并发风暴来袭!IO密集型与CPU密集型任务并发策略大比拼,你站哪队?
【7月更文挑战第17天】Python并发处理IO密集型(如网络请求)与CPU密集型(如数学计算)任务。IO密集型适合多线程和异步IO,如`ThreadPoolExecutor`进行网页下载;CPU密集型推荐多进程,如`multiprocessing`模块进行并行计算。选择取决于任务类型,理解任务特性是关键,以实现最佳效率。
269 4
PostgreSQL如何进行数据备份?
【8月更文挑战第4天】PostgreSQL如何进行数据备份?
798 6
深入探讨网络自动化的魅力所在,以及如何利用Python这一强大工具,实现网络设备的批量配置与监控
在信息洪流的浪潮中,网络自动化如同一盏明灯,引领着我们穿越复杂网络管理的迷雾。它不仅简化了网络运维人员的工作,更是在大数据、云计算等技术飞速发展的背景下,成为了构建高效、稳定网络环境的关键。本文将深入探讨网络自动化的魅力所在,以及如何利用Python这一强大工具,实现网络设备的批量配置与监控,以此展现网络自动化在简化复杂网络管理中的重要作用。
219 0
Docker环境下部署Ghost开源内容管理系统
【5月更文挑战第9天】Docker环境下部署Ghost开源内容管理系统
317 1
neo4j如何查看日志信息
【5月更文挑战第2天】neo4j如何查看日志信息
634 2
Redis热升级秘诀:保证高可用性的技术方案
Redis热升级方案允许在不中断业务的情况下,实现数千级别Redis的无缝更新。通过构建Redis Shell程序保存数据库状态,封装动态连接库,以及在运行时加载新版本库,保持客户端连接,该方法确保了业务连续性和高可用性,且升级仅需几毫秒,显著提升了系统效率。
828 6
深入探究LRU缓存机制:优化内存利用与提升性能
深入探究LRU缓存机制:优化内存利用与提升性能
1234 1
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问