RMAN各种情况下的备份恢复

【ORACLE】RMAN各种情况下的备份恢复

小编通过三天总结出来这片RMAN各种情况恢复的文章，希望能帮助大家解决一些生产上出现的问题。

众所周知，RMAN是ORACLE最常用的物理备份手段，也是数据库中最重要的知识点之一，但是也最容易被人忽略，小编一向本着实验证明真理的角度去尽力做好这个公众号，而且RMAN的操作也是需要大量的实验去验证和学习，所以我们今天来模拟一下各种情况下导致的数据库崩溃恢复情况。

这里先介绍一下试验环境：

单实例数据库：192.168.1.20

实例名：orcl

归档：开启

人们常说有了全被都不怕，现在先对数据库做一次全备

我们得到了以下的备份文件

下面我们就根据不同的情况进行数据库恢复：

1.数据文件丢失，一般是人为误操作，或者是磁盘出现问题的常见故障导致。

情况一：应用数据文件丢失数据库重启

我们删除了用户数据文件之后发现，数据库重启只能开启到mount状态data file 5丢失。

现在即可打开数据库。

情况二：应用数据文件丢失没有重启。

有时候磁盘出故障，导致数据文件丢失之后数据库在短暂时间之内是正常运行的，insert，select，这个表空间内的表都是正常的，我们来模拟一下

我们发现依旧可以插入，可以查询，这是因为控制文件依旧认为数据库是正常的，而且手动触发check point的时候还能落盘，commit操作也可以，有点不合常理，这里的原因可能是因为数据库这个时候的插入操作依旧插入到内存之中，没有落到磁盘里，这是linux的缓存特性导致的，linux下有句话称为‘杀不了的oracle’，即使数据库数据文件被删除，但是依旧有缓存信息在内存当中，直至真正发现其文件丢失，这时alert日志记录依旧正常。

多次执行alter system flush buffer_cache之后我们发现报错会被抛出，而且也无法查询和写入这个表了

我们在这种情况下恢复数据库的时候只能采用强制重启到mount的时候操作。

recover database ;

如果数据文件丢失数据库没有发现其数据文件丢失，我们可以将这个数据文件offline掉，之后将其恢复，不用关闭数据库。

注意：这里一定要offline数据文件，不能offline表空间，表空间无法offline

我们在offline 数据文件之后，我们查看数据文件状态,已经成为recover模式，这个时候就可以根据备份恢复了

接下来我们进行恢复操作

我们去数据库中查看数据文件状态，已经从recover 状态变成了offline状态。

我们将它online，这里可以使用datafile，也可以使用tablespace

恢复完成~~~~~~

这里可能有人要问，那system表空间如果丢失能用这种方法吗？我们通过实验看一看

果然是不行的，system表空间不能直接offline，系统的动态视图都在这里记录，怎么可能offline呢。

2.oradata全部丢失

有的时候当数据库磁盘损坏，导致所有的oradata下的文件全部丢失，这种情况下有备份在其他磁盘上的话，可以进行恢复，接下来实验鉴定真理。

我先在test.a表里面插入一条数据，之后再去说我的用意

删除oradata所有文件

这个时候，数据库有可能还能用，就是因为我之前说的，linux的缓存体系导致的，现在他的信息记录在缓存当中，所以数据库可能暂时还是可以使用的。但是即使能用，高兴不了多久，马上就会连登陆都难。

好，那我们来进行恢复。

首先我们先把数据库的进程杀掉。针对linux系统来说数据库是多进程的，我们只需要kill掉pmon或者是smon的话所有进程就都被干掉了。

进程都没有了，我们现在能把数据库开到nomount状态，因为我们的参数文件还在，参数文件是放在$ORACLE_HOME/dbs下的。或者更悲观的spfile不见了，我们也可以先通过pfile手动写入将其开到nomount状态，再把spfile恢复，之后用spfile启动，这里不做多余实验，很简单的。

现在我们是在nomount状态下，我们知道restore database的时候必须数据库要在mount模式才能使用，然而从nomount到mount又需要我们的controlfile，这个时候就要恢复我们的controlfile。

恢复完之后我们发现数据库的controlfile一个恢复到了oradata，然而还有一个放在了闪回区当中，这个时候我们可以把数据库开启到mount状态下，我们去看一下数据文件是否恢复回来了。

控制文件回来了，我们再往下进行restore database

注意这里在recover的时候恢复到了第180号归档，这里一定要注意，因为我们在操作数据库的时候，没有对当前的日志进行归档操作，所以，在没有生成归档的时候我们删除了redolog，这里控制文件当中已经记录了181号归档，但是没有生成对应的181号，所以这里的恢复成功也会丢失掉我们插入的数据。

