【Oracle】undo损坏,无备份非常规恢复

客户的一个测试环境,主机异常断电,启动后发现undo文件损坏,无法启动,在open阶段报错如下:

Errors in file /u01/app/oracle/diag/rdbms/cdrdb/CDRDB/trace/CDRDB_ora_4109.trc:

ORA-01122: database file 3 failed verification check

ORA-01110: data file 3: ‘/u01/app/oracle/oradata/CDRDB/undotbs01.dbf‘

ORA-01210: data file header is media corrupt

ORA-1122 signalled during: ALTER DATABASE OPEN...

由于是测试环境,没有备份,但是又需要里边的一些数据,所以我尝试使用非常规恢复方法进行了尝试。

先冷备份现有环境!!!!!!!!!!!!!!!!

创建pfile文件:

create pfile from spfile;

在pfile中修改这两个参数

#*.undo_tablespace=‘UNDOTBS1‘

*.undo_management= MANUAL

之后用这个pfile启动:

[email protected]>startup force pfile=‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initCDRDB.ora‘;

ORACLE instance started.

Total System Global Area  523108352 bytes

Fixed Size                  1337632 bytes

Variable Size             364906208 bytes

Database Buffers          150994944 bytes

Redo Buffers                5869568 bytes

Database mounted.

ORA-01122: database file 3 failed verification check

ORA-01110: data file 3: ‘/u01/app/oracle/oradata/CDRDB/undotbs01.dbf‘

ORA-01210: data file header is media corrupt

仍然报错

之后尝试drop掉这个undo

[email protected]>alter database datafile 3 offline drop;

Database altered.

之后重新开库

[email protected]>alter database open;

Database altered.

之后创建新的undo表空间undotbs2

[email protected]>create undo tablespace undotbs2 datafile ‘/u01/app/oracle/oradata/CDRDB/undotbs02_01.dbf‘ size 100M;

create undo tablespace undotbs2 datafile ‘/u01/app/oracle/oradata/CDRDB/undotbs02_01.dbf‘ size 100M

*

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01552: cannot use system rollback segment for non-system tablespace

‘DATA_OL‘

ORA-06512: at line 999

ORA-01552: cannot use system rollback segment for non-system tablespace

‘DATA_OL‘

产生报错如上

比较疑惑创建undo为什么会影响到DATA_OL表空间,所以做了个10046

[email protected]>oradebug event 10046 trace name context off

Statement processed.

[email protected]>oradebug tracefile_name

/u01/app/oracle/diag/rdbms/cdrdb/CDRDB/trace/CDRDB_ora_4279.trc

[[email protected] ~]$ tkprof /u01/app/oracle/diag/rdbms/cdrdb/CDRDB/trace/CDRDB_ora_4279.trc

output = 1.trm

查看1.trm,发现了原因:

"OGG".DDLReplication.dbQueried IS NULL THEN

SELECT database_role,

open_mode

INTO dbRole, dbOpenMode

FROM v$database;

"OGG".DDLReplication.dbQueried := TRUE;

END IF;

IF NOT (

^@                      (dbRole = ‘PRIMARY‘ OR dbRole = ‘LOGICAL STANDBY‘)

AND dbOpenMode =

‘READ WRITE‘

)

THEN

-- do not write any trace even though it

should work as this is standby

"OGG"

.DDLReplication.setCtxInfo(-1,-1,-1,-1,-1);

RETURN; -- do not use

trigger if not read/write and primary/logical_standby

END IF;

EXCEPTION

......略

原来是因为这个库配置过OGG的DDL同步,有DDL产生时会产生insert操作,使用DATA_OL表空间。

原因找到~  跑脚本关闭该库OGG的DDL配置即可

[email protected]>@ddl_disable.sql

Trigger altered.

之后再重新创建undotbs2表空间

[email protected]>create undo tablespace undotbs2 datafile ‘/u01/app/oracle/oradata/CDRDB/undotbs02_01.dbf‘ size 1000M;

Tablespace created.

这次很顺利的添加成功。

undotbs2添加完毕,接下来关闭数据库,修改pfile参数

*.undo_tablespace=‘UNDOTBS2‘

*.undo_management=AUTO

重启数据库用pfile启动

[email protected]>startup pfile=‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initCDRDB.ora‘;

ORACLE instance started.

Total System Global Area  523108352 bytes

Fixed Size                  1337632 bytes

Variable Size             364906208 bytes

Database Buffers          150994944 bytes

Redo Buffers                5869568 bytes

Database mounted.

Database opened.

数据库成功启动,然而在很多业务表查询时依然会报错:

ERROR at line 1:

ORA-00376: file 3 cannot be read at this time

ORA-01110: data file 3: ‘/u01/app/oracle/oradata/CDRDB/undotbs01.dbf‘

依然需要原来的undotbs01.dbf回滚数据库崩溃时未提交的事务

之后我先尝试了设置event 10513,来屏蔽smon的回滚

[email protected]>alter system set events ‘10513 trace name context forever, level 2‘;

System altered.

发现还是会报之前的错误,看来需要自己手工去屏蔽回滚段了。

[email protected]>SELECT SEGMENT_NAME,STATUS FROM DBA_ROLLBACK_SEGS;

SEGMENT_NAME                   STATUS

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

SYSTEM                         ONLINE

_SYSSMU10_4131489474$          NEEDS RECOVERY

_SYSSMU9_1735643689$           NEEDS RECOVERY

_SYSSMU8_3901294357$           NEEDS RECOVERY

_SYSSMU7_3517345427$           NEEDS RECOVERY

_SYSSMU6_2897970769$           NEEDS RECOVERY

_SYSSMU5_538557934$            NEEDS RECOVERY

