[20150619]undo文件损坏或者丢失的恢复3

[20150619]undo文件损坏或者丢失的恢复3.txt

--实际上前面的测试是非常理想情况下的测试,真实的情况肯定比上面介绍的复杂。

--一般情况下,数据库异常关机,最容易出现的是在线redo损坏,一般通过隐含参数_allow_resetlogs_corruption跳过。

SYS@test> @ &r/hide _allow_resetlogs_corruption
NAME                         DESCRIPTION                                       DEFAULT_VALUE  SESSION_VALUE  SYSTEM_VALUE
---------------------------- ------------------------------------------------- -------------- -------------- -------------
_allow_resetlogs_corruption  allow resetlogs even if it will cause corruption  TRUE           FALSE          FALSE

--如果在出现回滚段错误,通过修改参数_corrupted_rollback_segments,_offline_rollback_segments跳过一些回滚段。

--10g下一般很好确定,命名格式是:
像_SYSSMU1$ 格式 _SYSSMU$.

--而11g下加入了时间戳,在无法打开数据库的情况下,可以通过bvi或者bbed来确定。
--另外一般位置相对固定,只要找一个数据块大小一样的数据块查询sys.undo$(数据库版本要一致)的rowid基本可以是那些。

--
SCOTT@test> @ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

SCOTT@test> select rowid,us#,name from sys.undo$ where rownumROWID                     US# NAME
------------------ ---------- ----------------------------------------
AAAAAPAABAAAADhAAA          0 SYSTEM

SCOTT@test> @ lookup_rowid AAAAAPAABAAAADhAAA
    OBJECT       FILE      BLOCK        ROW DBA                  TEXT
---------- ---------- ---------- ---------- -------------------- ----------------------------------------
        15          1        225          0 1,225                alter system dump datafile 1 block 225 ;

BBED> set dba 1,225
        DBA             0x004000e1 (4194529 1,225)

BBED> x /2rncnnnnnnnnnnnnnnnnncct rowdata
rowdata[0]                                  @862
----------
flag@862:  0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@863:  0x00
cols@864:    17

col    0[2] @865: 4
col   1[20] @868: _SYSSMU4_1665036189$
col    2[2] @889: 1
col    3[2] @892: 3
col    4[3] @895: 176
col    5[6] @899: 4103678170
col    6[2] @906: 2
col    7[4] @909: 34048
col    8[4] @914: 10126
col    9[1] @919: 0
col   10[2] @921: 3
col   11[2] @924: 2
col   12[0] @927: *NULL*
col   13[0] @928: *NULL*
col   14[0] @929: *NULL*
col   15[0] @930: *NULL*
col   16[2] @931: 2

rowdata[72]                                 @934
-----------
flag@934:  0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@935:  0x00
cols@936:    17

col    0[3] @937: 104
col   1[21] @941: _SYSSMU104_777408806$
col    2[2] @963: 1
col    3[2] @966: 10
col    4[3] @969: 176
col    5[6] @973: 3414864939
col    6[2] @980: 2
col    7[3] @983: 1024
col    8[3] @987: 657
col    9[1] @991: 0
col   10[2] @993: 2
col   11[2] @996: 5
col   12[0] @999: *NULL*
col   13[0] @1000: *NULL*
col   14[0] @1001: *NULL*
col   15[0] @1002: *NULL*
col   16[2] @1003: 2
....

--也可以使用bbvi编辑:

SCOTT@test> @bbvi     1        225
BVI_COMMAND
------------------------------------------------------------------------------------------
bvi -b 1843200 -s 8192 /u01/app/oracle11g/oradata/test/system01.dbf

--执行如下:
$ touch aa.txt
$ bvi -b 1843200 -s 81920 /u01/app/oracle11g/oradata/test/system01.dbf
:w aa.txt

--说明-s 长度加大一些,因为可能在许多数据块中。

$ strings aa.txt | grep SYSSMU | uniq |head -10
_SYSSMU9_3043963034$
_SYSSMU3_2763804800$
_SYSSMU4_1665036189$
_SYSSMU104_777408806$
_SYSSMU103_9611014$
_SYSSMU102_1057122756$
_SYSSMU101_445156792$
_SYSSMU100_3478039479$
_SYSSMU99_2737214818$
_SYSSMU98_2332908142$

SYS@test> select rowid,us#,name from sys.undo$ where us#=3;

ROWID                     US# NAME
------------------ ---------- --------------------
AAAAAPAABAAAADhAAD          3 _SYSSMU3_2763804800$

SYS@test> select rowid,us#,name from sys.undo$ where us#=9;
ROWID                     US# NAME
------------------ ---------- --------------------
AAAAAPAABAAAADhAAJ          9 _SYSSMU9_3043963034$

--还是对上的。可以参考我以前写的:
http://blog.itpub.net/267265/viewspace-1162543/

