oracle误用操作系统命令删除数据文件的恢复方法

事故原因:

1.由于误操作用hp unix 命令 rm -f datafilename 删除表空间的数据文件

2.alter tablespace tablespacenaem drop datafile datafile ;

3.drop tablespace tablespacename including content and datafiles;

上述两个步骤我用了近三个小时都没有执行完，最后导致数据库宕机。下面把我当时启动数据的后台页面展现给大家，为以后出现同样的问题，提供一个参照的作用.

SP2-0734: unknown command beginning "sqlplus /n..." - rest of line ignored.
SQL> conn sys/passwd as sysdba;
Connected to an idle instance.
SQL> startup
ORACLE instance started.

Total System Global Area 3.2212E+10 bytes
Fixed Size                  2115136 bytes
Variable Size            3204450752 bytes
Database Buffers         2.8991E+10 bytes
Redo Buffers               14659584 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 3.2212E+10 bytes
Fixed Size                  2115136 bytes
Variable Size            3204450752 bytes
Database Buffers         2.8991E+10 bytes
Redo Buffers               14659584 bytes
Database mounted.
SQL> recover datafile tbs_db_bas2.dbf;
ORA-02236: invalid file name

SQL> recover datafile '/data/tbs_db_bas2.dbf';
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> revover database;
SP2-0734: unknown command beginning "revover da..." - rest of line ignored.
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> shutdown immediat;
SP2-0717: illegal SHUTDOWN option
SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 3.2212E+10 bytes
Fixed Size                  2115136 bytes
Variable Size            3204450752 bytes
Database Buffers         2.8991E+10 bytes
Redo Buffers               14659584 bytes
Database mounted.
SQL> alter database datafile '/data/tbs_db_bas1.dbf' offline drop;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> alter database datafile '/data/tbs_db_bas2.dbf' offline drop;

Database altered.

SQL> alter database open;

Database altered.

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
oracle@hljww:/oracle/oracle/OraHome_1/network/admin$ lsnrctl

LSNRCTL for HPUX: Version 10.2.0.4.0 - Production on 03-MAY-2010 20:13:51

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> stop
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hljww)(PORT=1521)))
The command completed successfully
LSNRCTL> start
Starting /oracle/oracle/OraHome_1/bin/tnslsnr: please wait...

TNSLSNR for HPUX: Version 10.2.0.4.0 - Production
System parameter file is /oracle/oracle/OraHome_1/network/admin/listener.ora
Log messages written to /oracle/oracle/OraHome_1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hljww)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hljww)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for HPUX: Version 10.2.0.4.0 - Production
Start Date                03-MAY-2010 20:14:08
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /oracle/oracle/OraHome_1/network/admin/listener.ora
Listener Log File         /oracle/oracle/OraHome_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hljww)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "hljwxwl" has 1 instance(s).
  Instance "hljwxwl", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

-- 总结上述报错原因是由于我的数据文件没有在oracle内部进行删除导致数据库重新启动时找不到相应的数据文件，报上述错误，所以我建议大家遇到问题时，要沉着，冷静，不要乱，做好备份工作，特别是遇到错误时我们上网查一下oracle错误，进行相应的处理。下面我把这次我用到的文档分享给大家，其中粉红色字体为本次用到的解决方案。

ORA-1157, "cannot identify/lock data file %s - see DBWR trace file"

引起的原因：

因为数据文件已经在被使用了从而导致数据库的后台进程不能找到相应的数据文件或者不能锁定相应的数据文件，这样数据库将禁止访问这些数据文件而其他的数据文件则没有影响。伴随这个错误操作系统将会提示是哪个数据文件不能被识别。

ORA-01157错误一般和ORA-01110错误一起出现，往往还有操作系统级别上的错误，例如ORA-07360，同时一个DBWR的trace文件会在background_dump_dest的目录下生成。例如，在Solaris的平台上，会有如下的错误信息显示：
more..
less..
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file

ORA-01110: data file 5: '/export/home/Oracle/oradata/817/users01.dbf'

