最近生产上要搞大动作,需要把生产库备份每天都恢复到另外一台机器上,进行测试。于是想到了用DUPLIDATE的方式,简单方便,前期配置好目录,然后一条命令就可以把库恢复出来。于是写了恢复脚本,也通过了测试,而且生产上使用一切正常。但一次需要在测试环境恢复数据库时,使用该脚本却报错RMAN-06054。奇怪的是同样的备份在生产上的另一个环境已经成功恢复了。下面来看看这个问题是怎么处理的。

先看报错的图:

从报错来看需要找节点1序号为36615的归档,但当前库的归档编号已经到了30多万了,显然是要找很早之前的归档。于是到MOS去找duplicate RMAN-06054相关的文章,不是很多,而且还有说是BUG的,不会这么巧又遇到BUG了吧。但这个备份文件在其他环境是已经成功恢复了的,为什么到了这个环境就恢复不成功了呢。简单对比了两个恢复过程中的日志,发现报错的这次恢复日志与成功的日志有区别,出现了creating datafile的日志,感觉比较奇怪,但不知道是什么原因。结果这是一个关键点,如果直接从这个点去排查,可能很快就发现问题了,但就这个问题还是耗费了2天的时间。下图为区别:

下面继续排查问题,既然DUPLICATE语句不能自动recover恢复数据,那尝试手动recover会是什么效果呢,看下图:

看来手动recover还是报错,要找sequence 36615的归档日志。recover不行那open reseglogs试试。这里劝各位,我这个是测试环境可以随意尝试,如果操作的是生产环境,请敬畏生产,防止事态进一步恶化。open reseglogs的结果仍然是报错:

查看备份文件中的归档日志的备份,sequence都是30多万根本没有报错要找的36615号归档,那这就是个结了,没有怎么恢复呢?

恢复不成功怎么办呢?测试还等着库用呢,难道是DUPLICATE的BUG吗?还是“姿势”不对?重新再恢复一遍,结果等待两个小时后依然报同样的错。

DUPLICATE恢复不成功,那我用传纺的方式手动restore recover的方式是不是就可以了呢?结果是理想很丰满,现实很骨感,依然同样报错。那问题在哪呢?

静下心来想想,recover database想找很早以前的归档日志,是不是备份文件出了问题,进而导致恢复出的文件有问题?于是使用validate把备份文件又验证了一下,结果是没有问题。那是不是传输过程中出了问题呢?对两边机器上的文件做了md5校验,结果是两边的文件又是一致的。那问题到底出在了哪呢?

突然想到可以通过查询数据字典查文件的scn号,通过这个是不是可以找到问题的答案呢?我们来看一下查询结果:

从v$datafile中查到的文件的scn号都比报错中的scn号大几个数量级,难道问题不在这?又想到,v$datafile应该是contral file中记录的信息,控制文件是从备份中恢复出来的,那应该记录的是比较新的scn号,如何找到文件中实际的scn号的,于是想到了v$datafile_header这个数据字典。终于从这个数据字典中找到了一些线索:

从上图中可以看到有部分文件的scn号比其他的小很多,应该是出问题的数据文件了。而且对比了文件号为12的scn号为22575491与RMAN报错中的scn号是吻合的。那应该就可以解释问题了,部分数据文件恢复出问题,导致需要更早的归档日志进行恢复,但归档日志已被删除,无法恢复,所以recover无法进行。

问题找到了,那重新restore出问题的文件不就好了么,结果还是那句理想很丰满,现实很骨感。restore datafile时又出现了creating datafile的语句,与最开始发现的问题一样,再次查询v$datafile_header这个文件还是有问题的。都已经到这一步了,问题该怎么解决呢?

查询datafile为12的备份文件,也是有的

但是尝试使用FULLBACKUP的tag进行恢复时,出现了新的报错no backup of copy of datafile found to restore。这就奇怪了,前面查备份是有的,但restore时报没有,难道是见“鬼”了吗?

实在想不出问题解决的办法,于是又去查恢复成功的日志,这次有了重大发现,原来datafile 12的备份文件是在20181218这个备份文件中的。

现在想明白了,原来其他同事在传输备份文件时,以为只有20181219的文件是全部的备份文件,而忽略了20181218的10个备份文件。而我就用这少了10个文件的备份尝试了多次恢复数据库。想想还是有点好笑,就跟开始说的那样,如果一开始发现恢复日志有异常就去详细对比日志的话,就不会花了这么多时间来捣鼓没有全部备份文件的恢复了。

把漏传的备份文件重新传输后,duplicate成功完成了恢复。

