利用dbms_repair来标记和跳过坏块

SQL> select file_id, block_id, blocks from dba_extents where owner = ‘LILC‘ and segment_name = ‘TEST‘;
,,,,,
 610624    1024
 611648    1024
83 rows selected.

破坏之前的数据:

SQL> select count(*) from test;

COUNT(*)

----------

783018

RMAN> recover datafile 6 block 11620 clear;

RMAN> recover datafile 6 block 4467 clear;

RMAN> backup check logical validate datafile 6;

Starting backup at 23-SEP-15

using channel ORA_DISK_1

using channel ORA_DISK_2

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00006 name=+DATA/phub/datafile/llc01.dbf

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07

List of Datafiles

=================

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

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

6    FAILED 0              20           12800           1991935

File Name: +DATA/phub/datafile/llc01.dbf

Block Type Blocks Failing Blocks Processed

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

Data       2              12140

Index      0              329

Other      1              311

validate found one or more corrupt blocks

See trace file /u01/app/oracle/diag/rdbms/phub/PHUB/trace/PHUB_ora_29666.trc for details

Finished backup at 23-SEP-15

数据查询肯定报错:

SQL> select count(*) from test;

select count(*) from test

*

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 6, block # 4467)

ORA-01110: data file 6: ‘+DATA/phub/datafile/llc01.dbf‘

skip_corrupt_blocks来跳过坏块:

SQL> exec dbms_repair.skip_corrupt_blocks(schema_name => ‘LILC‘,object_name => ‘TEST‘,flags => 1);

PL/SQL procedure successfully completed.

SQL> conn lilc/lilc;

Connected.

SQL> select count(*) from test;

COUNT(*)

----------

782884

这里少了34条数据

修复坏块;

RMAN> recover datafile 6 block 11620

2> ;

Starting recover at 23-SEP-15

using channel ORA_DISK_1

using channel ORA_DISK_2

finished standby search, restored 1 blocks

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 23-SEP-15

RMAN> recover datafile 6 block 4467

Starting recover at 23-SEP-15

using channel ORA_DISK_1

using channel ORA_DISK_2

finished standby search, restored 1 blocks

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 23-SEP-15

数据正常:

SQL> select count(*) from test;

COUNT(*)

----------

783018

时间: 2024-11-09 06:20:11

利用dbms_repair来标记和跳过坏块的相关文章

案例:Oracle exp dmp文件存在坏块并损坏 使用CPFL跳过坏块并成功导入恢复

Oracle数据库exp导出dmp文件损坏存在坏块/corruption通过CPFL工具跳过dmp坏块进发导入 在有些情况下,大家都知道通过dul可以恢复损坏的dmp文件的表的数据,但是该方法有很多问题,特别是对很多数据类型的支持不够完美,比如lob,long raw类型等,而且还有可能恢复出来数据大量丢失,本人通过对dmp结构的分析,使用使用一些特殊的技巧方法,可以实现对于损坏的dmp文件,通过跳过异常坏块所在表,继续恢复后续表,从而最大程度减少损坏 1.创建Oracle测试表 SQL> co

如何处理Oracle数据库中的坏块问题

本文主要介绍如何去处理在Oracle数据库中出现坏块的问题,对于坏块产生在不同的对象上,处理的方法会有所不同,本文将大致对这些方法做一些介绍.因为数据库运行时间长了,由于硬件设备的老化,出现坏块的几率会越来越大,因此,做为一个DBA,怎么去解决数据库出现的坏块问题就成了一个重要的议题了. 一:什么是数据库的坏块   首先我们来大概看一下数据库块的格式和结构 数据库的数据块有固定的格式和结构,分三层:cache layer,transaction layer,data layer.在我们对数据块进

Oracle数据库坏块的恢复

模拟数据块坏块: 对于发生数据块不一致的数据块,如果当前数据库有备份且处于归档模式,那么就可以利用rman工具数据块恢复功能 对数据块进行恢复,这种方法最简单有效,而且可以在数据文件在线时进行,不会发生数据丢失.对于被有备份的数据库 发生数据块损坏,可能会发生数据的丢失或数据不丢失,这要根据发生坏块的所在的对象决定的,如索引块发生损坏,数据 就不会丢失,重建索引就可以了,发生数据丢失的多发生在表或分区表数据块上. 1.不丢数据的恢复方法 ---使用rman工具的 blockrecover blo

Oracle 处理坏块

本文主要介绍如何去处理在Oracle数据库中出现坏块的问题,对于坏块产生在不同的对象上,处理的方法会有所不同,本文将大致对这些方法做一些介绍.因为数据库运行时间长了,由于硬件设备的老化,出现坏块的几率会越来越大,因此,做为一个DBA,怎么去解决数据库出现的坏块问题就成了一个重要的议题了. 什么是数据库的坏块首先我们来大概看一下数据库块的格式和结构 数据库的数据块有固定的格式和结构,分三层:cache layer,transaction layer,data layer.在我们对数据块进行读取写入

Oracle corrupt block(坏块) 详解

转自:http://blog.csdn.net/tianlesoftware/article/details/5024966 一. 坏块说明 1.1 相关链接 在看坏块之前,先看几个相关的链接,在后面的说明中,会用到链接中的一些内容. ORA-600 各个参数含义说明 http://blog.csdn.net/tianlesoftware/article/details/6645809 Oracle 不同故障的恢复方案 http://blog.csdn.net/tianlesoftware/ar

ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案(文档ID 1623284.1)

ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案(文档ID 1623284.1) (一)NOLOGGING操作引起的坏块(ORA-01578和ORA-26040)简介 如果只是错误ORA-01578,而没有伴随ORA-26040,那么这个坏块是由其它的原因引起的坏块,可以尝试使用RMAN的BMR(Block Media Recovery)修复. 如果数据段(表段.索引段)被定义为NOLOGGING属性,那么当NOLOGGING加APPEND.UNRE

ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案

(一)NOLOGGING操作引起的坏块(ORA-01578和ORA-26040)简介 如果只是错误ORA-01578,而没有伴随ORA-26040,那么这个坏块是由其它的原因引起的坏块,可以尝试使用RMAN的BMR(Block Media Recovery)修复. 如果数据段(表段.索引段)被定义为NOLOGGING属性,那么当NOLOGGING加APPEND.UNRECOVERABLE操作修改该数据段或者使用数据泵(DATAPUMP)impdp参数DISABLE_ARCHIVE_LOGGING

恢复数据块坏块

2014.7.22研究恢复数据库坏块: Oracle调用标准C的系统函数,对数据块进行读写操作,因此,坏块是有可能由以下几种原因产生: 硬件的I/O错误 操作系统的I/O错误或缓冲问题 内存或paging问题 磁盘修复工具 一个数据文件的一部分正在被覆盖 Oracle试图访问一个未被格式化的系统块失败 数据文件部分溢出 Oracle或者操作系统的bug 遇到"ORA-01578:ORACLE data block corrupted"错误 处理方法:1.rman的recover命令可以

oracle三种类型坏块的处理思路总结(没有物理备份)

坏块的发生,很罕见,但生产系统偶尔还是会出现.如果有物理备份,处理起来相对简单,直接进行块级recover即可,但如果只有逻辑备份呢?处理起来要分四种情况,在此总结一下: 一.块的data部分坏了,在sql执行扫描到这个块的时候会报ORA-01578: ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 21, block # 12)ORA-01110: data file 21: '/u01/app/oracle/ora