在这里我们需要恢复完之后，我们开启数据库提示需要resetlogs，这是因为在我们在对数据库进行恢复的时候，controlfile file丢失，我们使用备份的control file进行恢复，所以需要将数据库开启的时候resetlogs，日志的序号重新从1开始，并且这个操作会生成一个新的incarnation，这里先不说incarnation的问题，我会在文章会提到，只需要记住的是，一旦将数据库resetlogs打开之后，就一定要为数据库创建一次全备。

我们查看数据库发现已经是open状态了

我们去查一下test.a的那张表

我们发现，之前我们插入的id=5的数据丢失了，这是因为当时我们在插入test.a id=5,name=d的时候，我没有手动生成归档，当时的使用的redo日志文件没有生成归档就被我删除了，所以恢复完成后的scn号要早于我插入时的scn，所以当前的恢复丢了一部分数据，这里一定要注意的是，已经进行了resetlogs的操作，这样就会生成一个新的incarnation，也就是说进入了一个新的状态，我们之后做实验进行恢复的时候，就不能在使用之前的数据文件备份，否则只能恢复到值前的incarnation最后的一个状态。（关于incarnation，我会在后续出文章）

3.基于时间点的数据库恢复操作

这种恢复一般用在把数据库恢复到某一个时间点状态的情况下，比如说有人误删了一个表，有人误删了一个用户的操作，这里一定要注意，这种恢复是将整个数据库回退到某一个时间点当中。不是恢复一张表，一个用户。

我们先模拟一下场景：

想要恢复到一个指定scn 的话一定要将数据库开启到mount状态下。生产上不要学我Startup force很危险。

比较简单，切记，这种数据丢失的操作一定需要resetlog开启数据库。并且数据已经回到这个时间点了。

我还要多一句嘴，有些时候要是误操作的时候可能没有办法确定误操作前的scn是多少，所以可能需要进行日志挖掘，这是一件特别头疼的事情，当然ORACLE也提供了基于时间进行数据恢复的操作。

set until time="to_date('2018-04-19 15:27:00','yyyy-mm-dd hh24:mi:ss')";

这种用法在生产上用的更多一点，但是粒度可能会更大一点，也就是回滚的内容可能会更多，择优考虑。

4.redo日志的丢失

其实redolog丢失不需要rman的帮助，因为他在/oradata/下所以我就把它放在这里讲了，一般情况下，我们作为一个合格的dba，都会配置多个group 组去提升数据库性能，并且为每个group下去添加多个member保证冗余，但是这里是极端情况下丢失redolog的情况。

其实这种恢复方法有多种，我们一一描述一下：

情况一：丢了inactive的日志

我们去删除数据库对应的redo02.log

这个时候如果归档切了，数据库就会甩出一个报错，这种其实就是active状态的logfile丢失的恢复手段。

这里使用unarchived的原因是，current状态的日志丢失，没有生对应得归档文件，但是关闭的方法是一致性关闭，这里也就是强制将数据库日志清空。所以可能导致以后通过归档恢复数据的时候会数据丢失。

这样redo02就回来了。对应的日志状态也就成了unused状态了。

如果我们redolog丢的就是inactive的并且没有切到丢失的日志上，恢复起来就比较简单，这里就不需要让它不记录归档，因为inactive状态的日志已经被归档了。

情况二：丢了active的日志

我们上面也说了一种inactive日志丢失的情况，因为他们已经生成对应的归档，所以我们可以清空日志。只需要alter database clear logfile group 2;这里也没啥区别。

情况三：非一致性关闭数据库

我前面的两个实验多次强调的是一定要shutdown immediate一致性关闭数据库，这是因为在一致性关闭数据库的时候其生成了对应的归档文件，使用alter database clear的冰凌可以直接清空日志并且将其打开，如果是非一致性关闭，是不能这样操作的。

这个时候有两种方法可以解决这种问题：

第一种，采用欺骗的手段：假装做一次回复操作，实则没有回复，进行非一致性恢复操作。

这里找不到对应的3号，归档因为在非一致性关闭的时候没有生成归档日志，所以会丢失。看一下最新生成的归档是2号归档

恢复完之后虽然有报错，但是我们不要管他，直接alter database open resetlogs; 打开，如果可以，那么就证明恢复成功，如果不行，那么就需要进行隐藏参数的方法。下图就是不能恢复的情况陷入了一个死循环，一般是在非贵党模式下导致的。

第二种，隐藏参数“_allow_resetlogs_corruption'':

这种方法是一种特殊方法，通过在参数文件当中配置隐藏参数，在数据库开启的时候跳过一致性检验，可以强制将数据库拉起来，同时，在开启该参数之后开启数据库，也一定要把这个参数关掉，否则会经常报出ora-00600的各种报错，十分头疼。

将数据库重启到mount状态，并且将其resetlog打开：

注：如果数据库开启了闪回，那么是不允许其使用backup controlfile 恢复

THAT'S ALL

BY CUI PEACE!!!