你在这里

You are here:

首页

博客

PDSERVICE的博客

Oracle 在Duplicate … ‘backup location’时的RMAN-06136 ORA-01194 ORA-01110

Posted by PDSERVICE on 3月 22, 2016 In

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

[oracle@ocm_rac01 ~]$ oerr rman 6136
6136, 1, "ORACLE error from auxiliary database: %s"
// *Cause: This message should be accompanied by other error message(s)
// indicating the cause of the error.
// *Action: Check the accompanying errors.

适用于:

Oracle Database – Enterprise Edition – 版本 11.2.0.1 及以上
本文信息适用于任何平台。

症状

以’backup location’ 子句运行RMAN targetless duplicate ，返回错误：

RMAN-06136: ORACLE error from auxiliary database: ORA-01194: file X needs more recovery to be consistent
ORA-01110: data file X: ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX’

原因

在以’backup location’选项运行targetless duplicate时，RMAN不进行一致性检查。RMAN 假定需要在一致状态打开辅助数据库的所有备份都在指定的’backup location’中。RMAN会开始还原并通过可用的归档日志文件备份恢复。但是，当它尝试打开辅助数据库并发现数据库是非一致的，错误会被返回。

要确认你遇到该问题。在debug中运行RMAN duplicate ：

$ rman trace=debug_duplicate.trc log=rman_duplicate.log

RMAN> set echo on;
RMAN> connect auxiliary …
RMAN> debug on;
RMAN> duplicate ….
RMAN> debug off;

查看debug trace，我们看到与还原的数据文件相关的 ABSOLUTE FUZZY SCN。这是确保一致性的最小SCN。换句话说，必须恢复到提到的SCN来消除模糊性（fuzziness）。

RMAN-08161: contents of Memory Script:
{
set until scn 190220235785;

……. DBGRCVMAN: Datafile Copy
DBGRCVMAN: fileName=/u01/oradata/IBSOCHBT/datafile/undotbs1.283.765743847
DBGRCVMAN: media=
DBGRCVMAN: key=2 recid=2 stamp=829813564 status=A
DBGRCVMAN: compTime=26-OCT-13
DBGRCVMAN: deviceType=DISK blocks=4194302 blockSize=8192 cfCreationTime=01-APR-11
DBGRCVMAN: fromSCN=0 toSCN=190222194362 toTime=01-OCT-13 section_size=0
DBGRCVMAN: rlgSCN=20384287616 rlgTime=28-OCT-11 dbincKey=
DBGRCVMAN: afzSCN=190225321409 <<<<——absolute fuzzy of datafile —————

…
DBGRCVMAN: Datafile Copy
DBGRCVMAN: fileName=/u01/oradata/IBSOCHBT/datafile/undotbs2.333.765744149
DBGRCVMAN: media=
DBGRCVMAN: key=11 recid=11 stamp=829813564 status=A
DBGRCVMAN: compTime=26-OCT-13
DBGRCVMAN: deviceType=DISK blocks=4194302 blockSize=8192 cfCreationTime=28-OCT-11
DBGRCVMAN: fromSCN=0 toSCN=190222194362 toTime=01-OCT-13 section_size=0
DBGRCVMAN: rlgSCN=20384287616 rlgTime=28-OCT-11 dbincKey=
DBGRCVMAN: afzSCN=190225523927 <<<<——absolute fuzzy of datafile —————
DBGRCVMAN: dfNumber=12 creationSCN=20384294866 pluginSCN=0 foreignDbid=0 pl

使用’grep’ 来找出所有absolute fuzzy change SCN 会更简单，因此找出最小的恢复SCN。例如：

$cat debug_duplicate.trc|grep -i afzSCN|awk -F= ‘{print $2}’|sort -u

190222207344
190222268134
190222289690
190222300714
190222358369
190222424226
190222448489
190222519333
190222525684
190222587969
190222613944
190222732740
190223214948
190223250433
190223414735
190223421495
190223760442
190224434721
190224601566
190224727191
190225105744
190225321409
190225523927 <<<—————————– The largest number is the minimal recovery needed to remove the fuzziness amoung these datafiles.

解决方案

确认对RMAN duplicate指定的’backup location’ 中有可用的创建一致的辅助数据库所需的备份。

这能通过对目标数据库运行preview 命令完成，并确保所有返回的备份片被复制到指定的 ‘backup location’。

$rman target /
run{
allocate channel t1 type disk;
set until scn <scn >; //* also can opt time / sequence base on requirement
restore database preview;
}

另外，你可以运行以下查询来找出与数据库备份TAG相关的ABSOLUTE_FUZZY_CHANGE#。该查询假定每个完整数据库备份有唯一标签。

SQL> select tag,max(ABSOLUTE_FUZZY_CHANGE#) from v$backup_datafile d , v$backup_piece p
where d.SET_STAMP=p.SET_STAMP
and d.SET_COUNT=p.SET_COUNT
group by tag
/

有了该信息，确保指定的’backup location’中有可用的要恢复数据库以消除模糊性的必要备份，包括归档日志文件的备份。

参考

NOTE:1116484.1 - Master Note For Oracle Recovery Manager (RMAN)
 NOTE:1543996.1 - How to create a self-contained backup for RMAN Duplicate

你在这里

Oracle 在Duplicate … ‘backup location’时的RMAN-06136 ORA-01194 ORA-01110