天萃荷凈

Oracle研究中心案例分析：運(yùn)維DBA反映在對(duì)Oracle數(shù)據(jù)庫(kù)進(jìn)行恢復(fù)時(shí)報(bào)錯(cuò)，執(zhí)行recover database報(bào)RMAN-06004 RMAN-20003錯(cuò)誤。

最近遇到11.2.0.3 RAC FOR AIX平臺(tái)在出賬高峰期生成的歸檔日志有損壞，導(dǎo)致歸檔日志文件備份失敗。

關(guān)鍵在此系統(tǒng)上有DG，并且在出賬的期間，由于需要，將備庫(kù)轉(zhuǎn)換成SNAPSHOT STANDBY，此時(shí)遇到主庫(kù)已經(jīng)成功傳輸?shù)絺鋷?kù)的歸檔文件在主庫(kù)不能刪除的BUG，還由于其它一些原因，禁用主機(jī)傳輸?shù)絺鋷?kù)的歸檔路徑。悲劇來了，歸檔日志文件壞了，沒有辦法，月初高峰期后，使用增量備份來前滾物理備庫(kù)吧，但是不巧的是又遇到下面的報(bào)錯(cuò)。

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

下面是整個(gè)操作過程

1，主庫(kù)進(jìn)行增量備份

提供命令給備份工程師，讓備份工程師完成增量備份

SELECT MIN(checkpoint_change#) FROM V$DATAFILE;

BACKUP INCREMENTAL FROM SCN xxxxx DATABASE FOR 'STANDBY_20160000'；

大概幾個(gè)小時(shí)后，增量備份完成。

2，主庫(kù)備份控制文件

主庫(kù)備份控制文件，并傳輸?shù)絺鋷?kù)主機(jī)

backup current? controlfile? for standby format='/tmp/con_standby.ctl';

scp con_standby.ctl 192.168.111.12:/tmp

3，備庫(kù)還原控制文件

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';這里應(yīng)該使用restore standby controlfile

RMAN> alter database mount;

database mounted

released channel: ORA_DISK_1

4，更改數(shù)據(jù)文件路徑

由于主庫(kù)與備庫(kù)的數(shù)據(jù)文件路徑不一樣，需要手動(dòng)修改

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

修改數(shù)據(jù)文件的路徑

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

這里數(shù)據(jù)文件1有報(bào)錯(cuò)，感覺不好，正常情況這里應(yīng)該。下面使用手動(dòng)的方式來實(shí)現(xiàn)

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數(shù)據(jù)庫(kù)

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，查看數(shù)據(jù)庫(kù)的角色

SQL> select database_role from v$database;

DATABASE_ROLE

----------------

PRIMARY

這里看到數(shù)據(jù)庫(kù)主庫(kù)模式，下面重新還原一次控制文件

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，還原數(shù)據(jù)文件

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數(shù)據(jù)庫(kù)

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>? }

這里沒有在報(bào)錯(cuò)了

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，時(shí)時(shí)運(yùn)用模式

SQL> recover managed standby database using current logfile disconnect;

Media recovery complete.

11，啟用塊跟蹤與修改文件管理參數(shù)

整個(gè)增量前滾DG完成

本文固定鏈接: http://www.htz.pw/2016/05/09/recover-database-rman-06004-rman-20003.html | 認(rèn)真就輸

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

最權(quán)威、專業(yè)的Oracle案例資源匯總之【案例】Oracle RAC恢復(fù)報(bào)錯(cuò)RMAN-06004 RMAN-20003解決辦法筆記

總結(jié)

以上是生活随笔為你收集整理的oracle可恢复的等待,【案例】Oracle RAC恢复报错RMAN-06004 RMAN-20003解决办法笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。