无备份情况下回复undo表空间


UNDO表空间存储着DML操作数据块的前镜像数据,在数据回滚,一致性读,闪回操作,实例恢复的时候都可能用到UNDO表空间中的数据。如果在生产过程中丢失或破坏了UNDO表空间,可能导致某些事务无法回滚,数据库无法恢复到一致性的状态,Oracle实例可能宕机,之后实例无法正常启动;如果有多个UNDO表空间数据文件,丢失其中一个数据文件数据库实例可能不会导致实例宕机,数据库无法干净的关闭(只能SHUTDOWN ABORT),数据库实例能正常的重启,但所有未回滚的数据块依然无法处理,尝试新建UNDO表空间、exp、expdp等操作都会收到ORA-604, ORA-376, and ORA-1110的报错,下面通过一个实际的案例讨论如何处理UNDO损坏后的恢复。

如果你的数据库还能干净的关闭,但在正常情况下无法新建UNDO表空间,那么执行以下的步骤:
I.A. THE DATABASE WAS CLEANLY SHUT DOWN
---------------------------------------
If you are ABSOLUTELY POSITIVE that the database was cleanly shutdown,
i.e., it was closed with either shutdown NORMAL or IMMEDIATE, then
the simplest solution is to offline drop the missing datafile, open the
database in restricted mode, and then drop and recreate the undo 
tablespace to which the file belonged.  DO NOT follow this procedure
if the database was shut down ABORT or if it crashed.
The steps are:
1. Make sure the database was last cleanly shut down.
   Check the alert.log file for this instance.  Go to the bottom of
   the file and make sure the last time you shut the database down
   you got the messages:
        "Shutting down instance (immediate)"
   OR
"alter database close normal 
         Completed: alter database close normal"
   This also includes the case of a clean shutdown followed by a
   failed attempt to startup the database.  In that case, Oracle will
   issue error messages and shut itself down abort.  For the purposes
   of this solution, though, this counts as a clean shutdown.
   If that is not the case, i.e., if the last time YOU shut the database
   down it was in abort mode, or the database crashed itself, it is
   NOT safe to proceed.  You should follow the instructions for
   case I.B below.
2. If using automatic UNDO_MANAGEMENT, comment out this entry from the parameter
   file, or set it to MANUAL. 
将UNDO_MANAGEMENT修改为MANUAL是因为UNDO表空间在自动管理模式下,如果不能成功新建回滚段(后面会DROP现有表空间)将导致数据库实例宕机。
   If using rollback segments, remove all the rollback segments in the
   tablespace to which the lost datafile belongs from the ROLLBACK_SEGMENTS
   parameter in the init.ora file for this instance.  If you are not sure about which rollbacks are
   in that tablespace, simply comment out the whole ROLLBACK_SEGMENTS entry.
3. Mount the database in restricted mode.
   SQL> STARTUP RESTRICT MOUNT
以RESTRICT模式启动实例是避免在处理过程中有其他客户端连接。
4. Offline drop the lost datafile.
   SQL> ALTER DATABASE DATAFILE ‘‘ OFFLINE DROP;
5. Open the database.
   SQL> ALTER DATABASE OPEN
   You should receive the message "Statement processed,". 
   If instead you get ORA-604, ORA-376, and ORA-1110, it is likely the shutdown
   was not normal/immediate.  Review the rest of the options available and/or
   contact Oracle Support Services.  
6. Drop the undo tablespace or tablespace which contains rollback segments
   to which the datafile belonged.
   SQL> DROP TABLESPACE INCLUDING CONTENTS;
7. Recreate the undo tablespace.  If using rollback segments, recreate the
   rollback segment tablespace and all it‘s rollback segments.  Remember to
   bring the rollbacks online after you create them.
  SQL> CREATE TABLESPACE UNDOTBS2 DATAFILE <datafile_name< span="" style="word-wrap: break-word;">> SIZE 1G AUTOEXTEND ON NEXT 100M;
8. Edit the parameter file setting:
   UNDO_MANAGEMENT=AUTO
   UNDO_TABLESPACE=
   If using rollback segments, reinclude the rollbacks you just recreated in
   the ROLLBACK_SEGMENTS parameter in the init.ora file for this instance.
   As rollback segments were brought online in step #7, no need to proceed
   with shutdown/startup as needed for undo tablespace.  All that is required
   is:
   SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

如果你的数据库不能正常关闭,只需要在重启数据库实例之前将下面的参数加到参数文件:
_allow_resetlogs_corruption=TRUE
_offline_rollback_segments="_SYSSMU1$"
_offline_rollback_segments="_SYSSMU2$"
_offline_rollback_segments="_SYSSMU3$"
_offline_rollback_segments="_SYSSMU4$"
_offline_rollback_segments="_SYSSMU5$"
_offline_rollback_segments="_SYSSMU6$"
_offline_rollback_segments="_SYSSMU7$"
_offline_rollback_segments="_SYSSMU8$"
_offline_rollback_segments="_SYSSMU9$"
_offline_rollback_segments="_SYSSMU10$"
_corrupted_rollback_segments="_SYSSMU1$"
_corrupted_rollback_segments="_SYSSMU2$"
_corrupted_rollback_segments="_SYSSMU3$"
_corrupted_rollback_segments="_SYSSMU4$"
_corrupted_rollback_segments="_SYSSMU5$"
_corrupted_rollback_segments="_SYSSMU6$"
_corrupted_rollback_segments="_SYSSMU7$"
_corrupted_rollback_segments="_SYSSMU8$"
_corrupted_rollback_segments="_SYSSMU9$"
_corrupted_rollback_segments="_SYSSMU10$"
    rollback_segments的具体值可以从v$rollname中获得。
