新建的表空间(或数据文件)丢失以及控制文件丢失，有新建表空间(或数据文件)前的控制文...-CSDN博客

事情源于
http://www.itpub.net/showthread.php?s=&threadid=594452&perpage=10&pagenumber=1
同时结合很早的一个问题：
http://www.itpub.net/showthread.php?s=&threadid=326938&perpage=10&pagenumber=1

自己总结了一下。试验过程如下：
1、首先备份控制文件。
2、创建一个新的表空间。
3、在该表空间上创建一个表，并插入测试数据。
4、关闭数据库。这一步是关键。分为两种情况：正常关闭、非正常关闭。
5、OS上删除控制文件、新加入的数据文件。
6、启动以后，不完全恢复到表空间创建的时间。这个时间可以在alert.log里找到。试验证明，第四步，如果正常关闭则不能成功，如果非正常关闭，可以成功。

介绍一下不完全恢复的背景。不完全恢复能够成功的前提是所有的数据文件头部的SCN都保持一致才能算是成功。只要有一个数据文件头的SCN与其他数据文件头的SCN不一致，就不能打开数据库。不完全恢复包括until time、until cancel、until scn。

这三种方式的本质都是向前应用一大堆redo entry，直到达到某一确定SCN时为止，不再应用该SCN以后的所有redo entry。这三种方法无非提供了三种方式，让你能够找到该确定的SCN而已。
对于until time来说，就是你指定的时间点以前的最大的SCN。
对于until cancel来说，就是你指定cancel的时候，已经应用了的日志所含有的最大的SCN。
对于until scn来说，就是你指定的SCN。

ok，来做测试。
1、
SQL> alter database backup controlfile to 'C:oracleoradatacontrol01.ctl';

数据库已更改。

2、
SQL> create tablespace test datafile 'C:oracleoradataora10test.dbf' size 2M extent management local;

表空间已创建。

3、
SQL> create table test(n number) tablespace test;

表已创建。

SQL> insert into test values(1);

已创建 1 行。

SQL> commit;

提交完成。

4、非正常关闭数据库，注意这一步非常重要。
SQL> shutdown abort;
ORACLE 例程已经关闭。

5、删除控制文件、test数据文件。然后将第一步备份的控制文件恢复上去。

6、
SQL> connect / as sysdba
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。

Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项

SQL> set linesize 500
SQL> select name,creation_change#,checkpoint_change#,last_change#,online_change# from v$datafile;

NAME CREATION_CHANGE# CHECKPOINT_CHANGE# LAST_CHANGE# ONLINE_CHANGE#
---------------------------------------- ---------------- ------------------ ------------ --------------
C:ORACLEORADATAORA10SYSTEM01.DBF 6 230918 230744
C:ORACLEORADATAORA10DRSYS01.DBF 5688 230918 230744
C:ORACLEORADATAORA10EXAMPLE01.DBF 5705 230918 230744
C:ORACLEORADATAORA10INDX01.DBF 5723 230918 230744
C:ORACLEORADATAORA10TOOLS01.DBF 5741 230918 230744
C:ORACLEORADATAORA10USERS01.DBF 5761 230918 230744
C:ORACLEORADATAORA10XDB01.DBF 5779 230918 230744
C:ORACLEORADATAORA10UNDONEW01.DBF 230433 230918 230744

已选择8行。

SQL> recover database using backup controlfile until time '2006-07-21 13:31:11';
ORA-00279: 更改 230918 (在 07/21/2006 13:29:50 生成) 对于线程 1 是必需的
ORA-00289: 建议: C:ORACLEORADATAORA10ARCHIVEARC00001.001
ORA-00280: 更改 230918 对于线程 1 是按序列 # 1 进行的

指定日志: {=suggested | filename | AUTO | CANCEL}
C:oracleoradataora10redo01.log
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'C:ORACLEORADATAORA10REDO01.LOG'

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件1需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'C:ORACLEORADATAORA10SYSTEM01.DBF'

指定日志: {=suggested | filename | AUTO | CANCEL}
C:oracleoradataora10redo02.log
ORA-00283: 恢复会话因错误而取消
ORA-01244: 未命名的数据文件由介质恢复添加至控制文件
ORA-01110: 数据文件 2: 'C:ORACLEORADATAORA10TEST.DBF'

