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 -t
lsnrctl status

Ø 检查主备库打开状态，模式

检查数据库实例状态，正常状态为open
select instance_name,status from gv$instance;
检查数据库打开模式
OPEN_MODE正常状态为READ WRITE
LOG_MODE正常状态为ARCHIVELOG 
DATABASE_ROLE正常状态为PRIMARY
select INST_ID,NAME,open_mode,LOG_MODE,DATABASE_ROLE,PROTECTION_MODE,DB_UNIQUE_NAME from  gv$database;

Ø 主备库的 DG 参数检查确认

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_config
show parameter log_archive_dest_2
show parameter log_archive_dest_2_state

Ø 检查主库

col DEST_NAME for a30
select 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 logs
show  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 logs
SQL> 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 a50
select 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 a50
SELECT 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的数据文件，且是切换为主库所需要的数据文件，需要online
SQL> 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 -l

2、正式切换 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 immediate

4. edwstb备库关闭实例2

srvctl stop instance -d edwstb  -i edwstb2 -o immediate

5. 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 16047
16047, 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.03
19:38:20 SQL> select dest_name,status,error from v$archive_dest;
 
DEST_NAME                      STATUS    ERROR
------------------------------ --------- -----------------------------------------------------------------
LOG_ARCHIVE_DEST_1             VALID
LOG_ARCHIVE_DEST_2             VALID
LOG_ARCHIVE_DEST_3             INACTIVE

10. 备库只读打开(可选)

可根据实际情况，选择是否打开备库。

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

————————————————————————----———

基于 VMWARE Oracle Linux7.9 安装 Oracle19c RAC 详细配置方案

爆肝一万字终于把 Oracle Data Guard 核心参数搞明白了

使用 VMware 16 RHEL7.7 虚拟机静默安装 Oracle 19c RAC

Oracle 12c 及以上版本补丁更新说明及下载方法（收藏版）

Oracle 19c 19.10DBRU 最新补丁升级看这一篇就够了

Redhat 7.7 安装最新版 MongoDB 5.0.1 手册

ASM 管理的内部工具：KFED、KFOD、AMDU

性能优化|关于数据库历史性能问题的一道面试题

一线运维 DBA 五年经验常用 SQL 大全（二）

ORA-00349|激活 ADG 备库时遇到的问题

OGG-01004|OGG 初始化数据问题处理

Oracle 轻量级实时监控工具 oratop

Linux 7.7 源码安装 MySQL 8.0.26

MySQL OCP 认证考试你知道吗？

Oracle 19C RAC 安装遇到的坑

国产数据库|TiDB 5.0 快速体验

Oracle 19C MAA 搭建指南

Oracle 每日一题系列合集

百花齐放的国产数据库