问题描述
I was in NOARCHIVE LOG mode and took 2 full backups including CONTROLFILE.
then i swithed to ARCHIVE LOG mode and did not take back.
I swithed log file and got one archived log file.
i shutdown the database.
lOST on of the control backup.
now i want to restore database back to the state when i took full backup in NOARCHIVE LOG.
follwing is what is am doing and still not succeding.
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
RMAN> show all;
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\SNCFORCL.ORA'; # default
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
7 Full 1.03G DISK 00:03:34 09-APR-17
BP Key: 7 Status: AVAILABLE Compressed: YES Tag: TAG20170409T214809
Piece Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2017_04_09\O1_MF_NNNDF_TAG20170409T214809_DGNSGD9Q_.BKP
List of Datafiles in backup set 7
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\SYSTEM01.DBF
2 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\SYSAUX01.DBF
3 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\UNDOTBS01.DBF
4 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\USERS01.DBF
5 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\EXAMPLE01.DBF
6 Full 25715406 09-APR-17 E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\MISC_DEPT.DAT
7 Full 25715406 09-APR-17 E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\MISC_DEPT1.DAT
8 Full 25715406 09-APR-17 E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\REG_ADMISSION1.DAT
9 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\FLOW_1044708261460507.DBF
10 Full 25715406 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\RECLAIM01.DBF
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
8 Full 1.05M DISK 00:00:00 09-APR-17
BP Key: 8 Status: AVAILABLE Compressed: YES Tag: TAG20170409T214809
Piece Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2017_04_09\O1_MF_NCSNF_TAG20170409T214809_DGNSO6VV_.BKP
SPFILE Included: Modification time: 09-APR-17
SPFILE db_unique_name: ORCL
Control File Included: Ckp SCN: 25715406 Ckp time: 09-APR-17
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
9 Full 1.03G DISK 00:00:00 09-APR-17
BP Key: 9 Status: AVAILABLE Compressed: YES Tag: TAG20170409T225442
Piece Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2017_04_09\O1_MF_NNNDF_TAG20170409T225442_DGNXC5G3_.BKP
List of Datafiles in backup set 9
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\SYSTEM01.DBF
2 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\SYSAUX01.DBF
3 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\UNDOTBS01.DBF
4 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\USERS01.DBF
5 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\EXAMPLE01.DBF
6 Full 25716894 09-APR-17 E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\MISC_DEPT.DAT
7 Full 25716894 09-APR-17 E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\MISC_DEPT1.DAT
8 Full 25716894 09-APR-17 E:\APP\FAHAD\PRODUCT\11.2.0\DBHOME_2\DATABASE\REG_ADMISSION1.DAT
9 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\FLOW_1044708261460507.DBF
10 Full 25716894 09-APR-17 E:\APP\FAHAD\ORADATA\ORCL\RECLAIM01.DBF
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 1071333376 bytes
Fixed Size 1375792 bytes
Variable Size 830472656 bytes
Database Buffers 234881024 bytes
Redo Buffers 4603904 bytes
RMAN> restore controlfile from 'E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2017_04_09\O1_MF_NCSNF_TAG20170409T214809_DGNSO6VV
_.BKP';
Starting restore at 10-APR-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=63 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=E:\APP\FAHAD\ORADATA\ORCL\CONTROL01.CTL
output file name=E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\CONTROL02.CTL
Finished restore at 10-APR-17
RMAN> startup mount;
database is already started
database mounted
released channel: ORA_DISK_1
RMAN> restore database from tag 'TAG20170409T214809';
Starting restore at 10-APR-17
Starting implicit crosscheck backup at 10-APR-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=191 device type=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 10-APR-17
Starting implicit crosscheck copy at 10-APR-17
using channel ORA_DISK_1
Finished implicit crosscheck copy at 10-APR-17
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2017_04_10\O1_MF_1_1_DGOW16P0_.ARC
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2017_04_09\O1_MF_S_940891596_DGNXLVVK_.BKP
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2017_04_09\O1_MF_S_940891596_DGNYRCFY_.BKP
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2017_04_09\O1_MF_S_940891596_DGNYRRDX_.BKP
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2017_04_09\O1_MF_S_940891596_DGNYRY1S_.BKP
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2017_04_09\O1_MF_NCSNF_TAG20170409T214809_DGNSO6VV_.BKP
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2017_04_09\O1_MF_NNNDF_TAG20170409T225442_DGNXC5G3_.BKP
File Name: E:\APP\FAHAD\FLASH_RECOVERY_AREA\ORCL\CONTROL02_hold.CTL
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/10/2017 11:41:30
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 10 found to restore
RMAN-06023: no backup or copy of datafile 9 found to restore
RMAN-06023: no backup or copy of datafile 8 found to restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to 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
专家解答
看起来您正在使用闪存恢复区域。当您恢复旧的控制文件时,我们会 * 自动 * 查看FRA (请参见上面的 “隐式” 消息)。
因此,现在新还原的controlfile属于 * current * 数据库,而不是备份时的状态。
MOS note 965122.1谈论如何解决这个问题
===========================
在本文档中
症状
更改
原因
解决方案
参考文献
适用于:
Oracle数据库-企业版-版本10.1.0.2至11.2.0.3 [版本10.1至11.2]
本文档中的信息适用于任何平台。
*** 在10-12月-2015上检查相关性 ***
症状
从备份或使用备份控制文件启动数据库成功还原控制文件后,RMAN还原数据库命令失败,出现以下情况:
RMAN-00571: =
RMAN-00569: =
RMAN-00571: =
RMAN-03002: 11/11/2009 15:09恢复命令失败: 3
RMAN-06026: 一些目标未找到-中止恢复
....
RMAN-06023: 未找到要还原的数据文件3的备份或副本
RMAN-06023: 未找到要还原的数据文件2的备份或副本
RMAN-06023: 未找到要还原的数据文件1的备份或副本
在RMAN目录中,我们可以看到有可用的数据库备份。
更改
无
原因
这里的问题是,闪存恢复区域中有一些文件属于与可用备份当前版本不同的版本。
如果我们使用备份控制文件启动还原数据库,并且定义了闪存恢复区域,则RMAN执行和隐式交叉检查以及闪存恢复区域中所有对象的目录。
我们可以在rman脚本中看到类似的消息:
从11-2009 15:09:27开始还原
在11-2009 15:09:27启动隐式交叉检查备份
在11-2009 15:09:30完成隐式交叉检查备份
在11-2009 15:09:30开始隐式交叉检查副本
在11-2009 15:09:30完成隐式交叉检查副本
搜索恢复区域中的所有文件
编目文件...
编目完成
编目文件列表
=
文件1
文件2
...等等
RMAN将对闪存恢复区域中任何不会在控制文件中注册的对象进行编录,如果这些文件中的任何一个属于与控制文件中的当前化身不同的化身,则将控制文件的当前化身更改为正在编录的文件中找到的对象。
这可以防止数据库还原属于旧的当前版本的备份。
如果controlfile中的备份化身和当前化身相同,RMAN认为可以恢复备份。
我们可以用命令检查是否没有属于当前化身的备份:
RMAN> 列表备份可恢复;
此命令仅显示当前化身可用备份
解决方案
有两种方法可以解决此问题:
如果有问题的编目文件很少,那么我们可以将这些文件移动到闪存恢复区域之外的目录中,那么我们需要重新启动整个还原过程。有必要再次恢复控制文件
另一种解决方案是在还原和恢复命令的持续时间内暂时禁用闪存恢复区域的使用。
要禁用闪存恢复区域,您需要未定义db_recovery_file_dest:
2.1。生成一个init.ora文件:
SQL> 从spfile创建pfile;
2.2编辑init.ora并注释db_recovery_file_dest条目
# *.db_recovery_file_dest = '<目录>'
# *.db_recovery_file_dest_size =
2.3 Bounce数据库
SQL> 关机;
SQL> 启动nomount pfile = '....init.ora'
2.4重新启动还原控制文件,然后恢复/恢复数据库命令。
如果在Flash恢复区域中有一些备份或归档日志需要进行分类,则有必要使用以下命令手动对它们进行分类: 目录备份或目录归档日志命令
======================
因此,现在新还原的controlfile属于 * current * 数据库,而不是备份时的状态。
MOS note 965122.1谈论如何解决这个问题
===========================
在本文档中
症状
更改
原因
解决方案
参考文献
适用于:
Oracle数据库-企业版-版本10.1.0.2至11.2.0.3 [版本10.1至11.2]
本文档中的信息适用于任何平台。
*** 在10-12月-2015上检查相关性 ***
症状
从备份或使用备份控制文件启动数据库成功还原控制文件后,RMAN还原数据库命令失败,出现以下情况:
RMAN-00571: =
RMAN-00569: =
RMAN-00571: =
RMAN-03002: 11/11/2009 15:09恢复命令失败: 3
RMAN-06026: 一些目标未找到-中止恢复
....
RMAN-06023: 未找到要还原的数据文件3的备份或副本
RMAN-06023: 未找到要还原的数据文件2的备份或副本
RMAN-06023: 未找到要还原的数据文件1的备份或副本
在RMAN目录中,我们可以看到有可用的数据库备份。
更改
无
原因
这里的问题是,闪存恢复区域中有一些文件属于与可用备份当前版本不同的版本。
如果我们使用备份控制文件启动还原数据库,并且定义了闪存恢复区域,则RMAN执行和隐式交叉检查以及闪存恢复区域中所有对象的目录。
我们可以在rman脚本中看到类似的消息:
从11-2009 15:09:27开始还原
在11-2009 15:09:27启动隐式交叉检查备份
在11-2009 15:09:30完成隐式交叉检查备份
在11-2009 15:09:30开始隐式交叉检查副本
在11-2009 15:09:30完成隐式交叉检查副本
搜索恢复区域中的所有文件
编目文件...
编目完成
编目文件列表
=
文件1
文件2
...等等
RMAN将对闪存恢复区域中任何不会在控制文件中注册的对象进行编录,如果这些文件中的任何一个属于与控制文件中的当前化身不同的化身,则将控制文件的当前化身更改为正在编录的文件中找到的对象。
这可以防止数据库还原属于旧的当前版本的备份。
如果controlfile中的备份化身和当前化身相同,RMAN认为可以恢复备份。
我们可以用命令检查是否没有属于当前化身的备份:
RMAN> 列表备份可恢复;
此命令仅显示当前化身可用备份
解决方案
有两种方法可以解决此问题:
如果有问题的编目文件很少,那么我们可以将这些文件移动到闪存恢复区域之外的目录中,那么我们需要重新启动整个还原过程。有必要再次恢复控制文件
另一种解决方案是在还原和恢复命令的持续时间内暂时禁用闪存恢复区域的使用。
要禁用闪存恢复区域,您需要未定义db_recovery_file_dest:
2.1。生成一个init.ora文件:
SQL> 从spfile创建pfile;
2.2编辑init.ora并注释db_recovery_file_dest条目
# *.db_recovery_file_dest = '<目录>'
# *.db_recovery_file_dest_size =
2.3 Bounce数据库
SQL> 关机;
SQL> 启动nomount pfile = '....init.ora'
2.4重新启动还原控制文件,然后恢复/恢复数据库命令。
如果在Flash恢复区域中有一些备份或归档日志需要进行分类,则有必要使用以下命令手动对它们进行分类: 目录备份或目录归档日志命令
======================
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




