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...
相关文章
|
分布式计算 并行计算 Java
Python并发风暴来袭!IO密集型与CPU密集型任务并发策略大比拼,你站哪队?
【7月更文挑战第17天】Python并发处理IO密集型(如网络请求)与CPU密集型(如数学计算)任务。IO密集型适合多线程和异步IO,如`ThreadPoolExecutor`进行网页下载;CPU密集型推荐多进程,如`multiprocessing`模块进行并行计算。选择取决于任务类型,理解任务特性是关键,以实现最佳效率。
369 4
|
运维 数据安全/隐私保护 Python
Python基于telnetlib模块实现交换机全面巡检自动化运维项目
Python基于telnetlib模块实现交换机全面巡检自动化运维项目
|
运维 监控 大数据
深入探讨网络自动化的魅力所在,以及如何利用Python这一强大工具,实现网络设备的批量配置与监控
在信息洪流的浪潮中,网络自动化如同一盏明灯,引领着我们穿越复杂网络管理的迷雾。它不仅简化了网络运维人员的工作,更是在大数据、云计算等技术飞速发展的背景下,成为了构建高效、稳定网络环境的关键。本文将深入探讨网络自动化的魅力所在,以及如何利用Python这一强大工具,实现网络设备的批量配置与监控,以此展现网络自动化在简化复杂网络管理中的重要作用。
288 0
|
存储 监控 数据库
neo4j如何查看日志信息
【5月更文挑战第2天】neo4j如何查看日志信息
749 2
|
网络协议 数据安全/隐私保护 网络架构
计算机网络——第一章体系结构相关习题及详细解析
计算机网络——第一章体系结构相关习题及详细解析
240 0
|
SQL 关系型数据库 MySQL
Mysql主从同步报错解决:Fatal error: The slave I/O thread stops because ..
Mysql主从同步报错解决:Fatal error: The slave I/O thread stops because ..
1386 0
|
SQL 监控 Oracle
ORACLE常用性能监控SQL【二】
ORACLE常用性能监控SQL【二】
249 0
|
存储 Kubernetes 负载均衡
k8s离线安装部署教程X86(一)
k8s离线安装部署教程 文件名称 版本号 linux核心 docker版本 20.10.9 x86 k8s版本 v1.22.4 x86 kuboard v3 x86 一、k8s(x86) 1.dock
2107 0
|
虚拟化
【FusionCompute】添加CNA主机到VRM管理节点(四)
【FusionCompute】添加CNA主机到VRM管理节点(四)
870 0
【FusionCompute】添加CNA主机到VRM管理节点(四)