undo表空间损坏的处理过程

erpaa数据库，因为存储原因宕机，undo表空间损坏的处理过程
数据库在开启rman备份时，突然出现挂载磁盘无法识别情况，导至数据库宕机。
处理过程如下：


--检查数据库状态
C:\Documents and Settings\Administrator>sqlplus "/as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on 星期日 8月 19 11:49:13 2013
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
已连接到空闲例程。
SQL> startup
ORA-00376: 此时无法读取文件 18
ORA-01110: 数据文件 18: 'Y:\ORADATA\UNDO\UNDO02.DBF'
数据库启动报错，指出undo空间错误！经过分析，需要对undo空间进行重建

--备份参数文件，准备修改参数启动数据库，查看其它文件的状态。


SQL> create pfile='c:\pfilebak0819.ora' from spfile; 


尝试启动到mount状态：


SQL> startup mount;


这时数据库显示启动到了mount状态，查询一下数据库文件情况：


SQL> select name,status from v$datafile;


NAME                                     STATUS
---------------------------------------- -------
E:\ORACLE\ORADATA\erpaa\SYSTEM01.DBF    SYSTEM
E:\ORACLE\ORADATA\erpaa\UNDOTBS01.DBF   ONLINE
E:\ORACLE\ORADATA\erpaa\USERS01.DBF     ONLINE
E:\ORACLE\ORADATA\erpaa\XDB01.DBF       ONLINE
E:\ORACLE\ORADATA\erpaa\USER.ORA        ONLINE
Z:\ORADATA\USER\USER004.DBF              ONLINE
Y:\ORADATA\UNDO\UNDO02.DBF               RECOVER
Y:\ORADATA\UNDO\UNDO03.DBF               RECOVER

这里发现undo空间需要恢复，所以先恢复一下数据库，看能否恢复！


SQL> recover database;


Database recovered.


再次查看的时候，仍然处理需要恢复的状态。


--修改刚才备份的参数文件pfile，数据库启动到不一致的状态，添加undo表空间，并删除原undo表空间


加上如下两个参数：
*._allow_resetlogs_corruption=true
*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)


保存后用pfile启动


SQL> startup pfile='c:\pfilebak0819.ora';


启动数据库后，重新创建undo表空间。


SQL> CREATE UNDO TABLESPACE "UNDOTBS2"  DATAFILE 'E:\oracle\oradata\erpaa\undotbs02.dbf' SIZE 1024M REUSE AUTOEXTEND ON NEXT  2m MAXSIZE  4096M;


Tablespace created.


SQL> alter system set undo_tablespace=UNDOTBS2 scope=both;


System alerted.


SQL> drop tablespace UNDOTBS1 including contents and datafiles;


Tablespace droped.


再次查询需要恢复的文件，已经不存在了


SQL> select * from v$recover_file;


no rows selected


--再次关闭数据库，并重启，发现报错。


SQL> shutdown immediate
 
把原来的参数进行修改，去掉隐含参数，再次启动


SQL> startup pfile='c:\pfilebak0819.ora';


Errors in file e:\oracle\admin\erpaa\udump\erpaa_ora_1504.trc:
ORA-00600: 内部错误代码，参数: [25012], [1], [2], [], [], [], [], []


数据库又报错了，不过从这个错误参数来看，数据库仍然需要undotsb1的文件，所以把第一个undo建好，但不使用！


再次增加刚才的隐含参数进去，再不一致的情况下启动。


SQL> startup pfile='c:\pfilebak0819.ora';


数据库启动后，重建undo1


SQL> CREATE UNDO TABLESPACE "UNDOTBS1"  DATAFILE 'E:\oracle\oradata\erpaa\undotbs01.dbf' SIZE 100m;


Tablespace created.


SQL> shutdown immediate;


关闭数据库后，重新修改参数pfile文件，


SQL> startup pfile='c:\pfilebak0819.ora';


数据库启动后，做了几次日志切换都没有出现任何问题


SQL> alter system archive log current.


System alerted.


SQL> create spfile from pfile='c:\pfilebak0819.ora';




--但是，半个小时后，发现数据库突然宕了，报错如下：
BH (0x1DFE204C) file#: 2 rdba: 0x00800029 (2/41) class 21 ba: 0x1DABA000
  set: 5 dbwrid: 0 obj: -1 objn: 0
  hash: [1e7ffce8,1a7a994c] lru: [1dfe220c,1dfe1f1c]
  ckptq: [NULL] fileq: [NULL]
  st: XCURRENT md: NULL rsop: 0x00000000 tch: 3
  flags: gotten_in_current_mode
  LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]
*** 2013-08-19 14:10:17.000
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcbgcur_6], [23], [], [], [], [], [], []


发现2号文件还有问题，进行如下检查：
SQL> startup 


数据库能够正常启动,检查文件和回滚段。


SQL> select file_name,tablespace_name from dba_data_files where file# = 2


这时查询发现2号文件正是undotbs1的表空间文件


SQL> select segment_name,status,tablespace_name from dba_rollback_segs


发现有11个undo段是undotsb1的，并且是offline状态的，如下：
'_SYSSMU11$','_SYSSMU10$','_SYSSMU9$','_SYSSMU8$','_SYSSMU7$','_SYSSMU6$','_SYSSMU5$','_SYSSMU4$','_SYSSMU3$','_SYSSMU2$','_SYSSMU1$'


SQL> shutdown immediate


关闭数据库，修改参数文件pfile，做如下调整：


*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$，_SYSSMU11$)
undo_management=manual


SQL> startup pfile='c:\pfilebak0819.ora';


数据库启动后，这时候，需要把这些回滚段应该是原来undotbs1的，应该把它drop掉


SQL> drop rollback segment "_SYSSMU11$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU10$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU9$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU8$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU7$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU6$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU5$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU4$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU3$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU2$";


Rollback segment dropped


SQL> drop rollback segment "_SYSSMU1$";


Rollback segment dropped


再次关闭和开启数据库


SQL> shutdown immediate;


修改pfile
*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$，_SYSSMU11$)
undo_management=manual
把第一条删除，第二条改成AUTO


重新利用这个pfile开启数据库


SQL> startup pfile='c:\pfilebak0819.ora';
数据库启动后


SQL> create spfile from pfile='c:\pfilebak0819.ora';


至此，数据库恢复正常！

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

转载于:http://blog.itpub.net/29371470/viewspace-1062586/