昨日跟着君三思的涂抹oralce做RMAN的备份恢复实验，为了营造相同的实验环境，中间删除了books01.dbf这个文件，开始模拟控制文件丢失的情况，在这里我犯了一个错误，下面会讲，当我使用恢复操作之后重新打开数据库的时候，发现system01.dbf文件提示没有从过久的备份中恢复，原因为恢复之后的SCN与当前不一致，欲恢复之，发现控制文件是比较旧的时间，这就是我犯的错误，全库备份没有autobackup controlfile，导致恢复的控制文件是早上9点的，而其他的文件则是晚上6点的，并且无法open resetlogs，次奥啊，于是一直在恢复死循环中无限挣扎，后来“天高云淡”大师指点我查看v$datafile视图的status，发现被我删除掉的books01.dbf变成了unnamed00006，offline了，大擦嘞啊，drop offline之后，system01.dbf重新回到offline，unnamed00006offline了。。。在网上找到了用redolog还原数据文件的方法，一个一个试，终于redolog03可以用，介质恢复成功，成功恢复到晚上崩溃前的状态
但是查询jss.book_list，依然不可用，unnamed00006文件依然存在，
想办法还原books01.dbf，由于全库备份并没有此表空间，所以只能使用重做日志来恢复，此时又一个因为知识不全面而犯的错误，
open rsetlogs之后，联机存档日志组会清空，大概是这个意思吧？所以之前的14，5个日志序列都没有了，因为我恢复前没有备份，这是天高云淡大师告诉我的，说一般在生产环境中，肯定要先备份再恢复的，而且一般采用异机备份，这样能大大减少这样的误操作，。。。无奈使用君三思书中的办法，先创建那个数据文件，
查看之，名称已改好了，但SCN 依然是0，由于没有重做日志可用，几乎可以肯定没有办法还原了（当前能力和工具的限制范围内，大师说用复杂的工具可以）就在我万般绝望，准备放弃去睡觉的时候，我发现了flashback_recovery_area里面的几个文件，一看居然是重做日志文件，才忽然想到，闪回恢复功能是打开的，而且时间也吻合，尝试之
成功！！感谢上苍啊 ，
数据成功恢复，今天学到了很多东西，备份重于一切啊，要学习的还有很多，其实技术的学习让我很有感觉很有动力，加油！
