sitemap

RSS地图

收藏本站

设为首页

Oracle研究中心

当前位置:Oracle研究中心 > 运维DBA > Oracle等待事件 >

【案例】Oracle RAC恢复报错RMAN-06004 RMAN-20003解决办法笔记

时间:2016-11-07 21:10   来源:Oracle研究中心   作者:HTZ   点击:

天萃荷净 Oracle研究中心案例分析:运维DBA反映在对Oracle数据库进行恢复时报错,执行recover database报RMAN-06004 RMAN-20003错误。
最近遇到11.2.0.3 RAC FOR AIX平台在出账高峰期生成的归档日志有损坏,导致归档日志文件备份失败。

关键在此系统上有DG,并且在出账的期间,由于需要,将备库转换成SNAPSHOT STANDBY,此时遇到主库已经成功传输到备库的归档文件在主库不能删除的BUG,还由于其它一些原因,禁用主机传输到备库的归档路径。悲剧来了,归档日志文件坏了,没有办法,月初高峰期后,使用增量备份来前滚物理备库吧,但是不巧的是又遇到下面的报错。

released channel: t1
released channel: t2
released channel: t3
released channel: t4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/05/2016 16:29:47
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20003: target database incarnation not found in recovery catalog

下面是整个操作过程

1,主库进行增量备份

提供命令给备份工程师,让备份工程师完成增量备份

