« 如何使用Oracle全文检索功能? | Blog首页 | 使用dbv和RMAN检查数据文件中的坏块 »
应对RMAN-06026错误,使用dbms_backup_restore进行恢复
作者:eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接:https://www.eygle.com/archives/2005/06/oorman06026iioe.html
昨天做一个实验,结果把数据库搞坏了,当试图进行恢复时居然报了RMAN-06026错误。
回想一下,原来在尝试恢复中使用了_allow_resetlogs_corruption参数,resetlogs之后,Oracle使用当前的控制文件不允许从这个历史备份集中进行恢复。链接:https://www.eygle.com/archives/2005/06/oorman06026iioe.html
由于我没有使用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.恢复控制文件
由于大意,也没有备份控制文件,所以只好重建控制文件。
找到trace文件,编辑、执行重建控制文件需要部分:
5.执行恢复
至此恢复完毕。
历史上的今天...
>> 2012-06-11文章:
>> 2011-06-11文章:
>> 2009-06-11文章:
>> 2008-06-11文章:
>> 2007-06-11文章:
>> 2006-06-11文章:
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: { |
至此恢复完毕。
历史上的今天...
>> 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 |
"......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.
这个操作是从别的库作的吗?当前库不是起不来吗?
Mount和Open是两个概念阿!
您的意思是当前的库是可以mount的?
当然是可以Mount的。
这是怎么回事啊
没有控制文件也能mount?
楼上的要仔细看!
我做实验怎么经常出现这个错误啊,我可是啥也没做
就直接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分配过了,退出从来!
我也有这个问题,后来查明原因,是因为联机备份我没有备份归档日志,后来备份了归档日志,重新恢复就搞定了,呵呵。
我也有这个问题,后来查明原因,是因为联机备份我没有备份归档日志,后来备份了归档日志,重新恢复就搞定了,呵呵。