数据文件的恢复

ORA-01110: data file 103:'/XX/XX_48.DBF'

你想要open数据库，oracle会打开所有文件，并进行一致性处理，所以会报上述错误。所以oracle只进入mount状态，这时oracle打开控制文件，读取database的结构信息。

·情况之一：数据库没有归档和备份

如果redo.log记录了该表空间对象的所有操作，并且没有被其他内容循环使用，则下面的语句是可以恢复的，但是实际应用中这种理想状态基本不存在。

SQL>alter database datafile 8 offline drop;

Database altered.

SQL> alter database create datafile 8 as 'D:\TP_HOSPITAL.DBF';

Database altered.

SQL> recover datafile 8;

Media recovery complete.

SQL> alter database open;

Database altered.

实际情况，无法依赖redo.log进行恢复的，这种情况只能损失部分数据换取数据库的运行正常。

实际情况会遇到如下问题：

SQL> recover datafile 8;

ORA-00279: 更改 3270928 (在 12/02/2011 14:27:46 生成) 对于线程 1 是必需的

ORA-00289: 建议:E:\ORACLE\ARCHIVE\ARC00102_0756222529.001

ORA-00280: 更改 3270928 (用于线程 1) 在序列 #102 中

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00308: 无法打开归档日志'E:\ORACLE\ARCHIVE\ARC00102_0756222529.001'

ORA-27041: 无法打开文件

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。

ORA-00308: 无法打开归档日志'E:\ORACLE\ARCHIVE\ARC00102_0756222529.001'

ORA-27041: 无法打开文件

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。所以目前的方法是，将数据文件offline drop后，将数据库open，然后查出哪些表在该数据文件所在的表空间上，检查这些表是否正常，如果不正常的话，则导出这些表的数据，然后在数据库上删除表，然后将导出的数据再导入到oracle，这样该表就正常了。操作步骤，参考如下：

查找可能受影响的表：（spool x.txt spool off后可以查看命令结果）

SELECT T.SEGMENT_NAME, T.OWNER, T.PARTITION_NAME
FROM DBA_SEGMENTS T
WHERE TABLESPACE_NAME = 'TP_HOSPITAL'
   AND T.OWNER = 'HOSPITAL'
   AND SEGMENT_TYPE LIKE '%TABLE%';

导出该表的数据：

exp XXX/XXX@XXX file=/XXX/20091217_XXX.dmp log=/XXX/XXX.logtables=(XXX);

删除该表：

drop table XXX;

导入该表数据：

imp XXX/XXX@XXX file=/XXX/20091217_XXX.dmp tables=(XXX);

这样处理一定会损失部分数据的。导入完毕以后，查看该表是否正常，如有特殊需要则特殊处理。

注：如果涉及到的表太多，不想一个一个表导出的话，那么就将这个库exp出来，然后drop掉该模式(并drop掉该模式下所有的对象)，然后重建该模式以及给出大小适当的表空间，然后将导出的模式导入回去。

非归档模式下恢复利用offline drop命令误删除的数据文件

2010-02-23 16:46:33

标签：Oracle

众所周知，非归档模式下，联机日志并不归档。可能大多数的网友一直以来都会有这样的模糊认识。数据库作recover时，只能利用归档日志和current redo log联机日志。实际上所有的联机日志都是可以用的。此文介绍在非档模式下,恢复利用offline drop命令误删除的数据文件。offline drop命令相当于把一个数据文件至于离线状态，并且需要恢复或再也不使用此数据文件了。所在，在OS级别并不是删除数据文件的意思。但是要在非档模式下恢复此数据文件的前提是，联机日志中自数据文件创建以来的所有联机日志都没有被覆盖。下面是整个实验过程,并且注意，在整个恢复的过程中注意从视图中获得的数据文件状态的变化:

SQL> archive log list;
Database logmode             No Archive Mode
Automaticarchival            Disabled
Archivedestination           c:\arc
Oldest online log sequence     7
Current logsequence           9

SQL> set linesize 200
SQL> select * from v$log;

    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARCSTATUS          FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ----------------------------- ----------
        1         1          8  52428800          1 YESINACTIVE               730667 2008:01:15 08:57:55
        2         1          9  52428800          1 NO  CURRENT                755863 2008:01:15 11:49:53
        3         1          7  52428800          1 YESINACTIVE               696036 2008:01:14 12:30:46

SQL>
SQL> alter tablespace users add datafile 'C:\ORADATA\TEST\TEST\users03.dbf'size 5M;

Tablespace altered.

SQL> alter system switch logfile;

System altered.

SQL> select * from v$log;

    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARCSTATUS          FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ----------------------------- ----------
        1         1          8  52428800          1 YES INACTIVE               730667 2008:01:15 08:57:55
        2         1          9  52428800          1 NO  ACTIVE                 755863 2008:01:15 11:49:53
        3         1         10  52428800          1 NO CURRENT                768362 2008:01:18 15:19:46 

在操作系统层删除6号数据文件后，对6号数据文件作offlinedrop操作 

SQL> alter database datafile 'C:\ORADATA\TEST\TEST\users03.dbf' offlinedrop;

Database altered.

SQL>

查看数据文件状态,当对数据文件执行offline drop 命令后，数据文件状态变为recover

SQL> select file#,status,name from v$datafile order by 3;

     FILE# STATUS  NAME
---------- -------------------------------------------------------------------------------
         3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF
         1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF
         5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF
         4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF
         2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF
         6 RECOVERC:\ORADATA\TEST\TEST\USERS03.DBF
SQL>

根据控制文件中的信息，重新创建6号数据文件
SQL> alter database create datafile 6;

Database altered.

在执行完创建命令后，数据文件状态仍然为recover,此时数据文件中只有非常简单的信息

SQL> select file#,status,name from v$datafile order by 3;

     FILE# STATUS  NAME
---------- -------------------------------------------------------------------------------
         3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF
         1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF
         5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF
         4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF
         2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF
         6 RECOVER C:\ORADATA\TEST\TEST\USERS03.DBF

因为联机日志还未被覆盖，尽管处于非归档模式，仍然可以对6号数据文件作恢复

SQL> recover datafile 6;
Media recovery complete.
SQL>

数据文件状态变为offline
SQL> select file#,status,name from v$datafile order by 3;

     FILE# STATUS  NAME
---------- ------- -------------------------------------------------------
         3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF
         1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF
         5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF
         4 ONLINE C:\ORADATA\TEST\TEST\USERS01.DBF
         2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF
         6 OFFLINEC:\ORADATA\TEST\TEST\USERS03.DBF

在对数据文件作online操作后，数据文件恢复正常
SQL> alter database datafile 6 online;

Database altered.

SQL> select file#,status,name from v$datafile order by 3;

     FILE# STATUS  NAME
---------- ------- ----------------------------------------------
         3 ONLINE C:\ORADATA\TEST\TEST\SYSAUX01.DBF
         1 SYSTEM C:\ORADATA\TEST\TEST\SYSTEM01.DBF
         5 ONLINE C:\ORADATA\TEST\TEST\TBS_UNDO_01.DBF
         4 ONLINE  C:\ORADATA\TEST\TEST\USERS01.DBF
         2 ONLINE C:\ORADATA\TEST\TEST\USERS02.DBF
         6 ONLINE C:\ORADATA\TEST\TEST\USERS03.DBF

  从上面恢复的整个过程可以看出，尽管数据库处于非归档模式，只要数据文件创建以来的联机日志还没有被覆盖，数据文件就可以恢复出来

 

�增加：emctl start dbconsole和isqlplusctl start。