解析在没有备份的情况下undo损坏怎么办

如果Oracle在运行中很不幸遇到undo损坏，当然最好的方法是完全恢复，不过如果没有备份，可以采用一种非常规的手段（利用Oracle的隐藏参数），如果此时undo包含未提交的事务，会造成一点点的数据丢失（一般都是可忍受的），如果没有未提交的事务，则不会有数据丢失。其主要步骤有：

1.修改undo表空间管理为手动；

2.设置隐藏参数(_offline_rollback_segments或_corrupted_rollback_segments)标识受影响的回滚段，使Oracle忽略其上的未提交事务；

3.手动删除受影响的回滚段和undo表空间，然后重建新的undo表空间；

4.还原undo表空间管理为自动。

实验如下：

Step1.

如果undo数据文件损坏，数据库只能到mount状态，open时会出现以下错误：

ORA-01157:cannotidentify/lockdatafile14-seeDBWRtracefile

ORA-01110:datafile14:'I:\INTEL_DATA\O06DMS0\UNDO1.O06DMS0'

说明该undo文件已经损坏或丢失，把该文件offline之后就可以打开数据库了：

SQL>alterdatabasedatafile'I:\INTEL_DATA\O06DMS0\UNDO1.O06DMS0'offlinedrop;

SQL>alterdatabaseopen;

打开数据库的目的是为了找出受影响的回滚段：

SQL>selectsegment_name,statusfromdba_rollback_segs;

SEGMENT_NAMESTATUS

----------------------------------------------

SYSTEMONLINE

_SYSSMU10_1201331463$OFFLINE

_SYSSMU9_2926456744$OFFLINE

_SYSSMU8_640224757$OFFLINE

_SYSSMU7_3984293596$OFFLINE

_SYSSMU6_3694658906$OFFLINE

_SYSSMU5_3475919656$OFFLINE

_SYSSMU4_168502732$OFFLINE

_SYSSMU3_1987193959$OFFLINE

_SYSSMU2_3908286755$OFFLINE

_SYSSMU1_3281912951$OFFLINE

SQL>showparameterundo

NAMETYPEVALUE

------------------------------------------------------------

undo_managementstringAUTO

undo_retentioninteger900

undo_tablespacestringundo1

关闭数据库：

SQL>shutdownimmediate;

Step2.

创建一个临时的pfile：

SQL>createpfile='H:\initO06DMS0.ora'fromspfile;

修改pfile如下：

*.undo_management='manual'--undo表空间管理方式修改为手动

*.undo_tablespace='undo2'--指定一个新的undo表空间

*._offline_rollback_segments=('_SYSSMU10_1201331463$','_SYSSMU9_2926456744$','_SYSSMU8_640224757$','_SYSSMU7_3984293596$','_SYSSMU6_3694658906$','_SYSSMU5_3475919656$','_SYSSMU4_168502732$','_SYSSMU3_1987193959$','_SYSSMU2_3908286755$','_SYSSMU1_3281912951$')--把所有受影响的回滚段都列在这里

并以改pfile重新启动数据库：

SQL>startuppfile='H:\initO06DMS0.ora'

Step3.

手动删除受影响的回滚段：

SQL>droprollbacksegment_SYSSMU10_1201331463$;

SQL>droprollbacksegment_SYSSMU9_2926456744$;

SQL>droprollbacksegment_SYSSMU8_640224757$;

SQL>droprollbacksegment_SYSSMU7_3984293596$;

SQL>droprollbacksegment_SYSSMU6_3694658906$;

SQL>droprollbacksegment_SYSSMU5_3475919656$;

SQL>droprollbacksegment_SYSSMU4_168502732$;

SQL>droprollbacksegment_SYSSMU3_1987193959$;

SQL>droprollbacksegment_SYSSMU2_3908286755$;

SQL>droprollbacksegment_SYSSMU1_3281912951$;

手动删除旧的undo表空间：

SQL>droptablespaceundo1includingcontents;

重建新的undo表空间：

SQL>createundotablespaceundo2datafile'I:\INTEL_DATA\O06DMS0\UNDO2.O06DMS0'size100m;

创建新的spfile，覆盖旧的spfile：

SQL>createspfilefrompfile='H:\initO06DMS0.ora';

关闭数据库：

SQL>shutdownimmediate;

Step4.

以原来的spfile启动数据库：

SQL>startup;

还原undo表空间管理为自动：

SQL>altersystemsetundo_management='auto'scope=spfile;

取消隐藏参数的设置：

SQL>altersystemreset_offline_rollback_segmentsscope=spfile;

重启使其生效：

SQL>shutdownimmediate;

SQL>startup

SQL>showparameterundo

NAMETYPEVALUE

------------------------------------------------------------------

undo_managementstringAUTO

undo_retentioninteger900

undo_tablespacestringundo2

最终检查一下：

SQL>selectsegment_name,statusfromdba_rollback_segs;

SEGMENT_NAMESTATUS

----------------------------------------------

SYSTEMONLINE

_SYSSMU40_1968985325$ONLINE

_SYSSMU39_4040503138$ONLINE

_SYSSMU38_4059847715$ONLINE

_SYSSMU37_2692202156$ONLINE

_SYSSMU36_2617425201$ONLINE

_SYSSMU35_1133967719$ONLINE

_SYSSMU34_1916939664$ONLINE

_SYSSMU33_99444166$ONLINE

_SYSSMU32_162619813$ONLINE

_SYSSMU31_830375278$ONLINE