专栏首页Tidb再次踩到搜遍全网也找不到解药的坑ORA-49204之解决方案
原创

再次踩到搜遍全网也找不到解药的坑ORA-49204之解决方案

**导读**

> 作者:杨漆

> 16年关系型数据库管理,从oracle 9i 、10g、11g、12c到Mysql5.5、5.6、5.7、8.0 到TiDB获得3个OCP、2个OCM;运维路上不平坦,跌过不少坑、熬过许多夜。把工作笔记整理出来分享给大伙儿,希望帮到大家少走弯路、少熬夜。

最近总是踩到搜遍全网都也找不到解决方案,仅原厂才有解药的坑里

Dg告警日志中大量出现Error

2021-07-13T17:00:23.984655+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:

ORA-01110: 数据文件 155: '/u01/oradata/datafile/efsw_dat.980.1072178937'

2021-07-13T17:00:24.077126+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:

ORA-01110: 数据文件 156: '/u01/oradata/datafile/efsw_dat.982.1072179003'

2021-07-13T17:00:24.168845+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:

ORA-01110: 数据文件 157: '/u01/oradata/datafile/efsw_dat.979.1072179087'

2021-07-13T17:00:24.261303+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:

ORA-01110: 数据文件 158: '/u01/oradata/datafile/loan_dat.978.1072179227'

2021-07-13T17:00:24.353301+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:

ORA-01110: 数据文件 159: '/u01/oradata/datafile/loan_index.977.1072179343'

2021-07-13T17:00:24.448821+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:

ORA-01110: 数据文件 160: '/u01/oradata/datafile/efs_dat.976.1072179459'

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_tt00_8566.trc:

ORA-00314: 日志 16 (用于线程 1) 要求的 sequence# 291926 与 291553 不匹配

ORA-00312: 联机日志 16 线程 1: '/u01/oradata/onlinelogstb1_redo16.log'

2021-07-13T17:15:09.529144+08:00

Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_tt00_8566.trc:

ORA-00314: 日志 25 (用于线程 3) 要求的 sequence# 194861 与 194733 不匹配

ORA-00312: 联机日志 25 线程 3: '/u01/oradata/onlinelogstb3_redo25.log'

2021-07-13T17:15:09.573349+08:00

进一步打开trace文件:

fd: 7

----- END ADS Stream Desc Dump -----

File Name Fragment: /orcl/trace/orcl_m000_9167.trc

################ Open Stream File: 1 ################

PathFile: /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trm

OpFlag: 136, Status: 1, MagicBeg: 2153609765, MagicNum: 3593058129

Stream Access

----- ADS Stream Desc Dump -----

fd: 8

----- END ADS Stream Desc Dump -----

File Name Fragment: /orcl/trace/orcl_m000_9167.trm

----- END ADS Open Files Dump -----

----- END Diag Diagnostic DUMP -----

DDE encountered the following error:

ORA-49204: 递归 DDE 调用处于阶段 I

ORA-01110: 数据文件 160: '/u01/oradata/datafile/efs_dat.976.1072179459'

dbkh_create_finding: BEGIN

dbkhu_prepare_default_msgobj: BEGIN

dbkhu_prepare_default_msgobj:; name_id=71, type=2, flags=1

dbkhu_get_default_msg_def: BEGIN

dbkhu_get_default_msg_def: END

dbkhu_prepare_default_msgobj:: MSG PARAMS-1; i=0

dbkhu_prepare_default_msgobj: END

dbkhu_prepare_default_msgobj: BEGIN

dbkhu_prepare_default_msgobj:; name_id=71, type=2, flags=2

dbkhu_get_default_msg_def: BEGIN

dbkhu_get_default_msg_def: END

dbkhu_prepare_default_msgobj:: MSG PARAMS-2; i=0

dbkhu_prepare_default_msgobj: END

dbkh_create_finding: END

cross-check executed

dbkh_post_process_run: BEGIN

dbkh_post_process_run: NEW FAILURE COUNT: 0; DBKH_NUM_NEW_FAILURES_CTX(ctxp)=dbkh_post_process_run: END

dbkh_run_check_internal: END

dbkh_reactive_run_check: END

最近总是踩到搜遍全网都也找不到解决方案,仅原厂才有解药的坑里。

唯一有用的一篇帖子指出:

ora-49204: recursive dde invocation at phase i This error is followed by ora-01110. This happens for all data files

这个是12c的一个BUG。 ORA-01110 For All Files In Standby Database

MOS上给出的解决方案:下载并安装补丁包:p24844841_122010_Linux-x86-64.zip

续费问题商务组还在谈判,下载不了Bug补丁包,只能自己想办法。

琢磨一会儿,发现问题应该出在standby log上。

解决方案:

1.停止备库的恢复管理模式

2.清空standby日志

3.重启备库

