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

 

RMAN 的备份信息如下:

 

RMAN> list backupset summary;

List of Backups

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

Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

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

9   b  1  a disk    01-jun-11       1       1       no         dave_lev1

10  b  1  a disk    01-jun-11       1       1       no         dave_lev1

13  b  a  a disk    01-jun-11       1       1       no         arc_bak

14  b  a  a disk    01-jun-11       1       1       no         arc_bak

15  b  a  a disk    01-jun-11       1       1       no         arc_bak

16  b  a  a disk    01-jun-11       1       1       no         arc_bak

17   b  a  a disk   01-jun-11       1       1       no         arc_bak

18   b  a  a disk   01-jun-11       1       1       no         arc_bak

19   b  a  a disk   01-jun-11       1       1       no         arc_bak

20   b  a  a disk   01-jun-11       1       1       no         arc_bak

21   b  a  a disk   01-jun-11       1       1       no         arc_bak

22  b  f  a disk    01-jun-11       1       1       no         bak_ctlfile

23  b  f  a disk    01-jun-11       1       1       no         spfile

 

RMAN> crosscheck backup;

 

using channel ORA_DISK_1

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/dave_lev1_0cmdpuof_1_1_20110601 recid=9 stamp=752679695

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/dave_lev1_0bmdpuoe_1_1_20110601 recid=10 stamp=752679695

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0fmdpven_1_1_20110601 recid=13 stamp=752680408

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0gmdpven_1_1_20110601 recid=14 stamp=752680422

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0hmdpvj4_1_1_20110601 recid=15 stamp=752680549

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0imdpvj5_1_1_20110601 recid=16 stamp=752680582

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0jmdpvo4_1_1_20110601 recid=17 stamp=752680709

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0kmdpvo5_1_1_20110601 recid=18 stamp=752680721

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0mmdpvss_1_1_20110601 recid=19 stamp=752680863

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0lmdpvsr_1_1_20110601 recid=20 stamp=752680860

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/arch_0nmdpvv0_1_1_20110601 recid=21 stamp=752680929

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/ctl_file_0omdpvv7_1_1_20110601 recid=22 stamp=752680937

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/u01/backup/dave_spfile_0pmdpvva_1_1_20110601 recid=23 stamp=752680939

Crosschecked 13 objects

 

 

但是restore validate的时候, 报错:

 

RMAN> restore database validate;

 

Starting restore at 01-JUN-11

using channel ORA_DISK_1

 

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

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

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

RMAN-03002: failure of restore command at 06/01/2011 21:21:28

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

 

一般来说,遇到这种问题是因为控制过旧,即控制文件中没有备份的信息。

 

比如在nocatalog模式下,备份数据文件之前,先备份控制文件,然后在备份数据库。 在还原的时候,先还原还原控制文件,此时的控制文件中并没有包含RMAN 备份的信息,这时进行恢复就会遇到RMAN-06023 的错误。 但我这里控制文件没有修改。  所以不是这个原因造成。

 

google 一下。 有网友通过以下几种方法解决了这个问题:

       1. shutdown abort

       2. crosscheck backup

       3 设置 DBID

       4. 重建UNDO Tablespace

 

       这几种方法是问题的一方面,不过我遇到的情况还有一个特殊性。 就是我的RMAN 采用了增量备份,但是我没有做0级备份,而是直接用1级备份。 这种情况下,RMAN 发现没有0级备份,所以此时的1级备份也相当于0级备份。

 

 

尝试重新做了一次0级备份,在次validate,居然ok了。

 

RMAN> RESTORE DATABASE VALIDATE;

 

Starting restore at 01-JUN-11

using channel ORA_DISK_1

 

channel ORA_DISK_1: starting validation of datafile backupset

channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev0_10mdqqtd_1_1_20110601

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/backup/dave_lev0_10mdqqtd_1_1_20110601 tag=DAVE_LEV0

channel ORA_DISK_1: validation complete, elapsed time: 00:00:07

channel ORA_DISK_1: starting validation of datafile backupset

channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev0_0vmdqqtd_1_1_20110601

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/backup/dave_lev0_0vmdqqtd_1_1_20110601 tag=DAVE_LEV0

channel ORA_DISK_1: validation complete, elapsed time: 00:00:15

Finished restore at 01-JUN-11

 

 

       正常情况下直接进行1级备份也是可以进行恢复的。 所以不应该出现这种问题。 所以在进行一次测试,就是使用1级备份进行恢复,看这种备份能否正常用于恢复。

 

       到另一台单实例测试库上进行一下测试。 上面这台是我的RAC 测试库,折腾坏了,一时也没空去捣鼓。

 

备份脚本参考:

       Nocatalog 下的RMAN 增量备份 shell脚本

       http://www.cndba.cn/Dave/article/1476

 

先做一个1级备份:

 

RMAN> list backup summary;

 

