Oracle 18c&19c physical dg切换总结

这篇文章总结Oracle 18c/19c Physical Standby DG的主备切换的操作流程,主要参考官方文档18c & 19c Physical Standby Switchover Best Practices using SQL*Plus (Doc ID 2485237.1)[1].
由于参考官方的最佳实践，所以有些步骤/过程略显繁琐。其实正常情况下，这里面的很多步骤都可以略过。但是不妨我们从更严谨的态度和细节方面了解更多的技术细节。

前提条件(Prerequisites)检查

DG的设置/配置验证

• Primary & Standby 应使用相同版本的RDBMS
• 检查/验证主备库的告警日志，并确保没有错误或告警

$ grep "ORA-" alert_.log 
$ tail -600 alert_.log  | grep "ORA-"


• 在主库和备用数据库运行下面SQL检查验证没有坏块

select * from v$database_block_corruption; 
select * from v$nonlogged_block;


注意：没有记录表示正常，如果有相关记录返回，则表示数据库存在坏块。

• 确保主库和备库的配置正常/正确，并且重做日志传输(redo transport)和重做日志应用(redo apply)中没有错误
• 验证物理备用数据库是否正常运行,检查DG的主备库情况

获取主备库的信息以及保护模式(主备库执行)

set linesize 720
col name for a10
col open_mode for a20
col database_role for a16
col switchover_status for a12 heading "SWITCHOVER |STATUS"
col force_logging for a8
col dataguard_broker for a8 heading "DATAGUARD|BROKER"
col guard_status for a8
select name
      ,open_mode
      ,database_role
      ,protection_mode
      ,protection_level
      ,switchover_status 
      ,force_logging
      ,dataguard_broker
      ,guard_status
from v$database;


检查主库下SWITCHOVER_STATUS字段，如果值为"SESSION ACTIVE"或者"TO STANDBY", 则主数据库角色可以切换为备库角色。关于SWITCHOVER_STATUS字段的各个取值如下所示：

检查主库重做日志传输和应用状态

主库(Primary)

COL DEST_NAME FOR A20
COL DESTINATION FOR A25
COL ERROR FOR A15
COL ALTERNATE FOR A20
SET LINES 1000
SELECT DEST_NAME,DESTINATION,ERROR
      ,ALTERNATE,TYPE,STATUS
      ,VALID_TYPE,VALID_ROLE 
FROM V$ARCHIVE_DEST 
WHERE STATUS 'INACTIVE';


重点关注ERROR字段的输出信息，如果重做日志传输和应用有问题，就会有相关错误信息提示。

检查主库最后生成的归档日志文件

主库(Primary)

SELECT   THREAD#, MAX(SEQUENCE#) "Last Primary Seq Generated"  
FROM     GV$ARCHIVED_LOG VAL, GV$DATABASE VDB
WHERE    VAL.RESETLOGS_CHANGE# = VDB.RESETLOGS_CHANGE#
GROUP BY THREAD# ORDER BY 1;


备库(Standby)检查验证最后收到主库的归档日志

--Using the below query, check the last received archivelog from primary database 
--(RAC database result will be displayed for each thread).
SELECT   THREAD#, MAX(SEQUENCE#) "Last Standby Seq Received"  
FROM     GV$ARCHIVED_LOG VAL, GV$DATABASE VDB
WHERE    VAL.RESETLOGS_CHANGE# = VDB.RESETLOGS_CHANGE#
GROUP BY THREAD# ORDER BY 1;


备库(standby)检查最后应用的归档日志序列

--Check last archive log sequence applied at standby.
SELECT    THREAD#, MAX(SEQUENCE#) "Last Standby Seq Applied"
FROM     GV$ARCHIVED_LOG VAL, GV$DATABASE VDB
WHERE    VAL.RESETLOGS_CHANGE# = VDB.RESETLOGS_CHANGE#
AND      VAL.APPLIED IN ('YES','IN-MEMORY')
GROUP BY THREAD# ORDER BY 1; 


验证初始化参数

--主库(primary)&备库(standby)检查

--检查验证参数

show parameter log_archive_config;
show parameter fal_server;
show parameter fal_client;
show parameter db_unique_name;
show parameter log_archive_dest_;
show parameter compatible;
show parameter db_file_name_convert;
show parameter log_file_name_convert;
show parameter pdb_file_name_convert;

注意事项：要确保兼容参数compatible和noncdb_compatible在主备上一致。

切换前工作(Pre-Switchover)

Ensure Prerequisites are completely verified. Along with Prerequisites, Follow the below guidance to have successful switchover.
These steps should be executed before real planned outage starts and ensure no issues.

检查MRP进程状态

备库(standby)

select * from gv$dataguard_process;


停止/启动MRP进程，特殊情况下执行，此处不用执行。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT;


检查数据文件和Tempfiles

