用户管理的备份恢复（2）

上一章我们讲述了在数据文件存在的情况下进行了联机备份和脱机备份，那这里我们考虑一个问题，要是我们在没有任何备份的情况下，删除了原有的数据文件，数据库启动直接报错，那我们应该怎么恢复呢？
场景模拟
1.首先我们结合上一章所创建的xx表空间，现在删除xx表空间的数据文件xx.dbf。
2.startup force ，重启数据库后发现数据库起不来了，停留在mounted状态。

面对上面的情况，写出“没有备份下数据文件丢失”的解决方案：

--第一步，首先将出问题的数据文件设置为offline状态，将事故影响范围减小
alter database datafile 6 offline;
alter database open;
--第二步，已将数据库启动了，但是还要解决数据文件遗失的问题，这里我们就需要利用到重做日志或归档日志帮助我们找回遗失的数据文件。
alter database create datafile 6;
现在我们回到原来被删除的目录下就会发现遗失的数据文件已经回来了，原理如下：
丢失一个数据文件，没有备份但是有该数据文件创建以来的归档怎么恢复
先决条件：
a. 不能是系统数据文件
b. 不能丢失控制文件
满足a,b两点的前提，我们可以完成数据文件恢复。
-第四步，我们需要进行介质恢复，保证数据的一致性。
recover datafile 6;
这个时候recover应该会出现（也可能不会）ORA-00279的错误，意思是我们需要通过归档日志进行介质恢复，这里提醒我们输入几个参数，直接输入auto即可，既是自动寻找数据进行恢复在归档日志中。
--第五步，已经完成介质恢复了，这时我们就需要将本来已下线的表空间重新上线。
alter database datafile 6 online;

::以上就是应对这个问题的简单处理情况，当然一事一议，每个问题的发生点不一样，按照这个思路去寻觅迟早可以解决问题::

这里再列举一个简单的场景，我们通过v$datafile可以查看到我们数据库内不管是oracle自带的表空间还是我们自行创建的表空间都是存放在同一个目录下，也就是存放在同一个“硬盘下面”，以/u01为例，/u01这个硬盘下面存放了整个数据库的数据文件，那这时，如果这个/u01的硬盘因突发原因损坏了或者即将要损坏呢？
针对上述问题，给出以下解决方案：

--首先我们需要建立一个新的分区，这个可以自行创建多一个分区，就不细讲。
--通过管理员身份登录sqlplus，还是以xx表空间为例，这里只举一个表空间为例子，其他的表空间作法可以跟这个一样，首先我们保证xx表空间已经做好了备份，这里要说一点，建议大家以后不论是脱机备份还是联机备份，都不要将备份后的文件和被备份的文件保存在同一个硬盘下面，避免出现硬盘损坏的时候，备份和源文件都不可用；
--将xx数据文件设置为offline状态
alter database datafile 6 offline;
--将刚刚已经备份好的文件拷贝到新的硬盘分区下的文件夹中，新的分区我以 /u02为例子，下的backup3文件夹
cp -a /u01/xx.dbf /u02/backup3
--这时已经将物理文件进行硬盘转移，如果我们是之前已将备份在第二硬盘就不需要考虑上一个步骤，接下来登入sqlplus，重新指定xx表空间的数据文件路径。
sqlplus /nolog
conn sys / as sysdba
alter database rename file '/u01/xx.dbf' to '/u02/backup3';
这时我们已经将原来是u01路径下的逻辑目录改为新硬盘下的目录。
--老规矩，将数据文件设置为online状态，进行介质恢复。
recover datafile 6;
alter database datafile 6 online;
大功告成！

::在一个数据库建设初期，建议把数据文件保存在不同的硬盘下，避免出现任何突发情况导致全路径下的数据文件同一时间崩溃，备份文件也是建议异地存储；上面这种情况就是介绍了我们如何发现硬盘损坏，怎么迁移硬盘的数据文件，保证新硬盘下的数据文件让数据库能正常使用的步骤，还是那句话，一事一议，遇到任何情况多花时间想清楚步骤，再下手去做，毕竟是个胆大心细的活.::

从这里结合上一章我们就是介绍了用户管理的备份恢复,为什么要叫用户管理的备份恢复？因为我们都是通过一些SQL语句和OS命令帮助我们恢复数据库，都是采用用户执行帮助下完成的，所以叫用户管理的备份恢复。

不完全恢复

这里讲一下不完全备份的步骤，至于什么叫不完全备份，可以理解为某个时间点归档日志或重做日志损坏从而实现不同的时间点/SCN号进行备份恢复：

1.备份所有的数据文件和控制文件
2.做不完全恢复（基于时间线的恢复）
2.1.利用recover恢复重做日志或归档日志记载的时间线内的数据，13:01插入了1条数据，13:05插入了一条数据，13:09插入了一条数据，这时13:05的硬盘突然出现问题，导致这个时间以后记载的重做日志数据丢失了，只能恢复到13:05这个时间线。
recover automatic datafile 6 utill time ‘2020-06-30 13:05:01’;
这个时候已经完成时间线的恢复，有一点要注意， _{实例必须在mount状态下使用。}
2.2 将数据库切换成open状态，这里系统会提示ORA-01589必须选用resetlogs或者noresetlogs状态，这里我们选择将重做日志重置，scn重新开始记录，alter database open resetlogs;
3.做完不完全恢复后，再把所有的数据文件和控制文件备份一次
4.alter system archive log current;(切换日志组)
5.完成不完全恢复（大功告成！）
不完全恢复只能在归档模式下工作
::接着上面所说，我们只是恢复单个数据文件，我们也可以将所有的数据文件恢复到某个时间点 recover automatci database utill time ‘2020-06-30 13:05:01’;前提要先将我们刚刚备份完数据文件全部restore到原来的路径覆盖，再执行此操作。::
科普一下，我们在实际的生产环境中，并不可能很精确的定位到重做日志是在哪个时间点损坏的，这个时候我们就需要依赖第三方工具的协助，这里推荐一个对口重做日志的工具（logminer）

第二种不完全恢复就是scn号恢复，大致流程都和时间线恢复一样，但唯一不同就是recover命令，首先我们select current_scn from v$database;—查看当前数据库的scn号，假如我们在当前查询的scn号又插入了几条数据，之后又插入几条数据，现在我要恢复到我第一次插入的时候，流程大致相同，不同的则是命令 recover automatic database until change scn号（第一次插入的scn号）;这就是唯一不同的地方。

总结

结合上章，我们讲述了完全恢复和不完全恢复的区别，这里简单总结一下：
完全恢复：脱机模式，联机模式
不完全恢复：联机模式（归档）
建议大家可以用两种不同的模式实验一下，谢谢。