ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 数据库恢复实例二:恢复控制文件

数据库恢复实例二:恢复控制文件

原创 Linux操作系统 作者:jifei0611 时间:2008-12-15 10:23:21 0 删除 编辑

数据库恢复实例二:恢复控制文件

数据库错误如下:

[oracle@HDI01 hdi26]$ rman target / nocatalog

 

Recovery Manager: Release 10.2.0.1.0 - Production on Wed Dec 10 10:32:44 2008

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-00554: initialization of internal recovery manager package failed

RMAN-06003: ORACLE error from target database:

ORA-00210: cannot open the specified control file

ORA-00202: control file: '/u01/app/oracle/oradata/hdi26/control01.ctl'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

 

解决过程:

1.根据提示可以判断此错误由controlfile损坏引起的

 

2.确定为controlfile损坏程度

SQL> show parameter control_files;

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

control_files                        string      /u01/app/oracle/oradata/hdi26/

                                                 control01.ctl, /u01/app/oracle

                                                 /oradata/hdi26/control02.ctl,

                                                 /u01/app/oracle/oradata/hdi26/

                                                 control03.ctl

cd /u01/app/oracle/oradata/hdi26/

ll control*

结果为controlfile完成丢失

RMAN备份中配置了controlfile自动备份,从备份中恢复

3.controlfile的恢复需数据库在nomount状态,决定关数据库

SQL> shutdown immediate;

ORA-00210: cannot open the specified control file

ORA-00202: control file: '/u01/app/oracle/oradata/hdi26/control01.ctl'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

数据库不能正常关闭(controlfile丢失,无法记录scn),强制数据库启动到nomount状态

SQL> startup force nomount;

 

4.恢复controlfile

RMAN> restore controlfile from '/u09/orabackup/rman/controlfile/c-1504204985-20081209-00';

 

Starting restore at 10-DEC-08

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=156 devtype=DISK

 

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

output filename=/u01/app/oracle/oradata/hdi26/control01.ctl

output filename=/u01/app/oracle/oradata/hdi26/control02.ctl

output filename=/u01/app/oracle/oradata/hdi26/control03.ctl

Finished restore at 10-DEC-08

5. RMAN>alter database mount

 

6.恢复数据

RMAN> recover database;

 

Starting recover at 10-DEC-08

Starting implicit crosscheck backup at 10-DEC-08

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=158 devtype=DISK

Crosschecked 46 objects

Finished implicit crosscheck backup at 10-DEC-08

 

Starting implicit crosscheck copy at 10-DEC-08

using channel ORA_DISK_1

Crosschecked 2 objects

Finished implicit crosscheck copy at 10-DEC-08

 

searching for all files in the recovery area

cataloging files...

no files cataloged

 

using channel ORA_DISK_1

 

starting media recovery

 

archive log thread 1 sequence 47 is already on disk as file /u02/oradata/sfcsys/redo01a.log

archive log thread 1 sequence 48 is already on disk as file /u02/oradata/sfcsys/redo03a.log

archive log thread 1 sequence 49 is already on disk as file /u02/oradata/sfcsys/redo02a.log

archive log filename=/u03/archivelog/sfcsys/1_29_672944946.dbf thread=1 sequence=29

archive log filename=/u03/archivelog/sfcsys/1_30_672944946.dbf thread=1 sequence=30

archive log filename=/u03/archivelog/sfcsys/1_31_672944946.dbf thread=1 sequence=31

archive log filename=/u03/archivelog/sfcsys/1_32_672944946.dbf thread=1 sequence=32

archive log filename=/u03/archivelog/sfcsys/1_33_672944946.dbf thread=1 sequence=33

archive log filename=/u03/archivelog/sfcsys/1_34_672944946.dbf thread=1 sequence=34

archive log filename=/u03/archivelog/sfcsys/1_35_672944946.dbf thread=1 sequence=35

archive log filename=/u03/archivelog/sfcsys/1_36_672944946.dbf thread=1 sequence=36

archive log filename=/u03/archivelog/sfcsys/1_37_672944946.dbf thread=1 sequence=37

archive log filename=/u03/archivelog/sfcsys/1_38_672944946.dbf thread=1 sequence=38

archive log filename=/u03/archivelog/sfcsys/1_39_672944946.dbf thread=1 sequence=39

archive log filename=/u03/archivelog/sfcsys/1_40_672944946.dbf thread=1 sequence=40

archive log filename=/u03/archivelog/sfcsys/1_41_672944946.dbf thread=1 sequence=41

archive log filename=/u03/archivelog/sfcsys/1_42_672944946.dbf thread=1 sequence=42

archive log filename=/u03/archivelog/sfcsys/1_43_672944946.dbf thread=1 sequence=43

archive log filename=/u03/archivelog/sfcsys/1_44_672944946.dbf thread=1 sequence=44

archive log filename=/u03/archivelog/sfcsys/1_45_672944946.dbf thread=1 sequence=45

archive log filename=/u03/archivelog/sfcsys/1_46_672944946.dbf thread=1 sequence=46

archive log filename=/u02/oradata/sfcsys/redo01a.log thread=1 sequence=47

archive log filename=/u02/oradata/sfcsys/redo03a.log thread=1 sequence=48

archive log filename=/u02/oradata/sfcsys/redo02a.log thread=1 sequence=49

media recovery complete, elapsed time: 00:00:27

Finished recover at 10-DEC-08

7.开启数据库

RMAN> alter database open resetlogs;

至此恢复完毕

:恢复controfile的另外一种方法是通过trace文件重建

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

请登录后发表评论 登录
全部评论

注册时间:2008-01-12

  • 博文量
    143
  • 访问量
    276288