ORA-00904故障分析與解決一例

一. 問題描述

在一次資料庫恢復工作後,因為恢復工作中遇到一些問題,恢復後結合oracle官方文件,仔細研究rman的工作原理.將資料庫啟動到mount狀態後,想
看一下v$backup_archivelog_details檢視的內容,結果報了ORA-00904的錯誤,描述如下:

SQL> desc v$backup_archivelog_details;
ERROR:
ORA-00604: error occurred at recursive SQL level 3
ORA-00904: "SYS"."DBMS_RCVMAN"."SV_GETSESSIONUNTILTIMERANGE": invalid identifier

[@more@]

二. 問題分析

這個資料庫是前幾天做過資料庫恢復,恢復的時間點為2013-06-26日,今天是2013-07-08,使用的是control file記錄rman catalog資訊.而資料庫的引數control_file_record_keep_time預設設定為7
如下所示:
SQL> show parameter control_file_record_keep_time
control_file_record_keep_time integer 7

所以之前的歸檔日誌備份資訊已經超過了7天,不再保留,實際上資料庫恢復後啟動執行,在v$backup_archivelog_details檢視中這些記錄的status='D'(deleted)狀態.
所以我們把資料庫啟動到mount狀態,然後檢視v$backup_archivelog_details檢視時,報了ora-00904錯誤

三. 問題解決

首先修改引數,使保留時間為60天

SQL>alter system set control_file_record_keep_time=60 scope=both;

然後在rman中執行crosscheck bacupset ,使得這些備份集再次被識別.
rman>crosscheck backupset;

SQL> desc v$backup_archivelog_details;
Name Null? Type
----------------------------------------------------------------------------------------------------------------- -------- ----------------------------------------------------------------------------
BTYPE CHAR(9)
BTYPE_KEY NUMBER
SESSION_KEY NUMBER
SESSION_RECID NUMBER
SESSION_STAMP NUMBER
ID1 NUMBER
ID2 NUMBER
THREAD# NUMBER
SEQUENCE# NUMBER
RESETLOGS_CHANGE# NUMBER
RESETLOGS_TIME DATE
FIRST_CHANGE# NUMBER
FIRST_TIME DATE
NEXT_CHANGE# NUMBER
NEXT_TIME DATE
FILESIZE NUMBER
COMPRESSION_RATIO NUMBER
FILESIZE_DISPLAY VARCHAR2(4000)

SQL> select count(1) from v$backup_archivelog_details;

208

我們可以看到不再報ora-00904的錯誤,問題解決.
後記:
當我們把資料又一次啟動後,資料庫將又會將這些記錄設定為'D'狀態,呵呵,如果想在mount狀態下看到這個檢視,又需要crosscheck backupset操作.