最近给一套库做不完全恢复,其中映象较为深刻的对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位的版本低...
阅读 1249·2023-01-11 13:20
阅读 1558·2023-01-11 13:20
阅读 1012·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3971·2023-01-11 13:20
阅读 2519·2023-01-11 13:20
阅读 1355·2023-01-11 13:20
阅读 3486·2023-01-11 13:20