4.开启备库应用日志

5.检查

## standby日志:

ALTER DATABASE clear LOGFILE group 15;

ALTER DATABASE clear LOGFILE group 16;

ALTER DATABASE clear LOGFILE group 17;

ALTER DATABASE clear LOGFILE group 18;

ALTER DATABASE clear LOGFILE group 19;

ALTER DATABASE clear LOGFILE group 20;

ALTER DATABASE clear LOGFILE group 21;

ALTER DATABASE clear LOGFILE group 22;

ALTER DATABASE clear LOGFILE group 23;

ALTER DATABASE clear LOGFILE group 24;

ALTER DATABASE clear LOGFILE group 25;

ALTER DATABASE clear LOGFILE group 26;

ALTER DATABASE clear LOGFILE group 27;

ALTER DATABASE clear LOGFILE group 28;

ALTER DATABASE clear LOGFILE group 29;

ALTER DATABASE clear LOGFILE group 30;

ALTER DATABASE clear LOGFILE group 31;

ALTER DATABASE clear LOGFILE group 32;

ALTER DATABASE clear LOGFILE group 33;

ALTER DATABASE clear LOGFILE group 34;

ALTER DATABASE clear LOGFILE group 35;

ALTER DATABASE clear LOGFILE group 36;

ALTER DATABASE clear LOGFILE group 37;

ALTER DATABASE clear LOGFILE group 38;

ALTER DATABASE clear LOGFILE group 39;

重新开启备库应用日志后一切正常,经过一晚上的运行,今早到公司后再次检查告警日志,一切正常!

2021-07-14T09:50:40.195428+08:00

Primary database is in MAXIMUM PERFORMANCE mode

RFS[298]: Assigned to RFS process (PID:26345)

RFS[298]: Selected log 15 for T-1.S-292565 dbid 1513741333 branch 985960599

2021-07-14T09:50:46.238535+08:00

Recovery of Online Redo Log: Thread 1 Group 15 Seq 292565 Reading mem 0

Mem# 0: /u01/oradata/onlinelogstb1_redo15.log

2021-07-14T09:51:46.053469+08:00

RFS[297]: Selected log 26 for T-3.S-195400 dbid 1513741333 branch 985960599

2021-07-14T09:51:46.096309+08:00

Media Recovery Waiting for thread 3 sequence 195400 (in transit)

2021-07-14T09:51:46.097183+08:00

Recovery of Online Redo Log: Thread 3 Group 26 Seq 195400 Reading mem 0

Mem# 0: /u01/oradata/onlinelogstb3_redo26.log

2021-07-14T09:51:46.783207+08:00

Archived Log entry 1899 added for T-3.S-195399 ID 0x5a3a0712 LAD:1

2021-07-14T10:00:26.290941+08:00

Primary database is in MAXIMUM PERFORMANCE mode

RFS[299]: Assigned to RFS process (PID:26766)

RFS[299]: Selected log 15 for T-1.S-292565 dbid 1513741333 branch 985960599

2021-07-14T10:04:18.028763+08:00

Primary database is in MAXIMUM PERFORMANCE mode

Re-archiving standby log 21 T-2.S-229169

RFS[300]: Assigned to RFS process (PID:26859)

RFS[300]: Selected log 20 for T-2.S-229170 dbid 1513741333 branch 985960599

2021-07-14T10:04:18.381307+08:00

Media Recovery Waiting for thread 2 sequence 229170 (in transit)

2021-07-14T10:04:18.382131+08:00

Recovery of Online Redo Log: Thread 2 Group 20 Seq 229170 Reading mem 0

Mem# 0: /u01/oradata/onlinelogstb2_redo20.log

2021-07-14T10:04:18.387233+08:00

Archived Log entry 1900 added for T-2.S-229169 ID 0x5a3a0712 LAD:1

## 登陆备库二检查(昨天出现ora-49204的DB):

Connected to:

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL>

SQL>

SQL> select count(*),to_char(min(first_time),'yyyymmdd hh24:mi:ss') from v$archived_log where applied='NO';

