oracle 迁移数据库 rman 06026,应对RMAN-06026错误,使用dbms_backup_restore进行恢复

应对RMAN-06026错误,使用dbms_backup_restore进行恢复

6ee5639a40442445944d63b514b2dd02.png

_allow_resetlogs_corruption参数,resetlogs之后,Oracle使用当前的控制文件不允许从这个历史备份集中进行恢复。

由于我没有使用catalog,所以尝试使用dbms_backup_restore进行恢复。

1.错误信息

我们看到虽然list backup可以显示备份集,但是无法进行恢复,错误为RMAN-06026,RMAN-06026。

[oracle@jumper oradata]$ rman target /

Recovery Manager: Release 9.2.0.4.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: CONNER (DBID=3152029224)

RMAN> restore database;

Starting restore at 11-JUN-05

using target database controlfile instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=11 devtype=DISK

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

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

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

RMAN-03002: failure of restore command at 06/11/2005 01:19:01

RMAN-06026: some targets not found - aborting restore

RMAN-06023: no backup or copy of datafile 3 found to restore

RMAN-06023: no backup or copy of datafile 2 found to restore

RMAN-06023: no backup or copy of datafile 1 found to restore

RMAN> list backup;

List of Backup Sets

===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

13 Full 1G DISK 00:03:20 09-JUN-05

BP Key: 13 Status: AVAILABLE Tag: TAG20050609T173346

Piece Name: /opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1

SPFILE Included: Modification time: 08-JUN-05

List of Datafiles in backup set 13

File LV Type Ckp SCN Ckp Time Name

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

1 Full 240560269 09-JUN-05 /opt/oracle/oradata/conner/system01.dbf

2 Full 240560269 09-JUN-05 /opt/oracle/oradata/conner/undotbs01.dbf

3 Full 240560269 09-JUN-05 /opt/oracle/oradata/conner/users01.dbf

RMAN> exit

Recovery Manager complete.

2.使用dbms_backup_restore进行恢复

dbms_backup_restore是一个非常强大的package,可以在数据库nomount下使用,用于从备份集中读取各类文件。

本例使用如下脚本:

DECLARE

devtype varchar2(256);

done boolean;

BEGIN

devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');

sys.dbms_backup_restore.restoreSetDatafile;

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'/opt/oracle/oradata/conner/system01.dbf');

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'/opt/oracle/oradata/conner/undotbs01.dbf');

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'/opt/oracle/oradata/conner/users01.dbf');

sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'/opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1', params=>null);

sys.dbms_backup_restore.deviceDeallocate;

END;

/

3.执行恢复

[oracle@jumper conner]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Sat Jun 11 01:24:34 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup nomount;

ORACLE instance started.

Total System Global Area 101782828 bytes

Fixed Size 451884 bytes

Variable Size 37748736 bytes

Database Buffers 62914560 bytes

Redo Buffers 667648 bytes

SQL> DECLARE

2 devtype varchar2(256);

3 done boolean;

4 BEGIN

5 devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');

6 sys.dbms_backup_restore.restoreSetDatafile;

7 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'/opt/oracle/oradata/conner/system01.dbf');

8 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'/opt/oracle/oradata/conner/undotbs01.dbf');

9 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'/opt/oracle/oradata/conner/users01.dbf');

10 sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'/opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1',

params=>null);

11 sys.dbms_backup_restore.deviceDeallocate;

12 END;

13 /

PL/SQL procedure successfully completed.

SQL>

至此,从备份集中读取文件完毕。

4.恢复控制文件

由于大意,也没有备份控制文件,所以只好重建控制文件。

SQL> alter database mount;

Database altered.

SQL> alter database backup controlfile to trace;

Database altered.

找到trace文件,编辑、执行重建控制文件需要部分:

[oracle@jumper oracle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Sat Jun 11 01:30:50 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning option

JServer Release 9.2.0.4.0 - Production

SQL> shutdown immediate;

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

SQL> startup nomount;

ORACLE instance started.

Total System Global Area 101782828 bytes

Fixed Size 451884 bytes

Variable Size 37748736 bytes

Database Buffers 62914560 bytes

Redo Buffers 667648 bytes

SQL> set echo on

SQL> @ctl

SQL>

SQL> CREATE CONTROLFILE REUSE DATABASE "CONNER" RESETLOGS ARCHIVELOG

2 -- SET STANDBY TO MAXIMIZE PERFORMANCE

3 MAXLOGFILES 5

4 MAXLOGMEMBERS 3

5 MAXDATAFILES 100

6 MAXINSTANCES 1

7 MAXLOGHISTORY 1361

8 LOGFILE

9 GROUP 1 '/opt/oracle/oradata/conner/redo01.log' SIZE 10M,

10 GROUP 2 '/opt/oracle/oradata/conner/redo02.log' SIZE 10M,

11 GROUP 3 '/opt/oracle/oradata/conner/redo03.log' SIZE 10M

12 -- STANDBY LOGFILE

13 DATAFILE

14 '/opt/oracle/oradata/conner/system01.dbf',

15 '/opt/oracle/oradata/conner/undotbs01.dbf',

16 '/opt/oracle/oradata/conner/users01.dbf'

17 CHARACTER SET ZHS16GBK

18 ;

Control file created.

5.执行恢复

SQL> recover database;

ORA-00283: recovery session canceled due to errors

ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 240560269 generated at 06/09/2005 17:33:48 needed for thread 1

ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_7.dbf

ORA-00280: change 240560269 for thread 1 is in sequence #7

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 240600632 generated at 06/10/2005 10:42:26 needed for thread 1

ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_8.dbf

ORA-00280: change 240600632 for thread 1 is in sequence #8

ORA-00278: log file '/opt/oracle/oradata/conner/archive/1_7.dbf' no longer needed for this recovery

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 240620884 generated at 06/10/2005 10:45:42 needed for thread 1

ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_9.dbf

ORA-00280: change 240620884 for thread 1 is in sequence #9

ORA-00278: log file '/opt/oracle/oradata/conner/archive/1_8.dbf' no longer needed for this recovery

ORA-00283: recovery session canceled due to errors

ORA-00600: internal error code, arguments: [3020], [4242465], [1], [9], [314], [272], [], []

ORA-10567: Redo is inconsistent with data block (file# 1, block# 48161)

ORA-10564: tablespace SYSTEM

ORA-01110: data file 1: '/opt/oracle/oradata/conner/system01.dbf'

ORA-10560: block type 'DATA SEGMENT HEADER - UNLIMITED'

ORA-01112: media recovery not started

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 240620949 generated at 06/10/2005 10:45:44 needed for thread 1

ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_9.dbf

ORA-00280: change 240620949 for thread 1 is in sequence #9

Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

Media recovery cancelled.

SQL> alter database open resetlogs;

Database altered.

SQL> select name from v$datafile;

NAME

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

/opt/oracle/oradata/conner/system01.dbf

/opt/oracle/oradata/conner/undotbs01.dbf

/opt/oracle/oradata/conner/users01.dbf

SQL>

至此恢复完毕。

历史上的今天...

>>

2012-06-11文章:

2011-06-11文章:

2009-06-11文章:

2008-06-11文章:

2007-06-11文章:

2006-06-11文章:

By eygle on 2005-06-11 09:01 |

Comments (19) |

Backup&Recovery | 304 |

19 Comments

"......resetlogs之后,Oracle使用当前的控制文件不允许从这个历史备份集中进行恢复...."

如果在rman备份是同时备份了控制文件。在恢复时,先从mrna备份集中恢复控制文件,然后在恢复数据库可以吗?

我做过试验,数据库在非归档模式下,rman全备数据库,控制文件自动备份,后来进行了一次不完全恢复。把数据库恢复到备份的状态。

一段时间后,我再进行恢复,先是恢复控制文件,然后再restore database,提示出错。出错信息和上面第一个黑图表示的错误以信息一样

谢谢

在resetlogs之后,数据库会修改备份的控制文件c-1956347324-20051219-00? 我只看到文件的修改时间变成open resetlogs的时间,但是修改哪些信息?

在非归档模式下用c-1956347324-20051219-00再次恢复控制文件,然后再restore database可以

再归档模式下用c-1956347324-20051219-00再次恢复的控制文件,然后再restore database会报错

我这个试验,测试的环境在于:

丢失了控制文件,这样就备份集的欣喜就不可知,所以没有办法使用常规手段恢复。

如果拥有控制文件,控制文件包好备份集信息,那么就不用如此麻烦了。

其实我想问大师你的是,

在resetlogs之后,数据库会修改备份的控制文件c-1956347324-20051219-00? 我只看到文件的修改时间变成open resetlogs的时间,但是修改哪些信息?

大师如果有空的话,还请指点一下.

这个c-1956347324-20051219-00是控制文件自动备份产生的,在数据库发生文件增删等动作时都会产生。

这个是自动备份的,而不是去更新的。

参考:

http://www.eygle.com/faq/Oracle9i.New.Feature.Spfile.04.htm

如果使用了catalog那么就简单,用RESET DATABASE TO INCARNATION ... 来恢复到正确的incarnation,然后备份文件就可以用了。如果没有用catalog,除了恢复数据文件外,也可以考虑先DBMS_BACKUP_RESTORE恢复正确的控制文件,然后再恢复正确的INCARNATION

由于大意,也没有备份控制文件,所以只好重建控制文件。

SQL> alter database mount;

Database altered.

SQL> alter database backup controlfile to trace;

Database altered.

这个操作是从别的库作的吗?当前库不是起不来吗?

我做实验怎么经常出现这个错误啊,我可是啥也没做

就直接backup database force,然后一步步恢复到异机

我在做restore database时,报下面的错误:

RMAN> restore database;

启动 restore 于 2008-06-04 20:03:29

使用通道 ORA_DISK_1

RMAN-06026: 有些目标没有找到 - 终止恢复

RMAN-06023: 没有找到数据文件4的副本来恢复

RMAN-06023: 没有找到数据文件3的副本来恢复

RMAN-06023: 没有找到数据文件2的副本来恢复

RMAN-06023: 没有找到数据文件1的副本来恢复

在nomount模式下,运行下面的脚本:

DECLARE

devtype varchar2(256);

done boolean;

BEGIN

devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');

sys.dbms_backup_restore.restoreSetDatafile;

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'D:\primary\system01.dbf');

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'D:\primary\undotbs01.dbf');

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'D:\primary\users01.dbf');

sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'D:\primary\0ggmiabq_1_1', params=>null);

sys.dbms_backup_restore.deviceDeallocate;

END;

结果显示:

*

第 1 行出现错误:

ORA-19568: ?????????

ORA-06512: ? "SYS.X$DBMS_BACKUP_RESTORE", line 173

ORA-06512: ? "SYS.X$DBMS_BACKUP_RESTORE", line 148

ORA-06512: ? line 5

疑问?

1、toname的路径是不是另外指定的,还是原有数据文件的路径?

2、脚本运行为什么还会出错呢?

希望能得到指点,谢谢!

我晕,做为新手,体谅一把,哈哈

ORA-19568: a device is already allocated to this session

Cause: A device cannot be allocated to a session if another device is already allocated.

Action: Deallocate the current device

Device分配过了,退出从来!

我也有这个问题,后来查明原因,是因为联机备份我没有备份归档日志,后来备份了归档日志,重新恢复就搞定了,呵呵。

我也有这个问题,后来查明原因,是因为联机备份我没有备份归档日志,后来备份了归档日志,重新恢复就搞定了,呵呵。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值