共计 5193 个字符，预计需要花费 13 分钟才能阅读完成。
一. 问题描述：
由于生产库的归档备份由原来的文件 copy 方式改成用 rman 来备份档档，需要验证用 rman 能否正常还原出归档，所以在一个正在运行的测试库上来用 rman 还原归档。
在测试库主机上执行如下操作：
connect target /
connect catalog xxx/xxx@rman_11g;
run {
allocate channel c1 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c2 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c3 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c4 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
set archivelog destination to ‘/pdm/pdmsitdata/arch’;
restore archivelog sequence between 126720 and 126723;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
RELEASE CHANNEL c3;
RELEASE CHANNEL c4;
}
报 RMAN-20242 错误：
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 09/22/2016 10:55:10
RMAN-06004: Oracle error from recovery catalog database: RMAN-20242: specification does not match any archived log in the repository
二. 问题分析
在生产库上查看归档备份情况：
再在生产库执行：list backup of archivelog sequence between 126720 and 126740;
能正常查出需要恢复的归档，如下：
List of Archived Logs in backup set 106409
Thrd Seq Low SCN Low Time Next SCN Next Time
—- ——- ———- ——— ———- ———
1 126720 13264625429179 19-SEP-16 13264630177490 19-SEP-16
1 126721 13264630177490 19-SEP-16 13264633856924 19-SEP-16
1 126722 13264633856924 19-SEP-16 13264635340090 19-SEP-16
1 126723 13264635340090 19-SEP-16 13264636569222 19-SEP-16
1 126724 13264636569222 19-SEP-16 13264641943880 19-SEP-16
1 126725 13264641943880 19-SEP-16 13264650066165 19-SEP-16
1 126726 13264650066165 19-SEP-16 13264651755964 19-SEP-16
1 126727 13264651755964 19-SEP-16 13264653095621 19-SEP-16
1 126728 13264653095621 19-SEP-16 13264659008880 19-SEP-16
1 126729 13264659008880 19-SEP-16 13264659625618 19-SEP-16
1 126730 13264659625618 19-SEP-16 13264670245642 19-SEP-16
1 126731 13264670245642 19-SEP-16 13264676059672 19-SEP-16
1 126732 13264676059672 19-SEP-16 13264682985578 19-SEP-16
1 126733 13264682985578 19-SEP-16 13264683740014 19-SEP-16
1 126734 13264683740014 19-SEP-16 13264692162926 19-SEP-16
1 126735 13264692162926 19-SEP-16 13264696780989 19-SEP-16
1 126736 13264696780989 19-SEP-16 13264697482819 19-SEP-16
1 126737 13264697482819 19-SEP-16 13264702234852 19-SEP-16
1 126738 13264702234852 19-SEP-16 13264706967875 19-SEP-16
1 126739 13264706967875 19-SEP-16 13264711260507 19-SEP-16
1 126740 13264711260507 19-SEP-16 13264716460619 20-SEP-16
说明备份是存在的。
用下面脚本按时间是可以正常还原归档，却用 sequence 方式报错。
connect target /
connect catalog xxx/xxx@rman_11g;
run {
allocate channel c1 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c2 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c3 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c4 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
set archivelog destination to ‘/pdm/pdmsitdata/arch’;
restore archivelog from time ‘sysdate-1’;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
RELEASE CHANNEL c3;
RELEASE CHANNEL c4;
}
resetlogs 后数据库数据文件中 RESETLOGS SCN 和 time stamps 发生变化，与之前的备份出来的 archivelog 的 SCN\time stamps 不一致。不能进行恢复。
三. 解决方法
在 restore 命令后加上 incaration all 后，可以正常还原。实际上在我们正常对测试环境进行覆盖时，不会遇到问题。
RMAN> connect target /
connect catalog xxx/xxx@rman_11g;
run {
allocate channel c1 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c2 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c3 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
allocate channel c4 TYPE ‘SBT_TAPE’ parms ‘ENV=(NSR_SERVER=mhpl800, NSR_CLIENT=msuu206)’;
set archivelog destination to ‘/pdm/pdmsitdata/arch’;
restore archivelog sequence between 126720 and 126723 INCARNATION ALL;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
RELEASE CHANNEL c3;
RELEASE CHANNEL c4;
}
connected to target database: PDMSIT (DBID=3424929568)
RMAN>
connected to recovery catalog database
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12>
allocated channel: c1
channel c1: SID=913 device type=SBT_TAPE
channel c1: NMDA Oracle v8.2.0
allocated channel: c2
channel c2: SID=937 device type=SBT_TAPE
channel c2: NMDA Oracle v8.2.0
allocated channel: c3
channel c3: SID=961 device type=SBT_TAPE
channel c3: NMDA Oracle v8.2.0
allocated channel: c4
channel c4: SID=985 device type=SBT_TAPE
channel c4: NMDA Oracle v8.2.0
executing command: SET ARCHIVELOG DESTINATION
Starting restore at 22-SEP-16
channel c1: starting archived log restore to user-specified destination
archived log destination=/pdm/pdmsitdata/arch
channel c1: restoring archived log
archived log thread=1 sequence=126720
channel c1: restoring archived log
archived log thread=1 sequence=126721
channel c1: restoring archived log
archived log thread=1 sequence=126722
channel c1: restoring archived log
archived log thread=1 sequence=126723
channel c1: reading from backup piece archlog_PDMDB_2krgboqv_1_1
channel c1: piece handle=archlog_PDMDB_2krgboqv_1_1 tag=TAG20160921T094602
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:08:25
Finished restore at 22-SEP-16
released channel: c1
released channel: c2
released channel: c3
released channel: c4
RMAN> exit
Recovery Manager complete.
l-bash-4.1$ ls -ltr
total 3927666
-rw-r—– 1 pdmsit dba 542332416 Sep 22 19:32 1_126722_814035104.dbf
-rw-r—– 1 pdmsit dba 490157568 Sep 22 19:35 1_126721_814035104.dbf
-rw-r—– 1 pdmsit dba 488429568 Sep 22 19:38 1_126723_814035104.dbf
-rw-r—– 1 pdmsit dba 488354816 Sep 22 19:38 1_126720_814035104.dbf
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-12/138201.htm
