最近给一套库做不完全恢复,其中映象较为深刻的对RMAN-20207（如下图）的报错处理方式，下面在测试环境中来复现。
1、前提条件，全库备份在，后续归档文件在。
==》我这套测试环境中只有1，2，3，4，5。这个5个数据文件。system，sysaux，undo（rac环境中各个节点都要还原）这个三类表空间是必须要恢复的。5号表空间是模拟业务表空间，是我们这次要恢复的目标。
==》通过如上命令还原表空间对应的数据文件。
==》这里通过skip方式跳过不需要恢复的表空间，恢复完成后，使用resetlogs方式打开数据库。红框中2号文件被offlinedrop，这里的2号文件对应的是test2这个表空间。换个思路就是说，我们不使用skip命令，而是提前将不需要的表空间对应的数据文件给offlinedrop掉，就可以直接使用recoverdatabase ;进行恢复。（当然这是另外一种思路了）。
2、发现只恢复test1表空间，数据有丢失，需要二次恢复把test2表空间给加上如下图：
==》这里还原时新加了test2表空间对应的数据文件，2号文件。
==》随后进行recover报RMAN-20209.这里就复现了之前生产的报错。
关于报错原因：
我这里模拟使用了resetlogs后的控制文件进行二次恢复的（如上图红框），因为incarnation发生了改变，导致恢复报错。实际上生产上进行了恢复就是犯了这个错误，从而引发后续一系列的问题。
1、通过resetdatabase toincarnation，调整到resetlog之前的incarnation号。此外，根据二次恢复需要，检查v$datafile中status状态，将新添加的文件修改为online（首次恢复，通过skip命令调整成了offline。实际生产中，我们虽然reset了incarnation,但是未将新增的文件给online就进行了recover，虽然recover没有报错，但在启库阶段数据库一直拉不起来，最终导致第三次重新恢复。
2、重新恢复一份resetlog前的控制文件，根据需要对文件进行重新rename,随后执行recover操作。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129982.html
摘要：在过程中，发现的报错是在中两个页面的无刷切换中出现的。看向网址等等网址的前缀是，这个是谷歌浏览器插件的前缀。难不成，这个文件是谷歌浏览器插件的于是看向了中间的那一串神秘字符串。 场景重现 项目是一个SPA，使用了Vue+Vue-Router+Webpack+jQuery。报错的场景如下：showImg(http://7xk109.com1.z0.glb.clouddn.com/blog...
摘要：里的并不是万能的，因为他只能够捕获异常，而不能够捕获级别的报错。如果想捕获级的报错，并且像异常处理一样，做法如下报错尝试获得结果参考本站的一个问答 php里的 try{}catch(Exception $e){} 并不是万能的，因为他只能够捕获异常，而不能够捕获PHP级别的报错。 如果想捕获PHP级的报错，并且像异常处理一样，做法如下： set_error_handler(func...
摘要：于是检查时发现，拼写错误，应为。第个问题，是真真切切错误卸载重要软件包，导致系统崩溃，修复系统的方法自然也就是利用原镜像在下把该装的都装回去，前提是日志存在，万幸没有执行过。 首先问题产生的缘由很简单，是我一同事在安装oracle一套软件时，按照要求需要binutils软件包的32位版本，然而在Oracle Linux已经装有64位，按理说是可以安装i686的，我猜应该是32位的版本低...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4100·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3597·2023-01-11 13:20