using target database control file instead of recovery catalog

 

List of Backups

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

key     ty lv s device type completion time #pieces #copies compressed tag

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

5   b  1  a disk    02-jun-11       1       1       no         dave_lev1

6   b  1  a disk    02-jun-11       1       1       no         dave_lev1

9   b  a  a disk    02-jun-11       1       1       no         arc_bak

10  b  a  a disk    02-jun-11       1       1       no         arc_bak

11  b  f  a disk    02-jun-11       1       1       no         bak_ctlfile

12  b  f  a disk    02-jun-11       1       1       no         spfile

 

restore 进行一次验证:

RMAN> restore database validate;

 

Starting restore at 02-JUN-11

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=148 devtype=DISK

 

channel ORA_DISK_1: starting validation of datafile backupset

channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev1_0amdrva4_1_1_20110602

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/backup/dave_lev1_0amdrva4_1_1_20110602 tag=DAVE_LEV1

channel ORA_DISK_1: validation complete, elapsed time: 00:00:08

channel ORA_DISK_1: starting validation of datafile backupset

channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev1_09mdrva3_1_1_20110602

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/backup/dave_lev1_09mdrva3_1_1_20110602 tag=DAVE_LEV1

channel ORA_DISK_1: validation complete, elapsed time: 00:00:16

Finished restore at 02-JUN-11

 

居然没有报错,灵异事件啊。

 

灵异就灵异吧,继续验证下这个1级备份的恢复问题。

 

 

 

RMAN> shutdown immediate

 

database closed

database dismounted

Oracle instance shut down

 

RMAN> startup mount;

 

connected to target database (not started)

Oracle instance started

database mounted

 

Total System Global Area     239075328 bytes

 

Fixed Size                     1218700 bytes

Variable Size                 83887988 bytes

Database Buffers             146800640 bytes

Redo Buffers                   7168000 bytes

 

RMAN> restore database;

 

Starting restore at 02-JUN-11

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=157 devtype=DISK

 

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00002 to /u01/app/oracle/oradata/dave1/undotbs01.dbf

restoring datafile 00003 to /u01/app/oracle/oradata/dave1/sysaux01.dbf

restoring datafile 00005 to /u01/app/oracle/oradata/dave1/example01.dbf

channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev1_0amdrva4_1_1_20110602

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/backup/dave_lev1_0amdrva4_1_1_20110602 tag=DAVE_LEV1

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

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /u01/app/oracle/oradata/dave1/system01.dbf

restoring datafile 00004 to /u01/app/oracle/oradata/dave1/users01.dbf

channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev1_09mdrva3_1_1_20110602

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/backup/dave_lev1_09mdrva3_1_1_20110602 tag=DAVE_LEV1

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

Finished restore at 02-JUN-11

 

RMAN> recover database;

 

Starting recover at 02-JUN-11

using channel ORA_DISK_1

 

starting media recovery

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

 

Finished recover at 02-JUN-11

 

RMAN> alter database open;

 

database opened

 

 

       这种1级备份可以用来恢复。之前还遇到过一次rman 过期备份集在自动备份脚本里用:         delete noprompt expired backup;      不能删除的问题。

      

       有遇到这种情况的同学也可以说说。

 

 

 

 

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

QQ:492913789

Email:ahdba@qq.com

Blog: http://www.cndba.cn/dave


DBA1 群:62697716();   DBA2 群:62697977()   DBA3 群:62697850()  

DBA 超级群:63306533();  DBA4 群: 83829929  DBA5群: 142216823   

DBA6 群:158654907  聊天 群:40132017   聊天2群:69087192

--加群需要在备注说明Oracle表空间和数据文件的关系,否则拒绝申请