这个步骤不是必须的，如果你确认DG最近没有相关数据文件和临时表空间的相关文件调整，可以直接跳过这一步。

--Check the datafiles & Tempfiles status

SELECT NAME FROM V$DATAFILE WHERE STATUS='OFFLINE';
--ALTER DATABASE DATAFILE 'datafile-name' ONLINE;


检查temp表空间的文件

set linesize 680
set pagesize 40
col filename for a80
col tablespace for a16
select tf.name filename
      , bytes
      , ts.name tablespace    
from v$tempfile tf, v$tablespace ts where tf.ts#=ts.ts#;


检查redo log和standby redo log的信息

执行下面SQL检查redo log和standby redo log的信息(主库和备库)

set lines 680
col member for a50
select a.thread#,a.group#,a.bytes,a.blocksize,b.type,a.status,b.member 
from v$log a,v$logfile b 
where a.group#=b.group#
order by a.group#;


set lines 680
col member for a50
select s.thread#,s.group#,s.status,s.bytes,l.type,l.member 
from v$logfile l,v$standby_log s where s.group#=l.group#
order by s.thread#,s.group#;


--检查REDO LOG或归档日志应用延迟。(主库执行)

SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;


DEST_ID的值可以根据实际情况调整。STATUS字段应该为VALID，GAP_STATUS字段应该为"NO GAP"

检查监控告警日志

主库(Primary)和备库(Standby)

$ tail -600 alert_.ora | grep ORA 
$ tail -60f alert_.ora


关于检查的具体内容，官方文档描述为

1) From primary database alert logfile:
    * Check for issue reported for redo transport
    * Ensure there is no password file issue
    * Ensure there are no TNS or connection issue

2) From Standby database alert logfile:
    * There are no error related to Managed recovery
    * Recovery is moving forward by applying the archive log / redo log
    * There are no TNS or connection issue
    * There are no I/O issue or corruption issue
    select * from v$database_block_corruption;  -- it should return no rows
    select * from v$nonlogged_block; -- it should return no rows


DG切换(Switchover)

验证切换(Verify the switchover)

ADG切换验证：(主库执行):

ALTER DATABASE SWITCHOVER TO gspro VERIFY;


上面命令成功执行的话，则会返回"Database altered.",才可以执行下面命令，否则需要检查分析原因。

上面命令执行成功，主库告警日志中会出现下面信息：

2024-07-10T09:11:45.281610+08:00
ALTER DATABASE SWITCHOVER TO gspro VERIFY
2024-07-10T09:11:45.530174+08:00
SWITCHOVER VERIFY: Send VERIFY request to switchover target GSPRO
SWITCHOVER VERIFY COMPLETE: READY FOR SWITCHOVER
Completed: ALTER DATABASE SWITCHOVER TO gspro VERIFY


备库的告警日志中也会出现下面日志

2024-07-10T09:11:45.598106+08:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY COMPLETE


如果执行报错，也会在告警日志中看到详细的错误信息。

切换(Switchover)步骤

--Step 1: (主库执行)

ALTER DATABASE SWITCHOVER TO gspro;


--Step 2: 旧备库上/新的主库(new primary)执行

ALTER DATABASE OPEN;


--Step 3: 新的备库/旧主库上执行(current/new standby )

--If standby is Oracle Active data guard physical standby:
STARTUP;
--If standby is NOT Oracle Active data guard physical standby:
STARTUP MOUNT;


--注意：退出之前的sqlplus命令窗口，重新登陆执行命令，否则可能会遇到一些错误。如下例子所示：

SQL> STARTUP;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORA-49100: Failed to process event statement [10235 trace name context forever,level 2: 7445 trace name heapdump level 2: 10027 trace name context forever,level 1: 10949 trace name context forever,level 1] 
ORA-00972: identifier is too long


将PDB启动到OPEN状态

SHOW PDBS;
ALTER PLUGGABLE DATABASE ALL OPEN;


--Step 4:新的备库开始redo apply

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


--Step 5: 检查确认Switchover是否正常

--主库

alter system archive log current;
set linesize 720;
select dest_id,error,status from v$archive_dest where dest_id=;  --一般为2
select max(sequence#),thread# from v$log_history group by thread#;
select max(sequence#)  from v$archived_log where applied='YES' and dest_id=2;


--备库(standby)

select max(sequence#),thread# from v$archived_log group by thread#;
select name,role,instance,thread#,sequence#,action from gv$dataguard_process;


--备库执行SQL,检查同步状态

set linesize 720;
col name for a24;
col source_db_unique_name for a16;
col value for a16;
col unit for a20;
col time_computed for a19;
col datum_time for a19;
select source_db_unique_name
     , name
     , value
     , unit
     , time_computed 
     , datum_time
from v$dataguard_stats;

SQL>


参考资料[1]

1: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=246469404737555&id=2485237.1&_afrWindowMode=0&_adf.ctrl-state=18aegmiut3_4