How to recover the mistakenly deleted data files and control files by non-Rman method

After removing all controlfile control files on the Unix/linux, the instance does not crash at the first time, but it can also successfully complete the full checkpoint.

What is this for? ---Note that this problem applies only to Unix/linux, and that files that have already been opened by other processes are not allowed on the Windows platform.

The fundamental reason is that on Linux/unix read or write a file, the process will open a file associated with the open file descriptor open files descriptors (a file descriptor (FD) is a abstract Indicator for accessing a file. The term is generally used in POSIX operating systems. In POSIX, a file descriptor was an integer, specifically of the C type int.)

And in Linux/unix when a file is deleted, it is simply "unlink" that deletes a hard link hard link; the inode that actually contains the file data in all open file descriptors associated with the file (open files descriptors) Will not be physically deleted until it is turned off, and the process of opening the file descriptor can continue to read and write the file normally without using the close function to turn off these descriptors. The file is actually deleted when all the open files managed by the file are closed.

Note:--system cannot be recover online and needs to restart the database.

Undo can be recover online, but the undo file offline can not be manipulated--not DML, queries can--does not involve rolling back the data in the segment.

Other data files can be restored online.

The commands used are mainly:

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. Delete the recovery experiment for the system file:

Session 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

#############

Open a new Session 2:

View the DBWR process number and delete the/U01/ORADATA/BYS3/SYSTEM01.DBF

[Oracle@bys3 bys3]$ ps-ef |grep DBW |grep-v grep detect process pid---10986, Note here is the DBWR process, the control file, then check the CKPT process.

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

#########################