Heim  >  Artikel  >  Datenbank  >  Oracle中模拟及修复数据块损坏

Oracle中模拟及修复数据块损坏

WBOY
WBOYOriginal
2016-06-07 16:53:03827Durchsuche

在Oracle数据库中,我们可能遭遇很多数据损坏的情况,在面对这些情况时如何进行数据恢复是非常重要的。在很多情况下,恢复是极其

在Oracle数据库中,我们可能遭遇很多数据损坏的情况,在面对这些情况时如何进行数据恢复是非常重要的。
在很多情况下,恢复是极其复杂的,而且需要谨慎,轻率的操作和尝试可能导致数据库的永久损坏。
所以我建议在恢复尝试前应当先进行数据备份。
对于重要的数据库,如果不能确定恢复步骤和操作后果,建议最好先向专业人士进行咨询,以避免不必要的数据损失。

本文通过试验模拟和解决数据块损坏问题,是对一类数据库损坏的恢复探讨

1.插入数据

E:\Oracle\ora92\bin>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on 星期一 3月 8 20:27:15 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
E:\ORACLE\ORADATA\EYGLE\SYSTEM01.DBF
E:\ORACLE\ORADATA\EYGLE\UNDOTBS01.DBF
E:\ORACLE\ORADATA\EYGLE\EYGLE01.DBF

SQL> create tablespace block
2 datafile 'e:\oracle\oradata\eygle\block.dbf'
3 size 1M
4 extent management local;

表空间已创建。

SQL> alter user eygle default tablespace block;

用户已更改。

SQL> alter user eygle quota unlimited on block;

用户已更改。

SQL> connect eygle/eygle
已连接。

SQL> create table t as select * from dba_users;

表已创建。

SQL> insert into t select * from t;

已创建8行。

SQL> /

已创建16行。

SQL> /

已创建32行。

SQL> /

已创建64行。

SQL> /

已创建128行。

SQL> /

已创建256行。

SQL> /

已创建512行。

SQL> /

已创建1024行。

SQL> /

已创建2048行。

SQL> /

已创建4096行。

SQL> /
insert into t select * from t
*
ERROR 位于第 1 行:
ORA-01653: 表EYGLE.T无法通过8(在表空间BLOCK中)扩展

SQL> commit;

提交完成。

SQL> alter system checkpoint;

系统已更改。

SQL> select count(*) from t;

COUNT(*)
----------
8192

SQL> connect / as sysdba
已连接。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

2.损坏数据文件

关闭数据库后用Ultredit编辑数据文件,随便更改几个字符.然后启动数据库.

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 101785252 bytes
Fixed Size 454308 bytes
Variable Size 75497472 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> select count(*) from eygle.t;
select count(*) from eygle.t
*
ERROR 位于第 1 行:
ORA-01578: ORACLE 数据块损坏(文件号4,块号35)
ORA-01110: 数据文件 4: 'E:\ORACLE\ORADATA\EYGLE\BLOCK.DBF'

SQL>

此时如果查询该表,会出现错误,数据块损坏无法读取.

有个内部工具BBED也可以用来编辑数据块的内容

3.使用DBV检查数据文件

E:\Oracle\oradata\eygle>dbv file=block.dbf blocksize=8192

DBVERIFY: Release 9.2.0.4.0 - Production on 星期一 3月 8 20:48:50 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

DBVERIFY - 验证正在开始 : FILE = block.dbf
标记为损坏的页35
***
Corrupt block relative dba: 0x01000023 (file 4, block 35)
Bad check value found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0x01000023
last change scn: 0x0000.00049097 seq: 0x1 flg: 0x06
consistency value in tail: 0x90970601
check value in block header: 0xd6cb, computed block checksum: 0x2c0a
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页69
***
Corrupt block relative dba: 0x01000045 (file 4, block 69)
Bad check value found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0x01000045
last change scn: 0x0000.00049097 seq: 0x1 flg: 0x06
consistency value in tail: 0x90970601
check value in block header: 0x33d1, computed block checksum: 0x653
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

DBVERIFY - 验证完成

检查的页总数 :128
处理的页总数(数据):117
失败的页总数(数据):0
处理的页总数(索引):0
失败的页总数(索引):0
处理的页总数(其它):9
处理的总页数 (段) : 0
失败的总页数 (段) : 0
空的页总数 :0
标记为损坏的总页数:2
汇入的页总数 :0

dbv检测到坏块.

4.寻求恢复

在这种情况下,如果有备份,,需要从备份中恢复
如果没有备份,那么坏块部分的数据肯定要丢失了

在这个时候导出是不允许的:

E:\>exp eygle/eygle file=t.dmp tables=t

Export: Release 9.2.0.4.0 - Production on 星期一 3月 8 20:54:15 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

即将导出指定的表通过常规路径 ...
. . 正在导出表 T
EXP-00056: 遇到 ORACLE 错误 1578
ORA-01578: ORACLE 数据块损坏(文件号4,块号35)
ORA-01110: 数据文件 4: 'E:\ORACLE\ORADATA\EYGLE\BLOCK.DBF'
导出成功终止,但出现警告。

5.恢复步骤

当然,对于不同的情况需要区别对待

首先你需要检查损坏的对象,使用以下SQL:

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn