ADG无法切换:报错 ORA-16467

adg,无法,切换,报错,ora · 浏览次数 : 140

小编点评

**数据库切换成功** **步骤1:获取目标数据库 ID** ```sql SELECT dest_id FROM v$archive_dest_status WHERE dest_id = 2; ``` **步骤2:获取目标数据库 status、gap状态** ```sql SELECT status, gap_status FROM v$archive_dest_status WHERE dest_id = 2; ``` **步骤3:创建新备库** ```sql CREATE DATABASE demostartuprecover managed standby database disconnect; ``` **步骤4:从目标数据库中复制数据到新备库** ```sql COPY INTO demostartuprecover managed standby database TABLE v$archive_dest_status WHERE dest_id = 2; ``` **步骤5:关闭目标数据库** ```sql CLOSE DATABASE demo; ``` **步骤6:启动新备库** ```sql START DEMOAPPRECSTART; ``` **步骤7:切换到新备库** ```sql ALTER DATABASE switchover to demorac verify; ``` **步骤8:验证切换成功** ```sql SELECT status FROM v$archive_dest_status WHERE dest_id = 2; ``` **注意:** * 切换过程可能需要一些时间,具体取决于数据库大小和性能。 * 切换过程中可能会出现警告,需要查看告警日志进行处理。 * 切换成功后,需要确保新备库的性能满足要求。

正文

现象:
ADG无法切换:验证时就报错 ORA-16467

记录问题,顺便展现一次troubleshooting的心路历程。

具体查询:

在主库操作,
@primary

切换验证:

alter database switchover to demorac verify;

报错ORA-16467:

SQL> alter database switchover to demorac verify;

alter database switchover to demorac verify
*
ERROR at line 1:
ORA-16467: switchover target is not synchronized

主库alert告警日志:

ORA-16467 signalled during: alter database switchover to demorac verify...

主库传输链路并没有报错:

SQL> select error from v$archive_dest where dest_id= 2;

ERROR
-----------------------------------------------------------------

但是,如果去查v$archive_dest_status,就会发现问题,说有可解决的GAP:

SQL> select dest_id, status, gap_status from v$archive_dest_status where dest_id = 2;

   DEST_ID STATUS    GAP_STATUS
---------- --------- ------------------------
	 2 VALID     RESOLVABLE GAP

但是去备库查询,
@standby,

ADG并没有任何延迟:

SQL> select * from v$dataguard_stats;

SOURCE_DBID SOURCE_DB_ NAME		      VALUE		     UNIT			    TIME_COMPUTED		   DATUM_TIME			      CON_ID
----------- ---------- ---------------------- ---------------------- ------------------------------ ------------------------------ ------------------------------ ----------
	  0	       transport lag	      +00 00:00:00	     day(2) to second(0) interval   05/11/2023 18:16:43 	   05/11/2023 18:16:41			   0
	  0	       apply lag	      +00 00:00:00	     day(2) to second(0) interval   05/11/2023 18:16:43 	   05/11/2023 18:16:41			   0
	  0	       apply finish time			     day(2) to second(3) interval   05/11/2023 18:16:43 						   0
	  0	       estimated startup time 18		     second			    05/11/2023 18:16:43 						   0

查MOS文档资料,有一个bug:

  • Bug 33663444 - DataGuard: "alter database switchover verify" fails with ORA-16467 (Doc ID 33663444.8)

可是很快也排除掉:现象细节不完全匹配,另外这个bug正好在19.16已经修复:

[oracle@bogon ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep 33663444
     29353271, 29706141, 26352569, 33663444, 30476768, 30092280, 30843271

但这个文档给的一些解释中也得到了一些启发:

REDISCOVERY INFORMATION:
  SELECT GAP_STATUS FROM V$ARCHIVE_DEST_STATUS with show unresolvable gap.
 
Workaround
  temporarily re-enable the disabled redo thread

首先,我们查V$ARCHIVE_DEST_STATUS已经确认是resolvable gap,不匹配但是也有问题。
然后redo thread的re-enable,这个workaround让我去想到查询redo的thread,结果发现果然有些异常:

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE	  MEMBERS ARC STATUS	       FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME	  CON_ID
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ --------- ----------
	 1	    1	    1132  209715200	   512		1 NO  CURRENT		    44911942 11-MAY-23	 9.2954E+18		       0
	 2	    1	    1130  209715200	   512		1 YES INACTIVE		    44901958 11-MAY-23	   44911931 11-MAY-23	       0
	 3	    1	    1131  209715200	   512		1 YES INACTIVE		    44911931 11-MAY-23	   44911942 11-MAY-23	       0
	 4	    2	       0  104857600	   512		1 YES UNUSED			   0			  0		       0
	 5	    2	       0  104857600	   512		1 YES UNUSED			   0			  0		       0

我这里目前主库是单实例,而备库才是RAC,可是,为何主库的redo居然会有 thread#=2 的redo?
虽然都是unused,但出现在这里就很奇怪!
不知道谁动了这个环境,想不起来做过这样的测试。但可以肯定的是,完全可以把这个不该存在的thread删除掉!

直接删除会报错:

alter database drop logfile group 4;
alter database drop logfile group 5;


SQL> alter database drop logfile group 4;
alter database drop logfile group 4
*
ERROR at line 1:
ORA-01567: dropping log 4 would leave less than 2 log files for instance UNNAMED_INSTANCE_2 (thread 2)
ORA-00312: online log 4 thread 2: '/flash/fast_recovery_area/DEMO/onlinelog/o1_mf_4_kxn73zny_.log'


SQL> alter database drop logfile group 5;
alter database drop logfile group 5
*
ERROR at line 1:
ORA-01567: dropping log 5 would leave less than 2 log files for instance UNNAMED_INSTANCE_2 (thread 2)
ORA-00312: online log 5 thread 2: '/flash/fast_recovery_area/DEMO/onlinelog/o1_mf_5_kxn73zqd_.log'

删除不掉就尝试去先禁用掉这个没有用的thread 2,然后再次尝试删除:
alter database disable thread 2;

SQL> alter database disable thread 2;

Database altered.

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE	  MEMBERS ARC STATUS	       FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME	  CON_ID
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ --------- ----------
	 1	    1	    1132  209715200	   512		1 NO  CURRENT		    44911942 11-MAY-23	 9.2954E+18		       0
	 2	    1	    1130  209715200	   512		1 YES INACTIVE		    44901958 11-MAY-23	   44911931 11-MAY-23	       0
	 3	    1	    1131  209715200	   512		1 YES INACTIVE		    44911931 11-MAY-23	   44911942 11-MAY-23	       0
	 4	    2	       0  104857600	   512		1 YES UNUSED			   0			  0		       0
	 5	    2	       0  104857600	   512		1 YES UNUSED			   0			  0		       0

SQL> alter database drop logfile group 4;

Database altered.

SQL> alter database drop logfile group 5;

Database altered.

SQL>
SQL>
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE	  MEMBERS ARC STATUS	       FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME	  CON_ID
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ --------- ----------
	 1	    1	    1132  209715200	   512		1 NO  CURRENT		    44911942 11-MAY-23	 9.2954E+18		       0
	 2	    1	    1130  209715200	   512		1 YES INACTIVE		    44901958 11-MAY-23	   44911931 11-MAY-23	       0
	 3	    1	    1131  209715200	   512		1 YES INACTIVE		    44911931 11-MAY-23	   44911942 11-MAY-23	       0

删除成功!这次想来总该可以了吧?

SQL> alter database switchover to demorac verify;
alter database switchover to demorac verify
*
ERROR at line 1:
ORA-16467: switchover target is not synchronized

额,还是不行,但感觉再刺激刺激就OK了,继续尝试之前的十八般武艺(主要还是多切几次日志):

SQL> select dest_id, status, gap_status from v$archive_dest_status where dest_id = 2;

   DEST_ID STATUS    GAP_STATUS
---------- --------- ------------------------
	 2 VALID     RESOLVABLE GAP

SQL>
SQL> alter system switch logfile;

System altered.

SQL> select dest_id, status, gap_status from v$archive_dest_status where dest_id = 2;

   DEST_ID STATUS    GAP_STATUS
---------- --------- ------------------------
	 2 VALID     RESOLVABLE GAP

SQL> alter system archive log current;

System altered.

SQL> select dest_id, status, gap_status from v$archive_dest_status where dest_id = 2;

   DEST_ID STATUS    GAP_STATUS
---------- --------- ------------------------
	 2 VALID     RESOLVABLE GAP

SQL> alter system switch logfile;
alter system switch logfile;
System altered.

SQL>

System altered.

SQL>
SQL>
SQL>
SQL> alter system switch logfile;

System altered.

SQL> select dest_id, status, gap_status from v$archive_dest_status where dest_id = 2;

   DEST_ID STATUS    GAP_STATUS
---------- --------- ------------------------
	 2 VALID     NO GAP

SQL>

哎呀,直接提示没有GAP了,赶紧尝试继续切换。。

SQL> alter database switchover to demorac verify;
alter database switchover to demorac verify
*
ERROR at line 1:
ORA-16475: succeeded with warnings, check alert log for more details


SQL> !date
Thu May 11 18:36:31 CST 2023

额?成功了,但是有警告,看告警日志又是一个新的ORA-16475 错误。

2023-05-11T18:36:14.906996+08:00
alter database switchover to demorac verify
2023-05-11T18:36:15.094516+08:00
SWITCHOVER VERIFY: Send VERIFY request to switchover target DEMORAC
SWITCHOVER VERIFY WARNING: switchover target temporary files are not the same with the primary. See switchover target's alert log for details.
ORA-16475 signalled during: alter database switchover to demorac verify...

哎呀,去看看备库的alert日志:

2023-05-11T18:41:29.407685+08:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY WARNING: primary database has 5 temporary files, this database has 4 temporary files. More temp files  should be added to this database.
SWITCHOVER VERIFY COMPLETE

注意这个时间不太一致是因为两个机器时间不一样(差了5分钟),可以先不用管。
看问题本身是说临时文件,这无所谓,切换后可以自动创建。

快快来一把久违的切换吧!

--主库执行成功
alter database switchover to demorac;

--新主库demorac
alter database open;

--新备库demo
startup
recover managed standby database disconnect;

具体ADG切换参考:

嗯,终于OK了,也感觉肚子饿了,去点餐了。

与ADG无法切换:报错 ORA-16467 相似的内容:

ADG无法切换:报错 ORA-16467

现象: ADG无法切换:验证时就报错 ORA-16467 记录问题,顺便展现一次troubleshooting的心路历程。 具体查询: 在主库操作, @primary 切换验证: alter database switchover to demorac verify; 报错ORA-16467: SQ

ADG无法同步:TT00进程报错 Error 12514

环境: Oracle 19.16 ADG (Single Instance -> RAC) 在配置ADG的场景,发现ADG不能同步。 1.查看报错信息 2.oerr查看该错误说明 3.尝试sqlplus连接到standby 4.尝试relocate监听 5.继续排查发现是参数问题 6.总结和延伸 1

Oracle ADG环境下的RMAN备份策略

作为IT运维人员,尤其是数据库岗位,数据的备份重于一切。 现在很多用户会有一个普遍误区,认为现在类似ADG这类灾备已经很完善,且实时性也更佳,往往就忽略了传统的备份效用。 但实际上,我们千万不能因为有了容灾建设就盲目忽略备份的作用,二者其实有着本质区别。很多场景,灾备都是无法替代传统备份的,二者是缺

ADG备库中某个PDB缺失temp文件

之前认为缺失的temp文件在开库时会自动创建,但其实也有不能自动创建的场景,alert会有类似如下提示: 2023-05-11T20:35:35.974983+08:00 AWR(6):*********************************************************

ADG级联备库环境PSU应用验证

上篇文章 - [源端为备库的场景下Duplicate失败问题](https://www.cnblogs.com/jyzhao/p/17420831.html) 我只在中间备库环境应用了PSU,解决了级联备库从中间备库duplicate数据库的问题: 细心的朋友已经发现,因为是备库环境,并没有做数据库

19c ADG Switchover 切换测试

背景: 环境未配置DG Broker,手工切换ADG,19c也要比11g时代的切换更简单。 使用自己的测试环境,具体可参见: 单实例Primary快速搭建Standby RAC参考手册(19.16 ADG) 1.主库demo切换到RAC环境demorac: 在主库demo执行命令: SQL> alt

验证ADG的坏块检测和自动修复

环境: Oracle 19c ADG(主库:单实例;备库:RAC) 1.主库新建测试文件 2.主库创建测试表 3.查询表对应数据文件信息 4.模拟数据文件物理坏块 5.查询对应测试表 6.进一步查询日志信息 7.确认当前参数设置 1.主库新建测试文件 主库在AWR的PDB中做测试,为了不影响其他测试

11g ADG级联备库基础测试环境准备

客户通过duplicate生产备库的方式创建cascade备库。 发现每次都会遇到两个文件报错,ORA-17628: Oracle error 19505错误,且每一次跑,报错文件不一样。 现在想帮客户验证,这属于是正常现象还是bug; 本文需要先模拟客户11.2.0.3环境,构建备库、级联备库环境

部署19c ADG过程中的问题处理

回忆起来也是有些年没亲自动手搭建ADG了,今天正好有个机会重温,客户环境是19.16,恍惚记得上一次搭ADG还是在11.2.0.4的时代,时光荏苒啊。 正好看下19c的ADG和11g的ADG在部署方面有啥不同? 主备库都是RAC架构,数据库是CDB架构,包含有4个PDB,整个搭建过程还是遇到很多小问

记录一则ADG备库报错ORA-29771的案例

有客户找到我这边咨询,说他们的一套核心ADG库在业务高峰期报错,因为业务做了读写分离,其备库也实际承担读业务,所以备库故障也会对业务产生影响。 这里也要提醒大家,做读写分离,如果读库出现故障的情况,要有切换到主库的应急方案考虑进去。 客户这里自己通过重启备库暂时解决,但担心故障再现,所以非常着急要分