53. Oracle单个数据文件损坏该怎么办？

机器异常断电，导致表空间损坏，无法读取

SQL> select * from zmc.ATTR_GROUP ;
select * from zmc.ATTR_GROUP
                  *
ERROR at line 1:
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '/u01/app/oracle/oradata/XE/ZMC_001'

1.查看表空间以及表空间状态(发现表空间是正常)和查看数据文件的状态(发现有的数据文件是recover状态)

SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces ;
 
TABLESPACE_NAME      STATUS
-------------------- ---------
SYSTEM               ONLINE
SYSAUX               ONLINE
UNDOTBS1             ONLINE
TEMP                 ONLINE
USERS                ONLINE
TAB_ZMC              ONLINE
 
6 rows selected.
SQL> select file_id,online_status from dba_data_files order by 1;
 
FILE_ID ONLINE_
------- -------
      1 SYSTEM
      2 ONLINE
      3 ONLINE
      4 ONLINE
      5 RECOVER

分析：发现这是由于断电的时候，数据还在写入，但是没有写完，所以scn没有写到最新状态，导致需要恢复

由于牵涉恢复，那就要考虑很有可能需要用到归档文件，本能的去看下有没有开归档。

SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     282
Current log sequence           283

发现没归档，那么这个数据文件很有可能恢复不了。下面我们来验证一下：

如果想要恢复，那么只能当前数据文件需要恢复的数据都还在redolog里面，我们现在就来确认这部分数据是否还在redolog里面。

先看这个数据文件上面打的scn号：

SQL> select file#, status, fuzzy, checkpoint_time, checkpoint_change#,
  2  resetlogs_change#, resetlogs_time from v$datafile_header where file#=5;
 
     FILE# STATUS  FUZ CHECKPOIN CHECKPOINT_CHANGE# RESETLOGS_CHANGE# RESETLOGS
---------- ------- --- --------- ------------------ ----------------- ---------
         5 OFFLINE NO  24-AUG-17             398119            353178 23-AUG-17

看看其它数据文件的scn：

 
SQL> select file#, status, fuzzy, checkpoint_time, checkpoint_change#,resetlogs_change#, resetlogs_time from v$datafile_header;
 
     FILE# STATUS  FUZ CHECKPOIN CHECKPOINT_CHANGE# RESETLOGS_CHANGE# RESETLOGS
---------- ------- --- --------- ------------------ ----------------- ---------
         1 ONLINE  YES 09-SEP-18           13564013            353178 23-AUG-17
         2 ONLINE  YES 09-SEP-18           13564013            353178 23-AUG-17
         3 ONLINE  YES 09-SEP-18           13564013            353178 23-AUG-17
         4 ONLINE  YES 09-SEP-18           13564013            353178 23-AUG-17
         5 OFFLINE NO  24-AUG-17             398119            353178 23-AUG-17

也即是我们的scn至少需要恢复到13564013该数据文件才可以正常online

那么我们确认归档信息

SQL> Select sequence#,name,first_change#,next_change# from v$archived_log;
 
no rows selected

归档未开，所以没有数据。只能寄希望于redolog了

SQL>  select SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# from v$log;
 
 SEQUENCE# FIRST_CHANGE#        NEXT_CHANGE#
---------- ------------- -------------------
       283      13564013     281474976710655
       282      13535783            13564013
 
SQL> 

发现redolog里面最小的scn是13535783

而我们恢复的数据在scn为398119到13564013，很明显，这里面有398119到13535783这部分scn对应的数据缺失了。

因此无法恢复

下面讲如果可以恢复对应的操作：

直接恢复对应的数据文件：

alter database recover datafile 5;

恢复万后直接online该数据文件：

alter database  datafile  5 online;

 

案例2：

　　如果数据库在归档模式下，误删除了一个数据文件(.dbf)，一般可以按照如下方法进行恢复

　　1. 关闭数据库(shutdown immediate/abort)

　　2.将数据库启动到mount状态   startup mount

　　3.将删掉的数据文件进行下线  alter database datafile  文件号 offline;

　　4.再将数据库给open起来，alter database open

　　5.再创建误删除的数据文件.dbf   alter database create datafile 文件号;

　　6.然后再recover数据文件: recover datafile 文件号;

　　7.最后再online数据文件： alter database datafile 文件号 online；　　

 转载于：https://blog.csdn.net/kadwf123/article/details/82589163