在Unix/Linux上删除所有的Controlfile控制文件后实例并不会在第一时间crash，相反居然还可以顺利完成FULL checkpoint 。
这是为什么呢？ ---注意这个问题仅适用于Unix/Linux， 在Windows平台上不允许删除 已经被其他进程打开的文件。
究其根本原因是在Linux/Unix上Read 或 Write一个文件，进程都会打开一个与此文件相关联的 打开文件描述符 Open File Descriptors (a file descriptor (FD) is an abstract indicator for accessing a file. The term is generally used in POSIX operating systems.In POSIX, a file descriptor is an integer, specifically of the C type int.)
而在Linux/Unix上当一个文件被删除时，它只是简单地被”unlink”即删除一个硬链接hard link； 实际包含文件数据的inode 在所有与该文件关联的 打开文件描述符(Open File Descriptors)被关闭之前 都不会被实际删除，已经获得 打开文件描述符的进程 只要不用close函数关闭掉这些描述符， 都可以继续正常地对文件进行读写。 当所有该文件管理的打开文件符都被关闭时 文件才真正意义上被删除。
注意：--SYSTEM不能在线RECOVER，需要重启数据库。
UNDO可以在线RECOVER，不过UNDO 文件OFFLINE了不能做操作了--不能DML，查询可以--不涉及回滚段中数据的可以。
其它数据文件可以在线恢复。
使用的命令主要是：
ps -ef |grep dbw |grep -v grep
ps -ef |grep ckpt |grep -v grep
ll /proc/10986/fd
cp /proc/10986/fd/258 /u01/oradata/bys3/system01.dbf
alter database datafile 6 offline;
recover datafile 6;
alter database datafile 6 online;
1.删除SYSTEM文件的恢复实验：
会话1：
SYS@ bys3>select * from v$dbfile;
FILE# NAME
---------- ----------------------------------------
1 /u01/oradata/bys3/system01.dbf
2 /u01/oradata/bys3/sysaux01.dbf
3 /u01/oradata/bys3/undotbs01.dbf
4 /u01/oradata/bys3/user01.dbf
5 /u01/oradata/bys3/test1.dbf
6 /u01/oradata/bys3/test2.dbf
7 /u01/oradata/bys3/test22.dbf
8 /u01/oradata/bys3/test3.dbf
SYS@ bys3>select open_mode from v$database;
OPEN_MODE
--------------------
READ WRITE
#############
新打开一个会话2：
查看DBWR的进程号，并删除/u01/oradata/bys3/system01.dbf
[oracle@bys3 bys3]$ ps -ef |grep dbw |grep -v grep 查出进程PID---10986，注意这里查的是DBWR进程，如是控制文件，则查CKPT进程。
oracle 10986 1 0 Mar01 ? 00:04:10 ora_dbw0_bys3
[oracle@bys3 bys3]$ pwd
/u01/oradata/bys3
[oracle@bys3 bys3]$ ls
control01.ctl redo02.log system01.dbf test22.dbf undotbs01.dbf
control02.ctl redo03.log temp01.dbf test2.dbf user01.dbf
redo01.log sysaux01.dbf test1.dbf test3.dbf
[oracle@bys3 bys3]$ rm -rf system01.dbf
#########################