ora-01578

SQL> exec  DBMS_STATS.GATHER_DATABASE_STATS;
BEGIN DBMS_STATS.GATHER_DATABASE_STATS; END;

*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 870212)
ORA-01110: data file 4:
‘/s01/oradata/G10R25/datafile/o1_mf_users_7ch7d4nx_.dbf‘
ORA-06512: at "SYS.DBMS_STATS", line 15188
ORA-06512: at "SYS.DBMS_STATS", line 15530
ORA-06512: at "SYS.DBMS_STATS", line 15674
ORA-06512: at "SYS.DBMS_STATS", line 15638
ORA-06512: at line 1

使用RMAN blockreocver命令试图修改该物理坏块:

RMAN> blockrecover datafile 4 block 870212;

Starting blockrecover at 08-NOV-12

channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/s01/flash_recovery_area/G10R25/backupset/2012_08_06/o1_mf_nnndf_TAG20120806T075500_81zd4njn_.bkp tag=TAG20120806T075500
channel ORA_DISK_1: block restore complete, elapsed time: 00:01:16

starting media recovery

archive log thread 1 sequence 467 is already on disk as file /s01/flash_recovery_area/G10R25/archivelog/2012_10_31/o1_mf_1_467_893571cm_.arc
archive log thread 1 sequence 468 is already on disk as file /s01/flash_recovery_area/G10R25/archivelog/2012_10_31/o1_mf_1_468_893pc84l_.arc
archive log thread 1 sequence 469 is already on disk as file /s01/flash_recovery_area/G10R25/archivelog/2012_11_01/o1_mf_1_469_894zsbym_.arc
archive log thread 1 sequence 470 is already on disk as file /s01/flash_recovery_area/G10R25/archivelog/2012_11_01/o1_mf_1_470_896b944y_.arc
4_.arc
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of blockrecover command at 11/08/2012 06:19:40
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 466 lowscn 27762151 found to restore
RMAN-06025: no backup of log thread 1 seq 465 lowscn 27762145 found to restore
RMAN-06025: no backup of log thread 1 seq 464 lowscn 27762142 found to restore

由于缺少必要的归档日志导致blockrecover无法成功,需要另想办法。

首先确认该数据块属于哪个SEGMENT,如果是INDEX那么完全可以重建也不会丢失数据,但是如果是表数据则需要容忍丢失该坏块内的数据:

SQL> col tablespace_name for a20
SQL> col segment_type for a10
SQL> col segment_name for a20
SQL> col owner for a8
SQL> SELECT tablespace_name, segment_type, owner, segment_name
  2  FROM dba_extents
  3  WHERE file_id = &fileid
  4  and &blockid between block_id AND block_id + blocks - 1;
Enter value for fileid: 4
old   3: WHERE file_id = &fileid
new   3: WHERE file_id = 4
Enter value for blockid: 870212
old   4: and &blockid between block_id AND block_id + blocks - 1
new   4: and 870212 between block_id AND block_id + blocks - 1

TABLESPACE_NAME      SEGMENT_TY OWNER    SEGMENT_NAME
-------------------- ---------- -------- --------------------
USERS                TABLE      SYS      CORRUPT_ME

SQL> select count(*) from CORRUPT_ME;
select count(*) from CORRUPT_ME
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 870212)
ORA-01110: data file 4:
‘/s01/oradata/G10R25/datafile/o1_mf_users_7ch7d4nx_.dbf‘

SQL> analyze table corrupt_me validate structure;
analyze table corrupt_me validate structure
*
ERROR at line 1:
ORA-01498: block check failure - see trace file

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/s01/admin/G10R25/udump/g10r25_ora_19749.trc

Corrupt block relative dba: 0x010d4744 (file 4, block 870212)
Bad header found during buffer read
Data in bad block:
 type: 6 format: 2 rdba: 0x000d4744
 last change scn: 0x0000.00000000 seq: 0xff flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x000006ff
 check value in block header: 0x6323
 computed block checksum: 0x0
Reread of rdba: 0x010d4744 (file 4, block 870212) found same corrupted data
*** 2012-11-08 06:23:12.564
table scan: segment: file# 4 block# 870211
            skipping corrupt block file# 4 block# 870212
*** 2012-11-08 06:23:36.955
table scan: segment: file# 4 block# 870211
            skipping corrupt block file# 4 block# 870212
skipping corrupted block at rdba: 0x010d4744

下面使用10231 level 10事件来避免发生ORA-01578错误,并将原坏块表复制出来:

SQL> alter session set events ‘10231 trace name context forever,level 10‘;

Session altered.

SQL>  select count(*) from CORRUPT_ME;

  COUNT(*)
----------
     50857

SQL> create table corrupt_me_copy tablespace users as select * from  CORRUPT_ME;

Table created.

SQL> analyze table corrupt_me_copy validate  structure;

Table analyzed.

之后仅需要将新表rename为旧表,并重建索引即可:

