原来 Oracle 19c ADG Switchover 切换如此简单

科技   2024-09-10 08:06   中国  
作者 | JiekeXu
来源 |公众号 JiekeXu DBA之路(ID: JiekeXu_IT)
如需转载请联系授权 | (个人微信 ID:JiekeXu_DBA)
大家好,我是 JiekeXu,江湖人称“强哥”,荣获 Oracle ACE Pro 称号,墨天轮 MVP,墨天轮年度“墨力之星”,拥有 Oracle 11g OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCP 等众多国产数据库认证证书,今天和大家一起来看看原来 Oracle 19c ADG Switchover 切换如此简单欢迎点击最上方蓝字“JiekeXu DBA之路”关注我的微信公众号,然后点击右上方三个点“设为星标”置顶,更多干货文章才能第一时间推送,谢谢!

目   录

前 言
环境说明
切换前准备
正式 Switchover 切换
生产环境切换演示过程

参考链接

前  言

近期有一套 Oracle 19c RAC Non-CDB 环境由于某种原因需要迁移到新的存储和主机上,计划使用 ADG Switchover 切换进行操作。之前也写过一篇《Oracle 19c ADG Swithover 切换手册》,包含一些切换前的检查步骤,沿用 Oracle 11g 的切换语法操作 19c 也是正常切换了。殊不知从 Oracle 12.1 开始有更简洁的切换命令,今天就来试试。

环境说明

环境示意图大概如下,将新搭建的 RAC 备库切换为主库,原备库跟在新主库后,异地灾备库不受影响。

切换前准备

Switchover 切换比较简单,但在切换前需要检查相关参数设置是否正常。

参数检查,比如下面的几个参数

show parameter archshow parameter db_file_name_convertshow parameter log_file_name_convertshow parameter standby_file_managementshow parameter fal_clientshow parameter fal_servershow parameter log_archive

然后检查备库是否出现延迟。

-- 检查同步延迟set linesize 150;set pagesize 20;column name format a13;column value format a20;column unit format a30;column TIME_COMPUTED format a30;select name,value,unit,time_computed,datum_time from v$dataguard_stats where name in ('transport lag','apply lag');

如果按照以前的经验则需要再检查这两套环境的参数,然后在各自环境上先关闭实例二,进而在主库先切换成备库,在备库上取消日志应用然后切换为主库,正常情况下则就完成了 ADG Switchover 切换。

现如今,在 Oracle 12c 及以上的版本中,变得更加简单,只需要一条命令就搞定了主备切换,是的,你没看错,就一条命令搞定。

首先我们验证目标备库是否已准备好进行切换。

新的切换语句有一个 VERIFY 选项,可以检查切换所需的许多条件。检查的项目包括:

  • 切换目标上是否正在运行重做应用;

  • 切换目标的发行版本是否为 12.1 或更高版本;

  • 切换目标是否同步;

  • 以及是否正在运行 MRP。


主库:DB_UNIQUE_NAME JIEKEXU
备库:DB_UNIQUE_NAME   JIEKEXUADG

在 JIEKEXU 主库上发出如下 SQL:

ALTER DATABASE SWITCHOVER TO JIEKEXUADG(adg:db_unique_name) VERIFY;

如果检查备库不满足切换为主库的条件,此验证命令则报错。例如:

SQL> ALTER DATABASE SWITCHOVER TO JIEKEXUADG VERIFY;ERROR at line 1:ORA-16470: Redo Apply is not running on switchover target
SQL> ALTER DATABASE SWITCHOVER TO JIEKEXUADG VERIFY;ERROR at line 1:ORA-16475: succeeded with warnings, check alert log for more details

然后如果此操作成功, Alter 日志则会返回一条消息,在此示例中返回了 ORA-16470 错误。此错误意味着切换目标JIEKEXUADG 尚未准备好进行切换。切换操作之前必须启动 Redo Apply。启动 Redo Apply 后,再次发出 VERIFY 语句,但是,错误指示的警告 ORA-16475 可能会影响切换性能。Alter 日志包含类似以下内容的消息:

SWITCHOVER VERIFY WARNING: switchover target has dirty online redo logfiles that require clearing. It takes time to clear online redo logfiles. This may slow down switchover process.翻译:切换验证警告:切换目标有需要清除的脏联机重做日志文件。清除联机重做日志文件需要时间。这可能会减慢切换过程。

修复这些问题后,或者如果切换性能不重要,则可以忽略这些警告。在完成您认为必要的任何修复后,再次发出以下验证 SQL 语句:

SQL> ALTER DATABASE SWITCHOVER TO JIEKEXUADG VERIFY;Database altered.

没有报错说明切换目标 JIEKEXUADG 现已准备好可以进行切换。

正式 Switchover 切换

在 JIEKEXU 主库上发出如下 SQL:

SQL> ALTER DATABASE SWITCHOVER TO JIEKEXUADG;Database altered.

如果上面 SQL 没有发生错误,则我们将继续将新主库 JIEKEXUADG 打开数据库(原备库目前处于 mount 状态,角色为 PRIMARY)。

SQL> ALTER DATABASE OPEN;
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE-------------------- ----------------READ WRITE PRIMARY

然后另一个节点目前也是出于 mount 状态,我们需要将其打开即可。

原主库 JIEKEXU 则处于关闭状态,但角色已经是只读备库了,我们需要将其启动,应用 MRP0 进程。

SQL> STARTUP;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
生产环境切换演示过程

根据最开始的环境说明架构图,我们在 19c 主库 A 上,发起一个 verify 验证命令,当执行成功后,我们则开始切换。

--75.41  19c 主库 A 节点 1-- 检查是否满足切换条件alter database switchover to jiekxustd verify;
-- 执行切换alter database switchover to jiekxustd;

如下,则是 alert 日志的详细信息,关键信息处我有注释,感兴趣的朋友可以自行查看。

-- 开始进行 verify 验证,但是出现了 ORA-16475 错误
alter database switchover to jiekxustd verify2024-09-07T10:27:58.306517+08:00SWITCHOVER VERIFY: Send VERIFY request to switchover target jiekxuSTD2024-09-07T10:27:58.569049+08:00SWITCHOVER VERIFY WARNING: switchover target has no standby database defined in LOG_ARCHIVE_DEST_n parameter. If the switchover target is converted to a primary database, the new primary database will not be protected.ORA-16475 signalled during: alter database switchover to jiekxustd verify...2024-09-07T10:28:11.096746+08:00Redo thread 2 internally disabled at seq 1494915 (CKPT)2024-09-07T10:28:12.421928+08:00ARC2 (PID:95808): Archiving disabled T-2.S-14949152024-09-07T10:28:12.434314+08:00ARC2 (PID:95808): Archived Log entry 7915636 added for T-2.S-1494915 ID 0x30a949 LAD:12024-09-07T10:29:58.493582+08:00ALTER SYSTEM SET log_archive_dest_state_4='ENABLE' SCOPE=MEMORY SID='*';
----修正后继续 verify 验证,没有报错。
2024-09-07T10:30:27.885453+08:00alter database switchover to jiekxustd verify2024-09-07T10:30:28.178822+08:00SWITCHOVER VERIFY: Send VERIFY request to switchover target jiekxuSTDSWITCHOVER VERIFY COMPLETE: READY FOR SWITCHOVERCompleted: alter database switchover to jiekxustd verify--开始切换,在原库 A 库节点 1 执行
alter database switchover to jiekxustd2024-09-07T10:31:00.894689+08:00NET (PID:52154): The Time Management Interface (TMI) is being enabled for role transitionNET (PID:52154): information. This will result in messages beingoutput to the alert logNET (PID:52154): file with the prefix 'TMI: '. This is being enabled to make the timing ofNET (PID:52154): the various stages of the role transition available for diagnostic purposes.NET (PID:52154): This output will end when the role transition is complete.TMI: dbsdrv switchover to target BEGIN 2024-09-07 10:31:00.895255NET (PID:52154): Starting switchover [Process ID: 52154]TMI: kcv_switchover_to_target convert to physical BEGIN 2024-09-07 10:31:01.1755472024-09-07T10:31:01.175676+08:00ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 52154] (jiekxu1)--原主库 A 库 switchover 完成后,则自动关闭实例
TMI: dbsdrv switchover to target END 2024-09-07 10:31:39.506972Completed: alter database switchover to jiekxustdShutting down ORACLE instance (abort) (OS id: 52154)Shutdown is initiated by sqlplus@xr-jiekxu-rac1 (TNS V1-V3).License high water mark = 6172024-09-07T10:31:39.632412+08:00Instance shutdown complete (OS id: 52154)
--这里手动 startup A 库实例,开启 mrp0 应用日志
2024-09-07T10:34:27.066622+08:00Starting ORACLE instance (normal) (OS id: 14744)
2024-09-07T10:34:27.199847+08:00

