ADG无法切换:报错 ORA-16467

这篇具有很好参考价值的文章主要介绍了ADG无法切换:报错 ORA-16467。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

现象:
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切换参考:

  • 19c ADG Switchover 切换测试

嗯,终于OK了,也感觉肚子饿了,去点餐了。文章来源地址https://www.toymoban.com/news/detail-439149.html

到了这里,关于ADG无法切换:报错 ORA-16467的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ORA-28040:没有匹配的验证协议

    通过oracle客户端连接Oracle 12c的数据库,提示ORA-28040:没有匹配的验证协议 。 在服务器上登录正常 原因: oracle数据库为12c,使用客户端工具是11g版本,连接12c数据库时会报ora-28040错误。 在$ORACLE_HOME/network/admin/sqlnet.ora文件中添加: 重新启动 监听: 在11g的客户端连接正常。

    2024年02月11日
    浏览(15)
  • oracle报错:ORA-10997,ORA-09967解决

    报错信息: ORA-10997: another startup/shutdown operation of this instance inprogress ORA-09967: unable to create or open lock file Linux-x86_64 Error: 13: Permission denied 权限问题,修改Oracle目录权限 连接到Oracle重新启动就好

    2024年02月15日
    浏览(16)
  • 12C/19C Oracle连接提示ORA-28040 没有匹配的验证协议

    数据库升级19C后,客户端使用sqlplus、PL/SQl Developer等连接数据库提示 instantclient-basic-windows.x64-19.3.0.0.0dbru;-- x64 64位客户端 instantclient-basic-nt-19.12.0.0.0dbru; – x86 32位客户端 跟plsql developer没有关系的。 注意: 1、plsql连接oracle数据库,是通过instance-client作为连接驱动的,跟plsql没

    2024年02月02日
    浏览(13)
  • ubuntu20.04中sudo apt-get update由于没有公钥,无法验证下列签名报错解决

     更新安装软件需要用到指令: sudo apt-get update 此时ubuntu20.04报错 网上大部分方法是告诉你需要添加秘钥,把NO_PUBKEY后面的秘钥输入到下面指令并执行: sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv BAC6F0C353D04109 但是这个方法对我没用,终端报错: gpg: 从公钥服务器接收

    2024年02月03日
    浏览(23)
  • ora-12154无法解析指定的连接标识符

    用户反映查询的时候报错ora-12154 这个系统只做历史数据查询使用,使用并不平凡,该数据库曾做过一次服务器间的迁移。 用户描述,所有oracle客户端查询该视图都报tns错误,一般ora-12154会发生在连接数据库时,因为tns配置不正确而报错,但是这个报错发生在进行查询过程中

    2024年01月23日
    浏览(16)
  • ORA : 无法找到期望的FROM关键字 大数据

    ORA : 无法找到期望的FROM 大数据 大数据在现代社会中发挥着越来越重要的作用。它是指规模庞大、复杂度高且变化迅速的数据集合,通过分析这些数据,我们可以获得有价值的信息和洞察力。然而,在处理大数据时,我们经常会遇到各种挑战和问题。本文将探讨一个常

    2024年02月04日
    浏览(10)
  • oracle报错 ORA-00917: missing comma

    oracle执行sql语句报错,提示 oracle ORA-00917: missing comma 这是由于sql语句中缺少逗号,仔细检查下即可。 执行以下语句发生报错 结果提示: 在sql语句中缺少了逗号,导致报错。

    2024年02月14日
    浏览(15)
  • Oracle 解决ORA-00257 Archiver error 报错

    日期: 2023-12-11 作者: Tingy, H 订单投资交易环境进行 impdb 数据泵恢复数据,执行到一半,报错终止。 系统弹出提示: Oralce 安装在 Linux 机器上。 归档策略保留时间较长,或归档频率过高,导致数据库挂载盘符空间不足。 临时处理办法: 手动删除归档文件。 1. 登录 Linux 用

    2024年04月26日
    浏览(15)
  • 解决ORA-01400报错过程中遇到的问题

    报错信息:ORA-01400: cannot insert NULL into (\\\"OWNER\\\".\\\"TABLE_NAME\\\".\\\"COLUMN_NAME\\\") 问题原因:对不允许为NULL的字段插入了NULL。 解决办法:要么赋给该字段一个值使它不为空,要么执行 alter table \\\"TABLE_NAME\\\" modify \\\"COLUMN_NAME\\\" NULL; 使该字段允许为空。但有时候执行上面语句会返回报错: ORA-01451

    2024年02月12日
    浏览(27)
  • sql报错处理:ora-01722:invalid number

    1.ORA-01722错误是在尝试将字符串转换为数字时发生的,但字符串无法转换为数字。这可能是由于表达式中有无效的数字字符,或者您试图将文本值添加到数字列中。 在您提供的SQL代码中,我没有看到明显的原因会导致ORA-01722错误。但是,这个错误可能是由于数据库中的数据引

    2024年02月13日
    浏览(12)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包