丢失控制文件的恢复

9.3.3  丢失控制文件的恢复

前面曾经提到，在NOCATALOG模式下，RMAN创建的备份信息都将保存在目标数据库的控制文件中，所以一旦控制文件丢失，不仅目标数据库崩溃，连RMAN的备份信息也尽数丢失，这种情况下，如果您有控制文件备份，那还有救（没有备份的话，也并非完全没有希望，如果DBA对自己的Oracle数据库结构非常了解，可以通过写脚本的方式重建控制文件。你看Oracle是不是考虑的很周全？很多情况下你认为没救了的时候，也并非完全陷入绝境）。

本小节将模拟在归档模式下，控制文件丢失时的恢复，在本例中，我们仍然借助前面章节中建立的备份做恢复。

注 意

在恢复控制文件之前，必须知道目标数据库的DBID。关于数据库的DBID，有多种方式可查，比如创建自动备份时，如果没有更改其命名方式，文件名中会包含DBID；或者查看之前的RMAN备份日志，登录到RMAN之后会显示出目标数据库的DBID。

下面演示丢失控制文件的恢复过程。

1．模拟文件丢失

正在操作数据中：

  1. SQL> INSERT INTO JSS.BOOK_LIST VALUES   
  2. (2, 'ABOUT SANSI',SYSDATE);  
  3. 1 row created.  
  4. SQL> commit;  
  5. Commit complete. 

由于控制文件在Oracle数据库运行期间会被Oracle进程锁定，无法直接删除，因此这里还是按照前面模拟丢失数据文件的方式，首先SHUTDOWN数据库，然后再删除控制文件：

  1. SQL> SHUTDOWN IMMEDIATE  
  2. Database closed.  
  3. Database dismounted.  
  4. ORACLE instance shut down.  
  5. SQL> HOST DEL f:/oracle/oradata/jssbook/control*  
  6. SQL> STARTUP NOMOUNT  
  7. ORACLE instance started.  
  8. Total System Global Area  314572800 bytes  
  9. Fixed Size                  1248720 bytes  
  10. Variable Size              67109424 bytes  
  11. Database Buffers          239075328 bytes  
  12. Redo Buffers                7139328 bytes 

由于控制文件丢失，肯定是启动不到MOUNT状态了，因此最后将数据库启动到NOMOUNT状态。

2．恢复控制文件

新开一个窗口，连接到RMAN命令行：

  1. C:/Documents and Settings/junsansi>SET ORACLE_SID=jssbook  
  2. C:/Documents and Settings/junsansi>RMAN TARGET /  
  3. Recovery Manager: Release 10.2.0.1.0 - Production on   
  4. Wed Apr 29 22:58:25 2009  
  5. Copyright (c) 1982, 2005, Oracle.  All rights reserved.  
  6. connected to target database: jssbook (not mounted) 

目标数据库控制文件丢失，无法启动到MOUNT状态，此处必须首先指定DBID：

  1. RMAN> SET DBID=1415261003  
  2. executing command: SET DBID 

前面创建备份时都是在NOCATALOG模式下进行的，因此备份信息、备份设置等都是存储在目标数据库的控制文件中，现在控制文件丢失，相当于前面的一些配置也丢失了，用SHOW ALL命令查看，可见所有配置均恢复成了默认值，例如：

  1. RMAN> SHOW ALL;  
  2. using target database control file instead of recovery catalog  
  3. RMAN configuration parameters are:  
  4. CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default 
  5. CONFIGURE BACKUP OPTIMIZATION OFF; # default 
  6. CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default 
  7. CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default 
  8. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE   
  9. DISK TO '%F'; # default 
  10. CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO   
  11. BACKUPSET; # default 
  12. CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK   
  13. TO 1; # default 
  14. CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;   
  15. # default 
  16. CONFIGURE MAXSETSIZE TO UNLIMITED; # default 
  17. CONFIGURE ENCRYPTION FOR DATABASE OFF; # default 
  18. CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default 
  19. CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default 
  20. 此时要恢复控制文件，不能直接使用RESTORE CONTROLFILE  

FROM AUTOBACKUP命令，因为自动备份的设置也丢失了，并且此时也是在NOCATALOG模式下，无法配置CONTROLFILE AUTOBACKUP的相关属性，因此选择显式指定控制文件备份集的方式恢复控制文件。执行命令如下：

  1. RMAN> RESTORE CONTROLFILE FROM 'f:/oracle/backup  
  2. /C-1415261003-20090429-00';  
  3. Starting restore at 29-APR-09  
  4. allocated channel: ORA_DISK_1  
  5. channel ORA_DISK_1: sid=156 devtype=DISK  
  6. channel ORA_DISK_1: restoring control file  
  7. channel ORA_DISK_1: restore complete, elapsed time: 00:00:03  
  8. output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL01.CTL  
  9. output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL02.CTL  
  10. output filename=F:/ORACLE/ORADATA/JSSBOOK/CONTROL03.CTL  
  11. Finished restore at 29-APR-09 

提 示

指定控制文件备份集时，记得要找一个稍新一点的控制文件。另外如果恢复时没有指定TO子句，则控制文件会被恢复到初始化参数CONTROL_FILES指定的路径下。

有了控制文件，就可以将数据库置为MOUNT状态了：

  1. RMAN> ALTER DATABASE MOUNT;  
  2. database mounted  
  3. released channel: ORA_DISK_1 

由于只是控制文件丢失，数据文件仍在，因此并不需要对整个数据库进行修复操作，只需要执行RECOVER命令，重新应用备份的控制文件后生成的那些重做日志即可：

  1. RMAN> RECOVER DATABASE;  
  2. Starting recover at 29-APR-09  
  3. allocated channel: ORA_DISK_1  
  4. channel ORA_DISK_1: sid=155 devtype=DISK  
  5. starting media recovery  
  6. archive log thread 1 sequence 47 is already on disk as file   
  7. F:/ORACLE/ORADATA/JSSBOOK/REDO02.LOG  
  8. archive log filename=F:/ORACLE/ORADATA/JSSBOOK/REDO02.  
  9. LOG thread=1 sequence=47  
  10. media recovery complete, elapsed time: 00:00:02  
  11. Finished recover at 29-APR-09 

如果上述命令均正常执行，就可以打开数据库了：

  1. RMAN> ALTER DATABASE OPEN RESETLOGS;  
  2. database opened 

下面切换到SQL*Plus命令行环境下，看看数据是否都在：

  1. SQL> SELECT *FROM BOOK_LIST;  
  2.     BOOKID BOOKNAME  
  3. ---------- -------------------------------  
  4.          2 About Sansi  
  5.          1 Sansi's Note 

OK，一切正常。怎么样，你的操作都顺利吗？

posted @ 2009-12-23 00:10  无双的小宝  阅读(1793)  评论(0)  编辑  收藏  举报