<think>嗯,用户遇到了Oracle RMAN恢复时的报错组合,包含RMAN-03015、RMAN-06026和RMAN-06024。这些错误的核心是控制文件缺失备份,但用户提供的引用材料里还涉及数据文件备份缺失(RMAN-06023)和通道分配问题(RMAN-06100),需要整合分析。 从用户提供的引用文档看,关键线索有三个方向:首先是备份元数据与控制文件不一致(引用1的Doc ID 763703.1提到克隆环境问题),其次是通道配置错误可能导致RMAN无法访问备份(引用2的RMAN-06100),最后是备份验证命令的使用(引用3的list backup系列命令)。用户当前报错明确指向控制文件,应优先聚焦于此。 用户可能刚执行过类似"RESTORE CONTROLFILE"命令。深层需求其实是恢复整个数据库,但控制文件恢复失败导致后续步骤中断。需要引导用户先解决控制文件问题,再处理可能的其他文件缺失。 具体排查思路要分层:第一步验证备份是否存在(list backup),第二步检查恢复配置(通道分配、备份路径),第三步考虑特殊场景(如克隆环境)。引用文档中提到的"使用目标库控制文件替代恢复目录"的提示很重要,说明用户可能没使用恢复目录,这会影响备份可见性。 解决方案要强调操作顺序:先确认控制文件备份存在性,再检查设备类型匹配(磁盘备份用DISK通道,磁带用SBT)。用户引用材料里提到的"克隆主机"问题很关键,如果是从生产库克隆的测试库,备份路径不一致会导致RMAN找不到备份,这点必须包含在"特殊场景"里。 最后生成的问题要覆盖用户可能忽略的后续步骤,比如恢复控制文件后如何继续恢复数据库,以及如何避免类似问题——特别是备份策略的优化建议。用户没有提供数据库版本,但所有方案需保持通用性。</think>根据错误代码 `RMAN-03015`, `RMAN-06026`, `RMAN-06024` 的组合,核心问题是 **RMAN 找不到控制文件的备份集进行恢复**。以下是详细分析和解决方案: ### 错误原因分析 1. **RMAN-06024: no backup or copy of control file found to restore** * 根本原因:RMAN 在指定的备份位置(如快速恢复区、磁带或手动指定的路径)中**找不到有效的控制文件备份**。 2. **RMAN-06026: some targets not found - aborting restore** * 这是 `RMAN-06024` 的连锁反应。由于找不到控制文件备份,RMAN 中止了整个恢复操作。 3. **RMAN-03015: error occurred in stored script Memory Script** (如果存在) * 表明错误发生在 RMAN 运行的预定义脚本中,但根源仍是控制文件备份缺失。 ### 关键排查步骤与解决方案 #### ✅ 1. 确认控制文件备份是否存在 ```sql RMAN> LIST BACKUP OF CONTROLFILE; ``` * **无输出结果**:证明确实没有控制文件备份。跳到第 3 步。 * **有输出结果**:检查备份的 `Status` 是否为 `AVAILABLE`,备份片(`Piece Name`)所在的路径是否可访问,备份是否过期(`Keep` 状态)或被删除[^3]。 #### ✅ 2. 检查备份路径和通道配置 * **恢复目录/控制文件元数据**:RMAN 依赖控制文件或恢复目录中的元数据来定位备份。如果备份实际存在但元数据丢失/损坏,RMAN 会找不到备份。 * **通道配置**:确认 `RESTORE` 命令使用的 `CHANNEL` 设备类型(`DISK` 或 `SBT_TAPE`)与备份存储位置**一致**。磁盘备份需要 `DISK` 通道,磁带备份需要配置正确的磁带库驱动程序和 `SBT_TAPE` 通道[^2]。 * **备份路径可达性**:如果备份在磁盘上,确保数据库服务器 OS 用户(通常是 `oracle`)对备份文件及其目录有**读取权限**。使用 OS 命令(如 `ls -l`)验证。 #### ✅ 3. 创建新的控制文件备份 (如果确认缺失) 如果确认没有可用的控制文件备份,**必须立即创建**: ```sql RMAN> BACKUP CURRENT CONTROLFILE; ``` * 这将创建一个新的控制文件备份到配置的默认位置(通常是快速恢复区)。这是**最直接**的解决方法。 #### ✅ 4. 特殊场景:克隆环境或路径变更 (参考引用[^1]) * 如果数据库是从源库**克隆**到新主机,且恢复时使用的是**克隆库自身的控制文件**(而非源库的控制文件或恢复目录),那么控制文件中的备份元数据记录的仍是**源库的备份路径**。 * **解决方案**: 1. 将源库的备份文件**物理复制**到克隆库的相同路径下。 2. 或使用 `CATALOG` 命令将克隆库上的备份位置**重新注册**到当前控制文件: ```sql RMAN> CATALOG START WITH '/path/to/backups/on/cloned_host/'; ``` 3. 然后再次尝试 `LIST BACKUP OF CONTROLFILE;` 和 `RESTORE CONTROLFILE;`。 #### ✅ 5. 恢复操作的正确顺序 如果目标是恢复整个数据库,**必须先恢复控制文件**: ```sql RMAN> STARTUP NOMOUNT; -- 如果数据库未启动 RMAN> RESTORE CONTROLFILE; -- 关键步骤 RMAN> ALTER DATABASE MOUNT; -- 挂载新恢复的控制文件 RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN RESETLOGS; ``` ### 总结流程 1. **`LIST BACKUP OF CONTROLFILE;`** ➔ 确认备份存在性和状态。 2. 若备份存在但找不到: * 检查**通道配置**和设备类型匹配。 * 检查**备份路径权限**和可达性。 * 考虑**克隆环境路径问题**,使用 `CATALOG` 命令重新注册备份。 3. 若备份不存在: * **立即执行 `BACKUP CURRENT CONTROLFILE;`**。 4. 确保恢复操作顺序正确:`RESTORE CONTROLFILE` 必须在 `MOUNT` 数据库之前完成。 ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值