Oracle数据库教程—— undo表空间损坏的处理过程
oracle数据库表损坏解决办法
oracle数据库表损坏解决办法10.9上午，我和同事小汪一起到foshan，诊断解决数据坏块的问题，问题：用户查询一个表时，报数据文件有坏块目标：用户可以接受丢失这些坏块的数据，但该数据文件其它的好块应该可以查询数据。
下面是具体的步骤：1.询问用户徐工出错的表名，收集出错信息出错表名：fsgazhjf.fsgazhjf_tac_20061018trace文件中的出错信息：***Corrupt block relative dba: 0xb8428b33 (file 737, block 166707)Fractured block found during user buffer readData in bad block -type: 6 format: 2 rdba: 0xb8428b33last change scn: 0x0000.0a66398d seq: 0x1 flg: 0x00consistency value in tail: 0xbddc0601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***2.根据出错块id，查询出该块对应的物理表，跟第一步收集的比对select * from dba_extentswhere file_id=737 and block_id <= 166707 and (block_id + blocks - 1) >= 166707;FSGAZHJF FSGAZHJF_TAC_20061018 TABLE FSGAZHJF_GSM_10 1201 737 166665 1048576 128 737结果：的确是该表:FSGAZHJF_TAC_20061018，用户FSGAZHJF，表空间FSGAZHJF_GSM_103.查询该表，看报错信息是否和第一步一致select count(1) from fsgazhjf.fsgazhjf_tac_20061018;结果：果然报错4.收集该表的所有索引select * from dba_indexes where owner='FSGAZHJF' and lower(table_name)='fsgazhjf_tac_20061018';no rows结果：无索引5.用dbv工具来check bad blockSQL> select file_id||' '||file_name from dba_data_files where file_id=737;FILE_ID||''||FILE_NAME--------------------------------------------------------------------------------------------------737 K:ORADATAORA8FSGAZHJF_GSM_10_50.DBFC:>dbv file='K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF' blocksize=8192 logfile='h:dbv.log'DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006(c) Copyright 2000 Oracle Corporation. All rights reserved.DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006(c) Copyright 2000 Oracle Corporation. All rights reserved.DBVERIFY - 检验开始：FILE = K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF标记为损坏的页面166708***Corrupt block relative dba: 0xb8428b34 (file 0, block 166708) Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xcf012b08last change scn: 0x0000.0a91bf69 seq: 0x1 flg: 0x00consistency value in tail: 0x0ccc0601check value in block header: 0x0, block checksum disabledspare1: 0x0, spare2: 0x0, spare3: 0x0***标记为损坏的页面166709***Corrupt block relative dba: 0xb8428b35 (file 0, block 166709) Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xce00e7e9last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00 consistency value in tail: 0x0ce80601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***标记为损坏的页面166710***Corrupt block relative dba: 0xb8428b36 (file 0, block 166710) Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xce00e7ealast change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00 consistency value in tail: 0x0ce80601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***标记为损坏的页面166711***Corrupt block relative dba: 0xb8428b37 (file 0, block 166711)Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xce00e7eblast change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00consistency value in tail: 0x39910601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***DBVERIFY - 完成检验检查的页面总数：262144处理的页面总数（数据）：262010失败的页面总数（数据）：0处理的页面总数（索引）：0失败的页面总数（索引）：0处理的页面总数（其它）：9空的页面总数：120标记损坏的页面总数：4汇集的页面总数：0检查结果：4个坏块，块号是166708 ~ 166711 ，经查询，发现都在一个extent里，属于同一张表6.开始打标记具体过程：C:>sqlplus sys/change_on_installSQL*Plus: Release 8.1.7.0.0 - Production on 星期四11月9 12:18:08 2006(c) Copyright 2000 Oracle Corporation. All rights reserved.连接到:Oracle8i Enterprise Edition Release 8.1.7.4.1 - ProductionWith the Partitioning optionJServer Release 8.1.7.4.1 - ProductionSQL>execdbms_repair.admin_tables('REPAIR_TABLE',1,1,'USERS');PL/SQL 过程已成功完成。
oracle的undo表空间
Oracle 的Undo有两种方式：一是使用undo 表空间，二是使用回滚段.我们通过undo_management 参数来控制使用哪种方式，如果设为auto，就使用UNDO 表空间，这时必须要指定一个UNDO 表空间。
如果设为manual，系统启动后使用rollback segment方式存储undo信息。
如果系统没有指定undo_management，那么系统默认以manual 方式启动,即使设置了auto方式的参数，这些参数将被忽略。
当实例启动的时候，系统自动选择第一个有效的undo表空间或者是rollback segment，如果没有有效的可用的undo表空间或者是回滚段，系统使用system rollback segment。
这种情况是不被推荐的，当系统运行在没有undo的情况下，系统会在alert.log中记录一条警告信息。
SQL> show parameter undoNAME TYPE V ALUE------------------------------------ ----------- ------------------undo_management string AUTOundo_retention integer 900undo_tablespace string UNDOTBS1参考：Oracle undo 管理/tianlesoftware/archive/2009/11/30/4901666.aspx一．UNDO 表空间下面来看一下undo 的表空间管理。
先来查看一下表空间的使用情况：/* Formatted on 2010/6/23 9:46:58 (QP5 v5.115.810.9015) */SELECT a.tablespace_name,ROUND (a.total_size) "total_size(MB)",ROUND (a.total_size) - ROUND (b.free_size, 3) "used_size(MB)",ROUND (b.free_size, 3) "free_size(MB)",ROUND (b.free_size / total_size * 100, 2) || '%' free_rateFROM ( SELECT tablespace_name, SUM (bytes) / 1024 / 1024 total_sizeFROM dba_data_filesGROUP BY tablespace_name) a,( SELECT tablespace_name, SUM (bytes) / 1024 / 1024 free_sizeFROM dba_free_spaceGROUP BY tablespace_name) bWHERE a.tablespace_name = b.tablespace_name(+);TABLESPACE_NAME total_size(MB) used_size(MB) free_size(MB) FREE_RATE-------------------- -------------- ------------- ------------- --------------SYSAUX 580 545.187 34.813 6%UNDOTBS1 90 23.875 66.125 73.47%DA VE 20 6.25 13.75 68.75%USERS 10 8.375 1.625 16.25%SYSTEM 960 951.062 8.938 93%从结果我们看到UNDO 表空间已经用了23.875M。
ORACLE 回滚段表空间数据文件丢失或损坏处理方法
ORACLE 回滚段表空间数据文件丢失或损坏处理方法问题描述：这是一个回滚段表空间数据文件丢失或损坏的情景，这时oracle不能识别相应的数据文件。
当你试图startup 数据文件时会报ORA-1157，ORA-1110，并且可能会伴随着标识操作系统级别的错误，比如ORA-7360。
当你试图以shutdown normal或shutdown immediate模式关闭数据库时会导至ORA-1116,ORA-1110,并可能伴随标识操作系统级别的错误，比如ORA-7368，有时以正常方式shutdown数据库根本shutdown不下来。
警告：文章中所提及的步骤是供oracle的全球技术支持使用的。
特别是步骤6中的_corrupted_rollback_segments参数，使用后需要重建数据库，在使用这个参前请观察一下所有其它的选项。
解决方法解释：如下的解决方法取于检测问题出现时数据库所处于状态:I. 数据库是处于关闭状态的。
试图打开数据库时报ORA-1157和ORA-1110错误，这时的解决方法取于数据库是否是正常shutdown的(使用normal或immediate选项。
I.A.数据库是正常shutdown的如果数据数据库是正常shutdown的，最简单的解决方法是以offline drop选项删除丢失或损坏的数据文件，以restriceted模式打个数据库，删除并重建这个数据文件所属的那个回滚表空间。
如果数据库是以shutdown abort或自己崩溃掉的则不要遵循这个过程。
步骤如下：1、确认数据库是正常shutdown的。
可以检查alter.log这个文件，定位到最后几行看是否可以看到如下的信息："alter database dismountCompleted: alter database dismount"这当然也包括以正常方式shutdown,接然试图启动数据库确失败的状况。
undo表空间损坏
JServer Release 9.2.0.1.0 - Production
[ora920@tkyte-pc-isdn ora920]$ ls
control01.ctl cwmlite01.dbf indx01.dbf redo02.log redo0B.log temp01.dbf
undo_management string AUTO
undo_retention integer 10800
undo_suppress_errors boolean FALSE
create spfile='E:\oracle\ora92\database\SPFILESHAOMF.ORA' FROM pfile='E:\oracle\admin\shaomf\pfile\init.ora.162007221035';
大功告成。
==================
------------------------------ ---------------- ------------------------------
SYSTEM ONLINE SYSTEM
_SYSSMU1$ ONLINE UNDOTBS1
create spfile='d:\oracle\ora92\database\SPFILESFRJORCL.ORA' FROM pfile='d:\oracle\admin\sfrjorcl\pfile\init.ora.5102010215215';
Oracle误删UNDO表空间故障处理
Oracle 误删UNDO表空间故障处理H.sdon操作人员操删除ORACLE UNDO表空间，系统报ORA-01116: error in opening database file 25错误。
解决思路：删除原有UNDO表空间，新建一个UNDOTBS2表空间进行替换。
1、生成init文件Create pfile from spfile记住：在生成新的init文件前应对原有文件做好备份或将init文件生成在不同的目录名称下面2、修改init.ora文件undo_management=MANUALundo_retention=10800undo_tablespace=undotbs01rollback_segments='SYSTEM'3、使用PFILE重新启动数据库Startup pfile=’$ORACLE_HOME/dbs/init[sid].ora此步数据库已经能正常OPEN，但在做数据库操作的时候还会报以下错误SQL> shutdown immediate;ORA-00376: file 2 cannot be read at this timeORA-01110: data file 2: '/oradata/irms/undotbs01.dbf'4、使用以下命令对数据文件进行offline dropalter database datafile '/oradata/irms/undotbs04.dbf' offline drop;alter database datafile '/oradata/irms/undotbs03.dbf' offline drop;alter database datafile '/oradata/irms/undotbs01.dbf' offline drop;alter database datafile '/oradata/irms/undotbs02.dbf' offline drop;5、创建新的UNDO表空间UNDOTBS2create undo tablespace undotbs2datafile '/oradata/irms/undotbs20.dbf' size 500M;6、在init.ora更改默认UNDO表空间,使其启动后默认UNDO表空间为undotbs2,undo_management=AUTO后重新启动7、删除UNDOTBS1表空间，报Drop tablespace undotbs1ORA-01548: 已找到活动回退段'_SYSSMU1$'，8、查看回滚段使用情况select segment_name,status,tablespace_name from dba_rollback_segs;SEGMENT_NAME STATUS TABLESPACE_NAME------------------------------ ---------------- ------------------------------SYSTEM ONLINE SYSTEM_SYSSMU1$ NEEDS RECOVERY UNDOTBS1_SYSSMU2$ NEEDS RECOVERY UNDOTBS1_SYSSMU3$ NEEDS RECOVERY UNDOTBS1_SYSSMU4$ NEEDS RECOVERY UNDOTBS1_SYSSMU5$ NEEDS RECOVERY UNDOTBS1_SYSSMU6$ NEEDS RECOVERY UNDOTBS1_SYSSMU7$ NEEDS RECOVERY UNDOTBS1_SYSSMU8$ NEEDS RECOVERY UNDOTBS1_SYSSMU9$ NEEDS RECOVERY UNDOTBS1_SYSSMU10$ NEEDS RECOVERY UNDOTBS1可以看到_SYSSMU1$-_SYSSMU10$状态都为need recovery状态9、关闭数据库，更改init.ora默认UNDO表空间及其它参数undo_management=manualundo_retention=10800undo_tablespace=undotBS2_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$, _SYSSMU10$)10、以新的init.ora启动数据库Startup pfile=’$ORACLE_HOME/dbs/init[sid].ora11、删除UNDOTBS1Drop tablespace undotbs1 including contents查看回滚段状态,UNDOTBS中的信息已经没有SQL> select segment_name,status,tablespace_name from dba_rollback_segs;SEGMENT_NAME STATUS TABLESPACE_NAME------------------------------ ---------------- ------------------------------SYSTEM ONLINE SYSTEMSYSSMU11$ ONLINE UNDOTBS2_SYSSMU12$ ONLINE UNDOTBS2_SYSSMU13$ ONLINE UNDOTBS2_SYSSMU14$ ONLINE UNDOTBS2_SYSSMU15$ ONLINE UNDOTBS2_SYSSMU16$ ONLINE UNDOTBS2_SYSSMU17$ ONLINE UNDOTBS2_SYSSMU18$ ONLINE UNDOTBS2_SYSSMU19$ ONLINE UNDOTBS2_SYSSMU20$ ONLINE UNDOTBS211、将SPFILE中的UNDO_TABLESPACE改成UNDOTBS2后启动正常附言:。
损坏undo文件的恢复
有备份的情况和正常的数据文件恢复一样注：在做下面的任何恢复操作前必须做整个数据库的完全备份(数据文件的copy) SQL> conn block_user/block已连接。
SQL> DELETE FROM T2 ;已删除3750行。
--abort方式关闭数据库SQL> CONN /AS SYSDBA已连接。
SQL> SHUTDOWN ABORTORACLE 例程已经关闭。
--重新启动数据库SQL> STARTUPORACLE 例程已经启动。
Total System Global Area 135339844 bytesFixed Size 454468 bytesVariable Size 109051904 bytesDatabase Buffers 25165824 bytesRedo Buffers 667648 bytes数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件2 - 请参阅DBWR 跟踪文件ORA-01110: 数据文件2: 'D:\ORACLE\ORADA TA\ORCL\UNDOTBS01.DBF'SQL> RECOVER DA TABASEORA-00283: 恢复会话因错误而取消ORA-01110: 数据文件2: 'D:\ORACLE\ORADA TA\ORCL\UNDOTBS01.DBF' ORA-01157: 无法标识/锁定数据文件2 - 请参阅DBWR 跟踪文件ORA-01110: 数据文件2: 'D:\ORACLE\ORADA TA\ORCL\UNDOTBS01.DBF'SQL> exit从Oracle9i Enterprise Edition Release 9.2.0.4.0 - ProductionWith the Partitioning, OLAP and Oracle Data Mining optionsJServer Release 9.2.0.4.0 - Production中断开C:\Documents and Settings\Administrator>rman恢复管理器: 版本9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.RMAN> connect target /连接到目标数据库: ORCL (DBID=1186898049)RMAN> run{restore datafile 2;}启动restore 于20-11月-08正在使用目标数据库控制文件替代恢复目录分配的通道: ORA_DISK_1通道ORA_DISK_1: sid=12 devtype=DISK通道ORA_DISK_1: 正在开始恢复数据文件备份集通道ORA_DISK_1: 正在指定从备份集恢复的数据文件正将数据文件00002恢复到D:\ORACLE\ORADA TA\ORCL\UNDOTBS01.DBF通道ORA_DISK_1: 已恢复备份段1段handle=D:\BACKSCRIPT\DA TA\DBFULL_ORCL_D2*******_T670763188_S25_P1 tag=DB-FULLparams=NULL通道ORA_DISK_1: 恢复完成完成restore 于20-11月-08RMAN> recover datafile 2 ;启动recover 于20-11月-08使用通道ORA_DISK_1正在开始介质的恢复存档日志线程 1 序列 1 已作为文件D:\ORACLE\ORA92\RDBMS\ARC00001.001 存在于磁盘上存档日志线程 1 序列 2 已作为文件D:\ORACLE\ORA92\RDBMS\ARC00002.001 存在于磁盘上存档日志线程 1 序列 3 已作为文件D:\ORACLE\ORA92\RDBMS\ARC00003.001 存在于磁盘上存档日志线程 1 序列 4 已作为文件D:\ORACLE\ORA92\RDBMS\ARC00004.001 存在于磁盘上存档日志线程 1 序列 5 已作为文件D:\ORACLE\ORA92\RDBMS\ARC00005.001 存在于磁盘上存档日志文件名=D:\ORACLE\ORA92\RDBMS\ARC00001.001 线程=1 序列=1 存档日志文件名=D:\ORACLE\ORA92\RDBMS\ARC00002.001 线程=1 序列=2 存档日志文件名=D:\ORACLE\ORA92\RDBMS\ARC00003.001 线程=1 序列=3 完成介质的恢复完成recover 于20-11月-08RMAN> alter database open ;数据库已打开RMAN>无备份的情况—数据库正常关闭(包括归档和非归档)SQL> conn / as sysdba已连接。
Oracle11GRAC数据库undo表空间使用率100%故障分析解决
Oracle11GRAC数据库undo表空间使⽤率100%故障分析解决早上的时候，监控系统预警，⼀套⽣产库oracle rac undo 表空间使⽤率超过预警值，使⽤率⼏分钟钟之内达到100%，登陆数据库紧急扩
容，查看是否有长时间执⾏的查询、⼤的未提交的事务在执⾏，检查后⼀切正常。
⼏分钟后undo 表空间使⽤率再次达到100%，为了不影响⽣产业务，再次进⾏扩充。
检查数据库参数undo 保留时间undo_retention 为半个⼩时，没有发⽣过变动。
查询mos，找到 BUG 5387030: AUTOMATIC TUNING OF UNDO_RETENTION CAUSING SPACE PROBLEMS，是由于⾃动undo 保留调整导致的undo 表空间耗尽，11g 版本可以通过增加隐藏参数_undo_autotune = false 禁⽤该特性，参数为动态参数，可以在线调整⽣效，于是调整该参数:alter system set "_undo_autotune" =false scope=both sid='*' 。
过⼏分钟后观察，undo表空间使⽤率迅速下降⾄30%，后⾯观察使⽤率平稳，没再发⽣快速增长导致表空间满的情况，特此记录。
ORACLE 数据库故障解决方案
ORACLE 数据库故障解决方案一、引言ORACLE 数据库是一款广泛应用于企业级应用系统的关系数据库管理系统。
然而，在数据库运行过程中，可能会浮现各种故障，如数据损坏、性能下降、连接问题等。
本文将提供一些常见的 ORACLE 数据库故障解决方案，以匡助管理员快速解决问题并恢复数据库的正常运行。
二、故障解决方案1. 数据损坏数据库数据损坏可能导致数据丢失或者无法访问。
以下是一些常见的数据损坏问题及解决方案：- 数据块损坏：使用RMAN 工具进行数据块检查，并使用备份数据进行恢复。
- 表空间损坏：使用RMAN 工具进行表空间检查，并使用备份数据进行恢复。
- 表或者索引损坏：使用 DBMS_REPAIR 工具进行修复，或者从备份中恢复受损的对象。
2. 性能下降数据库性能下降可能导致用户体验差和系统响应延迟。
以下是一些常见的性能下降问题及解决方案：- 确保数据库服务器具有足够的硬件资源，如 CPU、内存和磁盘空间。
- 优化 SQL 查询语句，使用索引、避免全表扫描等。
- 定期采集和分析数据库性能指标，如等待事件、锁定和死锁等，以找出性能瓶颈并采取相应措施。
3. 连接问题连接问题可能导致用户无法连接到数据库或者连接超时。
以下是一些常见的连接问题及解决方案：- 检查数据库监听器是否运行，并确保监听器配置正确。
- 检查网络连接是否正常，如网络配置、防火墙设置等。
- 检查数据库实例是否正常启动，并检查数据库服务是否处于运行状态。
4. 容灾和备份恢复容灾和备份恢复是数据库管理的重要方面，以确保数据的可靠性和可恢复性。
以下是一些常见的容灾和备份恢复问题及解决方案：- 使用 Oracle Data Guard 实现数据库的冗余和自动故障转移。
- 定期进行数据库备份，并测试备份的可恢复性。
- 在灾难发生时，使用备份进行数据库恢复，并确保恢复过程的可靠性和完整性。
5. 安全性问题数据库安全性问题可能导致数据泄露、未授权访问等风险。
oracl数据库重做日志文件损坏处理
昨日，一客户反应在服务器因掉电重启后，客户端不能正常连接服务器端，简单远程过后发现是ORACLE数据库无法正常启动导致。
处理过程如下：1.查看系统服务SERVICE正常启动，但是所有工具均无法连接数据库；2.用SYS账户可以正常连接到数据库中，但是通过命令startup时出现错误，也就是可以通过mount挂载数据库，但是alter database open时发生错误，如下：3.基本已经确认是重做日志文件出了问题，重做日志文件总共有好几个，如何确定是哪一个，再通过如下确认即已经确认是REDO2文件出了问题4.随后再查看是否当前日志文件，和是否已经归档，不同的状态决定后续的处理会不相同，通过语句select * from v$log查看，如下，发现是当前日志文件。
5.这会比较难以处理，在网上查找相应的文章，要么是选择通过备份文件恢复，要么是通过不完全恢复，这会导致可能丢失一部分的数据，因目前没有可以进行恢复的备份文件，只能选择进行不完全恢复，此时发现出定时按期检查备份文件的重要性了。
但是在将数据文件备份至其他盘时，复制日志文件时发现日志文件完全无法读取和打开，怀疑是硬盘问题导致。
6.通过WINDOWS的磁盘检查工具进行修复，重启后，果然发现REDO2文件进行的修复，完成后可以正常的读取了。
7.首先将整个数据文件夹复制至其他盘，为避免出错可以进行恢复处理。
8.参考文章/thread-175996-1-1.html，基本比较详尽的介绍了日志文件出问题的处理方法，于是，按照其步骤，首先shutdown immediate然后备份一下spfile，即create pfile = 'd:\init.ora' from spfile根据文章所说，在备份出的pfile中加入参数 _allow_resetlogs_corruption=TRUE重新启动数据库startup mount pfile = 'd:\init.ora'然后再对数据库进行不完全的恢复recover database until cancel;cancel后会出现一大堆英文提示，不必理会，通过命令alter database open resetlogs处理9.正常情况下，此时可以正常打开数据库了，赶紧备份，再重新恢复处理即可，但是此时这里又出现了一个其他的错误，ORA-00600，数据库致命错误，这下就头痛了，网上百度了一下，此错误的可能性相当的广泛。
Oracle 10g UNDO表空间过大导致磁盘空间不足的解决
在Oracle 10g数据库的应用中，出现了UNDO表空间过大导致磁盘空间不足而崩溃的现象。
对此问题进行分析后，总结了出现该问题的原因主要有以下两点：1. 有较大的事务量让Oracle Undo自动扩展，产生过度占用磁盘空间的情况；2. 有较大事务没有收缩或者没有提交所导制；说明：本问题在Oracle系统管理中属于比较正常的一现象，日常维护多注意对磁盘空间的监控。
Oracle 10g 有自动Automatic Undo Retention Tuning 这个特性。
设置的 undo_retention 参数只是一个指导值，缺省值900秒,，Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误.。
通过查询V$UNDOSTAT（该视图记录4天以内的UNDO表空间使用情况，超过4天可以查询DBA_HIST_UNDOSTAT视图）的tuned_undoretention （该字段在10G版本才有，9I是没有的）字段可以得到Oracle 根据事务量（如果是文件不可扩展，则会考虑剩余空间）采样后的自动计算出最佳的 retenton 时间.。
1)查询retention值show parameter undo_retention查询自动计算出最佳的retenton 时间select tuned_undoretention, maxquerylen, maxqueryid from v$undostat;2）更改retention值ALTER SYSTEM SET undo_retention=10800 SCOPE=BOTH;这样对于一个事务量分布不均匀的数据库来说,，就会引发潜在的问题--在批处理的时候可能 Undo 会用光，而且这个状态将一直持续，不会释放。
如何取消10g的auto UNDO Retention Tuning，有如下三种方法：(1)10.2.0.2/10.2.0.3有相应的patch，这个bug在10.2.0.4中已经修复，建议找时间停机打patch.(2)设置隐含参数_smu_debug_mode=33554432，将tuned_undoretention取值算法修正为max(maxquerylen secs + 300,undo_retention )，不建议使用SQL> Alter system set"_smu_debug_mode" = 33554432;(3)设置隐含参数_undo_autotune=false，关闭自动undo retention调整特性，不建议使用SQL> Alter system set "_undo_autotune" = false;from metalink 420525.1： AutomaticTuning of Undo_retention Causes Space Problems.解决步骤：1. 启动SQLPLUS，并用sys登陆到数据库。
undo文件处理
Fixed Size 1250428 bytes
Variable Size 264244100 bytes
Database Buffers 339738624 bytes
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF'
恢复步骤:因为undo文件不保存数据,可以直接drop 后重建.
数据库的临时文件和undo文件不需要做备份,丢失后可以恢复,数据不会有丢失.
一,临时表空间的文件丢失后,在数据库启动后自动创建,不需要做干预.
模拟:在数据库shutdown后将临时文件删除,启动的时候发现自动创建.
二,undo表空间对应的文件丢失.
模拟:在数据库shutdown后将undo文件删除,启动的时候出错:
1,drop undo文件.
SQL> alter database datafile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF' offline drop;
Database altered.
2,将undo管理改为manual
SQL> alter system set undo_management='MANUAL' scope=spfile;
System altered.
undo表空间故障特殊恢复ORA-01092ORACLE实例终止强制断开连接
undo表空间故障特殊恢复（二）这个测试的是instance recover（单实例里就是crash recovery）的恢复需要故障undo里的数据，一般的情况instance recover使用联机日志文件的，当发生多版本更新的故障，也可需要回滚段数据的。
测试表SQL> select count(1) from tabtest;COUNT(1)----------17732SQL> insert into tabtest select * from tabtest where rownum<2001;已创建2000行。
SQL> insert into tabtest select * from tabtest where rownum<2001;已创建2000行。
模拟断电故障，让回滚段的数据没来得回滚，使回滚段在数据库关闭时，保留未commit的事务SQL> shutdown abortORACLE 例程已经关闭。
SQL> quit从Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing options 断开只有退出sqlplus环境，才能更改回滚段数据文件，删除回滚数据文件，模拟回滚段丢失C:/Documents and Settings/Administrator>sqlplus "/as sysdba"SQL*Plus: Release 10.2.0.4.0 - Production on 星期四9月9 22:23:50 2010Copyright (c) 1982, 2007, Oracle. All Rights Reserved.已连接到空闲例程。
UNDO 表空间满了的处理方法
表空间已更改。
4、删除原来的UNDO表空间:
SQL> drop tablespace UNDO incl ing contents AND DATAFILES CASCADE CONSTRAINTS ;
表空间已删除。
如果只是drop tablespace UNDO ，则只会在删除控制文件里的记录，并不会物理删除文件。
表已创建。
SQL> begin
2 for i in 1 .. 100000 loop
3 insert into dba val s(i);
4 commit;
5 end loop;
6 end;
7 /
begin
*
第 1 行出现错误:
4 commit;
5 end loop;
6 end;
7 /
PL/SQL 过程已成功完建立新的表空间UNDOTBS2
SQL> CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE ‘F:\backup\undo03.dbf’ size 100M reuse;
二． UNDO 表空间满了的处理方法
2.1 先模拟UNDO 表空间满的情况
SQL> alter system set undo_retention=10800; — 3个小时
系统已更改。
SQL> create undo tablespace undo datafile ‘F:\backup\undo.dbf’ size 1m ;
undo介绍及具体使用
--undo 的作用oracle 会将数据块上修改之前的数据【前映像】保存在回滚段中，这样当我们需要进行回滚(rollback)的时候就很容易能从回滚段中将之前的数据取出来将数据块上面的数据还原回来（数据回滚、闪回功能、和在数据库意外宕机之后都需要使用undo数据进行回滚操作）一个实例只能有一个undo表空间【RAC每个实例一个】 oracle 绝对禁止一个用户查看另一个用户未提交的事务数据。
--undo表空间满了怎么办？处理方法有两种：1添加undo表空间数据文件2重新创建新的undo表空间替换默认的1查看当前UNDO 表空间（例如现在只有一个undotbs1）SQL> show parameter undo;SQL> select * from dba_data_files where tablespace_name like'UNDOTBS*';2创建新的undo 表空间SQL> create undo tablespace UNDOTBS2 datafile'/oracle/oradata/itpuxdb/untotbs02.dbf' size100m autoextend off extent management local;3用新创建的undotbs2替换默认的undo表空间SQL> alter system set undo_tablespace=undotbs2 scope=both;SQL> show parameter undo4删除原来被替换的undotbs1SQL> drop tablespace UNDOTBS1 including contents and datafiles;注意：在删除的时候如果正在使用的那么写查询当前表空间有哪些事务是仍然在活动的如果不需要的可以手动kill 或者等它做完。
处理方法：SQL> select * from dba_2pc_pending; 查询出来SQL> commit force‘local_tran_id’; 强制提交--ORA-01555快照过旧错误：当我们的事务需要使用undo 来构建的时候，而此时对应的undo已经不存在就会出现ORA-01555原因是SQL 语句执行时间太长，或者undo 表空间过小，或者事务量过大，或者过于频繁的提交，导致执行SQL 过程中进行一致性读时，SQL执行后修改的前镜像(既UNDO数据) 在UNDO 表空间中已经被覆盖，不能构造一致性读块(CR blocks)。
ORA-00603，ORA-01595，ORA-00600非正常关机导致的UNDO损坏
ORA-00603，ORA-01595，ORA-00600⾮正常关机导致的UNDO损坏如果⾮必要⼀般不会重启服务器，如果重启服务器，必须先要正确关闭oracle，然后在重启。
⼈⽆完⼈，总有⼈会犯错误，其中⼀台线上oracle维护者，失误，直接将oracle服务器重启了，重启之后，直接造成了，数据库提⽰ora-00603: ORACLE server session terminated byfatal error, ⽤sqlplus 登录oracle;1 2 3su - oraclealter system set events '10046 trace name context off'; alter system set timed_statistics=false;然后重启oracle，最后发现还是报错，去了oracle 的⽇志⽬录并查找trace⽂件1 2 3 4 5 6cd /data0/oracle/admin/dzinfoiims/bdump/cat dzinfoiims_smon_6401.trcSMON: following errors trapped and ignored:ORA-01595: error freeing extent (4) of rollback segment (1))ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [62], [32], [], [], [], [], []最后⼏⾏显⽰ ora-01595，按照提⽰因为不正确关闭oracle导致回滚段失败，基本上可以断定undo表空间损坏，但是可以通过重建undo⽂件。
1）⽣成pfile1SQL> create pfile from spfile修改pfile参数：1 2 3#*.undo_management='AUTO' *.undo_management='MANUAL' _allow_resetlogs_corruption=true2）以pfile启动数据库010203 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22SQL> startup mount pfile='/data0/oracle/product/10.2.0/db_1/dbs/initdzinfoiims.ora'; ORACLE instance started.Total System Global Area 612368384 bytesFixed Size 2085872 bytesVariable Size 373296144 bytesDatabase Buffers 230686720 bytesRedo Buffers 6299648 bytesDatabase mounted.SQL> show parameter undoNAME TYPE------------------------------------ ----------------------VALUE------------------------------undo_management stringMANUALundo_retention integer900undo_tablespace stringUNDOTBS1SQL> alter database open;Database altered.3）新建undo表空间undotbs2 12 3 4 5 6 7SQL> create undo tablespace undotbs2 datafile '/data0/oracle/oradata/dzinfoiims/undotbs02.dbf' size 1G; table space created.SQL> drop tablespace undotbs1;The deleted table space .SQL> alter tablespace undotbs2 rename to undotbs1;table space was alted.。
Oracle释放undo表空间的实际操作步骤
Oracle释放undo表空间的实际操作步骤在实际操作中数据库维护数据库的编程的运行中我们经常会遇到过这样的情况，就是Oracle释放undo表空间，以下的文章主要是对Oracle释放undo表空间的实际操作步骤的介绍，望你浏览之后会有所收获。
对大数据量做DML操作之后，得把Oracle释放undo表空间扩展到十几个G或者几十个G 但是这些表空间的所占用磁盘的物理空间又不会被Oracle所释放。
如果你用的是PC机很可能会遇到磁盘空间不足的问题，经过个人整理经过如下操作可以重构Oracle释放undo表空间，同样temp表空间也可能在你查询大数据或则创建索引的时候无限扩大导致磁盘空间不足，同样可以用如下方式解决此问题：查看各表空间名称1.select name from v$tablespace查看某个表空间信息1.select file_name,bytes/1024/1024 from dba_data_files where tablespace_name like 'UNDOTBS1';查看回滚段的使用情况，哪个用户正在使用回滚段的资源，如果有用户最好更换时间(特别是生产环境)。
1.select ername, from v$transaction t,v$rollstat r, v$rollname u,v$session s2.where s.taddr=t.addr and t.xidusn=n and n=n order by ername;检查UNDO Segment状态1.select usn,xacts,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks from v$rollstat order by rssize;创建新的Oracle释放UNDO表空间，并设置自动扩展参数;1.create undo tablespace undotbs2 datafile'D:\Oracle\PRODUCT\10.1.0\ORADA TA\ORCL\UNDOTBS02.DBF'size 10m reuse autoextend on next 100m maxsize unlimited;动态更改spfile配置文件;1.alter system set undo_tablespace=undotbs2 scope=both;等待原UNDO表空间所有UNDO SEGMENT OFFLINE;1.select usn,xacts,status,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks from v$rollstat order by rssize;再执行看UNDO表空间所有UNDO SEGMENT ONLINE;1.select usn,xacts,status,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks from v$rollstat order by rssize;删除原有的UNDO表空间;1.drop tablespace undotbs1 including contents;确认删除是否成功;1.select name from v$tablespace;最后需要在重启数据库或者重启计算机后到存储数据文件的路径下删除数据文件(为什么要手动删除呢：以上步骤只是删除了Oracle释放undo表空间的逻辑关系，即删除了数据文件在数据字典中的关联，不会自动删除项关联的数据文件)。
RMAN备份与恢复之UNDO表空间丢失-电脑资料
RMAN备份与恢复之UNDO表空间丢失-电脑资料一 UNDO表空间讲解在上一篇文章（RMAN备份与恢复之可脱机数据文件丢失）中，我们讲到可脱机数据文件丢失怎么处理，这篇文章我们讲解UNDO表空间丢失的解决办法，。
UNDO表空间用于存放UNDO数据，当执行DML操作（INSERT、UPDATE、DELETE）的时候，ORACLE会将这些操作的旧数据写入到UNDO段。
UNDO数据也称为回滚数据，用于确保数据的一致性。
作用包括：回退事、读一致性、事务恢复、闪回查询。
9i开始，管理UNDO数据可以使用UNDO表空间，也可以使用回滚段。
10g开始，ORACLE已经放弃使用回滚段。
提到UNDO表空间，不得不提UNDO 段。
UNDO Segment分为两个部分，一个是UNDO Segment Head，还有一个是UNDO Segment Block（也称为事务槽)。
UNDO Segment Head中包含了这个回滚段的事务信息，而且有一个指针指向Undo Segment Block。
UNDO表空间是非常重要的，如果丢失，会出现无法对数据进行更新。
平时的数据库管理中应该注意UNDO表空间的空间是否足够，采用自动扩展还是限制大小，undo_retention 值的设定等等。
二备份与恢复UNDO表空间讲解备份与恢复UNDO表空间，首先要有备份。
使用RMAN备份完成后，我们模拟UNDO表空间丢失。
此时做更新操作仍然成功，因为shared pool和buffer cache存放了更新的信息。
如果我们刷新shared pool和buffer cache，再做连接用户或者更新操作，会提示数据文件找不到。
因为UNDO表空间丢失，并且UNDO表空间不可脱机，所以我们不能在数据库运行状态下对UNDO表空间进行恢复。
这就要求我们关闭数据库进行恢复操作。
如果在真实环境中进行操作，务必在业务低峰期或者测试库进行操作。
我们使用一致性关闭数据库会失败，只有强制关闭。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Oracle数据库教程——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> startupORA-00376: 此时无法读取文件18ORA-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 SYSTEME:\ORACLE\ORADATA\erpaa\UNDOTBS01.DBF ONLINEE:\ORACLE\ORADATA\erpaa\USERS01.DBF ONLINEE:\ORACLE\ORADATA\erpaa\XDB01.DBF ONLINEE:\ORACLE\ORADATA\erpaa\USER.ORA ONLINEZ:\ORADATA\USER\USER004.DBF ONLINEY:\ORADATA\UNDO\UNDO02.DBF RECOVERY:\ORADATA\UNDO\UNDO03.DBF RECOVER这里发现undo空间需要恢复，所以先恢复一下数据库，看能否恢复！SQL> recover database;Database recovered.再次查看的时候，仍然处理需要恢复的状态。
--修改刚才备份的参数文件pfile，数据库启动到不一致的状态，添加undo 表空间，并删除原undo表空间加上如下两个参数：*._allow_resetlogs_corruption=true*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_S YSSMU4$,_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';数据库启动后，重建undo1SQL> 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: 0hash: [1e7ffce8,1a7a994c] lru: [1dfe220c,1dfe1f1c]ckptq: [NULL] fileq: [NULL]st: XCURRENT md: NULL rsop: 0x00000000 tch: 3flags: gotten_in_current_modeLRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]*** 2013-08-19 14:10:17.000ksedmp: internal or fatal errorORA-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$','_S YSSMU6$','_SYSSMU5$','_SYSSMU4$','_SYSSMU3$','_SYSSMU2$','_SYSS MU1$'SQL> shutdown immediate关闭数据库，修改参数文件pfile，做如下调整：*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_S YSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9 $,_SYSSMU10$，_SYSSMU11$)undo_management=manualSQL> startup pfile='c:\pfilebak0819.ora';数据库启动后，这时候，需要把这些回滚段应该是原来undotbs1的，应该把它drop掉SQL> drop rollback segment "_SYSSMU11$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU10$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU9$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU8$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU7$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU6$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU5$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU4$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU3$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU2$";Rollback segment droppedSQL> drop rollback segment "_SYSSMU1$";Rollback segment dropped再次关闭和开启数据库SQL> shutdown immediate;修改pfile*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_S YSSMU4$,_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';至此，数据库恢复正常！更多文章可见：我们其中一位工程师的博客：/。