【恢复】非归档模式下因误删除数据文件导致数据库无法OPEN的故障处理
模拟一下这个数据库故障，同时给出一个“简单”的恢复处理过程。1.查询获得TBS_SEC_D表空间对应的数据文件信息
sys@ora10g> col FILE_NAME for a40
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
/oracle/oradata/ora10g/hou.dbf 13 AVAILABLE
2.非归档模式下模拟误删除数据文件
1）确认数据库的归档模式
sys@ora10g> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /oracle/arch/ora10g
Oldest online log sequence 1541
Current log sequence 1543
2）模拟误删除hou.dbf数据文件
sys@ora10g> !rm -f /oracle/oradata/ora10g/hou.dbf
3）此时的数据库状态没有异样
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
/oracle/oradata/ora10g/hou.dbf 13 AVAILABLE
3.重启数据库观察一系列的报错信息
1）关闭数据库过程中的报错信息
sys@ora10g> shutdown immediate;
ORA-03113: end-of-file on communication channel
2）启动数据过程中的报错信息
NotConnected@> startup;
ORACLE instance started.
Total System Global Area209715200 bytes
Fixed>
Variable> Database Buffers 75497472 bytes
Redo Buffers 6316032 bytes
Database mounted.
ORA-01157: cannot>data file 13 - see DBWR trace file
ORA-01110: data file 13: '/oracle/oradata/ora10g/hou.dbf'
这里提示无法定位13号数据文件。
此时数据库仅处于mount状态。
NotConnected@> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
4.恢复方法
既然数据文件被误删除了，而且我们又没有有效的备份可用，同时数据库又处于非归档的状态（“杯具”到了极致），那我们只能容忍数据的丢失（如果13号数据文件存有数据的情况下）。
1）在mount状态下使用offline drop命令将数据文件与表空间之间的关系隔断。
NotConnected@> col name for a50
NotConnected@> select FILE#,STATUS,ENABLED,NAME from v$datafile where name like '%hou%';
FILE# STATUSENABLED NAME
---------- ------- ---------- ---------------------------------------
13 ONLINEREAD WRITE /oracle/oradata/ora10g/hou.dbf
NotConnected@>>
Database> NotConnected@> select FILE#,STATUS,ENABLED,NAME from v$datafile where name like '%hou%';
FILE# STATUSENABLED NAME
---------- ------- ---------- ----------------------------------------
13 RECOVER READ WRITE /oracle/oradata/ora10g/hou.dbf
2）此时我们便可以顺利的OPEN数据库
NotConnected@>>
Database> 5.收尾工作
即便按照上述的方法简单处理了这个故障，但是在数据库中还是遗留了一下“垃圾”信息。
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
/oracle/oradata/ora10g/hou.dbf 13 AVAILABLE
此时表明物理上已经不存在的“/oracle/oradata/ora10g/hou.dbf”文件还是归属于表空间TBS_SEC_D。如何彻底的断绝这样的无意义的关系？
这里给出“简单粗暴”的重建表空间方法。
大体步骤如下：
1）想办法逻辑备份表空间中包含的数据
2）删除表空间
sys@ora10g> drop tablespace TBS_SEC_D including contents and datafiles;
Tablespace dropped.
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
no rows selected
3）重建表空间
sys@ora10g> create tablespace TBS_SEC_D datafile '/oracle/oradata/ora10g/tbs_sec_d_01.dbf'> Tablespace created.
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
4）使用逻辑备份恢复表空间的内容
6.小结
又一次实践证明，【无备份、非归档】是DBA界最可怕的场景。
假设这个故障发生之前存在有效的备份，恢复的过程将会非常的简便，也不会冒着丢失数据的风险。
珍爱DBA生命，请及时完善备份策略并定期安排备份介质有效性验证等常规“枯燥”任务，只有“她们”才是最美丽的！
Good luck.
页:
[1]