事情是这样的，上周六中午刚要出去吃饭，便看到微信群里备份工程师的微信消息，说某套环境备份失败，让 DBA 检查下环境，我猜想这不是什么大问题，便不慌不忙的登陆到服务器上，打开备份的日志查看，果然不是什么大问题，之前也出现过类似的问题。结果日志中出现很明显、很关键的几个错误，如：RMAN-03002 、RMAN-06059、ORA-19625、ORA-17053、ORA-15012，日志报错如下截图：

那么，我们来一起扯扯事情发生的经过吧。

起因：

看到这报错，很简单对吧，找不到归档日志，便报错了，基本上没什么可说的，但对于初学者而言，还是记录以下，以便后来者参考。先说说这个错误怎么来的吧，事情的经过是这样的（回忆片段走起），上周四晚上回家途中，马上要下地铁了，手机微信里出现了一大片关于数据库的告警，数一数有 7 套数据库同时告警，感觉出大事了，后来说是存储那边出问题了，经过一天的修复，只剩下一台机器有问题了，操作系统无法启动，也修复不了，幸好修复不了的机器只是我们数据库的一个节点，可这就造成了我们其中的一台数据库由RAC 变成单点了。

经过：

数据库由 RAC 变成单机的了，总不能一直单机跑着啊，于是，上周五晚上便开始停业务起变更，对数据库进行添加节点的操作，方案是这么定下来了，可是明天和意外永远不知道那个先来，停完业务，数据库这边准备的差不多了，可是虚拟化存储那边的工程师可让人无语。五六个小时了虚拟机分不出来，各种问题，等到凌晨两点了，也没搞定。最后，人家领导决定不这么干了，等到周六晚上重建，这就意味着我们数据库需要新搭建一套环境，然后将之前的数据做全备进行恢复，幸好也是数据量不大，之前也出现过这样的案例。那就这么定了，上周六晚上，开始新建环境恢复数据。我们这帮人也就消停了，各回各家撤人了，于是乎，也体验了一把 凌晨三点的北京，还特意发了一下朋友圈！

结果：

上周六晚上，虚拟化、操作系统、数据库岗一起协作，经过大半夜的努力，大概凌晨四点多，也没出现什么问题，看到我们同事群里说数据库恢复好了，业务可以验证功能了，也就算重建、恢复完成了。数据库正常使用了，备份工程师需要部署备份，那么，执行备份时就出现了开篇中的问题。

问题解决：

由于是新装的机器，旧的备份和归档日志没有复制过来，控制文件里面还有这些归档日志文件信息， RMAN 备份时会去备份这些归档日志，而这些旧的归档日志又不存在了，所以就会出现这个错误。这才是重点，既然知道了这个问题，就先解决了在说吧。两条命令搞定，如下：

crosscheck archivelog all; 检查控制文件和实际物理文件的差别，如果一些归档日志已经删除或丢失，那么设置它们为expired。

delete expired archivelog all; 同步控制文件的信息和实际物理文件的信息(it will delete expired archivelog and updates your controlfile)。

问题解决了，说一下如上问题出现的其他可能性，手工删除归档日志或移动了归档日志也会出现如上的错误，需要手工执行 crosscheck 过程后，RMAN备份才能正常进行。

有时候，Oracle  自带的原生态命令也可以帮助我们查看问题，我记得以前面试的时候，居然没有回答上来这个命令的使用，这里大概记录一下，oerr 命令是 $ORACLE_HOME/bin 下自带原生态命令，故需要在 OS 层面下的 oracle 用户执行，例如：oerr ora 600 等。

通过 OS 层面也能查个七七八八，基本的 ora 和 rman 错误均可查看，用好了也是一把利器，让我们一起学习一下吧，出现问题时先通过 OS 的提示看看也很方便。

好了，今天就说这么多吧，对于上文中的  RAC 是怎么重建怎么恢复的，以后有时间再说，最重要的一点就是做好备份，不管冷备，热备，至少有一个，保障数据不丢失就行。