一. 问题描述
在一次数据库恢复工作后,因为恢复工作中遇到一些问题,恢复后结合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操作.