mysql ora--00904_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操作.