,,,,,,,,最近生产上要搞大动作,需要把生产库备份每天都恢复到另外一台机器上,进行测试。于是想到了用DUPLIDATE的方式,简单方便,前期配置好目录,然后一条命令就可以把库恢复出来。于是写了恢复脚本,也通过了测试,而且生产上使用一切正常。但一次需要在测试环境恢复数据库时,使用该脚本却报错RMAN - 06054。奇怪的是同样的备份在生产上的另一个环境已经成功恢复了。下面来看看这个问题是怎么处理的。
,,,,,,,,先看报错的图:
,,,,,,,,从报错来看需要找节序点1号为36615的归档,但当前库的归档编号已经到了30多万了,显然是要找很早之前的归档。于是到MOS去找重复RMAN - 06054相关的文章,不是很多,而且还有说是错误的,不会这么巧又遇到错误了吧。但这个备份文件在其他环境是已经成功恢复了的,为什么到了这个环境就恢复不成功了呢。简单对比了两个恢复过程中的日志,发现报错的这次恢复日志与成功的日志有区别,出现了创建数据文件的日志,感觉比较奇怪,但不知道是什么原因。结果这是一个关键点,如果直接从这个点去排查,可能很快就发现问题了,但就这个问题还是耗费了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无法进行。