如下是原备库新 RAC 备库 D 的 RAC1 的 alert 日志,感兴趣的可以看看。

-- 192.168.75.11 备库 D RAC1 alert 
-- 原库主库 A 执行 verify 命令,备库 D 开始 SWITCHOVER VERIFY 验证2024-09-07T10:27:58.425521+08:00SWITCHOVER VERIFY BEGINSWITCHOVER VERIFY WARNING: no standby database is defined in LOG_ARCHIVE_DEST_n to protect this database if it is converted to a primary databaseSWITCHOVER VERIFY COMPLETE
-- 修复问题后,原库主库 A 第二次执行 verify 命令,很快执行完毕
2024-09-07T10:30:28.301628+08:00SWITCHOVER VERIFY BEGINSWITCHOVER VERIFY COMPLETE
-- 原库主库 A 执行 alter database switchover to jiekxustd 后,备库也开始切换,-- 执行来自主库的命令“'ALTER DATABASE COMMIT TO SWITCHOVER  TO PRIMARY' from primary database”
2024-09-07T10:31:01.022557+08:00 rfs (PID:65797): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:52154)2024-09-07T10:31:01.315903+08:00 rfs (PID:65935): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:78461)2024-09-07T10:31:04.356410+08:00 rfs (PID:65974): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:52154)2024-09-07T10:31:04.401664+08:00 rfs (PID:65974): Selected LNO:11 for T-1.S-2395893 dbid 4212766427 branch 10374056322024-09-07T10:31:05.566551+08:00PR00 (PID:72131): Resetting standby activation ID 3189065 (0x30a949)2024-09-07T10:31:05.567668+08:00Media Recovery End-Of-Redo indicator encountered2024-09-07T10:31:05.567693+08:00Media Recovery ContinuingPR00 (PID:72131): Media Recovery Waiting for T-1.S-23958942024-09-07T10:31:06.556422+08:00.... (PID:66252): The Time Management Interface (TMI) is being enabled for role transition.... (PID:66252): information. This will result in messages beingoutput to the alert log.... (PID:66252): file with the prefix 'TMI: '. This is being enabled to make the timing of.... (PID:66252): the various stages of the role transition available for diagnostic purposes..... (PID:66252): This output will end when the role transition is complete.SWITCHOVER: received request 'ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY' from primary database.2024-09-07T10:31:06.557276+08:00ALTER DATABASE SWITCHOVER TO PRIMARY (jiekxu1)Maximum wait for role transition is 15 minutes.
-- 等待 MRP0 完成,取消 MRP0 进程
TMI: kcv_commit_to_so_to_primary wait for MRP to finish BEGIN 2024-09-07 10:31:06.557329Switchover: Media recovery is still active rmi (PID:66252): Role Change: Canceling MRP - no more redo to apply2024-09-07T10:31:06.602122+08:00PR00 (PID:72131): MRP0: Background Media Recovery cancelled with status 160372024-09-07T10:31:06.615042+08:00Errors in file /u01/app/oracle/diag/rdbms/jiekxustd/jiekxu1/trace/jiekxu1_pr00_72131.trc:ORA-16037: user requested cancel of managed recovery operation2024-09-07T10:31:06.615930+08:00.... (PID:67534): Managed Standby Recovery not using Real Time Apply2024-09-07T10:31:06.631630+08:00ARC2 (PID:68019): Archived Log entry 31860 added for T-1.S-2395893 ID 0x30a949 LAD:12024-09-07T10:31:07.105227+08:00Recovery interrupted!2024-09-07T10:31:07.434837+08:00
2024-09-07T10:31:07.434837+08:00Reconfiguration started (old inc 6, new inc 8)List of instances (total 2) : 1 2My inst 1 Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out
--集群重配完成 14.9 secs
LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 02024-09-07T10:31:09.020352+08:00 Set master node info Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted2024-09-07T10:31:22.306394+08:00Reconfiguration complete (total time 14.9 secs)2024-09-07T10:31:22.629666+08:00
--原备库 D 库自动重启实例到 mount ,角色变为主库
KZAUDIT: AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.2024-09-07T10:31:37.534662+08:00 rmi (PID:66252): Database role cleared from PHYSICAL STANDBY [kcvs.c:1134]Enabling Dynamic Remastering: STNDB->NORM switchSwitchover: Complete - Database mounted as primaryTMI: kcv_commit_to_so_to_primary Switchover from physical END 2024-09-07 10:31:37.871995SWITCHOVER: completed request from primary database.
---手动打开 D 库实例 1 和实例 2 alter database open 角色变为读写模式
2024-09-07T10:32:54.524217+08:00alter database open2024-09-07T10:32:54.524276+08:00TMI: adbdrv open database BEGIN 2024-09-07 10:32:54.5242422024-09-07T10:32:54.527109+08:00idle dispatcher 'D000' terminated, pid = (67, 1)2024-09-07T10:32:54.540899+08:00This instance was first to open
2024-09-07T10:32:57.910622+08:00CJQ0 started with pid=294, OS id=72255Completed: alter database open

