UNDO表空间存储着DML操作数据块的前镜像数据,在数据回滚,一致性读,闪回操作,实例恢复的时候都可能用到UNDO表空间中的数据。如果在生产过程中丢失或破坏了UNDO表空间,可能导致某些事务无法回滚,数据库无法恢复到一致性的状态,Oracle实例可能宕机,之后实例无法正常启动;如果有多个UNDO表空间数据文件,丢失其中一个数据文件数据库实例可能不会导致实例宕机,数据库无法干净的关闭(只能SHUTDOWN ABORT),数据库实例能正常的重启,但所有未回滚的数据块依然无法处理,尝试新建UNDO表空间、exp、expdp等操作都会收到ORA-604, ORA-376, and ORA-1110的报错,下面通过一个实际的案例讨论如何处理UNDO损坏后的恢复。 如果你的数据库还能干净的关闭,但在正常情况下无法新建UNDO表空间,那么执行以下的步骤: 如果你的数据库不能正常关闭,只需要在重启数据库实例之前将下面的参数加到参数文件: |
如果Oracle在运行中很不幸遇到undo损坏,当然最好的方法是完全恢复,不过如果没有备份,可以采用一种非常规的手段(利用Oracle的隐藏参数),如果此时undo包含未提交的事务,会造成一点点的数据丢失(一般都是可忍受的),如果没有未提交的事务,则不会有数据丢失。其主要步骤有:
1. 修改undo表空间管理为手动;
2. 设置隐藏参数(_offline_rollback_segments或_corrupted_rollback_segments)标识受影响的回滚段,使Oracle忽略其上的未提交事务;
3. 手动删除受影响的回滚段和undo表空间,然后重建新的undo表空间;
4. 还原undo表空间管理为自动。
实验如下:
Step 1.
如果undo数据文件损坏,数据库只能到mount状态,open时会出现以下错误:
ORA-01157: cannot identify/lock data file 14 - see DBWR trace file
ORA-01110: data file 14: ‘I:\INTEL_DATA\O06DMS0\UNDO1.O06DMS0‘
说明该undo文件已经损坏或丢失,把该文件offline之后就可以打开数据库了:
SQL> alter database datafile ‘I:\INTEL_DATA\O06DMS0\UNDO1.O06DMS0‘ offline drop; 这个地方需要指定具体的文件名,否则自我试了几次出错
SQL> alter database open;
打开数据库的目的是为了找出受影响的回滚段:
SQL> select segment_name,status from dba_rollback_segs;
SEGMENT_NAME STATUS
------------------------------ ----------------
SYSTEM ONLINE
_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> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- -------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string undo1
关闭数据库:
SQL> shutdown immediate;
Step 2.
创建一个临时的pfile:
SQL> create pfile=‘H:\initO06DMS0.ora‘ from spfile;
修改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> startup pfile=‘H:\initO06DMS0.ora‘
Step 3.
手动删除受影响的回滚段:
SQL>drop rollback segment "_SYSSMU10_1201331463$";
SQL>drop rollback segment "_SYSSMU9_2926456744$";
SQL>drop rollback segment "_SYSSMU8_640224757$";
SQL>drop rollback segment "_SYSSMU7_3984293596$";
SQL>drop rollback segment "_SYSSMU6_3694658906$";
SQL>drop rollback segment "_SYSSMU5_3475919656$";
SQL>drop rollback segment "_SYSSMU4_168502732$";
SQL>drop rollback segment "_SYSSMU3_1987193959$";
SQL>drop rollback segment "_SYSSMU2_3908286755$";
SQL>drop rollback segment "_SYSSMU1_3281912951$";
手动删除旧的undo表空间:
SQL> drop tablespace undo1 including contents;
重建新的undo表空间:
SQL> create undo tablespace undo2 datafile ‘I:\INTEL_DATA\O06DMS0\UNDO2.O06DMS0‘ size 100m;
创建新的spfile,覆盖旧的spfile:
SQL> create spfile from pfile=‘H:\initO06DMS0.ora‘;
关闭数据库:
SQL> shutdown immediate;
Step 4.
以原来的spfile启动数据库:
SQL> startup;
还原undo表空间管理为自动:
SQL> alter system set undo_management=‘auto‘ scope=spfile;
取消隐藏参数的设置:
SQL> alter system reset "_offline_rollback_segments" scope=spfile;
重启使其生效:
SQL> shutdown immediate;
SQL> startup
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- -------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string undo2
最终检查一下:
SQL> select segment_name,status from dba_rollback_segs;
SEGMENT_NAME STATUS
------------------------------ ----------------
SYSTEM ONLINE
_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
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5669213349582
原文地址:https://www.cnblogs.com/chendian0/p/10322250.html