联机重做日志全部删除模拟丢失
关闭数据库重新启动看看数据库提示什么错误。重新启动数据
启动数据库 报错----提示找不到联机日志文件 也可以看警告日志。
因为我们的数据库是在非归档模式下建立的所以我们只能用控制文件来重建当前日志文件
用alter database open resetlogs来启动数据库 –数据库提示说resetlogs模式必须在不完全恢复模式下恢复；
用一个欺骗命令用备份的控制文件恢复(说明系统的控制文件的scn小于等于当前的数据文件头里的号) 我们用这个命令来告诉数据库我们用备份的控制文件来恢复当前控制文件然后
数据库自动去查找相应归档日志文件来恢复数据 ，因为我们是在非归档模式下的所以没有归档日志，而且当前的日志文件也丢失了。所以在执行到specify log时我们直接回车即可
直接用resetlogs直接打开数据库
我们查看下数据库 数据没有丢失。如果在数据库DBWN进程没有将提交的数据写入数据文件时 ，那么我们的数据库数据肯定会丢失了。因为联日志文件丢了。所以会造成数据丢失。
通过resetlogs命令打开数据库 我们的控制文件都自动的恢复完毕，但是里面的日志戳都丢失了。
如果用resetlogs模式 以前所有的归档日志全部不能使用，而且当前的log文件的scn号从1开始。代表以前所作的所有的操作都已经不能用日志恢复。如果使用这种模式重建控制文件建议数据库启动起来立刻做下全备份 然后重新建库 。
为了防止数据库中的联机重做日志丢失 建议数据库打开归档模式（现在我们就介绍非归档模式下所有的redolog全部丢失的情况下如何处理 保证数据数据的完整性）
打开归档模式的方式如下
现在已经是归档模式了
为了防止日志文件丢失或者是损坏我们需要在一个日志组下面放多个成员并且放在不同的磁盘位置上 ，而且日志文件的大小也要注意，如果在数据写入写出比较频繁的库中日志文件应稍大一些，能保证15-20分钟归档一次，而不是频繁的归档，如果是频繁归档数据库就会产生很大的屏障。在日志文件组不多的情况下频繁归档导致数据库变慢；--------
