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

JiekeXu

于 2024-09-10 08:06:34 发布

阅读量1k

点赞数 24

文章标签： oracle 数据库

本文链接：https://blog.csdn.net/jiekexu/article/details/142135591

版权

作者 | 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 arch
show parameter db_file_name_convert
show parameter log_file_name_convert
show parameter standby_file_management
show parameter fal_client
show parameter fal_server
show 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 verify
2024-09-07T10:27:58.306517+08:00
SWITCHOVER VERIFY: Send VERIFY request to switchover target jiekxuSTD
2024-09-07T10:27:58.569049+08:00
SWITCHOVER 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:00
Redo thread 2 internally disabled at seq 1494915 (CKPT)
2024-09-07T10:28:12.421928+08:00
ARC2 (PID:95808): Archiving disabled T-2.S-1494915
2024-09-07T10:28:12.434314+08:00
ARC2 (PID:95808): Archived Log entry 7915636 added for T-2.S-1494915 ID 0x30a949 LAD:1
2024-09-07T10:29:58.493582+08:00
ALTER SYSTEM SET log_archive_dest_state_4='ENABLE' SCOPE=MEMORY SID='*';


----修正后继续 verify 验证，没有报错。


2024-09-07T10:30:27.885453+08:00
alter database switchover to jiekxustd verify
2024-09-07T10:30:28.178822+08:00
SWITCHOVER VERIFY: Send VERIFY request to switchover target jiekxuSTD
SWITCHOVER VERIFY COMPLETE: READY FOR SWITCHOVER
Completed: alter database switchover to jiekxustd verify
--开始切换，在原库 A 库节点 1 执行


alter database switchover to jiekxustd
2024-09-07T10:31:00.894689+08:00
NET  (PID:52154): The Time Management Interface (TMI) is being enabled for role transition
NET  (PID:52154): information.  This will result in messages beingoutput to the alert log
NET  (PID:52154): file with the prefix 'TMI: '.  This is being enabled to make the timing of
NET  (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.895255
NET  (PID:52154): Starting switchover [Process ID: 52154]
TMI: kcv_switchover_to_target convert to physical BEGIN 2024-09-07 10:31:01.175547
2024-09-07T10:31:01.175676+08:00
ALTER 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.506972
Completed: alter database switchover to jiekxustd
Shutting down ORACLE instance (abort) (OS id: 52154)
Shutdown is initiated by sqlplus@xr-jiekxu-rac1 (TNS V1-V3).
License high water mark = 617
2024-09-07T10:31:39.632412+08:00
Instance shutdown complete (OS id: 52154)


--这里手动 startup A 库实例，开启 mrp0 应用日志


2024-09-07T10:34:27.066622+08:00
Starting 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:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY WARNING: no standby database is defined in LOG_ARCHIVE_DEST_n to protect this database if it is converted to a primary database
SWITCHOVER VERIFY COMPLETE


-- 修复问题后，原库主库 A 第二次执行 verify 命令，很快执行完毕


2024-09-07T10:30:28.301628+08:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER 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 1037405632
2024-09-07T10:31:05.566551+08:00
PR00 (PID:72131): Resetting standby activation ID 3189065 (0x30a949)
2024-09-07T10:31:05.567668+08:00
Media Recovery End-Of-Redo indicator encountered
2024-09-07T10:31:05.567693+08:00
Media Recovery Continuing
PR00 (PID:72131): Media Recovery Waiting for T-1.S-2395894
2024-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:00
ALTER 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.557329
Switchover: Media recovery is still active
 rmi (PID:66252): Role Change: Canceling MRP - no more redo to apply
2024-09-07T10:31:06.602122+08:00
PR00 (PID:72131): MRP0: Background Media Recovery cancelled with status 16037
2024-09-07T10:31:06.615042+08:00
Errors in file /u01/app/oracle/diag/rdbms/jiekxustd/jiekxu1/trace/jiekxu1_pr00_72131.trc:
ORA-16037: user requested cancel of managed recovery operation
2024-09-07T10:31:06.615930+08:00
.... (PID:67534): Managed Standby Recovery not using Real Time Apply
2024-09-07T10:31:06.631630+08:00
ARC2 (PID:68019): Archived Log entry 31860 added for T-1.S-2395893 ID 0x30a949 LAD:1
2024-09-07T10:31:07.105227+08:00
Recovery interrupted!
2024-09-07T10:31:07.434837+08:00


2024-09-07T10:31:07.434837+08:00
Reconfiguration started (old inc 6, new inc 8)
List of instances (total 2) :
 1 2
My 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 0
2024-09-07T10:31:09.020352+08:00
 Set master node info
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
2024-09-07T10:31:22.306394+08:00
Reconfiguration 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 switch
Switchover: Complete - Database mounted as primary
TMI: kcv_commit_to_so_to_primary Switchover from physical END 2024-09-07 10:31:37.871995
SWITCHOVER: completed request from primary database.


---手动打开 D 库实例 1 和实例 2 alter database open 角色变为读写模式


2024-09-07T10:32:54.524217+08:00
alter database open
2024-09-07T10:32:54.524276+08:00
TMI: adbdrv open database BEGIN 2024-09-07 10:32:54.524242
2024-09-07T10:32:54.527109+08:00
idle dispatcher 'D000' terminated, pid = (67, 1)
2024-09-07T10:32:54.540899+08:00
This instance was first to open


2024-09-07T10:32:57.910622+08:00
CJQ0 started with pid=294, OS id=72255
Completed: 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';


-- 启动service
srvctl start service -db jiekxustd -service jiekxu_data
srvctl start service -db jiekxustd -service jiekxu_etl

备库相关参数设置

--19c A库，目前为备库
startup
alter 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;


--同城备库 B
alter 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_management
alter 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
——————————————————————————