然后查看DBWR的trace文件内容，会有如下的内容：

ORA-01157: cannot identify/lock data file 5 - see DBWR trace file

ORA-01110: data file 5: '/export/home /Oracle/oradata/817/users01.dbf'

ORA-27037: unable to obtain file status

SVR4 Error: 2: No such file or directory

Additional information: 3

下面就几个容易产生ORA-1157错误的方面详细谈谈：

二． 通常引起ORA-1157错误的原因和解决方法

如果你是使用Oracle9i，就用SQLPLUS代替SVRMGRL执行以下的命令。

1． 数据文件存在，但是Oracle认不到它

这种情况可能是在操作系统级上数据文件被重命名了或者移动到了一个新的分区或者位置，这种情况比较简单，只是需要将数据文件恢复成原始的数据文件名字或者重新命名数据文件到一个新的位置/目录就可以解决问题了。

重新命名数据文件到一个新的位置/目录的方法：

A. 数据库是打开状态的
1）查看那个数据文件所在的表空间还包含有哪些数据文件，执行以下查询：

SELECT FILE_NAME, STATUS FROM DBA_DATA_FILES

WHERE TABLESPACE_NAME = ''；

2）确定所有数据文件的状态都是可用的。

3）把表空间变成只读表空间：

ALTER TABLESPACE READ ONLY；

4）确定在数据字典中表空间是显示为只读的：

SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES

WHERE TABLESPACE_NAME = ''；

TABLESPACE_NAME STATUS

------------------------------ ---------

READ ONLY

5）用操作系统命令拷贝数据文件到一个新的位置，拷贝完成后把整个表空间OFFLINE，这个时候用户是不能访问这个表空间的：

ALTER TABLESPACE OFFLINE；

6）重命名这个数据文件到一个新的位置了，这个操作会自动的更新控制文件中的内容：

ALTER DATABASE RENAME FILE

'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'

TO

'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'；

7）ONLINE这个表空间：

ALTER TABLESPACE YOUR_TABLESPACE_NAME ONLINE；

8）把这个表空间置成可读写的状态：

ALTER TABLESPACE YOUR_TABLESPACE_NAME READ WRITE；

9）在操作系统级上删除原来旧的数据文件。

B．数据库是关闭状态的

1） 先正常关闭数据库。

2） 用操作系统命令拷贝数据文件到一个新的位置。

3） MOUNT数据库，这样将读取控制文件，但是不会读取数据文件：

STARTUP MOUNT

4) 重命名这个数据文件到一个新的位置了，这个操作会自动的更新控制文件中的内容：

ALTER DATABASE RENAME FILE

'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'

TO

'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'；

5） 打开数据库：

ALTER DATABASE OPEN；

 

2． 数据文件不存在或者对于Oracle来说是不可用的

数据文件被物理的移走了或者损坏导致Oracle不能再认到了，例如数据文件被截断或者覆盖了，一般会出现ORA-27046、ORA-1157的错误提示：

ORA-27046: file size is not a multiple of logical block size

这种情况下可以有两种选择去解决问题：

A． 重建数据文件所属的那个表空间

这种方法比较适用于USERS、TEMP、INDEX表空间，如果数据库是正常关闭的，也就是说回滚段中没有激活的表空间事务,也推荐使用这种方法。如果是SYSTEM表空间，则要重建数据库了。

具体步骤如下：

1） MOUNT数据库：

STARTUP MOUNT PFILE=''；

2） OFFLINE DROP数据文件：

ALTER DATABASE DATAFILE '' OFFLINE DROP；

3） 打开数据库：

ALTER DATABASE OPEN；

4） 删除表空间：

DROP TABLESPACE INCLUDING CONTENTS；

5） 重建表空间：

CREATE TABLESPACE DATAFILE

' SIZE ；

6） 重建表空间中所有以前存在的对象:可以使用以前创建对象的脚本或者利用最近可用的EXPORT DUMP来重建以前存在的对象。

