此帖子已超过 5 年
181 消息
0
6345
Networker备份Oracle出现错误“NOARCHIVELOG 模式下的手动归档必须标识日志“
使用的是向导创建client，选得是Typical scheduled backup一路默认配置，
备份时候出现错误，日志如下，是什么问题啊？
suppressed 613 bytes of output.
RMAN> connect *********
2>
3> RUN {
4> ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE';
5> BACKUP
6> FULL
7> FORMAT '%d_%U'
8> DATABASE
9> INCLUDE CURRENT CONTROLFILE
10> PLUS ARCHIVELOG
11> ;
12> RELEASE CHANNEL CH1;
13> }
14>
连接到目标数据库: BFSSERVE (DBID=4152992018)
使用目标数据库控制文件替代恢复目录
分配的通道: CH1
通道 CH1: SID=82 设备类型=SBT_TAPE
通道CH1: NMDA Oracle v1.2.0
向通道发命令: CH1
启动 backup 于 23-11月-13
来自目标数据库的 ORACLE 错误:
ORA-00258: NOARCHIVELOG 模式下的手动归档必须标识日志
说明与资料档案库中的任何归档日志都不匹配
由于没有要备份的文件而取消了备份
完成 backup 于 23-11月-13
启动 backup 于 23-11月-13
通道 CH1: 正在启动全部数据文件备份集
通道 CH1粗苹疃募?
继续执行其他作业步骤, 将不重新运行失败的作业
通道 CH1: 正在启动全部数据文件备份集
通道 CH1: 正在指定备份集内的数据文件
备份集内包括当前控制文件
备份集内包括当前的 SPFILE
通道 CH1: 正在启动段 1 于 23-11月-13
通道 CH1: 已完成段 1 于 23-11月-13
段句柄=BFSSERVE_0gopm08p_1_1 标记=TAG20131123T101904 注释=API Version 2.0,MMS Version 1.2.0.0
通道 CH1: 备份集已完成, 经过时间:00:00:07
释放的通道: CH1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: backup plus archivelog 命令 (在 11/23/2013 10:19:13 上) 失败
RMAN-03009: backup 命令 (CH1 通道上, 在 11/23/2013 10:19:05 上) 失败
ORA-19602: 无法按 NOARCHIVELOG 模式备份或复制活动文件
恢复管理器完成。
The backup process failed:
RMAN exited with return code '1'.
Exiting with error:
RMAN exited with return code '1'.
sfhdmis10: RMAN exited with return code '1'.
Unable to find any full backups of the save set 'sfhdmis10:RMAN:\bfsserver_FULL' in the media database. Performing a full backup.
sfhdmis10:RMAN:\bfsserver_FULL: retried 1 times.
born_chen
1.8K 消息
0
2013年11月22日 21:00
LZ，首先您的这个问题已经解决。另外再补充下，主流、常规备份软件进行备份的时候，是必须开启数据库的归档的。
建议在对重要生产主机执行备份的时候能把这些准备的内容了解清楚先，因为可能涉及到数据库重启等。
duron64
181 消息
0
2013年11月22日 19:00
果然，设置为归档模式后，问题解决，备份成功。
度娘了一下：
数据库使用归档方式运行时才可以进行灾难性恢复。
1.归档日志模式和非归档日志模式的区别
非归档模式只能做冷备份,并且恢复时只能做完全备份.最近一次完全备份到系统出错期间的数据不能恢复.
归档模式可以做热备份,并且可以做增量备份,可以做部分恢复.
用ARCHIVE LOG LIST 可以查看当前模式状态是归档模式还是非归档模式.
duron64
181 消息
0
2013年11月22日 19:00
应该是把Oracle设置为归档模式就可以了吧，我先试试
duron64
181 消息
0
2013年11月22日 22:00
除了数据库的归档以外，一般还需要了解哪些内容啊？
duron64
181 消息
0
2013年11月22日 23:00
继续提问：
问题1、恢复的时候是在client端networker user选择存储集恢复吗？
问题2 存储集的名字是不规则的，如何判别是数据库中的哪个实例？
问题3、点击确定恢复后，貌似没成功，在Oracle数据库修改的还是没还原回来。 networker user日志如下，是否有问题？
Ř 正在从服务器“10.237.49.121”中恢复客户机“sfhdmis10”的文件。
正在将文件恢复到其原始位置。
Recover start time: 2013/11/23 15:08:57
正在从服务器请求 1 个恢复会话。
从 NSR 服务器"10.237.49.121"收到 0 个匹配的文件
恢复完成时间：2013/11/23 15:09:01
duron64
181 消息
0
2013年11月23日 00:00
帮忙救命啊
继续： 换了在NMC右键Oracle服务器选择恢复，使用向导创建好脚本，然后在client端使用命令rman cmdfile:/xxx log=xxx.log来恢复，还是提示错误，如下。
上网找了下，说是增量恢复要设置为mount状态（但我使用向导创建的oracle备份是全备），有没有其他解决办法？
---------------------
MAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: restore 命令 (在 11/23/2013 16:01:31 上) 失败
ORA-19870: 还原备份片段 BFSSERVE_0uopmf2u_1_1 时出错
ORA-19573: 无法获得 exclusive 入队 (数据文件 5 的)
Yanhong1
1.6K 消息
0
2013年11月23日 00:00
周末还在认真研究
赞一个
liulei_it
3.2K 消息
0
2013年11月23日 02:00
这说明您之前的备份没有成功耶
duron64
181 消息
0
2013年11月23日 04:00
但是备份完后没有错误的警告啊
liulei_it
3.2K 消息
1
2013年11月24日 16:00
首先，如果你的数据库是10g及以上那么可以尝试使用flash back功能，不一定非得使用Rman进行恢复。你现在用的是测试库吧，一般最好在异地恢复数据。
还有一种比较可行的办法是直接从命令行运行rman脚本，由于你的这个数据库是通过networker集成备份数据库的，那么直接使用rman命令将会自动调用networker进行恢复。偶这边用的是HP的DP，你要把networker的rman脚本格式给弄清楚，然后可以按照这个自己编写脚本运行下。以下demo是按照DP的格式，需要修改。
run {
allocate channel 'dev_1' type 'sbt_tape';
allocate channel 'dev_2' type 'sbt_tape';
allocate channel 'dev_3' type 'sbt_tape';
allocate channel 'dev_4' type 'sbt_tape';
SET UNTIL TIME = '2004-09-26:17:43:42';
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}
born_chen
1.8K 消息
0
2013年11月24日 17:00
能看到自动产生的自动脚本的内容么？
o17Uu33DCF12520
1.1K 消息
0
2013年11月25日 00:00
问题1、恢复的时候是在client端networker user选择存储集恢复吗？
是的
问题2 存储集的名字是不规则的，如何判别是数据库中的哪个实例？
BFSSERVE不是你的实例名么？
问题3、点击确定恢复后，貌似没成功，在Oracle数据库修改的还是没还原回来。 networker user日志如下，是否有问题？
Ř 正在从服务器“10.237.49.121”中恢复客户机“sfhdmis10”的文件。
正在将文件恢复到其原始位置。
Recover start time: 2013/11/23 15:08:57
正在从服务器请求 1 个恢复会话。
从 NSR 服务器"10.237.49.121"收到 0 个匹配的文件
恢复完成时间：2013/11/23 15:09:01
貌似没有文件可以恢复。
duron64
181 消息
0
2013年11月25日 06:00
再次备份和恢复了下，备份和恢复都没有错误提示，但查看数据库 被删除的内容还是没有找回来，这点比较头疼
我的操作步骤如下：
1、使用向导创建client，选得是Typical scheduled backup一路默认配置。
2、运行Group，执行备份。
3、修改数据库，对其中的表做删除几条。
4、使用向导创建还原脚本，然后Oracle设置为mount模式，使用rman cmdfile=e:/Oracle log=e:/log.log命令还原
5、Oracle设置为open，再检查恢复情况。
恢复的日志如下：
恢复管理器: Release 11.2.0.1.0 - Production on 星期一 11月 25 15:48:31 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN> connect target *
2>
3> RUN {
4>
5> ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE';
6> ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE';
7> ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE';
8> ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE';
9>
10> SEND 'NSR_ENV=(NSR_SERVER=sfhdcz01,
11> NSR_CLIENT=sfhdmis10)';
12>
13> restore database;
14>
15> recover database;
16>
17> RELEASE CHANNEL CH1;
18> RELEASE CHANNEL CH2;
19> RELEASE CHANNEL CH3;
20> RELEASE CHANNEL CH4;
21>
22> }
23>
24>
25>
26>
27>
28>
29>
30>
31>
32>
33>
34>
35>
36>
37>
38>
39>
已连接到目标数据库: BFSSERVE (DBID=4152992018, 未打开)
使用目标数据库控制文件替代恢复目录
分配的通道: CH1
通道 CH1: SID=129 设备类型=SBT_TAPE
通道CH1: NMDA Oracle v1.5.0
分配的通道: CH2
通道 CH2: SID=192 设备类型=SBT_TAPE
通道CH2: NMDA Oracle v1.5.0
分配的通道: CH3
通道 CH3: SID=6 设备类型=SBT_TAPE
通道CH3: NMDA Oracle v1.5.0
分配的通道: CH4
通道 CH4: SID=67 设备类型=SBT_TAPE
通道CH4: NMDA Oracle v1.5.0
向通道发命令: CH1
向通道发命令: CH2
向通道发命令: CH3
向通道发命令: CH4
启动 restore 于 25-11月-13
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00006 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\CDBFS.DBF
通道 CH1: 正在读取备份片段 zs_bk_64_1_20131125
通道 CH1: 段句柄 = zs_bk_64_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:45
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00007 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\NHBFS.DBF
通道 CH1: 正在读取备份片段 zs_bk_65_1_20131125
通道 CH1: 段句柄 = zs_bk_65_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:45
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00005 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\SFHD.DBF
通道 CH1: 正在读取备份片段 zs_bk_66_1_20131125
通道 CH1: 段句柄 = zs_bk_66_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:07
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00008 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\SFHDTEST.DBF
通道 CH1: 正在读取备份片段 zs_bk_67_1_20131125
通道 CH1: 段句柄 = zs_bk_67_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:15
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00001 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\SYSTEM01.DBF
通道 CH1: 正在读取备份片段 zs_bk_68_1_20131125
通道 CH1: 段句柄 = zs_bk_68_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:15
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00002 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\SYSAUX01.DBF
通道 CH1: 正在读取备份片段 zs_bk_69_1_20131125
通道 CH1: 段句柄 = zs_bk_69_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:15
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00003 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\UNDOTBS01.DBF
通道 CH1: 正在读取备份片段 zs_bk_70_1_20131125
通道 CH1: 段句柄 = zs_bk_70_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:07
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00009 还原到 E:\ORACLE\ORADATA\JMIS.ORA
通道 CH1: 正在读取备份片段 zs_bk_71_1_20131125
通道 CH1: 段句柄 = zs_bk_71_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:07
通道 CH1: 正在开始还原数据文件备份集
通道 CH1: 正在指定从备份集还原的数据文件
通道 CH1: 将数据文件 00004 还原到 E:\APP\ADMINISTRATOR\ORADATA\BFSSERVER\USERS01.DBF
通道 CH1: 正在读取备份片段 zs_bk_72_1_20131125
通道 CH1: 段句柄 = zs_bk_72_1_20131125 标记 = TAG20131125T104809
通道 CH1: 已还原备份片段 1
通道 CH1: 还原完成, 用时: 00:00:07
完成 restore 于 25-11月-13
启动 recover 于 25-11月-13
正在开始介质的恢复
介质恢复完成, 用时: 00:00:02
完成 recover 于 25-11月-13
释放的通道: CH1
释放的通道: CH2
释放的通道: CH3
释放的通道: CH4
恢复管理器完成。
duron64
181 消息
0
2013年11月25日 06:00
时间是看起来不大正常，虽然现在恢复的这个是测试数据库 数据量非常小。
但不知道从何排查，如果有error提示就好了
born_chen
1.8K 消息
0
2013年11月25日 06:00
recover 时间那么短的？2秒？