处理完成后停止数据库实例,去掉以上参数,修改好UNDO相关参数即可正常启动数据库实例,之后再手动处理TEMP表空间丢失的TEMP数据文件。
虽然数据库实例能够正常启动,也恢复了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

时间: 2024-08-05 06:56:52

无备份情况下回复undo表空间的相关文章

Oracle备份恢复之无备份情况下恢复undo表空间

UNDO表空间存储着DML操作数据块的前镜像数据,在数据回滚,一致性读,闪回操作,实例恢复的时候都可能用到UNDO表空间中的数据.如果在生产过程中丢失或破坏了UNDO表空间,可能导致某些事务无法回滚,数据库无法恢复到一致性的状态,Oracle实例可能宕机,之后实例无法正常启动:如果有多个UNDO表空间数据文件,丢失其中一个数据文件数据库实例可能不会导致实例宕机,数据库无法干净的关闭(只能SHUTDOWN ABORT),数据库实例能正常的重启,但所有未回滚的数据块依然无法处理,尝试新建UNDO表空

迁移/home目录至新硬盘分区总结--无备份情况下

搞了一天,终于成功迁移.由于一开始就没备份过程实在很曲折. 希望本篇对那些没有备份习惯的朋友们有所帮助. 准备工作: sudo vim /etc/fstab 在文件中加入: /dev/sdb8       /home            ext4    user,rw 0       2 这里其实有问题的,后面会提到 一个新的linux分区,这里我的新分区是sdb8,个人不尽相同.我用的是ext4格式,注意要新的,不要有坏块,最好重新格式化下.我就是因为没格式化,吃过亏,logo界面就提示挂载

错误ORA-01110,在已删除数据文件情况下如何删除表空间

如果先行删除了数据文件,再删除表空间,drop tablespace 会出现如下错误: ORA-01116: error in opening database file 89 ORA-01110: data file 89: '/templv/osm/OSM_TABP_00.dbf' ORA-27041: unable to open file Linux Error: 2: No such file or directory Additional information: 3 解决方案: 首

ORACLE11gR2-RAC之OCR无备份情况下损坏恢复

情景介绍:做OCR备份恢复实验,OCR有4份自动备份.将OCR磁盘从+DATA替换为+OCR2(/dev/raw/raw4) 完成之后使用ocrconfig -manualbackup手动备份OCR,完成之后对/dev/raw/raw4执行dd操作.关闭集群,启动集群,发现集群不能启动. 问题分析(假设不知道问题出在哪里,先分析):1.检查集群服务,发现CRS和CSS服务未能正常启动crsctl check crs2.检查CRS和CSS日志,发现OCR磁盘异常3.恢复OCR(其实就是使用root

MySQL5.7新特性——在线收缩undo表空间

1. MySQL 5.5时代的undo log 在MySQL5.5以及之前,大家会发现随着数据库上线时间越来越长,ibdata1文件(即InnoDB的共享表空间,或者系统表空间)会越来越大,这会造成2个比较明显的问题: (1)磁盘剩余空间越来越小,到后期往往要加磁盘: (2)物理备份时间越来越长,备份文件也越来越大. 这是怎么回事呢? 原因除了数据量自然增长之外,在MySQL5.5以及之前,InnoDB的undo log也是存放在ibdata1里面的.一旦出现大事务,这个大事务所使用的undo

监控和管理Oracle UNDO表空间的使用

监控和管理Oracle UNDO表空间的使用 对Oracle数据库UNDO表空间的监控和管理是我们日常最重要的工作之一,UNDO表空间通常都是Oracle自动化管理(通过undo_management初始化参数确定):UNDO表空间是用于存储DML操作的前镜像数据,它是实例恢复,数据回滚,一致性查询功能的重要组件:我们常常会忽略对它的监控,这会导致UNDO表空间可能出现以下问题: 1).空间使用率100%,导致DML操作无法进行. 2).告警日志中出现大量的ORA-01555告警错误. 3).实

总结Oracle8i 的UNDO表空间损坏(ORA-01092及ORA-00600【4193】)情况下的数据库不完全恢复的经历

服务器断电重启导致备份生产环境的恢复目录库无法进行启动,提示Ora-01092例程终止.强行断开连接 查看跟踪日志: Wed Jan 10 08:41:37 2018 Errors in file d:\Oracle\admin\l3bckdb\bdump\l3bckdbSMON.TRC: ORA-00600: internal error code, arguments: [4193], [1836], [1844], [], [], [], [], [] Wed Jan 10 08:41:3

在非归档模式下不能更改表空间为备份模式

Oracle表空间设置为备份模式后,便可以联机对表空间下数据文件进行文件系统级别的copy备份操作,因为期间对表空间的修改都记录到数据库的重做日志文件中. 由此想到数据库如果是非归档模式,那么这个表空间备份模式的时间必须不能超过联机日志被覆盖的时间,才能保证数据的修改不会丢失. 那么Oracle对这种情况是如何择决的呢? 实验表明:Oracle是干脆不让你在非归档模式下开启表空间的备份模式. 报错如下: ORA-01123: cannot start online backup; media r

案例:Oracle dul数据挖掘 没有备份情况下非常规恢复drop删除的数据表

通过Oracle dul工具在没有备份情况下进行非常规恢复,找出drop删除的Oracle数据表中的数据进行恢复 dul对被drop对象进行恢复,需要提供两个信息1.被删除表所属表空间(非必须)2.被删除表结构(必须) 1.Oracle数据库中模拟删除表 --创建测试表 SQL> create table t_dul_drop tablespace czum 2 as 3 select * from dba_tables; Table created. --备份被删除表数据,便于比较和提供测试表