归档模式和非归档模式下的数据恢复区别

首先，归档模式和非归档模式下的数据恢复是物理恢复。
归档模式下试验流程：
1. 创建一个表空间test1 使用test01.dbf；
2. 给test01.dbf创建一个副本（备份）；
3. 做一些操作使test01.dbf文件中的数据发生变化；
4. 切换联机日志文件，让它归档；
5. 关闭数据库，删除test01.dbf，启动数据库找不到文件；
6. 把最初的副本复制过去，或者让alter database renamed file；
7. 然后开启提示要恢复。最后恢复成功，步骤3的操作也都在
非归档模式下的流程：
与归档模式基本一致，区别：
1. 步骤4对于非归档模式意义不大；
2. test1 之类都都变成了2；
3. 步骤7恢复很快捷，不过恢复方法是有区别的。

总结：
非归档模式和归档模式都能进行数据文件的恢复，共同点是都必须有依靠一个备份文件才能恢复备份之后的操作。区别在于：
1. 归档模式依靠归档日志文件，使用arc放入data buffer cache再写入以此恢复
2. 非归档模式依靠联机日志文件，放入data buffer cache再写入以此恢复

我们知道，联机日志文件本身不大，是通过arc把它里面日志放到大得多的归档日志文件进行归档，以此保存更长久的日志。

步骤1： 创建一个表空间test1 使用test01.dbf；

SQL> archive log list
数据库日志模式非存档模式
自动存档禁用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 86
当前日志序列 88

SQL> alter database close;//到mount阶段
数据库已更改。

SQL> alter database archivelog;
数据库已更改。

SQL> archive log list
数据库日志模式存档模式
自动存档启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 86
下一个存档日志序列 88
当前日志序列 88
SQL> shutdown immediate
ORA-01109: 数据库未打开

已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。

Total System Global Area 1653518336 bytes
Fixed Size 2176288 bytes
Variable Size 1073744608 bytes
Database Buffers 570425344 bytes
Redo Buffers 7172096 bytes
数据库装载完毕。
数据库已经打开。
SQL> create tablespace test datafile 'D:/test01.dbf' size 5M;

表空间已创建。

步骤2：给test01.dbf创建一个副本（备份）；

SQL> host copy D:\test01.dbf E:\test01.dbf
已复制 1 个文件。

这里数据库打开也可以复制
步骤3：做一些操作使test01.dbf文件中的数据发生变化；

SQL> conn scott/tiger
已连接。
SQL> create table test tablespace test as select * from emp;//修改了数据

表已创建。

步骤4： 切换联机日志文件，让它归档；

SQL> conn sys/xuhan1992 as sysdba
已连接。

SQL> select group#,sequence#,bytes,members,archived,status from v$log;

GROUP# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- --- ----------------
1 88 52428800 1 NO CURRENT
2 86 52428800 1 YES INACTIVE
3 87 52428800 1 YES INACTIVE
经过多次 alter system switch logfile・・・・・・
SQL> select group#,sequence#,bytes,members,archived,status from v$log;

GROUP# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- --- ----------------
1 94 52428800 1 YES INACTIVE
2 95 52428800 1 NO CURRENT
3 93 52428800 1 YES INACTIVE
这里要说明：
CURRENT表示LGWR正在使用
ACTIVE表示LGWR没有使用，但是实例恢复还需要它，归档模式的话它就现在等待归档
INACTIVE表示LGWR没有使用，实例恢复也不需要它，归档模式的话它就已经被arc进程拿去归档。

现在它是INACTIVE了，归档就是在ACTIVE到INACTIVE的切换中完成的（我们刚刚是手动切换的）
步骤5：关闭数据库，删除test01.dbf，启动数据库找不到文件；

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host del d:\test01.dbf
SQL> startup
ORACLE 例程已经启动。

Total System Global Area 1653518336 bytes
Fixed Size 2176288 bytes
Variable Size 1073744608 bytes
Database Buffers 570425344 bytes
Redo Buffers 7172096 bytes
数据库装载完毕。//证明数据库已经到mount状态，是打开数据文件，发现找不到而出错的
ORA-01157: 无法标识/锁定数据文件 5 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 5: 'D:\TEST01.DBF'

