Oracle 11g 文件损坏处理

rman 备份时报以下错误:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of backup plus archivelog command at 08/20/2015 17:33:37

ORA-19566: exceeded limit of 0 corrupt blocks for file /app/oracle/oradata/orcl/system01.dbf

由报错信息可知  /app/oracle/oradata/orcl/system01.dbf 损坏

查找坏块:

[oracle@zhoux backup]$ dbv file=/app/oracle/oradata/orcl/system01.dbf

DBVERIFY: Release 11.2.0.1.0 - Production on Thu Aug 20 17:35:46 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /app/oracle/oradata/orcl/system01.dbf

Page 72303 is marked corrupt

Corrupt block relative dba: 0x00411a6f (file 1, block 72303)

Bad check value found during dbv:

Data in bad block:

 type: 6 format: 2 rdba: 0x00411a6f

 last change scn: 0x0000.000bd526 seq: 0x1 flg: 0x06

 spare1: 0x0 spare2: 0x0 spare3: 0x0

 consistency value in tail: 0xd5260601

 check value in block header: 0x3388

 computed block checksum: 0x2000


使用SQL语句:

SELECT tablespace_name,segment_type,owner,segment_name FROM dba_extents WHERE file_id = 1 AND 72303 between block_id AND block_id+blocks-1;

找到错误的地方,根据情况处理问题.

时间: 2024-10-20 19:49:32

Oracle 11g 文件损坏处理的相关文章

Oracle dmp文件损坏恢复案例

前一段时间帮一个朋友的朋友恢复了一个损坏的dmp文件,大概100多个G,记录一下恢复过程并简单总结一下 一.描述 这个dmp文件是从一个Oracle 9i的数据库上exp出来的,在导入Oracle 11g版本的时候,可能会随机出现两类错误,如下 (1)dmp文件导入的时候,一直停留在某张表上不动,两三天都是这样,导入操作无法进行,如下 导入了                                                             0 行 . . 正在导入表    

Oracle模拟文件损坏BBED

模拟文件损坏可以使用两个工具,windows nt 下使用uttra edit ,还有就是使用ORACLE内部工具BBED,下面主要看这个工具如何使用. 一.BBED(Oracle?Block?Browerand?EDitor Tool),用来直接查看和修改数据文件数据的一个工具,是Oracle一款内部工具,可以直接修改Oracle数据文件块的内容,在一些极端恢复场景下比较有用.该工具不受Oracle支持,所以默认是没有生成可执行文件的,在使用前需要重新连接. 我这里的作用 二.BBED 安装

centos6.5下搭建oracle 11g

1.安装依赖 sudo yum install binutils compat-libstdc++-33 compat-libstdc++-33.i686 elfutils-libelf elfutils-libelf-devel gcc gcc-c++ glibc glibc.i686 glibc-common glibc-devel glibc-devel.i686 glibc-headers ksh libaio libaio.i686 libaio-devel libaio-devel.

关于数据库文件损坏风险的提醒

前言 小y最近处理了几起Oracle数据库文件损坏的case,因为某些Bug风险较大,因此不敢有丝毫怠慢,赶紧拿出来分享!希望能够帮助到有需要的朋友!风险提示! 如上图所示,Linux 5/6上的一个已知缺陷,在某些触发条件下,将导致Oracle数据文件出现内容全是0的的坏块.该操作系统上的缺陷,除了会导致Oracle数据库数据文件损坏外,还会导致包括归档日志.在线日志的损坏.而如果是current状态的在线日志发生损坏,那么对于数据库的影响将是致命的.需要引起重视! BUG触发条件: 当同时满

Oracle 11g在ASM磁盘组上添加控制文件

控制文件(Control File)是Oracle的物理文件之一,它记录了数据库的名字.数据文件的位置等信息.控制文件的重要性在于,一旦控制文件损坏,数据库将会宕机.如果没有数据库的备份和归档日志文件,数据库将无法恢复.因此,我们应该多路镜像控制文件(Multiplex Control Files),并把每个镜像的控制文件分布在不同的物理磁盘.根据经验,控制文件多路镜像以后,几个控制文件同时坏掉的可能性几乎为零.控制文件管理的重心是重在预防,而不是亡羊补牢! 今天做在测试环境为control f

案例:Oracle exp dmp文件损坏 通过CPFL工具抽取dmp中的数据表进行恢复

Oracle数据库逻辑导出exp的dmp文件损坏,通过非常规恢复抽取dmp文件中表的数据 在有些时候,exp的dmp文件因为某种原因损坏(比如磁盘异常,exp过程损坏等),导致imp导入无法继续,下面的处理方法(直接读取dmp文件)来对dmp文件进行抢救性恢复,最大程度减少数据丢失损失 1.创建exp dmp文件并使用dd破坏 SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> selec

oracle ora-01578 ORACLE 数据块损坏 (文件号 4, 块号 840339)

ORA-01578是 数据块物理坏块/损坏的一种,不同于逻辑损坏/坏块,一般 会伴随ORA-1110出现,一旦ORACLE读取到存在损坏的块就会报出Caused by: java.sql.SQLException: ORA-01578: ORACLE 数据块损坏 (文件号 4, 块号 840339)ORA-01110: 数据文件 4: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS01.DBF' 解决方法如下:1.使用DBV检查数据文件,在cmd目录下直接输入d

Oracle 11g 导入dmp文件出现的问题

1.导入命令: imp userId/[email protected] full=y  file=D:\data\T_DAYLOG_CALLANALYSIS.dmp ignore=y 2.导出命令 exp userId/[email protected] file=d:\dkj\test.dmp tables=(wf_test) 如出现:”只有dba才能导入由其他dba导出的文件“的问题 登录该用户:执行SQL: grant dba to testuser ; 如果还不行,再执行: alter

oracle 11g 从 dmp 文件中导出 sql 代码 的方法.

impdp sys/password full=y dumpfile=bg.dmp nologfile=y sqlfile=bg_dmp.sql 备注: bg.dmp 是 dmp 文件,   bg_dmp.sql 是导出来的 SQL  代码.   导出的文件和代码都存放在:oracle 安装目录:  app/oracle/admin/ORCL/dpdump 文件夹下面. oracle 11g 从 dmp 文件中导出 sql 代码 的方法.