Linux下利用文件描述符恢复的成功失败实验
数据误删除是作为初级运维人员常常遇到的“低级错误”，一些有经验的老手有时也在疲劳、不冷静的情况下“马失前蹄”。一旦误删除数据文件，尽快采用影响最小、最迅速的手段恢复数据库是第一要务。
恢复数据的方法很多，比如冷热备份、闪回数据库等等，如果是直接从操作系统OS层面删除数据文件，在Linux/Unix环境下，有一些优选手段可以使用。其中之一就是文件描述符（File Description）。
--------------------------------------分割线 --------------------------------------
推荐阅读：
--------------------------------------分割线 --------------------------------------
1、聊聊File Description
不同的操作系统，在实现CPU管理、内存管理和存储文件管理的时候，采用不同的方式手段。
在Linux和Unix里面，采用文件描述符进行文件管理。一个进程要打开文件，是调用操作系统内核功能，内核返回一个文件描述符。对文件的读写操作也通过这个描述符进行操作。操作系统删除一个文件的时候，是要确定文件所有文件描述符都是释放掉之后，才会最后删除。
我们的误操作，如果是发生在正在运行的数据库系统中，文件虽然在操作系统上删除不可见了。但是数据库Oracle进程中还会保有一些存在的文件描述符，借用这些文件描述符，我们是可能找到文件信息，来恢复数据文件的。
所以，一旦发生了误删除动作，切忌三点：心态冷静、断开应用、维护现场不关库。
但是，在实际中，这种可以快速恢复的技术，并不是百分之百成功的。使用文件描述符恢复数据需要数据库不能关闭、数据库进程不能“自动剔除”数据文件等。本文从两个实验着手，介绍一下操作方法和前提。
2、实验环境搭建
我们选择Linux 2.6内核和Oracle 11g进行试验。注意：在生产环境下，绝对不能进行这样的实验。进行试验的时候，也需要完备的备份。
[oracle@bspdev ~]$ uname -a
Linux bspdev.localdomain 2.6.18-308.el5 #1 SMP Tue Feb 21 20:05:41 EST 2012 i686 i686 i386 GNU/Linux
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 – Production
创建专门的表空间、用户和数据表，用于进行试验。
SQL> create tablespace rmdtest datafile '/u01/oradata/WILSON/datafile/rmdtest01.dbf' size 1000m
2 extent management local uniform size 1m
3 segment space management auto;
Tablespace created
SQL> create user rmtest identified by rmtest default tablespace rmdtest;
User created
SQL> grant resource, connect to rmtest;
Grant succeeded
SQL> grant select any dictionary to rmtest;
Grant succeeded
SQL> create table rm_tab as select * from dba_objects;
Table created
SQL> insert into rm_tab select * from rm_tab;
72731 rows inserted
SQL> commit;
Commit complete
数据表T，在实验环境的表空间文件里面。
SQL> select tablespace_name, bytes/1024/1024 M from dba_segments where owner='RMTEST' and segment_name='RM_TAB';
TABLESPACE_NAME M
------------------------------ ----------
RMDTEST 17
确保有一份好的备份！
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
135 Full 1.39G DISK 00:03:13 02-FEB-14
BP Key: 135 Status: AVAILABLE Compressed: NO Tag: TAG20140202T012300
（篇幅原因，有省略……）
Piece Name:
Piece Name: /u01/flash_recovery_area/WILSON/autobackup/2014_02_02/o1_mf_s_838430779_9gtckx4s_.bkp
SPFILE Included: Modification time: 02-FEB-14
SPFILE db_unique_name: WILSON
Control File Included: Ckp SCN: 5370719 Ckp time: 02-FEB-14
下面进行两次实验过程，模拟运行状态下数据文件被删除的场景。注意：由于操作系统差异性，Windows下是不会出现“运行打开的文件被删除”的场景的。所以，在Linux/AIX中，更容易出现误删除的情况。
3、一次“不成功”的实验
首先是一次不成功的实验。运维生产环境中，我们的原则永远是稳定。危险不确定的事情场景，一定要避免。哪怕不做、不修、不优化，也不要让业务系统的可用性去冒险。
实验环境中，我们总能够发现很多知识和现象。首先，我们尝试删除数据文件，确认文件位置。
[oracle@bspdev ~]$ cd /u01/oradata/WILSON/datafile/
[oracle@bspdev datafile]$ ls -l | grep rmdtest01.dbf
-rw-r----- 1 oracle oinstall 1048584192 Feb 2 02:14 rmdtest01.dbf
删除文件。
[oracle@bspdev datafile]$ rm rmdtest01.dbf
[oracle@bspdev datafile]$ ls -l
total 8121892
-rw-r----- 1 oracle oinstall 10493952 Feb 2 02:14 mvtbltest01.dbf
（篇幅原因，有省略……）
-rw-r--r-- 1 oracle oinstall 10493952 Feb 2 02:14 tts_simple01.dbf
注意：此时数据文件虽然从OS中删除，但是我们依然可以查询到数据！
SQL> select count(*) from rmtest.rm_tab;
COUNT(*)
----------
145462
对于这种现象，笔者认为两种可能性，一是buffer cache中的缓存数据信息，可以支持这种查询动作。另一种可能性，就是由于文件描述符的存在，让数据文件没有被真正删除，还以某种方式存在于系统中，支持dbwr查询。
证明两种猜想，对buffer cache进行清理。
SQL> alter system flush buffer_cache;
System altered
SQL> alter system flush shared_pool;
System altered
--依然可以查询结果
SQL> select count(*) from rmtest.rm_tab;
COUNT(*)
----------
145462
但是，如果数据库以某种方式，发现了文件被删除，比如check point动作，就会引起很多自动化动作出现。