6. 把最初的副本复制过去，或者让alter database renamed file；
关闭数据库
SQL> host copy e:\test01.dbf d:\test01.dbf
已复制 1 个文件。
7. 然后开启提示要恢复。最后恢复成功，步骤3的操作也都在

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 1653518336 bytes
Fixed Size 2176288 bytes
Variable Size 1073744608 bytes
Database Buffers 570425344 bytes
Redo Buffers 7172096 bytes
数据库装载完毕。
ORA-01113: 文件 5 需要介质恢复
ORA-01110: 数据文件 5: 'D:\TEST01.DBF'

SQL> recover datafile 5;
ORA-00279: 更改 2684172 (在 11/16/2013 11:59:29 生成) 对于线程 1 是必需的
ORA-00289: 建议:
G:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GUJUNPU\ARCHIVELOG\2013_11_16\O1_MF_1_8
8_98FW0GTV_.ARC
ORA-00280: 更改 2684172 (用于线程 1) 在序列 #88 中

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 2684951 (在 11/16/2013 12:09:50 生成) 对于线程 1 是必需的
ORA-00289: 建议:
G:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GUJUNPU\ARCHIVELOG\2013_11_16\O1_MF_1_8
9_98FW0PTH_.ARC
ORA-00280: 更改 2684951 (用于线程 1) 在序列 #89 中

ORA-00279: 更改 2684956 (在 11/16/2013 12:09:58 生成) 对于线程 1 是必需的
ORA-00289: 建议:
G:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GUJUNPU\ARCHIVELOG\2013_11_16\O1_MF_1_9
0_98FW0WMT_.ARC
ORA-00280: 更改 2684956 (用于线程 1) 在序列 #90 中

ORA-00279: 更改 2684959 (在 11/16/2013 12:10:03 生成) 对于线程 1 是必需的
ORA-00289: 建议:
G:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GUJUNPU\ARCHIVELOG\2013_11_16\O1_MF_1_9
1_98FW0Z24_.ARC
ORA-00280: 更改 2684959 (用于线程 1) 在序列 #91 中

ORA-00279: 更改 2684963 (在 11/16/2013 12:10:06 生成) 对于线程 1 是必需的
ORA-00289: 建议:
G:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GUJUNPU\ARCHIVELOG\2013_11_16\O1_MF_1_9
2_98FW1NFR_.ARC
ORA-00280: 更改 2684963 (用于线程 1) 在序列 #92 中

ORA-00279: 更改 2684977 (在 11/16/2013 12:10:27 生成) 对于线程 1 是必需的
ORA-00289: 建议:
G:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GUJUNPU\ARCHIVELOG\2013_11_16\O1_MF_1_9
3_98FW1Q9P_.ARC
ORA-00280: 更改 2684977 (用于线程 1) 在序列 #93 中

已应用的日志。
完成介质恢复。
SQL> select status from v$instance;

STATUS
------------
MOUNTED

SQL> alter database open; ;

数据库已更改。
最后也查到内容了，太长就不贴出来了
接着做了一个测试：
1.我切换到非归档模式，还是删除test01.dbf2.复制、恢复结果：由于已经归档，哪怕现在不是归档模式，恢复的时候还是用的归档文件
那如果一开始就是非归档模式，在恢复的时候会略有不同：
SQL> startup
ORA-01081: 无法启动已在运行的 ORACLE - 请首先关闭它
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01113: 文件 6 需要介质恢复
ORA-01110: 数据文件 6: 'E:\TEST02.DBF'

SQL> recover datafile 6;
完成介质恢复。 //这里没有像刚才一样启用很多的线程，而这里就这一行字，而且一下就结束了，速度也快得多。
最后是也是正常恢复。
和归档模式使用归档日志文件恢复不同，非归档模式下恢复数据文件使用的是联机日志文件（但跟实例恢复有区别，实例恢复是自动执行的），而且更快。
但是这里数据量小，而且受到联机日志文件大小的限制，不能长久的依赖它来进行数据恢复。