B．用正常的恢复过程去恢复数据文件

这种方法比较适用于只读表空间或者那种不能用重建表空间的方法的USERS和INDEX表空间。如果是回滚段表空间，那必须要求数据库是正常关闭的才能使用这个方法。如果是SYSTEM表空间，并且备份和所有的归档日志都全的情况下，强烈建议使用这种方法去恢复的，但是如果是非归档方式，则就只能利用当前所有的联机日志进行恢复了。

在很多的情况下，重建表空间是不可能的或者是非常费时费力的，因此，从备份和利用归档日志恢复数据文件是一种比较好的方法，尤其是对于只读表空间来说，因为没有数据的写入和更改，因此直接用备份来恢复是最快最省事的。

具体步骤如下：

1） 从备份中恢复丢失或者损坏的数据文件。

2） MOUNT数据库：

STARTUP MOUNT PFILE=''；

3） 执行以下的查询：

SELECT V1.GROUP#, MEMBER, SEQUENCE#,

FIRST_CHANGE#

FROM V$LOG V1, V$LOGFILE V2

WHERE V1.GROUP# = V2.GROUP#；

这个查询将列出所有联机重做日志以及它们所代表的SEQUENCE和FIRST CHANGE NUMBER.

4） 如果数据库是非归档状态下的，执行以下的查询：

SELECT FILE#, CHANGE# FROM V$RECOVER_FILE；

如果CHANGE#大于最小的联机重做日志文件的FIRST_CHANGE#，那么数据文件可以被恢复，记住恢复数据文件的时候要应用所有的联机重做日志文件，然后到第5步。

如果CHANGE#小于最小的联机重做日志文件的FIRST_CHANGE#，那么这个数据文件将不能被恢复了，那么只能从最近的数据库全备份恢复或者重建这个数据文件所属的表空间了。

5） 恢复数据文件：

RECOVER DATAFILE ''；

6） 确认所有的归档日志都被应用了直至出现"Media recovery complete"的提示信息，如果Oracle提示有一个不存在的归档日志文件，那么就可能要应用所有的联机重做日志文件来恢复直至出现"Media recovery complete"的提示信息。

7） 打开数据库：

ALTER DATABASE OPEN；

 

3． 数据库临时表空间的数据文件的丢失

当数据库的临时表空间的数据文件丢失也会引起ORA-01157的错误。因为数据库对临时表空间的数据文件不会发生检查点，所以这个时候数据库照样能够打开。这种情况下的解决方法是逻辑上删除临时表空间的数据文件，并且重新增加一个新的临时表空间的数据文件。

例如：

SELECT * FROM DBA_OBJECTS ORDER BY OBJECT_NAME；

select * from dba_objects order by object_name；

* ERROR at line 1:

ORA-01157: cannot identify/lock data file 5 - see DBWR trace file

ORA-01110: data file 5: '/Oracle/oradata/temp01.dbf'

ALTER DATABASE TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ DROP；

SELECT TABLESPACE_NAME,FILE_NAME FROM DBA_TEMP_FILES；

ALTER TABLESPACE TEMP ADD TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ SIZE 100M；

 

三．由于操作系统的问题或者第三方软件的问题导致ORA-01157错误

1． 当使用vxfddstat去访问快速I/O或者其它的应用，会获得"Cannot open file"的错误，而Oracle会返回如下的错误：

ORA-01157: cannot identify data file 1 - file not found

ORA-01110: data file 1: ''

这个时候用户应该去联系Veritas的技术支持，技术支持网站网址为http://support.veritas.com/。

2． 在HP-UNIX的机器上，如果系统核心参数nflock设置不是足够大的时候，这样可能会使Oracle不能锁定所需要的数据文件而导致错误：

ORA-27086: skgfglk: unable to lock file - already in use

或者错误：

ORA-01157: cannot identify/lock data file 4 - see DBWR trace file

ORA-0110: data file 4: '/Oracle/oradata/user01.dbf'