_SYSSMU4_1003442803$           NEEDS RECOVERY

_SYSSMU3_1204390606$           NEEDS RECOVERY

_SYSSMU2_967517682$            NEEDS RECOVERY

_SYSSMU1_592353410$            NEEDS RECOVERY

SEGMENT_NAME                   STATUS

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

_SYSSMU30_244658789$           ONLINE

_SYSSMU29_1020880693$          ONLINE

_SYSSMU28_2912622077$          ONLINE

_SYSSMU27_747253598$           ONLINE

_SYSSMU26_560868814$           ONLINE

_SYSSMU25_1357066082$          ONLINE

_SYSSMU24_103440716$           ONLINE

_SYSSMU23_1006903361$          ONLINE

_SYSSMU22_2808190508$          ONLINE

_SYSSMU21_39626587$            ONLINE

21 rows selected.

之后把查询到的NEEDS RECOVERY的表加到以下两个参数中,屏蔽这些回滚段

_offline_rollback_segments/_corrupted_rollback_segments参数

*._offline_rollback_segments=(_SYSSMU10_4131489474$,_SYSSMU9_1735643689$,_SYSSMU8_3901294357$,_SYSSMU7_3517345427$,_SYSSMU6_2897970769$,_SYSSMU5_538557934$,_SYSSMU4_1003442803$,_SYSSMU3_1204390606$,_SYSSMU2_967517682$,_SYSSMU1_592353410$)

*._corrupted_rollback_segments=(_SYSSMU10_4131489474$,_SYSSMU9_1735643689$,_SYSSMU8_3901294357$,_SYSSMU7_3517345427$,_SYSSMU6_2897970769$,_SYSSMU5_538557934$,_SYSSMU4_1003442803$,_SYSSMU3_1204390606$,_SYSSMU2_967517682$,_SYSSMU1_592353410$)

使用这个pfile启动数据库

startup force pfile=‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initCDRDB.ora‘;

之后对那些测试表都查询了一下,确认可以查询,之后导出帮他们导出数据,一切OK~

时间: 2024-10-24 19:17:44

【Oracle】undo损坏,无备份非常规恢复的相关文章

案例:Oracle dul数据挖掘 没有数据库备份非常规恢复truncate删除的数据表

Oracle数据库在没有备份情况下在对表中的某数据表进行truncate删除后,通过oracle dul进行非常规恢复 1.准备oracle dul测试环境 SQL> select count(*) from t_xifenfei; COUNT(*) ---------- 67854 SQL> desc t_xifenfei Name Null? Type ----------------------------------------- -------- ------------------

oracle数据泵的备份和恢复

数据泵工具可以从命令好使用程序 expdp 和impdp中调用数据泵技术的特点导入/导出的所有工作都由数据库实例完成可以使用dbms_datapump pl/sql APL建立.检测和调用数据泵任务可以对IMPDP/ECPD导入导出任务进行重新启动,类似于网络下载的断点续传 expd的导出方式数据库方式,整个数据库被导出操作系统文件中用户模式,导出一个或多个用户下的所有数据和元数据表方式,导出的数据包括一组表中的所有数据和元素据表空间方式 导出时提取用于一个表空间的所有对像的数据. grant

测试oracle数据库的脱机备份和恢复

环境:windows7.Oracle11g 一.脱机备份 脱机备份是指在数据库关闭情况下的数据备份,也称为冷备份. 在书上学到的备份步骤: 1.记录所要备份数据库文件所在的操作系统路径: 2.关闭数据库,不要使用shutdown abort这种关闭方式: 3.拷贝数据库文件到备份目录中: 4.重启数据库,完成备份. 了解到这些步骤后,做了一个备份测试,要备份的数据库为testdb. 1.记录所要备份数据库文件所在的操作系统路径     (1)查看数据文件的路径(用管理员账户连接) 备注:可以在s

Oracle备份和恢复简史

Oracle备份和恢复简史 --http://www.searchdatabase.com.cn/showcontent_90388.htm?info=sinaweibo 这些年来,Oracle数据库备份和恢复方式已经发生了重大变化,特别是在Recovery Manager(RMAN)功能有了进一步改善之后.那么接下来,就让我们来回顾下,在没有RMAN之前,以及有了RMAN之后,DBA如何备份数据,以及RMAN如何改善这一过程. 回到很久之前的Oracle 5,那时候的备份是这么做的:关闭数据库

Oracle Undo tablespace恢复(无备份)

Oracle Undo tablespace恢复 系统环境:   操作系统:RedHat EL55   Oracle:  Oracle 11gR2   Oracle 9i后,采用了undo tablespace管理undo数据,实现undo的自动管理,本案例演示了undo表空间被破坏后如何恢复:如果有备份,通过备份恢复非常容易,但在没有备份的情况下,就需要采用非常规手段来恢复了,呵呵. 1.案例应用环境 undo表空间undo segments: 14:34:44 [email protecte

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

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

己亥清爽恢复系列之数据文件3篇:非核心数据文件物理损坏或丢失(无备份恢复)

己亥清爽系列说明:清爽系列是作为恢复系列的基础篇,基于FS(File System)文件系统的手工还原恢复,也叫基于用户管理的还原恢复,来自于博客园AskScuti. 实验说明:物理删除非关键系统数据文件,模拟介质损坏或丢失,且在无备份的情况下,如何进行手工完全还原恢复操作.注:控制文件.在线日志和归档日志都完整的情况下. 基于版本:Oracle 11gR2 11.2.0.4 AskScuti 概念说明:请严格区分什么叫还原(Restore),什么叫恢复(Recover). 还原(Restore

案例: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. --备份被删除表数据,便于比较和提供测试表

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

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