所有控制文件损坏，掉电(shutdown abort)，无归档，无备份的成功恢复

biti_rainy

最初由 coolyl 发布
[B]这种情况只有redo还没有被覆盖才能完全恢复，否则的话就只能不完全恢复了 [/B]

如果被覆盖的日志中数据已经  写入了数据文件，就不会有问题的了

而被覆盖的日志文件中数据可能没有被写入数据文件么？不可能！
如果检查点还没有完成，数据库会挂起： checkpoint  not  complete !

如果存在你说的这种情况，oracle根本就不保险，它自己的 instance  recovery 都没有办法恢复了，还用我们来折腾？这样是整个数据库的设计的失败

你说呢  ？

除非你使用的是原来备份的旧的数据文件来恢复，才存在你说的问题

jzld0627

我想这是非归档模式下，只能是不完全恢复，而且控制文件没了要重建，也只能resetlogs。不过 玉面飞龙说的这种情况，应该不会吧？

eygle

在内存中，未提交的数据肯定是损失了

但是只要是commit过的数据，redo未损坏，数据是不会丢失的

coolyl

biti，我说的意思可能有点偏差，我是说redo如果有损坏的情况或者通过备份恢复的时候
重建控制文件当然不会写redo，那时候redo还没有打开啊，想写也没地方啊

coolyl

最初由 jzld0627 发布
[B]我想这是非归档模式下，只能是不完全恢复，而且控制文件没了要重建，也只能resetlogs。不过 玉面飞龙说的这种情况，应该不会吧？ [/B]

也可能啊，就是在buffer中，而此时断电就出现玉面飞龙说的这种情况了。
biti举这个例子的意思是说怎么去重建控制文件，举的例子是比较理想化的。我们都不应该在备份恢复上做文章了，这样违背了biti的本意了啊。

biti_rainy

针对 控制文件损坏无备份的还是很有用处的

如果有备份，有一个好的备份策略
用不着这样了

当然有备份，但是非 current 的 log  损坏，这样也许能够完全恢复数据的呀  

但是使用备份却可能不能恢复完全数据了
所以根据具体情况选择合理的恢复方法呀

如果仅仅是 online log 有损坏,或者控制文件也损坏，但损坏log 还没有来得及归档，current未损坏
这样可以完全恢复，如果采用备份来恢复，反而丢失数据了

小段探花

