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

如果自己搞不定可以找诗檀软件专业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

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号