#加深对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

Linux下Oracle 数据文件被物理误删除的恢复