SELECT MIN(checkpoint_change#) FROM V$DATAFILE;
BACKUP INCREMENTAL FROM SCN xxxxx DATABASE FOR 'STANDBY_20160000';
大概几个小时后,增量备份完成。

2,主库备份控制文件

主库备份控制文件,并传输到备库主机

backup current  controlfile  for standby format='/tmp/con_standby.ctl';
scp con_standby.ctl 192.168.111.12:/tmp

3,备库还原控制文件

QL> !rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Thu May 5 16:14:46 2016
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
connected to target database: ACCT (not mounted)

RMAN> restore controlfile from '/tmp/con_standby.ctl';这里应该使用restore standby controlfile
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1

4,更改数据文件路径

由于主库与备库的数据文件路径不一样,需要手动修改

RMAN> catalog start with '/linshi/dev';

修改数据文件的路径

RMAN> switch database to copy;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 05/05/2016 16:17:32
RMAN-06571: datafile 1 does not have recoverable copy
这里数据文件1有报错,感觉不好,正常情况这里应该。下面使用手动的方式来实现

SQL> select 'set newname for datafile '||file#||' to '||chr(39)||name||chr(39)||';' from v$backup_copy_details order by file#;

'SETNEWNAMEFORDATAFILE'||FILE#||'TO'||CHR(39)||NAME||CHR(39)||';'
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
set newname for datafile 1 to '/linshi/dev/vx/rdsk/htz/lv_system_111.dbf';
set newname for datafile 2 to '/linshi/dev/vx/rdsk/htz/lv_sysaux_111.dbf';
set newname for datafile 3 to '/linshi/dev/vx/rdsk/htz/lv_undo_111.dbf';
set newname for datafile 4 to '/linshi/dev/vx/rdsk/htz/lv_users_111.dbf';
...............................................................................


5,recover数据库

oracle@htz#[/linshi/shell]nohup sh ./recover_database.sh &
[1]     30671256
oracle@htz#[/linshi/shell]Sending output to /home/oracle/nohup.out

Starting recover at 05-MAY-16
released channel: t1
released channel: t2
released channel: t3
released channel: t4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/05/2016 16:29:47
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20003: target database incarnation not found in recovery catalog

6,查看数据库的角色

SQL> select database_role from v$database;

DATABASE_ROLE
----------------
PRIMARY

这里看到数据库主库模式,下面重新还原一次控制文件
SQL> !rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Fri May 6 00:47:09 2016
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
connected to target database: ACCT (not mounted)

RMAN> restore standby controlfile from '/tmp/standby.ctl';

Starting restore at 06-MAY-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2002 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/linshi/control.ctl
Finished restore at 06-MAY-16

SQL> select database_role from v$database;

DATABASE_ROLE
--------------------------------
PHYSICAL STANDBY

RMAN> list incarnation;

using target database control file instead of recovery catalog

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       ACCT     3716340531       PARENT  1          29-MAR-12
2       2       ACCT     3716340531       CURRENT 14754146318553 30-APR-16

RMAN> reset database to INCARNATION  1;
database reset to incarnation 1

RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       ACCT     3716340531       CURRENT 1          29-MAR-12
2       2       ACCT     3716340531       ORPHAN  14754146318553 30-APR-16

7,还原数据文件

SQL> alter system set standby_file_management=manual;
System altered.

run
{
  ALLOCATE channel t1 type 'sbt_tape';
  ALLOCATE channel t2 TYPE 'sbt_tape';
  ALLOCATE channel t3 TYPE 'sbt_tape';
  ALLOCATE channel t4 TYPE 'sbt_tape';
  send 'NSR_ENV=(NSR_SERVER=htzback,NSR_CLIENT=htz01)';
restore datafile 647,645,646 from tag 'FORSTANDBY2319';
}

8,RECOVER数据库

RMAN>  run
2> {
3> allocate channel t1 type 'sbt_tape' PARMS 'ENV=(NSR_SERVER=htzback,NSR_CLIENT=htz02)';
4> allocate channel t2 type 'sbt_tape' PARMS 'ENV=(NSR_SERVER=htzback,NSR_CLIENT=htz02)';
5> allocate channel t3 type 'sbt_tape' PARMS 'ENV=(NSR_SERVER=htzback,NSR_CLIENT=htz01)';
6> allocate channel t4 type 'sbt_tape' PARMS 'ENV=(NSR_SERVER=htzback,NSR_CLIENT=htz01)';
7> recover database;
8> release channel t1;
9>  release channel t2;
10>  release channel t3;
11>  release channel t4;
12>  }
这里没有在报错了

9,添加STANDBY日志文件

SQL>
alter database add standby logfile  thread 1 '/htz/standby11.dbf'  reuse
alter database add standby logfile  thread 1 '/htz/standby12.dbf'  reuse ;
alter database add standby logfile  thread 1 '/htz/standby13.dbf'  reuse ;
alter database add standby logfile  thread 1 '/htz/standby14.dbf'  reuse ;
alter database add standby logfile  thread 1 '/htz/standby15.dbf'  reuse ;
alter database add standby logfile  thread 1 '/htz/standby16.dbf'  reuse ;
alter database add standby logfile  thread 1 '/htz/standby17.dbf'  reuse ;
alter database add standby logfile thread 2 '/htz/standby21.dbf'   reuse ;
alter database add standby logfile thread 2 '/htz/standby22.dbf'   reuse ;
alter database add standby logfile thread 2 '/htz/standby23.dbf'   reuse ;
alter database add standby logfile thread 2 '/htz/standby24.dbf'   reuse ;
alter database add standby logfile thread 2 '/htz/standby25.dbf'   reuse ;
alter database add standby logfile thread 2 '/htz/standby26.dbf'   reuse ;
alter database add standby logfile thread 2 '/htz/standby27.dbf'   reuse ;

10,时时运用模式

SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.

11,启用块跟踪与修改文件管理参数

整个增量前滚DG完成

本文固定链接: http://www.htz.pw/2016/05/09/recover-database-rman-06004-rman-20003.html | 认真就输

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之【案例】Oracle RAC恢复报错RMAN-06004 RMAN-20003解决办法笔记

本文由大师惜分飞原创分享,网址:http://www.oracleplus.net/arch/1197.html

Oracle研究中心

关键词:

RMAN-06004解决笔记

RMAN-20003解决笔记

Oracle数据库recover database报RMAN-06004 RMAN-20003错误