sysaux表空间故障处理

接开发人员的报障。某些用户的一些表明明是存在的，在DROP或SELECT的时候却会提示此表不存在。上去测试了一下，确实是这样。查看DBA_TABLES、DBA_OJBECTS等一些视图，都能查看到这些表的存在，且状也是正常可用的。查看ALERT.LOG，从7月26日就开始有报这个错误：

Errors in file /opt/oracle/admin/prtdb/bdump/prtdb2_j000_14772.trc:

ORA-12012: error on auto execute of job 42780

ORA-00376: file ORA-00376: file 3 cannot be read at this time

ORA-01110: data file 3: '+DATA/prtdb/datafile/sysaux.257.671819149'

ORA-06512: at "EXFSYS.DBMS_RLMGR_DR", line 17

ORA-06512: at line 1

很明示SYSAUX表空间有问题，它的DATAFILE不可用。查看它的DATAFILE处于RECOVER状态。手工RECOVER这个DATAFILE，报错。提示需要7月26日的归档日志。而我们的备份只保留10天，这么长时间经来的归档基本是找不回来的了。

GOOGLE上查了很久，有两种方法：

1 exp出来，重建库

2 重建SYSAUX表空间

Shutdown the database (make a backup)

- startup migrate

- drop sysaux tablespace

- recreate sysaux tablespace

(CREATE TABLESPACE SYSAUX DATAFILE '...' SIZE xxxM

EXTENT MANAGEMENT LOCAL

SEGMENT SPACE MANAGEMENT AUTO; )

- reexecute catalog and all optional scripts you used at database creation

- shutdown immediate

- startup

第二种找测试机测试了，没有成功。且就这样的RECREATE了SYSAUX，但里边的一些对像如何恢复呢。10G的一些统计数据都是放在SYSAUX里边的对像的。目前EXP出来，重建库，这种方法了。这里也需要注意的是，EXP的时候是不能在用户级进行导出的，当然表空间迁移也不行，都提示SYSAUX表空间的不可用而失败。

About to export specified users ...

. exporting pre-schema procedural objects and actions

. exporting foreign function library names for user PORTAL_USER 

. exporting PUBLIC type synonyms

. exporting private type synonyms

. exporting object type definitions for user PORTAL_USER 

About to 

export PORTAL_USER's objects ...

. exporting database links

. exporting sequence numbers

. exporting cluster definitions

EXP-00056: ORACLE error 376 encountered

ORA-00376: file 3 cannot be read at this time

ORA-01110: data file 3: '+DATA/prtdb/datafile/sysaux.257.671819149'

EXP-00000: Export terminated unsuccessfully

只有在表空间级导出是可行的，用如下命令：

exp system/manager buffer=1000000 compress=N STATISTICS=NONE TABLESPACES=PORTAL_DATA file=portal_data.dmp

这样导出的只有内容，很多其它的对像，如存储过程、包等还是需要手工重建的，跟表空间迁移相似。

后来得知这个数据库，其实是有带库的。带库备份的是RMAN备份出来的备份文件。查了一下带库的备份，能找到所有需要的备份集。真是上天怜悯啊！！

磁带库的恢复速度还是可以的，比想像中的速度快很多。600G的东西不用一个下午就恢复出来了。只是问题还是一个接一个来到来。在RESTORE归档日志的时候，很多出错提示说是找不到备份集，但物理文件是存在的。这样推测应该是RMAN里没有记录那久以前的一些备份集信息。后来查到的确是这样，我们没有用CATALOG数据库，所有的备份信息都是存在控制文件里的，而控制文件默认只会记录一定时间内的记录，更旧的就会删除。这个默认值在RMAN的CONFIGURE里应该可以查到并可以修改的。

所以现在问题是能不能且如何才能把这个更早的备份信息添加到控制文件里呢?!手动添加还是有其它的方法。在网上找到了一个命令，可以把扫描到的备份集信息自动的添加到控制文件里。 CATALOG START WITH '/u03/backup/prtdb'。不过有一点不太爽，这个命令每次只会扫描固定的几十行记录，然后添加，且并不是目录里有多少，就会一次过的所有都扫描进去。所以需要执行很多次才把备份集的信息都添加进去。

添加进去后，ORACLE的自动执行RECOVER，在日志里可以找到如下信息：

Thu Nov 25 18:06:47 2010

alter database recover datafile 3

Thu Nov 25 18:06:47 2010

Media Recovery Start

 parallel recovery started with 3 processes

ORA-279 signalled during: alter database recover datafile 3...

上需要ORA-279报错应该是因为节点3没有启动的原因。若还想手工执行RECOVER会报如下错误：

SQL> /

alter database recover datafile 3

*

ERROR at line 1:

ORA-00275: media recovery has already been started

只是到目前为止，已经三天了，还没有RECOVER完。SYSAUX空间清空是不可用的。真的有一点怀疑数据库是不是在RECOVER SYSAUX空间。

在捕捉正在执行的SQL，经常不断的是捕捉到如下一些SQL:

SELECT     ROWID, actschat, rset_owner, rset_name, rsetproc,

           sys_op_tosetid (rsetincrrs)

      FROM rlm$schactlist fus

     WHERE fus.ROWID =

              (SELECT MIN (ROWID)KEEP (DENSE_RANK FIRST ORDER BY actschat,

                       ROWID)

                 FROM rlm$schactlist

                WHERE actschat IS NOT NULL)

FOR UPDATE NOWAIT;

INSERT INTO rlm$schacterrs

            (actschat, rset_owner, rset_name, oraerrcde

            )

     VALUES (:b4, :b3, :b2, :b1

            )

DECLARE

   job                   BINARY_INTEGER           := :job;

   next_date             TIMESTAMP WITH TIME ZONE := :mydate;

   broken                BOOLEAN                  := FALSE;

   job_name              VARCHAR2 (30)            := :job_name;

   job_subname           VARCHAR2 (30)            := :job_subname;

   job_owner             VARCHAR2 (30)            := :job_owner;

   job_start             TIMESTAMP WITH TIME ZONE := :job_start;

   job_scheduled_start   TIMESTAMP WITH TIME ZONE := :job_scheduled_start;

   window_start          TIMESTAMP WITH TIME ZONE := :window_start;

   window_end            TIMESTAMP WITH TIME ZONE := :window_end;

BEGIN

   BEGIN

      dbms_rlmgr_dr.execschdactions ('RLM$SCHDNEGACTION');

   END;

   :mydate := next_date;

   IF broken

   THEN

      :b := 1;

   ELSE

      :b := 0;

   END IF;

END;

操作的对像都是在SYSAUX表空间的。这样看好像在是在RECOVER。现在只能是等待了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/540427/viewspace-680478/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/540427/viewspace-680478/