ORA-01112: 未启动介质恢复

ok，从这里可以看到，原来备份的控制文件里是没有记录有关test.dbf数据文件记录的。因为该文件是在备份控制文件以后创建的。然后，通过应用日志redo02.log，里面记录了创建test.dbf的命令。但是因为控制文件不知道现在该文件叫什么名字了，所以将其命名为一个很怪的名字：UNNAMED00002。注意，这个时候，数据文件并没有实际恢复回来。因为控制文件里没有记录test.dbf这个数据文件，所以也就没有执行创建表空间和数据文件的redo entry，而是直接弹出错误。

SQL> select name,creation_change#,checkpoint_change#,last_change#,online_change# from v$datafile;

NAME CREATION_CHANGE# CHECKPOINT_CHANGE# LAST_CHANGE# ONLINE_CHANGE#
---------------------------------------- ---------------- ------------------ ------------ --------------
C:ORACLEORADATAORA10SYSTEM01.DBF 6 231078 230744
C:ORACLEORA92DATABASEUNNAMED00002 231076 231076 0
C:ORACLEORADATAORA10DRSYS01.DBF 5688 231078 230744
C:ORACLEORADATAORA10EXAMPLE01.DBF 5705 231078 230744
C:ORACLEORADATAORA10INDX01.DBF 5723 231078 230744
C:ORACLEORADATAORA10TOOLS01.DBF 5741 231078 230744
C:ORACLEORADATAORA10USERS01.DBF 5761 231078 230744
C:ORACLEORADATAORA10XDB01.DBF 5779 231078 230744
C:ORACLEORADATAORA10UNDONEW01.DBF 230433 231078 230744

已选择9行。

没问题，可以通过命令把这个名字改回来，并同时创建该数据文件。
SQL> alter database create datafile 'C:ORACLEORA92DATABASEUNNAMED00002' as 'C:ORACLEORADATAORA10test.dbf';

数据库已更改。

SQL> select name,creation_change#,checkpoint_change#,last_change#,online_change# from v$datafile;

NAME CREATION_CHANGE# CHECKPOINT_CHANGE# LAST_CHANGE# ONLINE_CHANGE#
---------------------------------------- ---------------- ------------------ ------------ --------------
C:ORACLEORADATAORA10SYSTEM01.DBF 6 231078 230744
C:ORACLEORA92DATABASETEST.DBF 231076 231076 0
C:ORACLEORADATAORA10DRSYS01.DBF 5688 231078 230744
C:ORACLEORADATAORA10EXAMPLE01.DBF 5705 231078 230744
C:ORACLEORADATAORA10INDX01.DBF 5723 231078 230744
C:ORACLEORADATAORA10TOOLS01.DBF 5741 231078 230744
C:ORACLEORADATAORA10USERS01.DBF 5761 231078 230744
C:ORACLEORADATAORA10XDB01.DBF 5779 231078 230744
C:ORACLEORADATAORA10UNDONEW01.DBF 230433 231078 230744

已选择9行。

再次应用日志，将test表恢复回来。
SQL> recover database using backup controlfile until time '2006-07-21 13:31:11';
ORA-00279: 更改 231076 (在 07/21/2006 13:30:33 生成) 对于线程 1 是必需的
ORA-00289: 建议: C:ORACLEORADATAORA10ARCHIVEARC00001.001
ORA-00280: 更改 231076 对于线程 1 是按序列 # 1 进行的

指定日志: {=suggested | filename | AUTO | CANCEL}
C:oracleoradataora10redo02.log
已应用的日志。
完成介质恢复。

SQL> alter database open resetlogs;

数据库已更改。

SQL> select * from test;

N
----------
1

SQL>

如果在第四步正常关闭数据库的话，则由于正常关闭数据库将提高数据文件头的SCN，这样导致在恢复到指定的时间点时，只有被恢复的test.dbf的文件头SCN增加上去了，而其他数据文件由于没有应用到redo entry，导致比test.dbf的scn要低，所以这时是不能打开数据库的。必须把这个时间点推迟到正常关闭数据库的那个时间点才能够应用足够的redo entry。
这也就解释了以前的一个问题：
http://www.itpub.net/showthread.php?s=&threadid=326938&perpage=10&pagenumber=11

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9842/viewspace-156320/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9842/viewspace-156320/