致些,问题解决,最后提醒一下自己,做事情还需要再仔细一些。还有最重要的一点就是敬畏生产。

转载于:https://blog.51cto.com/hbxztc/2334304

RMAN duplicate恢复数据库报错RMAN-06054问题处理相关推荐

  1. linux还原数据库报错,RMAN还原数据库报错问题解决案例

    报错1.数据库开启block change tracking ,恢复完成后打开因文件不存在报错. RMAN> alter database open resetlogs; RMAN-00571: ...

  2. linux ora 01157,案例:Oracle报错ORA-01157 ORA-01110 数据启动报错RMAN恢复数据库思路

    天萃荷净 rman从多份备份中还原操作,运维DBA工程师反映数据库在进行恢复时报错ORA-01157 ORA-01110,分析原因为11号数据文件需要recover 1.数据恢复ORA错误 RMAN& ...

  3. Oracle 11gR2 使用RMAN Duplicate复制数据库

    Oracle 11gR2 使用RMAN Duplicate复制数据库 整体步骤 构建辅助数据库目录结构配置辅助数据库相关参数 安装软件并创建数据库 开启归档 配置静态监听 启动数据库到nomount状 ...

  4. 数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”

    故障描述 故障主要表现为打开数据库时报错,内容为:"system01.dbf需要更多的恢复来保持一致性,数据库无法打开".经过对数据库文件的检测后初步可得出以下结论:sysaux0 ...

  5. 数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”的解决方法...

    故障描述 故障主要表现为打开数据库时报错,内容为:"system01.dbf需要更多的恢复来保持一致性,数据库无法打开".经过对数据库文件的检测后初步可得出以下结论:sysaux0 ...

  6. Springboot 优雅的处理数据库报错信息

    目录 完整性约束报错处理 测试实例 邮箱字段被占用 账号被占用 原理 Duplicate entry 'xxx' for key 'xxxx' 平时我们遇到 mysql 报错的时候很难处理,例如字段重 ...

  7. Navicat链接数据库报错1130解决方案

    Navicat链接数据库报错1130解决方案 参考文章: (1)Navicat链接数据库报错1130解决方案 (2)https://www.cnblogs.com/newAndHui/p/113451 ...

  8. OpenStack在keystone部分同步数据库报错Errno 13解决办法

    OpenStack在keystone部分同步数据库报错Errno 13 在执行 su -s /bin/sh -c "keystone-manage db_sync" keyston ...

  9. mysql数据库报错1146_关于MySQL报错:[ERR] 1146

    最近因为电脑重装了系统,导致自己原本的数据库呗覆盖,需要重新重新安装数据库,但是由于我之前数据库版本是mysql 5.0.22,版本太低,所以小编决定安装mysql 5.7.23版本的,一开始没什么问 ...

最新文章

  1. StackOverFlow上你没看过的7个Java最佳答案
  2. String Manipulation
  3. ie设置ActiveX控件不提示
  4. 【C 语言】数组 ( 多维数组做函数形参退化为指针过程 | int array[2][3] -> int array[][3] -> int (*array)[3] )
  5. 大数据学习笔记1000条
  6. mysql 聚合函数内比较运算符_关于常用 MYSQL 聚合函数,其他函数 ,类型转换,运算符 总结...
  7. 牛客练习赛89E-牛牛小数点【数论】
  8. java eden分配参数,JVM垃圾收集器与内存分配策略,
  9. 细说WCF中的会话模式
  10. Spring 事务失效的 8 大场景,看看你都遇到过几个?
  11. python基础(笔记)
  12. Apollo注册到自己的Eureka注册中心+配置中心集群
  13. [转载] python面向对象编程实例
  14. miui android 版本下载安装,MIUI12.2.2.0稳定版安装包
  15. 计算机大学生职业规划书word模板,大学生职业规划书范文word模板
  16. 又是一年“剁手”时,AI一下更优惠?
  17. xutils中dbutils的使用
  18. UVa 10015 - Joseph's Cousin
  19. 计算机发展的雏形,( )是现代计算机的雏形。
  20. uniapp支付打开支付宝app进行付款

热门文章

  1. careercup-数学与概率 7.7
  2. debian下使用dpkg来安装/卸载deb包 (转载)
  3. ecshop 模板标签
  4. WPF中的动画——(三)时间线(TimeLine)
  5. 翻译:TRUNCATE TABLE(已提交到MariaDB官方手册)
  6. FastDFS+Nginx+Module
  7. Linux signal 编程(转载)
  8. Mysql事件的创建和使用
  9. 按创建日期删除指定日期之前的文件夹及文件夹下的所有子目录
  10. [转]WF事件驱动(4) -持久化