#加深对Linux句柄的理解/紧急情况下Oracle的快速恢复
不同于从Oracle中drop掉数据文件，在某些情况下，可能会遇到数据库在运行时数据文件在操作系统级别被删除，而此时Oracle实例并未崩溃，仍然处于open状态。此时就要求尽量在最小的影响下最高效率地完成恢复。现将恢复过程整理出来，以备不时之需。
<<过程模拟>>
<STEP 1>模拟删除
SYS@icsdb >select name from v$datafile;
NAME
--------------------------------------------------
/ora_data/icsdb/system01.dbf
/ora_data/icsdb/sysaux01.dbf
/ora_data/icsdb/undotbs01.dbf
/ora_data/icsdb/users01.dbf
/ora_data/icsdb/icsdb01.bdf
/ora_data/icsdb/hr01.dbf
已选择6行。
[root@iccsdb01 icsdb]# ls -ld icsdb01.bdf
-rw-r-----. 1 oracle oinstall 1073750016 5月 25 16:24 icsdb01.bdf
检查一下数据看看当前表和数据条数，有3个表
ICS@icsdb >select table_name from user_tables;
TABLE_NAME
------------------------------------------------------------------------------------------
SC
COURSE
STUDENT
已student表为例，说明表中有39条数据
ICS@icsdb >select count(*) from student;
COUNT(*)
----------
39
insert into student values(200216303,‘王伟‘,‘男‘,33,‘IS‘);
删除测试数据文件
[root@icsdb02 icsdb]# rm -rf /oracle_data/icsdb/icsdb01.dbf
SQL> ho rm /oracle_data/icsdb/icsdb01.dbf --删除用户数据文件;
在查看数据文件已经不在了
[root@iccsdb01 icsdb]# ls -ld icsdb01.bdf
ls: 无法访问icsdb01.bdf: 没有那个文件或目录
这里千万不要重启数据库，否则就真丢了
<STEP 2>通过句柄恢复数据文件--先找出db writer所对应的PID(3742)
[root@iccsdb01 icsdb]# ps -ef|grep dbw0|grep -v grep
oracle 3742 1 0 11:13 ? 00:00:00 ora_dbw0_icsdb
--再找出被进程所删除文件的句柄(3742)，可能会有多个进程，本处只有一个
[root@iccsdb01 icsdb]# ls -l /proc/3742/fd | grep deleted
lrwx------. 1 oracle oinstall 64 5月 25 16:36 263 -> /ora_data/icsdb/icsdb01.bdf (deleted)
--将被删数据文件的句柄拷贝回数据文件，先备份到tmp下
[root@iccsdb01 icsdb]# cp /proc/3742/fd/263 /tmp/icsdb01.dbf
重启数据库测试恢复，关闭数据库关闭不掉会报错
SYS@icsdb >shutdown immediate;
ORA-01116: 打开数据库文件 5 时出错
ORA-01110: 数据文件 5: ‘/ora_data/icsdb/icsdb01.bdf‘
ORA-27041: 无法打开文件
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
强制关闭数据库
SYS@icsdb >shutdown abort
ORACLE 例程已经关闭。
启动数据库测试，启动只能启动到mount状态，open不了
SYS@icsdb >startup
ORACLE 例程已经启动。
Total System Global Area 471830528 bytes
Fixed Size 2254344 bytes
Variable Size 360712696 bytes
Database Buffers 104857600 bytes
Redo Buffers 4005888 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 5 - 请参阅 DBWR 跟踪文件 ORA-01110:
数据文件 5: ‘/ora_data/icsdb/icsdb01.bdf‘
SYS@icsdb >select instance_name,status from v$instance;
INSTANCE_NAME STATUS
------------------------------------------------ ------------------------------------
icsdb MOUNTED
将数据文件拷贝会原来目录，并修改属组为oracle
[root@iccsdb01 tmp]# mv icsdb01.dbf /ora_data/icsdb/
[root@iccsdb01 icsdb]# chown oracle:oinstall icsdb01.dbf
alter tablespace ICSDB rename DATAFILE ‘/ora_data/icsdb/icsdb01.bdf‘ to ‘/ora_data/icsdb/icsdb01.dbf‘;
<STEP 3>通过日志恢复事务
接下来便是事务的恢复操作，分为两种情况：
1)对于归档模式，只需简单offline掉数据文件，进行recover最后再将数据文件online即可，如：
SQL> alter database datafile 4 offline;
Database altered.
SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;
Database altered.
2)如果是非归档，那么作offline datafile的时候会遇到ORA-01145错误，但是可以在copy完文件句柄之后，
尝试offline tablespace，然后再online tablespace，这时候会要求恢复之前误删除的文件，如果日志组还没有切换到全部覆盖，那么recover是可以成功的。
SQL> alter tablespace users offline;
Tablespace altered.
SQL> recover datafile 4 ;
Media recovery complete.
SQL> alter tablespace users online;
Tablespace altered.
至此恢复完成！
<<恢复原理>>
在Linux操作系统中，如果文件从操作系统级别被rm掉，之前打开该文件的进程仍然持有相应的文件句柄，所指向的文件仍然可以读写，
并且该文件的文件描述符可以从/proc目录中获得。但是要注意的是，此时如果关闭数据库，则此句柄会消失，那么除了扫描磁盘进行文件恢复之外就没有 其它方法了，
因此在数据库出现问题的时候，如果不确认情况的复杂程度，千万不要随便关闭数据库。重启数据库往往是没有意义的，甚至是致命的。
另：rm操作始终是系统上最危险的区域，需谨慎驾驶！
本文出自 “学习像树一样活着” 博客，请务必保留此出处http://laobaiv1.blog.51cto.com/2893832/1948152
原文地址：http://laobaiv1.blog.51cto.com/2893832/1948152