去年，我们的数据库（noarchivelog)就出现了这样的问题：
A 表空间的一个数据文件损坏，数据库shutdown后不能启动，俺当时不知如何处理，把A表空间OFFLINE，数据库启动了。
后来由于忙别的事情，找资料晚了，后来再recovery就怎么都没有办法完成了。现在呢，领导找别人给弄了，也不知道是怎么弄的，就好了，A空间的数据也恢复了。
我想是否是这样的：
1、因为是noarchivelog模式，且redo log不知已经提交多少次了，损坏的数据文件，应该不等恢复了，就resize。
2、再把A空间online,(不知是否可以？）
3、alter database open resetlog.

大虾，看是否可以？

lunar2000

biti ，恐怕你的做法是有问题的！
在817和9i中都是仅仅丢失全部的控制文件，重建控制文件应该没有问题，不管是归档还是非归档，道理很简单，你仅仅丢失了控制文件，又没有丢失任何数据，原则上就不该在恢复的时候有部分恢复的情况，也就是说，重建控制文件不会破坏数据的完整性。

下面是oracle 81740 on Tru64 4.0f上的例子
我也曾经做过oracle 9201在win上的例子，过程一样，并且归档非归档都是这样的，因为道理一样：




丢失全部控制文件的恢复（81740）
（非归档模式，无备份）










Lunar






















目  录

检查当前是否为NOARCHIVE MODE        3
关闭数据库，并作一个冷备份        3
重新启动数据库，并制作测试数据        4
模拟数据crash和丢失所有控制文件        6
通过重建控制文件来完全恢复数据库        7
nomount启动数据库        7
重建控制文件        7
完全恢复数据库        8
正常打开数据库        8
验证数据的完整性        8































检查当前是否为NOARCHIVE MODE
feptwo> sqlplus internal  

SQL*Plus: Release 8.1.7.0.0 - Production on Fri Mar 28 10:48:11 2003

(c) Copyright 2000 Oracle Corporation.  All rights reserved.


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
JServer Release 8.1.7.4.0 - Production

SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Enabled
Archive destination            /usr/oracle/app/oracle/product/8.1.7/admin/cint208/arch
Oldest online log sequence     98
Current log sequence           100
SQL>

关闭数据库，并作一个冷备份
（防止恢复过程（测试恢复的方法）如果出现问题）
SQL> alter database backup controlfile to trace;

Database altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> host
$ ls
coldback        control03.ctl   rbs01.dbf       redo03.log      testspace1.dbf
control01.ctl   drsys01.dbf     redo01.log      system01.dbf    tools01.dbf
control02.ctl   indx01.dbf      redo02.log      temp01.dbf      users01.dbf
$ mv *ctl *dbf *log coldback
$ ls
coldback
$ cd coldback
$ ls
control01.ctl   drsys01.dbf     redo01.log      system01.dbf    tools01.dbf
control02.ctl   indx01.dbf      redo02.log      temp01.dbf      users01.dbf
control03.ctl   rbs01.dbf       redo03.log      testspace1.dbf
$

重新启动数据库，并制作测试数据
（假设命名当前的窗口为：窗口a）
SQL> startup
ORACLE instance started.

Total System Global Area   81884132 bytes
Fixed Size                   103396 bytes
Variable Size              57401344 bytes
Database Buffers           24199168 bytes
Redo Buffers                 180224 bytes
Database mounted.
Database opened.
SQL> conn lunar
Enter password:
Connected.
SQL> conn lunar
Enter password:
Connected.
SQL> create table test(a number);

Table created.

SQL> insert into test values(1);

1 row created.

SQL> insert into test values(2);

1 row created.

SQL>

再开一个窗口（窗口b）做checkpoin：
feptwo> sqlplus internal

SQL*Plus: Release 8.1.7.0.0 - Production on Fri Mar 28 10:59:13 2003

(c) Copyright 2000 Oracle Corporation.  All rights reserved.


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
JServer Release 8.1.7.4.0 - Production

SQL> alter system checkpoint;

System altered.

SQL>

回到以前的窗口（窗口a），再次插入数据，并commit：
SQL> insert into test values(3);

1 row created.

SQL> insert into test values(4);

1 row created.

SQL> commit;

Commit complete.

SQL> insert into test values(5);

1 row created.

SQL> insert into test values(6);

1 row created.

SQL>


回到窗口b，做swhtch log：
SQL> alter system switch logfile;

System altered.

SQL>

回到窗口a，继续插入数据：
SQL> insert into test values(6);

1 row created.
错了，误操作了，呵呵，插了两条6，以后不好比对了
SQL> delete from test where a=6;

2 rows deleted.

SQL> insert into test values(7);

1 row created.

SQL> commit;

Commit complete.

SQL> insert into test values(8);

1 row created.

SQL> insert into test values(9);

1 row created.

SQL>

模拟数据crash和丢失所有控制文件
回到窗口b，模拟数据crash：
SQL> shutdown abort
ORACLE instance shut down.
SQL>

删除所有的控制文件：
SQL> host
ls
$ coldback        control03.ctl   rbs01.dbf       redo03.log      testspace1.dbf
control01.ctl   drsys01.dbf     redo01.log      system01.dbf    tools01.dbf
control02.ctl   indx01.dbf      redo02.log      temp01.dbf      users01.dbf
$ rm *ctl
$ ls
coldback        indx01.dbf      redo01.log      redo03.log      temp01.dbf      tools01.dbf
drsys01.dbf     rbs01.dbf       redo02.log      system01.dbf    testspace1.dbf  users01.dbf

通过重建控制文件来完全恢复数据库
nomount启动数据库
$ sqlplus internal

SQL*Plus: Release 8.1.7.0.0 - Production on Fri Mar 28 11:50:27 2003

(c) Copyright 2000 Oracle Corporation.  All rights reserved.

Connected to an idle instance.

SQL> startup nomount;
ORACLE instance started.

Total System Global Area   81884132 bytes
Fixed Size                   103396 bytes
Variable Size              57401344 bytes
Database Buffers           24199168 bytes
Redo Buffers                 180224 bytes
SQL>

重建控制文件
SQL> CREATE CONTROLFILE REUSE DATABASE "CINT208" NORESETLOGS NOARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 2
  4      MAXDATAFILES 30
  5      MAXINSTANCES 1
  6      MAXLOGHISTORY 226
  7  LOGFILE
  8    GROUP 1 '/usr/oracle/data/oradata/cint208/redo03.log'  SIZE 500K,
  9    GROUP 2 '/usr/oracle/data/oradata/cint208/redo02.log'  SIZE 500K,
10    GROUP 3 '/usr/oracle/data/oradata/cint208/redo01.log'  SIZE 500K
11  DATAFILE
12    '/usr/oracle/data/oradata/cint208/system01.dbf',
13    '/usr/oracle/data/oradata/cint208/tools01.dbf',
14    '/usr/oracle/data/oradata/cint208/rbs01.dbf',
15    '/usr/oracle/data/oradata/cint208/temp01.dbf',
16    '/usr/oracle/data/oradata/cint208/users01.dbf',
17    '/usr/oracle/data/oradata/cint208/indx01.dbf',
18    '/usr/oracle/data/oradata/cint208/drsys01.dbf',
19    '/usr/oracle/data/oradata/cint208/testspace1.dbf'
20  CHARACTER SET ZHS16GBK
21  ;

Control file created.
SQL>

完全恢复数据库
SQL> recover database;
Media recovery complete.
SQL>

正常打开数据库
SQL> alter database open;

Database altered.

SQL>

验证数据的完整性
SQL> conn lunar/lunarz
Connected.
SQL> select * from test;

         A
----------
         1
         2
         3
         4
         5
         7

6 rows selected.

SQL>

lunar2000

最初由 小段探花 发布
[B]去年，我们的数据库（noarchivelog)就出现了这样的问题：
A 表空间的一个数据文件损坏，数据库shutdown后不能启动，俺当时不知如何处理，把A表空间OFFLINE，数据库启动了。
后来由于忙别的事情，找资料晚了，后来再recovery就怎么都没有办法完成了。现在呢，领导找别人给弄了，也不知道是怎么弄的，就好了，A空间的数据也恢复了。
我想是否是这样的：
1、因为是noarchivelog模式，且redo log不知已经提交多少次了，损坏的数据文件，应该不等恢复了，就resize。
2、再把A空间online,(不知是否可以？）
3、alter database open resetlog.

大虾，看是否可以？ [/B]

这个问题有两种恢复方法（就是含有脱机表空间的数据库恢复问题）

方法一：
将备份的数据文件拷贝回来（restore）       
Mount数据库并查看是否有offline的数据文件       
将脱机（offline）状态的数据文件联机（online）       
使用recover database恢复数据库       
打开数据库       
使脱机的表空间联机       

方法二：
将备份的数据文件拷贝回来（restore）       
Mount数据库并查看是否有offline的数据文件       
使用recover database恢复数据库       
打开数据库       
使脱机的表空间联机       
将脱机（offline）状态的数据文件联机（online）       
使脱机的表空间联机，报错       
恢复表空间       
再使脱机的表空间联机

biti_rainy

CREATE CONTROLFILE     REUSE   DATABASE "billy"

问题出在  "SET"  <-------->   REUSE  
晕！