RMAN-20035 RMAN-06004與恢復目錄重新注冊

一個數(shù)據庫RMAN 熱備份失敗，報錯RMAN-20035 和RMAN-06004 。而使用exp 進行的邏輯備份正常。

具體信息如下：

RMAN-03022: compiling command: backup

RMAN-03026: error recovery releasing channel resources

RMAN-08031: released channel: ch01
-
 

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure during compilation of command

RMAN-03013: command type: backup

RMAN-03014: implicit resync of recovery catalog failed

RMAN-06004: Oracle error from recovery catalog database: RMAN-20035: invalid high recid

這些錯誤信息也證明數(shù)據庫本身沒有問題，問題應該出在RMAN 上。

這個庫的環(huán)境和備份配置這里先介紹一下。

數(shù)據庫是Oracle 8.1.7.4 ，很早的一個版本。RMAN 備份的目錄庫是在一個Oracle 10g 的數(shù)據庫中。

這個錯誤導致了數(shù)據庫RMAN 熱備份不成功。

問題的關鍵點是來自恢復目錄數(shù)據庫的錯誤，如下：

RMAN-06004: Oracle error from recovery catalog database: RMAN-20035: invalid high recid

1.  分析
第一步，檢查備份腳本

確認備份腳本一直以來沒有變化過。因此，腳本本身沒有問題。

第二步，檢查目錄庫

在該數(shù)據庫服務器上登錄sqlplus ，連接到目錄庫上。

bash-2.05$ sqlplus  m18_rman_cata_34/wexxxxxxxx@xxxdb

SQL*Plus: Release 8.1.7.0.0 - Production on Fri May 18 14:42:41 2012

(c) Copyright 2000 Oracle Corporation.  All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production

With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL>

顯示是可以連接的。

第三步，檢查備份集情況

使用rman 操作，顯示一下備份情況。

RMAN> list backupset;

RMAN-03022: compiling command: list

RMAN-03026: error recovery releasing channel resources

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure during compilation of command

RMAN-03013: command type: list

RMAN-03014: implicit resync of recovery catalog failed

RMAN-06004: Oracle error from recovery catalog database: RMAN-20035: invalid high recid

結果很悲劇。

已經不能從恢復目錄庫中查詢備份結果集的信息了。

可以確定備份的恢復目錄庫有問題了。

將恢復目錄庫重做一下，也可以解決這個問題。

還有一種方法，是重新注冊一下，將本庫重新注冊進入恢復目錄庫。

2.  解決
首先，查詢一下該庫在恢復目錄庫中的注冊信息。

SQL> select db_key,dbid,name from rc_database;

    DB_KEY       DBID NAME

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

         1 3753655651 M18

在恢復目錄庫中，NAME 為M18 的記錄就是我們備份失敗的數(shù)據庫。這個恢復目錄庫中只有一個庫的備份信息存儲在其中。

其次，使用dbms_rcvcat 包的unregiseterdatabase 函數(shù)解除恢復目錄庫中的注冊信息

使用sqlplus 登錄到恢復目錄庫中，執(zhí)行下面的SQL

exec dbms_rcvcat.unregisterdatabase(1,3753655651);

最后，重新注冊一下恢復目錄庫

在rman 下執(zhí)行register database; 命令注冊。操作過程如下：

bash-2.05$ rman target / rcvcat m18_rman_cata_34/xxxxx@xxxdb

Recovery Manager: Release 8.1.7.4.0 - Production

RMAN-06005: connected to target database: M18 (DBID=3753655651)

RMAN-06008: connected to recovery catalog database

RMAN> register database;

RMAN-03022: compiling command: register

RMAN-03023: executing command: register

RMAN-08006: database registered in recovery catalog

RMAN-03023: executing command: full resync

RMAN-08002: starting full resync of recovery catalog

^[RMAN-08004: full resync complete

可以從執(zhí)行結果中看出，已經完全和恢復目錄同步成功了。

數(shù)據庫RMAN 熱備份工作恢復正常。

3.  總結
這個系統(tǒng)的環(huán)境畢竟復雜，經歷了從物理機器遷移到虛擬機，又遷移回來。一般這種錯誤是數(shù)據庫使用open resetlogs 方式打開過，恢復目錄庫的信息就得重建。另有一種情況，就是bug 導致。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]