对Oracle DBA而言，生产运维环境和数据的安全都是安身立命的根本。很多时候，行事谨慎、凡是先思后行往往比技术水平能力更重要。所有的Oracle使用者，在进行数据库操作，特别是关键操作的时候，一定要三思而后行。
1、问题故障
临下班之前，一个朋友电话咨询数据文件误删除的处理操作。问题的起因是运维DBA在创建表空间和数据文件的时候，阴差阳错的操作系统层面直接就将新创建出的数据文件删除掉。现在文件日志中不断报错说文件不存在。具体关键信息如下：
ü 测试环境，处在搭建过程中。数据没有备份；
ü 误删除的表空间中没有数据，经询问也不需要将OS误删除的数据找回来。可以删掉表空间之后重新创建数据；
ü 误删除之后，由于笔者朋友的介入，就没有贸然关闭服务器重启；
ü 误删除表空间为普通的数据表空间，非系统System/Sysaux、Temp和Undo；
ü 误删除表空间中包括多个数据文件，只有一部分文件被删除；
ü 操作系统OS是Linux环境，具体Oracle版本为10.2.0.5；
从上面的信息来看，这个案例不难处理。虽然没有备份，但是毕竟这是测试环境，而且没有任何业务数据在其中。所以，笔者是赞同将原有表空间进行丢弃处理。而且，数据表空间没有什么系统运行依赖，也就是即使目前损坏，也没有对数据库本身致命的影响。
由于各种原因，笔者在获得故障alert_log之后，在自己的实验环境中进行了相应的故障模拟。
2、实验环境准备
这个案例中，数据库Oracle版本不是关键问题。所以，笔者选择了手头方便的11g进行实验。
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
创建实验表空间，由多个文件共同组成。
SQL> create tablespace mytest datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl01.dbf' size 10m autoextend off
2 extent management local uniform. size 1m
3 segment space management auto;
Tablespace created
SQL> alter tablespace mytest add datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl02.dbf' size 10m autoextend off;
Tablespace altered
SQL> alter tablespace mytest add datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf' size 10m autoextend off;
Tablespace altered
SQL> alter tablespace mytest add datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl04.dbf' size 10m autoextend off;
Tablespace altered
创建完的数据表空间和文件结构如下：
SQL> select file_Name, bytes,tablespace_name from dba_data_files;
FILE_NAME BYTES TABLESPACE_NAME
-------------------------------------------------------------------------------- ---------- ------------------------------
/u01/app/oradata/ORA11G/datafile/o1_mf_users_7vpyc2xd_.dbf 5242880 USERS
/u01/app/oradata/ORA11G/datafile/o1_mf_undotbs1_7vpyc2py_.dbf 267386880 UNDOTBS1
/u01/app/oradata/ORA11G/datafile/o1_mf_sysaux_7vpyc2hb_.dbf 754974720 SYSAUX
/u01/app/oradata/ORA11G/datafile/o1_mf_system_7vpyc1x7_.dbf 754974720 SYSTEM
/u01/app/oradata/ORA11G/datafile/mytesttbl01.dbf 10485760 MYTEST
/u01/app/oradata/ORA11G/datafile/mytesttbl02.dbf 10485760 MYTEST
/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf 10485760 MYTEST
/u01/app/oradata/ORA11G/datafile/mytesttbl04.dbf 10485760 MYTEST
8 rows selected
在OS层面将一部分的数据文件强制删除。
[oracle@bsplinux datafile]$ ls -l
total 1836932
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:22 mytesttbl01.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:23 mytesttbl02.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:23 mytesttbl03.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:24 mytesttbl04.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:25 o1_mf_sysaux_7vpyc2hb_.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:23 o1_mf_system_7vpyc1x7_.dbf
-rw-r----- 1 oracle oinstall 54534144 Jul 2 22:26 o1_mf_temp_7vpz05do_.tmp
-rw-r----- 1 oracle oinstall 267395072 Jul 3 03:25 o1_mf_undotbs1_7vpyc2py_.dbf
-rw-r----- 1 oracle oinstall 5251072 Jul 3 03:14 o1_mf_users_7vpyc2xd_.dbf
[oracle@bsplinux datafile]$ rm -f mytesttbl03.dbf
[oracle@bsplinux datafile]$ rm -f mytesttbl04.dbf
[oracle@bsplinux datafile]$ ls -l
total 1816404
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:22 mytesttbl01.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:23 mytesttbl02.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:26 o1_mf_sysaux_7vpyc2hb_.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:26 o1_mf_system_7vpyc1x7_.dbf
-rw-r----- 1 oracle oinstall 54534144 Jul 2 22:26 o1_mf_temp_7vpz05do_.tmp
-rw-r----- 1 oracle oinstall 267395072 Jul 3 03:26 o1_mf_undotbs1_7vpyc2py_.dbf
-rw-r----- 1 oracle oinstall 5251072 Jul 3 03:14 o1_mf_users_7vpyc2xd_.dbf
此时，在alert_log中，虽然没有明确的信息，但是只要涉及到相关的文件操作，都会报错。
SQL> create table t tablespace mytest as select * from dba_objects ;
create table t tablespace mytest as select * from dba_objects
ORA-01116: 打开数据库文件 7 时出错
ORA-01110: 数据文件 7: '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf'
ORA-27041: 无法打开文件
Linux Error: 2: No such file or directory
Additional information: 3
3、未关闭服务器情况下的处理过程
处理文件误删除，要区分是否关闭服务器。在这个处理案例中，如果没有关闭服务器，处理的难度比较小。
处理的方法是直接强制的删除表空间，连带删除文件和相应内容。命令为：drop tablespace mytest including contents and datafiles。在日志中，我们看到相关的报错信息。但是，还是可以成功的将表空间删除。
Tue Jul 03 03:30:20 2012
drop tablespace mytest including contents and datafiles
Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_4232.trc:
(乱码)
Linux Error: 2: No such file or directory
Additional information: 3
(乱码)
Linux Error: 2: No such file or directory
Additional information: 3
(乱码)
Deleted file /u01/app/oradata/ORA11G/datafile/mytesttbl01.dbf
Deleted file /u01/app/oradata/ORA11G/datafile/mytesttbl02.dbf
Completed: drop tablespace mytest including contents and datafiles
对应的文件信息，的确也表示已经删除。
[oracle@bsplinux datafile]$ ls -l
total 1795876
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:30 o1_mf_sysaux_7vpyc2hb_.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:30 o1_mf_system_7vpyc1x7_.dbf
-rw-r----- 1 oracle oinstall 54534144 Jul 2 22:26 o1_mf_temp_7vpz05do_.tmp
-rw-r----- 1 oracle oinstall 267395072 Jul 3 03:30 o1_mf_undotbs1_7vpyc2py_.dbf
-rw-r----- 1 oracle oinstall 5251072 Jul 3 03:14 o1_mf_users_7vpyc2xd_.dbf
4、关闭服务器情况下的处理
如果因为各种原因，已经关闭了服务器。怎么处理呢？首先，让我们恢复环境。
SQL> create tablespace mytest datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl01.dbf' size 10m autoextend off
2 extent management local uniform. size 1m
3 segment space management auto;
Tablespace created
SQL> alter tablespace mytest add datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl02.dbf' size 10m autoextend off;
Tablespace altered
SQL> alter tablespace mytest add datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf' size 10m autoextend off;
Tablespace altered
（OS 层面的Ls –l结果）
total 1826668
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:33 mytesttbl01.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:33 mytesttbl02.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:34 mytesttbl03.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:33 o1_mf_sysaux_7vpyc2hb_.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:34 o1_mf_system_7vpyc1x7_.dbf
-rw-r----- 1 oracle oinstall 54534144 Jul 2 22:26 o1_mf_temp_7vpz05do_.tmp
-rw-r----- 1 oracle oinstall 267395072 Jul 3 03:34 o1_mf_undotbs1_7vpyc2py_.dbf
-rw-r----- 1 oracle oinstall 5251072 Jul 3 03:14 o1_mf_users_7vpyc2xd_.dbf
误删除表空间一个文件。
[oracle@bsplinux datafile]$ rm mytesttbl03.dbf
[oracle@bsplinux datafile]$ ls -l
total 1816404
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:33 mytesttbl01.dbf
-rw-r----- 1 oracle oinstall 10493952 Jul 3 03:33 mytesttbl02.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:33 o1_mf_sysaux_7vpyc2hb_.dbf
-rw-r----- 1 oracle oinstall 754982912 Jul 3 03:34 o1_mf_system_7vpyc1x7_.dbf
-rw-r----- 1 oracle oinstall 54534144 Jul 2 22:26 o1_mf_temp_7vpz05do_.tmp
-rw-r----- 1 oracle oinstall 267395072 Jul 3 03:34 o1_mf_undotbs1_7vpyc2py_.dbf
-rw-r----- 1 oracle oinstall 5251072 Jul 3 03:14 o1_mf_users_7vpyc2xd_.dbf
注意，在这个时候，只有使用突然断电和shutdown –abort方法才可能停机。因为其他几种关机方式都会伴随文件检查过程（如Checkpoint）。
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate;
ORA-01116: error in opening database file 7
ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
SQL> shutdown normal;
ORA-01116: error in opening database file 7
ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
SQL> shutdown abort
ORACLE instance shut down.
SQL>
在重新启动的时候，从mount到open过程中，是会报错。
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 422670336 bytes
Fixed Size 1336960 bytes
Variable Size 318769536 bytes
Database Buffers 96468992 bytes
Redo Buffers 6094848 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 7 - see DBWR trace file
ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf'
此时，alert_log中的信息为。
Completed: ALTER DATABASE MOUNT
Tue Jul 03 03:41:50 2012
ALTER DATABASE OPEN
Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_dbw0_4641.trc:
ORA-01157: cannot identify/lock data file 7 - see DBWR trace file
ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_4684.trc:
ORA-01157: cannot identify/lock data file 7 - see DBWR trace file
ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf'
ORA-1157 signalled during: ALTER DATABASE OPEN...
分析可以知道，在open阶段，要去定位各个数据文件，依据的内容是controlfile中的数据文件信息。故在open阶段会报错。
处理的方法是启动到mount，之后通过命令将数据文件向Oracle“隐藏”掉。具体处理如下：
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 422670336 bytes
Fixed Size 1336960 bytes
Variable Size 318769536 bytes
Database Buffers 96468992 bytes
Redo Buffers 6094848 bytes
Database mounted.
在mount阶段将数据文件隐藏掉，在open阶段将tablespace删除掉。
SQL> alter database datafile '/u01/app/oradata/ORA11G/datafile/mytesttbl03.dbf' offline drop;
Database altered.
--mount阶段不能处理tablespace删除
SQL> drop tablespace mytest;
drop tablespace mytest
*
ERROR at line 1:
ORA-01109: database not open
SQL> alter database open;
Database altered.
SQL> drop tablespace mytest;
Tablespace dropped.
Alert log上也显示可以正常的启动。
Recovery of Online Redo Log: Thread 1 Group 2 Seq 104 Reading mem 0
Mem# 0: /u01/app/oradata/ORA11G/onlinelog/o1_mf_2_7vpyx20p_.log
Mem# 1: /u01/app/flash_recovery_area/ORA11G/onlinelog/o1_mf_2_7vpyxdyv_.log
Completed redo application of 0.00MB
Completed crash recovery at
Thread 1: logseq 104, block 5650, scn 2592058
11 data blocks read, 11 data blocks written, 3 redo k-bytes read
Tue Jul 03 03:47:00 2012
Thread 1 advanced to log sequence 105 (thread open)
Thread 1 opened at log sequence 105
Current log# 3 seq# 105 mem# 0: /u01/app/oradata/ORA11G/onlinelog/o1_mf_3_7vpyxw4h_.log
Current log# 3 seq# 105 mem# 1: /u01/app/flash_recovery_area/ORA11G/onlinelog/o1_mf_3_7vpyy4ls_.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
Tue Jul 03 03:47:01 2012
SMON: enabling cache recovery
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Completed: alter database open
5、结论
在处理表空间、文件和操作系统的时候，作为DBA一定要小心小心再小心。如果是在生产环境和没有备份的情况下，问题处理就比较复杂了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/148459/viewspace-1062194/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- oracle获取数据字典定义详细总结
- undo表空间损坏的处理过程
- Oracle 巡检手册
- 修改Oracle数据文件名及数据文件存放路径
- 【手工建库】确保数据库处于自动 UNDO管理模式
- 【SQL*Plus】11g中使用SQL*Plus的-S选项依然可以看到“Enter password:”问题
- 【FGA】扩展Oracle细粒度审计功能——调用定制的存储过程
- 【PASSWORD】Linux环境下使用密码验证方式重置SYS用户密码
- 【CONNECT】ORA-00020错误模拟及处理方法
- 【DIRECTORY】确保DIRECTORY对应路径书写正确以避免遭遇ORA-29913和ORA-29400错误
