首页 / MYSQL / 恢复丢失的控制文件

恢复丢失的控制文件

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了恢复丢失的控制文件，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含20046字，纯文字阅读大概需要29分钟。

内容图文

本文档主要转发自：http://book.51cto.com/art/201108/287826.htm，只加了自己操作后的备注与理解，操作环境：虚拟机Vmware Player 5.0.2+RHEL Server 6.4+Oracle 11.2.0.3(单机)+ASM. 9.6 利用恢复的控制文件进行数据库恢复 （David备注：标题有点大，实际

本文档主要转发自：http://book.51cto.com/art/201108/287826.htm，只加了自己操作后的备注与理解，操作环境：虚拟机Vmware Player 5.0.2+RHEL Server 6.4+Oracle 11.2.0.3(单机)+ASM.

9.6 利用恢复的控制文件进行数据库恢复

（David备注：标题有点大，实际上本节并没有讲控制文件+其他文件如数据库、在线日志丢失的场景，只是在讲述控制文件丢失后怎么恢复控制文件)

Oracle文档中提到，一旦用备份的控制文件进行数据库恢复，就需要使用resetlogs的方法打开数据库。但是resetlogs通常意味着不完全恢复(David备注：这句话是有问题的，其实resetlogs本来就适用于不完全恢复和使用backup controlfile恢复），而且更重要的是一旦用resetlogs方法打开数据库，日志的序号用重新从1开始。其实如果只是控制文件损坏，日志文件都完整的话，数据库是可以完全恢复的，而且不必非得用resetlogs打开。接下来，我们就对不完全恢复做出总结(备注：这句话改为“恢复丢失的控制文件”更为恰当），如图9-10所示，然后再通过一些实验深入理解。

恢复丢失的控制文件 - 文章图片

9.6.1 使用alter database open resetlogs的场合

使用resetlogs选项，会把当前的日志序号（log sequence number）重设为1，并抛弃所有日志信息。在以下条件时需要使用resetlogs选项：

在不完全恢复（介质恢复）；

使用备份控制文件。

使用resetlogs打开数据库后，务必要完整地进行一次数据库备份。

David备注：From oracle 10g:

Simplified Recovery Through RESETLOGS

-Database can be opened immediately after RESETLOGS

-A full backup no longer needs to be taken

-Usage scenarios:Incomplete recovery,Recovery using backup control file) The simplified recovery through the RESETLOGS feature is an enhancement to recovery operations so that previous incarnation backups can be used for recovery of the current
database incarnation.

Oracle10g能做到这一点主要是做了两点优化：

1.From Oracle Database 10g,you can use the ALTER DATABASE OPEN RESETLOGS statement so that the database now archives the current online redo logs (if possible) before clearing the logs.

2.a new format specification for archived redo log files is introduced to avoid overwriting archived redo log files with the same sequence number across these incarnations.

9.6.2 重建控制文件

如果数据库的控制文件损坏，有3种方法可以用来重建控制文件，每一种方法的后续处理又有不同，这3种方法分别是：

从自动备份或者备份中恢复；

用create controlfile resetlogs方法重建；

用create controlfile noresetlogs方法重建。

每一种方法所对应的后续处理是这样的。

（1）如果是从备份中恢复的控制文件，后续要：

使用using backup controlfile子句进行数据库恢复；

打开数据库时需要用resetlogs方式打开。

（2）如果使用resetlogs方法重建的控制文件，后续要：

使用using backup controlfile的方法进行数据库恢复；

要用resetlogs方式打开数据库。

（3）如果是用noresetlogs方法创建的控制文件，后续要：

恢复数据库时无须用using backup controlfile；

无须使用resetlogs方式打开数据库。

值得一提的是，create controlfile resetlogs/noresetlogs这两种重建方法的区别在于，noresetlogs重建控制文件时，控制文件中datafile Checkpoint来自Online logs中的Current log头。而用resetlogs重建控制文件时，控制文件中datafile Checkpoint来自各数据文件头。

9.6.3 使用using backup controlfile的场合

以下条件需要使用using backup controlfile：

使用备份控制文件；

用resetlogs方法重建控制文件,如果用noresetlogs重建不必要使用using backup controlfile。

接下来，我们通过3个例子深入分析这些场景的处理，注意，下面这些例子中日志文件都是好的，也就是从数据角度来看，做的都是完全恢复，没有数据丢失。但因为控制文件的来源不同，后续处理也就不一样。

9.6.4 例子1：使用备份的控制文件做恢复（1）（1）备份控制文件：
  1. RMAN> backup datafile 1;
  3. Starting backup at 13-APR-11
  4. allocated channel: ORA_DISK_1
  5. channel ORA_DISK_1: sid=2476 devtype=DISK
  6. channel ORA_DISK_1: starting full datafile backupset
  7. channel ORA_DISK_1: specifying datafile(s) in backupset
  8. input datafile fno=00001 name=/zxm/cindytest/system01.dbf
  9. channel ORA_DISK_1: starting piece 1 at 13-APR-11
  10. channel ORA_DISK_1: finished piece 1 at 13-APR-11
  11. piece handle=/oracle/product/10G_single/dbs/
    0om9lsiu_1_1 tag=TAG20110413T113453 comment=NONE
  12. channel ORA_DISK_1: backup set complete, elapsed time: 00:00:35
  13. Finished backup at 13-APR-11
  15. Starting Control File and SPFILE Autobackup at 13-APR-11
  16. piece handle=/oracle/product/10G_single/dbs/c
    -539593454-20110413-00 comment=NONE
  17. Finished Control File and SPFILE Autobackup at 13-APR-11

备份的控制文件在/oracle/product/10G_single/dbs/c-539593454-20110413-00，稍后就利用这个备份进行恢复。

（2）进行了一堆操作和日志切换：

  1. SQL> alter system switch logfile;
  3. System altered.
  5. SQL> create table a as select * from tabs;
  7. Table created.
  9. SQL> alter system switch logfile;
  11. System altered.
  13. SQL> create table b as select * from a;
  15. Table created.
  17. SQL> alter system switch logfile;

当前的日志序列：

  1. SQL> select sequence# from v$log;
  3. SEQUENCE#
  4. ----------
  5. 24
  6. 22
  7. 23

（3）关闭数据库，模拟故障：

  1. SQL> shutdown abort;
  2. ORACLE instance shut down

删除控制文件。

（4）启动数据库，因为没有控制文件，所以只能打开到nomount状态，这也是恢复所必须的状态：

  1. SQL> startup
  2. ORACLE instance started.
  4. Total System Global Area 3221225472 bytes
  5. Fixed Size 2024200 bytes
  6. Variable Size 637537528 bytes
  7. Database Buffers 2566914048 bytes
  8. Redo Buffers 14749696 bytes
  9. ORA-00205: error in identifying control file,
    check alert log for more info

（5）恢复控制文件：

  1. [oracle@dbs cindytest]$ rman target /
  3. Recovery Manager: Release 10.2.0.1.0 - Production
    on Wed Apr 13 11:38:56 2011
  5. Copyright (c) 1982, 2005, Oracle. All rights reserved.
  7. connected to target database: ctest (not mounted)
  9. RMAN> restore controlfile from '/oracle/product/
    10G_single/dbs/c-539593454-20110413-00';
  11. Starting restore at 13-APR-11
  12. using target database control file instead of recovery catalog
  13. allocated channel: ORA_DISK_1
  14. channel ORA_DISK_1: sid=2486 devtype=DISK
  16. channel ORA_DISK_1: restoring control file
  17. channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
  18. output filename=/zxm/cindytest/control01.ctl
  19. Finished restore at 13-APR-11

把数据库打开到mount状态：

  1. SQL> select status from v$instance;
  3. STATUS
  4. ------------
  5. STARTED
  7. SQL> alter database mount;
  9. Database altered.
  11. SQL> select sequence# from v$log;
  13. SEQUENCE#
  14. ----------
  15. 21
  16. 20
  17. 19 David备注：v$log是从control file中提取的，备份时control file中的redo log序号最大还在21，备份后又做了三次log switch，因此上面查到的是22-24，这里查到的是19-21.

（6）恢复数据库，如果不用using子句，rman会提示：

  1. SQL> recover database;
  2. ORA-00283: recovery session canceled due to errors
  3. ORA-01610: recovery using the BACKUP
    CONTROLFILE option must be done
  5. SQL> recover database using backup controlfile;
  6. ORA-00279: change 76850708247 generated at
    04/13/2011 09:52:40 needed for
  7. thread 1
  8. ORA-00289: suggestion : /zxm/cindytest/arch/1_21_747160176.dbf
  9. ORA-00280: change 76850708247 for thread 1 is in sequence #21
  12. Specify log: {=suggested | filename | AUTO | CANCEL}
  14. ORA-00279: change 76850708257 generated at
    04/13/2011 11:35:48 needed for
  15. thread 1
  16. ORA-00289: suggestion : /zxm/cindytest/arch/
    1_22_747160176.dbf
  17. ORA-00280: change 76850708257 for thread 1
    is in sequence #22
  18. ORA-00278: log file '/zxm/cindytest/arch/1_2
    1_747160176.dbf' no longer needed
  19. for this recovery
  22. Specify log: {=suggested | filename | AUTO | CANCEL}
  24. ORA-00279: change 76850708305 generated at 04/
    13/2011 11:36:01 needed for
  25. thread 1
  26. ORA-00289: suggestion : /zxm/cindytest/arch/1_23_747160176.dbf
  27. ORA-00280: change 76850708305 for thread 1 is in sequence #23
  28. ORA-00278: log file '/zxm/cindytest/arch/1_22_
    747160176.dbf' no longer needed
  29. for this recovery
  32. Specify log: {=suggested | filename | AUTO | CANCEL}
  34. ORA-00279: change 76850708336 generated at
    04/13/2011 11:36:21 needed for
  35. thread 1
  36. ORA-00289: suggestion : /zxm/cindytest/arch/1_24_747160176.dbf
  37. ORA-00280: change 76850708336 for thread 1 is in sequence #24
  38. ORA-00278: log file '/zxm/cindytest/arch/1_23_
    747160176.dbf' no longer needed
  39. for this recovery
  42. Specify log: {=suggested | filename | AUTO | CANCEL}
  44. ORA-00308: cannot open archived log '/zxm/
    cindytest/arch/1_24_747160176.dbf'
  45. ORA-27037: unable to obtain file status
  46. Linux-x86_64 Error: 2: No such file or directory
  47. Additional information: 3

rman会自己猜测归档日志文件，我们只需要按下回车键就可以了，不过最后一个需要注意，第24号日志文件实际是联机日志，并不是控制文件，所以需要我们明确告诉rman这个日志文件的位置。

如果不记得到底哪一个是当前日志了，那就从第一个开始吧，再次输入这个命令，在遇到提示时输入联机日志的位置；

  1. SQL> recover database using backup controlfile;
  2. ORA-00279: change 76850708336 generated at
    04/13/2011 11:36:21 needed for
  3. thread 1
  4. ORA-00289: suggestion : /zxm/cindytest/arch/1_24_747160176.dbf
  5. ORA-00280: change 76850708336 for thread 1 is in sequence #24
  7. Specify log: {=suggested | filename | AUTO | CANCEL}

输入文件位置：

  1. /zxm/cindytest/redo01.log

恢复成功：

  1. Log applied.
  2. Media recovery complete.
David备注：我实验时,如果使用SQL与上面完全相同，但是如果使用rman可以直接recover database，加using backup controlfile会报语法错：
SQL> startup
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 572043264 bytes
Fixed Size 2230432 bytes
Variable Size 520095584 bytes
Database Buffers 46137344 bytes
Redo Buffers 3579904 bytes
ORA-00205: error in identifying control file, check alert log for more info

restore控制文件后： alter database mount;
Database altered.

SQL> select sequence# from v$log;

SEQUENCE#
----------
16
15
17
RMAN> recover database;


Starting recover at 12-JAN-14
released channel: ORA_DISK_1
Starting implicit crosscheck backup at 12-JAN-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=26 device type=DISK
Crosschecked 4 objects
Finished implicit crosscheck backup at 12-JAN-14

Starting implicit crosscheck copy at 12-JAN-14
using channel ORA_DISK_1
Finished implicit crosscheck copy at 12-JAN-14

searching for all files in the recovery area
cataloging files...
cataloging done


List of Cataloged Files
=======================
File Name: /opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_19_9f4vkr74_.arc
File Name: /opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_17_9f4vjvms_.arc
File Name: /opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_18_9f4vkbbg_.arc
File Name: /opt/app/oracle/fast_recovery_area/IPCDB/backupset/2014_01_12/o1_mf_ncsnf_TAG20140112T181519_9f4tvm53_.bkp

using channel ORA_DISK_1
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
ORACLE error from target database:
ORA-19922: there is no parent row with id 0 and level 1

starting media recovery

archived log for thread 1 with sequence 17 is already on disk as file /opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_17_9f4vjvms_.arc
archived log for thread 1 with sequence 18 is already on disk as file /opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_18_9f4vkbbg_.arc
archived log for thread 1 with sequence 19 is already on disk as file /opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_19_9f4vkr74_.arc
archived log for thread 1 with sequence 20 is already on disk as file +DATA/ipcdb/onlinelog/group_2.268.835737765
archived log file name=/opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_17_9f4vjvms_.arc thread=1 sequence=17
archived log file name=/opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_18_9f4vkbbg_.arc thread=1 sequence=18
archived log file name=/opt/app/oracle/fast_recovery_area/IPCDB/archivelog/2014_01_12/o1_mf_1_19_9f4vkr74_.arc thread=1 sequence=19
archived log file name=+DATA/ipcdb/onlinelog/group_2.268.835737765 thread=1 sequence=20
media recovery complete, elapsed time: 00:00:02
Finished recover at 12-JAN-14

（7）虽然进行的是完全恢复，没有数据丢失，但是因为使用了using子句，打开数据库时必须使用resetlogs方法打开；

  1. SQL> alter database open;
  2. alter database open
  3. *
  4. ERROR at line 1:
  5. ORA-01589: must use RESETLOGS or NORESETLOGS
    option for database open
  7. SQL> alter database open noresetlogs;
  8. alter database open noresetlogs
  9. *
  10. ERROR at line 1:
  11. ORA-01588: must use RESETLOGS option for database open
  13. SQL> alter database open resetlogs;
  15. Database altered.

现在日志序列重新从1开始编号。

  1. SQL> select group#,sequence#,status from v$log;
  3. GROUP# SEQUENCE# STATUS
  4. ---------- ---------- ----------------
  5. 1 1 INACTIVE
  6. 2 2 CURRENT
  7. 3 0 UNUSED

9.6.5 例子2：用noresetlogs方法重建控制文件（1）

（1）继续测试，再做一次备份：

  1. RMAN> backup datafile 1;
  3. Starting backup at 13-APR-11
  4. using target database control file instead of recovery catalog
  5. allocated channel: ORA_DISK_1
  6. channel ORA_DISK_1: sid=2489 devtype=DISK
  7. channel ORA_DISK_1: starting full datafile backupset
  8. channel ORA_DISK_1: specifying datafile(s) in backupset
  9. input datafile fno=00001 name=/zxm/cindytest/system01.dbf
  10. channel ORA_DISK_1: starting piece 1 at 13-APR-11
  11. channel ORA_DISK_1: finished piece 1 at 13-APR-11
  12. piece handle=/oracle/product/10G_single/dbs/
    0sm9lufk_1_1 tag=TAG20110413T120716 comment=NONE
  13. channel ORA_DISK_1: backup set complete, elapsed time: 00:00:35
  14. Finished backup at 13-APR-11
  16. Starting Control File and SPFILE Autobackup at 13-APR-11
  17. piece handle=/oracle/product/10G_single/dbs
    /c-539593454-20110413-01 comment=NONE
  18. Finished Control File and SPFILE Autobackup at 13-APR-11

（2）做一些操作和日志切换：

  1. SQL> create table aa as select * from a;
  3. Table created.
  5. SQL> create table bb as select * from b;
  7. Table created.
  9. SQL> alter system switch logfile;
  11. System altered.
  13. SQL> create table cc as select * from a;
  15. Table created.
  17. SQL> alter system switch logfile;
  19. System altered.

当前日志序列：

  1. SQL> select group#,sequence#,status from v$log;
  3. GROUP# SEQUENCE# STATUS
  4. ---------- ---------- ----------------
  5. 1 4 CURRENT
  6. 2 2 ACTIVE
  7. 3 3 ACTIVE

（3）关闭数据库，模拟故障：

  1. SQL> shutdown abort;
  2. exit
  3. ORACLE instance shut down.
  4. SQL> Disconnected from Oracle Database 10g
    Enterprise Edition Release 10.2.0.1.0 - 64bit Production
  5. With the Partitioning, OLAP and Data Mining options

删除控制文件：

  1. SQL> startup
  2. ORACLE instance started.
  4. Total System Global Area 3221225472 bytes
  5. Fixed Size 2024200 bytes
  6. Variable Size 637537528 bytes
  7. Database Buffers 2566914048 bytes
  8. Redo Buffers 14749696 bytes
  9. ORA-00205: error in identifying control file,
    check alert log for more info

（4）恢复控制文件：

  1. RMAN> restore controlfile from '/oracle/product
    /10G_single/dbs/c-539593454-20110413-01';
  3. Starting restore at 13-APR-11
  4. using channel ORA_DISK_1
  6. channel ORA_DISK_1: restoring control file
  7. channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
  8. output filename=/zxm/cindytest/control01.ctl
  9. Finished restore at 13-APR-11

把控制文件备份到trace文件：

[David备注]需要先将数据库置为mount状态： alter database mount;

  1. SQL> alter database backup controlfile to trace;
  3. Database altered

（5）重建控制文件，先关闭数据库，删除之前从备份中恢复出来的控制文件，启动到nomount状态：

  1. SQL> shutdown immediate;
  2. ORA-01109: database not open
  5. Database dismounted.
  6. ORACLE instance shut down.

删除控制文件：

  1. SQL> startup nomount ;
  2. ORACLE instance started.
  4. Total System Global Area 3221225472 bytes
  5. Fixed Size 2024200 bytes
  6. Variable Size 637537528 bytes
  7. Database Buffers 2566914048 bytes
  8. Redo Buffers 14749696 bytes

[David备注]trace文件生成时会生成两个脚本：resetlogs与noresetlogs,且说明如果online redo logs还是全的，就使用noresetlogs，如果online redo logs不可用，则使用resetlogs:

-- Below are two sets of SQL statements, each of which creates a new

-- control file and uses it to open the database. The first set opens
-- the database with the NORESETLOGS option and should be used only if
-- the current versions of all online logs are available. The second
-- set opens the database with the RESETLOGS option and should be used
-- if online logs are unavailable.

（6）用noresetlogs创建，因为联机日志还在，所以可以用noresetlogs的方法创建：

  1. SQL> CREATE CONTROLFILE REUSE DATABASE
    "CTEST" NORESETLOGS ARCHIVELOG
  2. 2 MAXLOGFILES 16
  3. 3 MAXLOGMEMBERS 3
  4. 4 MAXDATAFILES 100
  5. 5 MAXINSTANCES 8
  6. 6 MAXLOGHISTORY 292
  7. 7 LOGFILE
  8. 8 GROUP 1 '/zxm/cindytest/ctest/redo01.log' SIZE 50M,
  9. 9 GROUP 2 '/zxm/cindytest/ctest/redo02.log' SIZE 50M,
  10. 10 GROUP 3 '/zxm/cindytest/ctest/redo03.log' SIZE 50M
  11. 11 -- STANDBY LOGFILE
  12. 12 DATAFILE
  13. 13 '/zxm/cindytest/ctest/system01.dbf',
  14. 14 '/zxm/cindytest/ctest/undotbs01.dbf',
  15. 15 '/zxm/cindytest/ctest/sysaux01.dbf',
  16. 16 '/zxm/cindytest/ctest/users01.dbf'
  17. 17 CHARACTER SET ZHS16GBK;
  19. Control file created.
  21. SQL> alter database open;
  22. alter database open
  23. *
  24. ERROR at line 1:
  25. ORA-01113: file 1 needs media recovery
  26. ORA-01110: data file 1: '/zxm/cindytest/ctest/system01.dbf'

7）目前数据文件还不一致，需要进行介质恢复，但是不用using子句：

  1. SQL> recover database;
  2. Media recovery complete.

（8）打开数据库：

  1. SQL> alter database open;
  3. Database altered.
[David备注]在trace文件中的步骤比这个多一些： -- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE
-- Block change tracking was enabled, so re-enable it now.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '+DATA/ipcdb/changetracking/ctf.256.835737421' REUSE;
-- All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;
-- Database can now be opened normally.
ALTER DATABASE OPEN;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATA/ipcdb/tempfile/temp.265.835737729' REUSE;
-- End of tempfile additions.

9.6.6 例子3：用resetlogs方法重建控制文件

（1）模拟过程和之前的步骤都一样，就不再演示了，主要看重建控制文件之后的操作。

（2）因为联机日志还在，如果用resetlogs方法，要求联机日志中必须要没有活动事务才行。创建控制文件的操作并不会清空当前联机日志内容，因此，如果有数据文件的不一致，当前联机日志还是可以用来恢复的；

  1. SQL> CREATE CONTROLFILE REUSE DATABASE "CTEST"
    RESETLOGS ARCHIVELOG
  2. 2 MAXLOGFILES 16
  3. 3 MAXLOGMEMBERS 3
  4. 4 MAXDATAFILES 100
  5. 5 MAXINSTANCES 8
  6. 6 MAXLOGHISTORY 292
  7. 7 LOGFILE
  8. 8 GROUP 1 '/zxm/cindytest/ctest/redo01.log' SIZE 50M,
  9. 9 GROUP 2 '/zxm/cindytest/ctest/redo02.log' SIZE 50M,
  10. 10 GROUP 3 '/zxm/cindytest/ctest/redo03.log' SIZE 50M
  11. 11 -- STANDBY LOGFILE
  12. 12 DATAFILE
  13. 13 '/zxm/cindytest/ctest/system01.dbf',
  14. 14 '/zxm/cindytest/ctest/undotbs01.dbf',
  15. 15 '/zxm/cindytest/ctest/sysaux01.dbf',
  16. 16 '/zxm/cindytest/ctest/users01.dbf'
  17. 17 CHARACTER SET ZHS16GBK
  18. 18 ;
  20. Control file created.

控制文件创建之后，数据库自动到mount状态：

  1. SQL> alter database mount;
  2. alter database mount
  3. *
  4. ERROR at line 1:
  5. ORA-01100: database already mounted

（3）尝试用resetlogs方法打开数据库：

  1. SQL> alter database open resetlogs;
  2. alter database open resetlogs
  3. *
  4. ERROR at line 1:
  5. ORA-01194: file 1 needs more recovery to be consistent
  6. ORA-01110: data file 1: '/zxm/cindytest/ctest/system01.dbf'

（4）数据文件不一致，需要进行介质恢复：

  1. SQL> recover database;
  2. ORA-00283: recovery session canceled due to errors
  3. ORA-01610: recovery using the BACKUP
    CONTROLFILE option must be done

因为控制文件是用resetlogs的方法创建的，因此恢复时必须要用using子句；

  1. SQL> recover database using backup controlfile;
  2. ORA-00279: change 558697 generated at 04/
    13/2011 14:25:26 needed for thread 1
  3. ORA-00289: suggestion : /zxm/cindytest/arch/1_8_748360440.dbf
  4. ORA-00280: change 558697 for thread 1 is in sequence #8
  6. Specify log: {=suggested | filename | AUTO | CANCEL}
  8. ORA-00308: cannot open archived log '/
    zxm/cindytest/arch/1_8_748360440.dbf'
  9. ORA-27037: unable to obtain file status
  10. Linux-x86_64 Error: 2: No such file or directory
  11. Additional information: 3

Oracle自己猜测的归档日志其实是联机日志，因此需要手工指定这个文件；

  1. SQL> recover database using backup controlfile;
  2. ORA-00279: change 558697 generated at 04/13
    /2011 14:25:26 needed for thread 1
  3. ORA-00289: suggestion : /zxm/cindytest/arch/1_8_748360440.dbf
  4. ORA-00280: change 558697 for thread 1 is in sequence #8
  6. Specify log: {=suggested | filename | AUTO | CANCEL}

给出这个文件：

  1. /zxm/cindytest/ctest/redo01.log

恢复成功：

  1. Log applied.
  2. Media recovery complete.

（5）打开数据库，必须用resetlogs的方法打开才行：

  1. SQL> alter database open ;
  2. alter database open
  3. *
  4. ERROR at line 1:
  5. ORA-01589: must use RESETLOGS or NORESETLOGS
    option for database open
  7. SQL> alter database open resetlogs;
  9. Database altered.

内容总结

以上是互联网集市为您收集整理的恢复丢失的控制文件全部内容，希望文章能够帮你解决恢复丢失的控制文件所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/530222.html

来源：【匿名】