RMAN duplicate恢复数据库报错RMAN-06054问题处理
最近生产上要搞大动做，须要把生产库备份天天都恢复到另一台机器上，进行测试。因而想到了用DUPLIDATE的方式，简单方便，前期配置好目录，而后一条命令就能够把库恢复出来。因而写了恢复脚本，也经过了测试，并且生产上使用一切正常。但一次须要在测试环境恢复数据库时，使用该脚本却报错RMAN-06054。奇怪的是一样的备份在生产上的另外一个环境已经成功恢复了。下面来看看这个问题是怎么处理的。
数据库
先看报错的图：
ide
从报错来看须要找节点1序号为36615的归档，但当前库的归档编号已经到了30多万了，显然是要找很早以前的归档。因而到MOS去找duplicate RMAN-06054相关的文章，不是不少，并且还有说是BUG的，不会这么巧又遇到BUG了吧。但这个备份文件在其余环境是已经成功恢复了的，为何到了这个环境就恢复不成功了呢。简单对比了两个恢复过程当中的日志，发现报错的此次恢复日志与成功的日志有区别，出现了creating datafile的日志，感受比较奇怪，但不知道是什么缘由。结果这是一个关键点，若是直接从这个点去排查，可能很快就发现问题了，但就这个问题仍是耗费了2天的时间。下图为区别：
测试
下面继续排查问题，既然DUPLICATE语句不能自动recover恢复数据，那尝试手动recover会是什么效果呢，看下图：3d
看来手动recover仍是报错，要找sequence 36615的归档日志。recover不行那open reseglogs试试。这里劝各位，我这个是测试环境能够随意尝试，若是操做的是生产环境，请敬畏生产，防止事态进一步恶化。open reseglogs的结果仍然是报错：
rest
查看备份文件中的归档日志的备份，sequence都是30多万根本没有报错要找的36615号归档，那这就是个结了，没有怎么恢复呢？
日志
恢复不成功怎么办呢？测试还等着库用呢，难道是DUPLICATE的BUG吗？仍是“姿式”不对？从新再恢复一遍，结果等待两个小时后依然报一样的错。
blog
DUPLICATE恢复不成功，那我用传纺的方式手动restore recover的方式是否是就能够了呢？结果是理想很丰满，现实很骨感，依然一样报错。那问题在哪呢？
md5
静下心来想一想，recover database想找很早之前的归档日志，是否是备份文件出了问题，进而致使恢复出的文件有问题？因而使用validate把备份文件又验证了一下，结果是没有问题。那是否是传输过程当中出了问题呢？对两边机器上的文件作了md5校验，结果是两边的文件又是一致的。那问题到底出在了哪呢？
it
忽然想到能够经过查询数据字典查文件的scn号，经过这个是否是能够找到问题的答案呢？咱们来看一下查询结果：
class
从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成功完成了恢复。
致些，问题解决，最后提醒一下本身，作事情还须要再仔细一些。还有最重要的一点就是敬畏生产。