这样,整个 ADG Switchover 就完成了,过程如此丝滑,操作更丝滑。

切换完成后,我们需要在新主库上调整备库相关参数,以符合我们前面说的 D 库作为主库,A 库作为他的备库,原来的同城 B 库要作为 D 库的备库,异地灾备 C 库级联到 B 库,整体符合如下图示要求。

--D 库
select open_mode,database_role from v$database;
alter system set log_archive_config='dg_config=(jiekxu,jiekxustd,jiekxuadg,jiekxudg)';alter system set log_archive_dest_2='service=jiekxuadg ASYNC valid_for=(online_logfiles,primary_role) compression=enable db_unique_name=jiekxuadg';alter system set log_archive_dest_3='service=jiekxu ASYNC valid_for=(online_logfiles,primary_role) compression=enable db_unique_name=jiekxu';
-- 启动servicesrvctl start service -db jiekxustd -service jiekxu_datasrvctl start service -db jiekxustd -service jiekxu_etl

备库相关参数设置

--19c A库,目前为备库startupalter database recover managed standby database disconnect from session;select open_mode,database_role from v$database;select PROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKS FROM V$MANAGED_STANDBY;
--同城备库 Balter system set log_archive_config=dg_config=(jiekxu,jiekxustd,jiekxuadg,jiekxudg);alter system set log_archive_dest_2='service=jiekxustd ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=jiekxustd';
select PROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKS FROM V$MANAGED_STANDBY;select name,value,unit,time_computed from v$dataguard_stats where name in ('transport lag','apply lag');
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;alter database flashback on;ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;select NAME,LOG_MODE,VERSION_TIME,OPEN_MODE,FLASHBACK_ON from v$database;

