Oracle 19c ADG Swithover 切换手册
作者 | JiekeXu
来源 | JiekeXu DBA之路（ID: JiekeXu_IT）
大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 Oracle 19c ADG Swithover 切换流程，欢迎点击上方蓝字关注我，标星或置顶，更多干货第一时间到达！
本文档主要是根据前面文档中搭建的 Oracle 19c MAA 架构的备库进行 Swithover 切换，然后将备库变为主库，主库变为备库，达到一个迁移的目的。
源地址IP为 192.168.0.86/87，目标端IP地址段为：192.168.21.81-87。规则如下：其中81/82/83为SCAN，86/84为一节点的PUB/VIP，87/85为二节点的PUB/VIP。
其中IP地址列表如下：
源端IP | 192.168.0.86/87 | 目标端IP | 192.168.21.86/87 |
源端版本 | Linux7 RAC 19.4.0 | 目标端版本 | Linux7 RAC 19.4.0 |
源端字符集 | AL32UTF8 | 目标端字符集 | AL32UTF8 |
源端db | edw | 目标端db | edwstb |
文章标题《Oracle 19c ADG Swithover 切换手册》那必定可以当手册使用，文档也已经整理好了，在本公众号后台回复关键字【ADG切换手册】获取本文文档版本。
1、切换前准备工作
Ø 检查集群状态，监听状态
crsctl status res -tlsnrctl statusØ 检查主备库打开状态，模式
检查数据库实例状态，正常状态为openselect instance_name,status from gv$instance;检查数据库打开模式OPEN_MODE正常状态为READ WRITELOG_MODE正常状态为ARCHIVELOG DATABASE_ROLE正常状态为PRIMARYselect INST_ID,NAME,open_mode,LOG_MODE,DATABASE_ROLE,PROTECTION_MODE,DB_UNIQUE_NAME from gv$database;Ø 主备库的 DG 参数检查确认
show parameter db_file_name_convertshow parameter log_file_name_convertshow parameter standby_file_managementshow parameter fal_clientshow parameter fal_servershow parameter log_archive_configshow parameter log_archive_dest_2show parameter log_archive_dest_2_stateØ 检查主库
col DEST_NAME for a30select DEST_ID,DEST_NAME,STATUS,RECOVERY_MODE from V$ARCHIVE_DEST_STATUS where DEST_NAME='LOG_ARCHIVE_DEST_2';status正常状态为VALID ，如果备库停止日志传输，设置defer则status为BAD PARAM RECOVERY_MODE正常状态为 MANAGED REAL TIME APPLY如果备库恢复模式不是“REAL TIME APPLY”，备库重启日志恢复进程，起用“REAL TIME APPLY”[备库][oracle用户][节点1]ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;Ø 检查主库、备库确定有足够的归档进程
log_archive_max_processes值需大于等于4，但也不会太大。show parameter LOG_ARCHIVE_MAX_PROCESSESØ 检查standby redo是否创建了
select * from v$logfile;Ø 备库检查redo logs是否需要清理
[备库][oracle用户][节点1][SQL]备库查询redo logs是否需要清理，有数据则说明需要清理SQL>SELECT DISTINCT L.GROUP# FROM V$LOG L, V$LOGFILE LF WHERE L.GROUP# = LF.GROUP# AND L.STATUS NOT IN ('UNUSED','CLEARING','CLEARING_CURRENT');
如果存在需要清理的redo,可通过以下两种方式处理:1）备库设置LOG_FILE_NAME_CONVERT参数，主备切换时会自动清理redo logs,该参数为静态参数，如搭建时未设置，设置需重启数据库生效。如该参数已设置，官方仍建议切换前清理redo logsshow parameter LOG_FILE_NAME_CONVERT;设置方法：alter system set log_file_name_convert='+ARCH','+ARCH' scope=spfile;shutdown immediate;startup;2）需要停止日志应用，通过group#清理redo logs取消日志应用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;清理redo logsSQL> ALTER DATABASE CLEAR LOGFILE GROUP <需要清理的日志组号>;重新应用日志ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;Ø 检查主库standby日志情况
检查主库是否创建了standby的redo log日志
注意：standby的redo log日志要比源库的redo log日志多一组，大小和redo log大小一致，例如源库数据库的 redo log 为2组4个，那么standby 的redo log应该为3组6个
1）查看redo log情况
select group#,thread#,sequence#,members,archived,status,bytes/1024/1024 M from v$log order by 1;2）查看standby日志情况
col MEMBER for a50select GROUP#,THREAD#,BYTES/1024/1024 M,STATUS from v$STANDBY_log;如果主库没有standby日志组，可使用如下语句添加添加standby日志组：（比主库多添加一组）alter database add standby logfile thread 1 size 512m;alter database add standby logfile thread 1 size 512m;alter database add standby logfile thread 1 size 512m;alter database add standby logfile thread 2 size 512m;alter database add standby logfile thread 2 size 512m;alter database add standby logfile thread 2 size 512m;Ø 备库查询应用到的日志REDO SEQUENCE
主库查询当前的REDO SEQUENCE
SELECT THREAD#, SEQUENCE# FROM V$THREAD;
备库查询应用到的日志REDO SEQUENCE ，正常查询结果和上面主库的REDO SEQUENCE 数值只差1～2个
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED = 'YES' AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE# FROM V$DATABASE_INCARNATION WHERE STATUS = 'CURRENT') GROUP BY THREAD#;Ø 备库检查数据库是否有gap
检查数据库是否有gap，正常没有select thread#,low_sequence#,high_sequence# from v$archive_gap;Ø 检查下当前应用进程是否有延时
column name format a13;column value format a20;column unit format a30;column TIME_COMPUTED format a30;select name,value,unit,time_computed from v$dataguard_stats where name in ('transport lag','apply lag');Ø 关闭应用并确认当前连接会话
select username,sid,status,event,program,machine,sql_id from v$session where username !='SYS'; select username,sid,status,event,program,machine,sql_id,logon_time from gv$session where username !='SYS' order by logon_time desc;Ø 主库、备库确定数据文件、临时文件状态
确定主备数据库临时文件一致，且所有的数据文件都是online的
col FILENAME for a50SELECT TMP.NAME FILENAME, BYTES/1024/1024 M, TS.NAME TABLESPACE FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#; SELECT NAME FROM V$DATAFILE WHERE STATUS='OFFLINE';如果存储offline的数据文件，且是切换为主库所需要的数据文件，需要onlineSQL> ALTER DATABASE DATAFILE 'datafile-name' ONLINE;Ø 主库验证当前是否可转换为备库
检查主库 switchover_status状态，正常结果为TO STANDBY或SESSION ACTIVE
select switchover_status from v$database;注意事项：
如果switchover_status为TO_STANDBY说明可以直接转换
alter database commit to switchover to physical standby;
如果switchover_status为SESSIONS ACTIVE ，但是查询V$SESSION会话，都是系统会话，可以通过如下命令在主库进行SWITCHOVER切换。
alter database commit to switchover to physical standby with session shutdown; SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;SWITCHOVER_STATUS----------------------------------TO STANDBY 或者SESSIONS ACTIVE --备库状态SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS--------------------NOT ALLOWEDØ 再次确认下主库上面的crontab job是否转移到备库上了
crontab -l2、正式切换 switchover
1. 修改主库ORA30A参数（当主备库的目录结构不一致时需要修改此参数）
#以下参数需要重启方能生效alter system set db_file_name_convert='+DATA','+DATA' scope=spfile;alter system set log_file_name_convert='+FRA','+FRA' scope=spfile;2. 修改备库ORA30A_JX参数（当主备库的目录结构不一致时需要修改此参数）
#以下参数需要重启方能生效alter system set db_file_name_convert='+DG_DATA/ora30astd_jx' ,'+DG_DATA/ora30a_jx' scope=spfile;alter system set log_file_name_convert='+DG_REDO/ora30astd_jx','+DG_REDO/ora30a_jx' scope=spfile;本次 MAA 切换不需要修改此参数。
3. edw主库关闭实例2
srvctl stop instance -d edw -i edw2 -o immediate4. edwstb备库关闭实例2
srvctl stop instance -d edwstb -i edwstb2 -o immediate5. edw主库切换到standby
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;6. 验证备库的切换状态
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;SWITCHOVER_STATUS--------------------TO PRIMARY --如果备库为 SESSIONS ACTIVE 但查询没有会话则可以重启一下7. 切换备库为主库
SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;SQL>alter database open;8. 打开新备库的日志同步进程
SQL> startup mount SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;9. 验证切换后的结果
主库进行日志切换，查看备库的日志，看是否开始接收并应用。
经过检查多次切换日志，新备库均没有接受到日志，这个可能的原因比较多，按照之前说的检查备库 alert 日志，没有报错，只有一句提示：
2021-06-09T18:50:01.005734+08:00
TT02 (PID:26883): LOG_FILE_NAME_CONVERT is not defined, stop clearing ORLs
那么既然有这个提示就修改一下这个参数吧。只在备库修改，然后重启备库，应用日志后还是没有同步。
ALTER SYSTEM SET db_file_name_convert='+DATA','+DATA' SCOPE=SPFILE;alter system set log_file_name_convert='+DATA','+DATA' scope=spfile;不过终于在主库的 alert 日志中发现了错误 ORA-16047
ORA-16047: DGID mismatch between destination setting and target database
2021-06-09T19:27:17.609158+08:00
查看错误居然报备库 DB_UNIQUE_NAME 不匹配，检查备库参数后也没问题。
[oracle]$ oerr ora 1604716047, 00000, "DGID mismatch between destination setting and target database"// *Cause: The DB_UNIQUE_NAME specified for the destination did not match// the DB_UNIQUE_NAME at the target database.// *Action: Ensure that the DB_UNIQUE_NAME specified in the LOG_ARCHIVE_DEST_n// parameter matches the DB_UNIQUE_NAME parameter defined at the// destination.然后通过以下视图查看时，在新主库上发现了错误。参数 LOG_ARCHIVE_DEST_2 配置错误，参数中 SERVICE 和 DB_UNIQUE_NAME 果然不匹配，重新修改后备库立马恢复正常，同步正常。
select dest_name,status,error from v$archive_dest; 19:37:22 SQL> show parameter LOG_ARCHIVE_DEST_2 NAME TYPE VALUE------------------------------------ ----------- ------------------------------log_archive_dest_2 string SERVICE=EDWSTB LGWR ASYNC VALI D_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) DB_UNIQUE_NAME=edw 19:37:32 SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=EDW LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=edw'; System altered. Elapsed: 00:00:00.0319:38:20 SQL> select dest_name,status,error from v$archive_dest; DEST_NAME STATUS ERROR------------------------------ --------- -----------------------------------------------------------------LOG_ARCHIVE_DEST_1 VALIDLOG_ARCHIVE_DEST_2 VALIDLOG_ARCHIVE_DEST_3 INACTIVE10. 备库只读打开(可选)
可根据实际情况，选择是否打开备库。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;SQL> alter database open;SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;11. 打开RAC的另一个节点
主库和备库的另一个节点都可以打开。
startup
3、检查修改DBLINK
由于迁移主机发生变化了，因此需要检查确认是否有其他数据库配置了到本数据库的DBLINK连接。检查下是否存在其他库到本库的DBLINK，若有，则在那些库上面，修改dblink涉及到的本数据库服务器IP地址。
select * from dba_db_links;4、修改应用连接 IP 地址
由于数据库服务器IP地址发生了变化，因此需要将应用连接到数据库的IP地址也进行修改。
5、启应用
以上步骤全部完成之后，启应用，检查日志并确认下应用连接是否正常，业务测试。
本次分享到此结束啦~
❤️ 欢迎关注我的公众号，来一起玩耍吧！！！
——————————————————————--—--————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
腾讯云：https://cloud.tencent.com/developer/user/5645107
————————————————————————----———