SQL>  alter table corrupt_me rename to corrupt_me_copy1;

Table altered.

SQL> alter table corrupt_me_copy rename to corrupt_me;

Table altered.

SQL> rebuild indexs
时间: 2024-08-08 01:08:25

ora-01578的相关文章

[转] AIX lv 4k偏移量

转自:http://www.aixchina.net/Question/29969 前几天在客户数据库做巡检的时候,在警告日志中发现有如下警告:引用WARNING: You are creating datafile /dev/rtbs_data01.WARNING: Oracle recommends creating new datafiles on devices with zero offset. The command "/usr/sbin/mklv -y LVname -T O -w

对Oracle数据库坏块的理解

1.物理坏块和逻辑坏块 在数据库中有一个概念叫做数据块的一致性,Oracle的数据块的一致性包括了两个层次:物理一致性和逻辑一致性,如果一个数据块在这两个层次上存在不一致性,那就对应到了我们今天要要说的物理坏块和逻辑坏块. 在每一个数据块的头部有一个校验和字段,每当数据块要被写回磁盘前,Oracle都会重新计算 这个数据块的校验和,并记录到这个字段最终写会磁盘.下次数据块被读入内存,Oracle会重新 计算数据块的校验和,并和块头的字段相比较,如果有差异,Oracle就知道这个数据块有错误, 会

oracle block corrupt 坏块

整体上来讲,oracle的坏块能够分为两种情景:物理损坏和逻辑损坏.物理损坏是因为存储等原因造成的,致使oracle在处理数据块时发现块的checksum不一致.逻辑损坏多是因为oracle的bug或者内存错误引起,通过检測数据块的checksum并不会发现什么问题,可是在逻辑上这些块已经发生了损坏. oracle通过两个參数来控制对物理损坏和逻辑损坏的检測: SQL> show parameter db_block_check NAME TYPE VALUE -----------------

恢复数据块坏块

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

aix5.3系统安装oracle 10g使用裸设备--4k偏移量问题

今天朋友在aix 5.3系统上安装oracle 10g 建库是用裸设备时候,dbca建库到2%报错退出,观察alert日志发现是temp表空间空间不足导致.查看该表空间数据文件所在的裸设备容量为512M,建库时候给出的数据文件大小也是512M.也许是因为aix系统以1000进制计算,而oracle数据库计算容量是以1024进制导致差距,随即将oracle数据文件大小改为500M,则正常通过. 但是,在alert日志中不断爆出warning提示:WARNING: You are creating

讨厌麻烦的ora 01722无效数字

webservice开发过程中,数据库由原来的oracle改为现在的sql server.然后重新调试,结果报出ora 01722无效数字的错误. 由于连接oracle数据库的时候并没有问题,所以一开始我以为是数据库不同,导致部分数据类型差异,(但又觉得有点离谱,切换数据库,不至于会导致这种错误吧) 经过排查,总结得出如下: 1.对于两个类型不匹配(一个数字类型,一个非数字类型,同下)的值进行赋值操作;2.两个类型不匹配的值进行比较操作(例如,"=");3.to_number函数中的值

ORACLE RAC 下非缺省端口监听配置(listener.ora tnsnames.ora)

不论是单实例还是RAC,对于非缺省端口下(1521)的监听器,pmon进程不会将service/instance注册到监听器,即不会实现动态注册.与单实例相同,RAC非缺省端口的监听器也是通过设置参数local_listener来达到目的.除此之外,还可以对实例进行远程注册,以达到负载均衡的目的.这是通过一个参数remote_listener来实现. 有关Oracle 网络配置相关基础以及概念性的问题请参考:      配置ORACLE 客户端连接到数据库   配置非默认端口的动态服务注册   

oerr ora 000845解决方法是扩大/dev/shm空间

打开虚拟机发现实例起不来 [[email protected] ~]# su - oraclesq[[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Tue Aug 2 14:59:54 2016 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to an idle instance. [ema

tnsnames.ora文件说明

目录位置 unix:$ORACLE_HOME/network/admin WINDOW:%ORACLE_HOME%\network\admin 设置相应的环境变量:TNS_ADMIN tnsname.ora文件内容例子 --负载均衡,故障转移 sample2= (DESCRIPTION= (LOAD_BALANCE=on) (FAILOVER=on) (ADDRESS_LIST= (SOURCE_ROUTE=yes) (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(POR

在TNSNAMES.ORA文件中配置本机装的oracle

首先,感谢这两位网友:http://zhidao.baidu.com/link?url=eGYeoEa-EhQdVitSGqjE36uNfVmEsryXH1WUjPue6YvArDSx-Y1N9_rd9Hx6vh-NklyevkcCtAMh1X28fI1Hoq 引子: 我在Oracle SQL Developer工具中创建了一个名为"oa"的连接,然后登陆PLSQL Developer,从本地导入一张表"T_DEPT",打开Oracle SQL Developer,