时间: 2024-09-23 02:47:16

[20150619]undo文件损坏或者丢失的恢复3的相关文章

[20150619]undo文件损坏或者丢失的恢复1

[20150619]undo文件损坏或者丢失的恢复1.txt --昨天别人问一些undo文件损坏或者丢失的恢复,实际上如果正常关机,undo文件丢失,恢复是很容易的. --这些以前应该也做过,重复做1个记录: 1.测试环境: SCOTT@test> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- --------------

[HOWTO]SQL Server2000数据库文件损坏的时候如何恢复

server|恢复|数据|数据库 数据库文件损坏的时候如何恢复 欢迎大家同我交流:小白  enhydra_boy@tom.com 欢迎转载,请保留本声明,谢谢! SQL Server2000中,如果数据库文件(非系统数据库文件)遇到错误的时候,我们该怎么办.以下是笔者以前的笔记.仅适用于非master,msdb的数据库. 说明如下: 1 建一个测试数据库test(数据库类型为完全)2 建一个表,插入点记录  create table a(c1 varchar(2))  go  insert in

Oracle重做日志文件损坏或丢失后的恢复

很多网友在把某个数据库实例的REDO01~03.LOG三个重做日志删掉后,会出现无法正常登陆数据库的现象,下面的示例是具体的恢复过程,希望能为大家解决难题: 一: c:/>sqlplus /nolog 二: sql>connect /@instancename as sysdba; 三: startup mount; --启动实例,安装数据库,但不打开数据库, 可以开始操作控制文件.日志文件.数据文件等. 四: select * from v$logfile; --察看Redo文件的信息 五;

Win7无法启动提示Hal.dll损坏或丢失怎么办

  我们在使用Win7系统的时候,出现电脑无法进行启动开机,提示"<Windows root>system32hal.dll 损坏或丢失,导致Windows无法启动.那么出现这样的问题,我们要怎样进行解决呢?下面就和小编一起看看Win7系统无法启动提示Hal.dll损坏或丢失的解决方法. 一.出现Windows无法启动提示hal.dll损坏或丢的原因有: 1.GHOST系统引起,GHOST原封装的系统文件与品牌主机分区类型不一起引起(品牌电脑大多数有隐藏分区); 2.偶然的系统非正常

解决Windows无法启动提示hal.dll损坏或丢失的方法

  1.GHOST系统引起,GHOST原封装的系统文件与品牌主机分区类型不一起引起(品牌电脑大多数有隐藏分区); 2.偶然的系统非正常关机后,开机就无法启动,使用系统修复盘修复提示system32//hal.dll这个文件损坏或丢失; 3.超频也可能导致系统文件损坏,提示system32//hal.dll损坏或丢失; 4.是内存的故障,把内存条拔下来擦下金手指上的污垢,检查下是否插紧再试试,或者找一条确保正常的内存条安装上先测试下,排除到底是不是内存条的问题! 下面就为大家说说提示hal.dll

【恢复】Redo日志文件丢失的恢复

第一章 Redo日志文件丢失的恢复 1.1  online redolog file 丢失 联机Redo日志是Oracle数据库中比较核心的文件,当Redo日志文件异常之后,数据库就无法正常启动,而且有丢失据的风险,强烈建议在条件允许的情况下,对Redo日志进行多路镜像.需要注意的是,RMAN不能备份联机Redo日志文件.所以,联机Redo日志一旦出现故障,则只能进行清除日志了.清除日志文件即表明可以重用该文件. 1.1.1  数据库归档/非归档模式下inactive redo异常ORA-003

联机日志文件损坏后的恢复方法

恢复 昨天遇到一个Oracle数据库的问题,环境是:Windows2000+Oracle9i.使用windows关机重启后,oracle无法连接,当用startup启动时总是报ORA-00333错误,检查Oracle文档对此问题的描述,如下:ORA-00333 redo log read error block string count stringCause: An I/O error occurred while reading the log described in theaccompa

所有控制文件损坏的恢复--resetlogs方式

        此方式和 所有控制文件损坏的恢复--noresetlogs方式恢复时的前五个步骤是一样的. 1)先备份控制文件            SQL> alter database backup controlfile to 'f:\lib\control.ctl' reuse;数据库已更改.2)生成跟踪文件. SQL> alter database backup controlfile to trace;数据库已更改.SQL> @f:\sql\gettrace.sql---一个

数据库文件损坏的恢复方法

  说明如下:SQL Server 2000文件损坏的恢复 1.建一个测试数据库test(数据库类型为完全). 2.建一个表,插入点记录. create table a(c1 varchar(2)) go insert into a values('aa') go insert into a values('bb') go 3.作完全备份,到文件test_1.bak. 4.在作一点修改. insert into a values('cc') go create table b(c1 int) g