COUNT(*) TO_CHAR(MIN(FIRST

---------- -----------------

0

SQL>

SQL> select count(*),to_char(max(first_time),'yyyymmdd hh24:mi:ss') from v$archived_log where applied='YES';

COUNT(*) TO_CHAR(MAX(FIRST

---------- -----------------

1879 20210714 10:03:18

## 登陆备库一比对(一直正常运行的):

SQL*Plus: Release 12.2.0.1.0 Production on Wed Jul 14 10:04:27 2021

Copyright (c) 1982, 2016, Oracle. All rights reserved.

Connected to:

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL>

SQL>

SQL> select count(*),to_char(max(first_time),'yyyymmdd hh24:mi:ss') from v$archived_log where applied='YES';

COUNT(*) TO_CHAR(MAX(FIRST

---------- -----------------

14711 20210714 10:03:18

一切正常,问题解决!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • oracle 12C上Error 16063的解药

    TT02: Standby redo logfile selected for thread 1 sequence 289676 for destination...

    杨漆
  • 多维度架构

    什么事多维度架构,看完下面故事你就明白了 我的的惨痛就医经历: 咳嗽,去看呼吸内科,先拍x光,医生开药头孢+止咳水什么的,诊断结果是支气管炎。我看了很久持续了几...

    netkiller old
  • 搜遍全网,仅MOS能找到解药的ORA-00141错误

    最近为新项目搭建两套新库,在Vmware上手动部署完第一套。为了省事,用snapshot克隆出第二套,通过修改IP地址、hostname、tns、listene...

    杨漆
  • PageAdmin企业网站制作中踩过的坑

    PageAdmin是一套很不错的网站内容管理系统,也是国内最知名的net网站管理系统之一,功能强大、安全稳定,是许多大型门户网站建设解决方案之一,其基于.Net...

    用户4831957
  • Java开发中遇到的那些坑!

    之前在这个手册刚发布的时候看过一遍,当时感觉真是每个开发者都应该必读的一本手册,最近由于在总结一些我们日常开发中容易忽略的问题,可能是最低级的编码常见问题,往往...

    互扯程序
  • Java开发中如何正确踩坑

    之前在这个手册刚发布的时候看过一遍,当时感觉真是每个开发者都应该必读的一本手册,期间还写过一篇关于日志规约的文章:《下一个项目为什么要用 SLF4J》,最近由于...

    Java团长
  • 关于最近项目的思考-databus2

    最近还在搞databus binlog同步,之前针对databus搭建安装写过一篇行云流水的文章,那时候项目刚立项,前期调研了下,没想到后期会有这么多问题出现。

    用户2825413
  • 警示:一个专为AIX上12.1版本定制的Bug正在发生

    题记:一些用户在使用 Oracle Database 12.1 版本时(包含12.1.0.1 和 12.1.0.2 初始版本),再次遭遇到一个『专门为 AIX ...

    数据和云
  • Java 开发中如何正确的踩坑

    我们的做法是,要用最好的人。我一直都认为研发本身是很有创造性的,如果人不放松,或不够聪明,都很难做得好。你要找到最好的人,一个好的工程师不是顶10个,是顶100...

    好好学java
  • VS Code无法实现"转到定义"?

    VS Code一度个人日常工作中必不可少的IDE之一,在前文中也提到,它和Jupyterlab+Pycharm构成了个人工作日常IDE组合。然而,近日在新电脑中...

    luanhz
  • Spring Cloud微服务初探

    初次接触Spring Cloud,一看到各种版本,刚开始有点懵逼。给大家看下最新的Spring Cloud的版本是什么样子的。

    猿天地
  • 学习编程的你,遇到了Bug该怎么办?

    这里我先回答标题的问题,答案就是:百度! 直接把错误提示复制在搜索栏,用百度搜索。如果没有现成的错误提示,只有模糊的需求,那就整理一下需求,组织一下语言,然后...

    爱吃西瓜的番茄酱
  • OracleRac ASM+DG前任搭建偷懒最不易发现的坑

    OracleRac ASM+DG前任搭建时偷懒随手埋下的雷,后任接手最易踩爆的那声响

    杨漆
  • Windows下配置TensorFlow-GPU开发环境经验总结

    其实TensorFlow有一个别人提供的服务器在用着,不过最近访问不了了,估计给收回去了吧。另外自己的MacBook Pro也其实有TensorFlow,但是这...

    ZNing
  • 整合Atomikos、Quartz、Postgresql的踩坑日记

    由于业务需要,在单体Spring Boot项目中需要引入分布式事务,来保证单体应用连接的多个数据源的事务统一。

    HUC思梦
  • 测试开发之Spring篇(六)

    最近小编拟写一篇spring junit单元测试的案例的博文,编写完成过程中发现一个问题,那就是tomcat、jdk、junit与dynamic ...

    muntainyang
  • Spring Cloud微服务初探

    因为加了不少优秀的知识星球,结交了更多的小伙伴,加了更多的群,每每在自我介绍的时候,都说自己是Android & Java攻城狮。

    程序员小跃
  • Ubuntu14升级MySQL

    sudo wget https://dev.mysql.com/get/mysql-apt-config_0.8.1-1_all.deb

    烟草的香味
  • 不漫谈大数据反欺诈技术架构 No.126

    一年多以前,有朋友让我聊一下你们的大数据反欺诈架构是怎么实现的,以及我们途中踩了哪些坑,怎么做到从30min延迟优化到1s内完成实时反欺诈。当时呢第一是觉得不合...

    大蕉

扫码关注云+社区

领取腾讯云代金券