除了以上参数设置外,还需要注意网络、防火墙、TNS 是否均已配置好,另外原主备互切后,db_file_name_convert 和 log_file_name_convert 参数以及 db_create_file_dest 参数是否正确,以防止新主库添加表空间和数据文件时无法同步到备库 B 或者级联备库 C,我这里就因为没有使用 OMF 置空了 db_create_file_dest 参数,主库发生切换 convert 参数又设置的不正确导致新增数据文件无法同步到级联备库。

无法传递数据文件到备库,则会导致 MRP0 进程挂掉,但是会在控制文件中记录 “$ORACLE_HOME/dbs/unknown” 这么一个文件,实际上 dbs 目录下也没有生成此文件。那么怎么处理呢?

还记得大概一年前的时间,有开发无意中 rm dbf 数据文件时的处理方案大同小异,如果还有没看到的戳这里查看,在 Oracle 归档模式下直接 rm dbf 数据文件并重启数据库还有救吗?本次问题发现的及时,还有归档日志保留了三四天,算是比较完整,处理起来也就比较顺手了。

--先取消 MRP0 进程ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
show parameter standby_file_managementalter system set standby_file_management=MANUAL;
--执行此命令则可实际在 datafile 目录下创建原大小的数据文件alter database create datafile '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/unknown' as '/data/jiekexuadg/datafile/jiekexu_data08.dbf';
alter system set standby_file_management=AUTO;
--启动 MRP0 进程ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

这样第一个数据文件则就可以正常同步了,由于归档日志没有中断,convert 参数也调整了,后续的数据文件也能正常同步了,启动 MRP0 进程小半天的时间则已经正常同步了,完美收工!!!

参考链接

https://docs.oracle.com/en/database/oracle/oracle-database/23/sbydb/performing-oracle-data-guard-role-transitions.html#GUID-EEBC6DA6-E192-470E-8FC9-F507B004406E
https://docs.oracle.com/en/database/oracle/oracle-database/19/spmss/switchover-to-a-physical-db.html#GUID-AAD70601-D248-4309-B8DD-F461EE31A5FF

全文完,希望可以帮到正在阅读的你,如果觉得有帮助,可以分享给你身边的朋友,同事,你关心谁就分享给谁,一起学习共同进步~~~

欢迎关注我的公众号【JiekeXu DBA之路】,一起学习新知识!



分享几个数据库备份脚本

一文搞懂 Oracle 统计信息

我的 Oracle ACE 心路历程

MOP 系列|MOP 三种主流数据库索引简介

Oracle 主流版本不同架构下的静默安装指南

关机重启导致 ASM 磁盘丢失数据库无法启动

Oracle SQL 性能分析(SPA)原理与实战演练

Oracle 11g 升级到 19c 需要关注的几个问题

Windows 10 环境下 MySQL 8.0.33 安装指南

SQL 大全(四)|数据库迁移升级时常用 SQL 语句

OGG|使用 OGG19c 迁移 Oracle11g 到 19C(第二版)

Oracle 大数据量导出工具——sqluldr2 的安装与使用

从国产数据库调研报告中你都能了解哪些信息及我的总结建议

使用数据泵利用 rowid 分片导出导入 lob 大表及最佳实践

在归档模式下直接 rm dbf 数据文件并重启数据库还有救吗?

欢迎关注我的公众号【JiekeXu DBA之路】,一起学习新知识!
——————————————————————————
公众号:JiekeXu DBA之路
墨天轮:https://www.modb.pro/u/4347

CSDN :https://blog.csdn.net/JiekeXu
ITPUB:https://blog.itpub.net/69968215
腾讯云:https://cloud.tencent.com/developer/user/5645107
——————————————————————————

JiekeXu DBA之路
JiekeXu:Oracle ACE-Pro,获 Oracle OCP/OCM 及 MySQL OCP 认证,墨天轮 MVP,利用闲时间记录菜鸟 DBA 学习成长之路,所发布文字属于个人观点和学习笔记,如有错误及不当之处,敬请批评指正!
 最新文章