Oracle 索引出现坏块处理

SQL> create table test as select * from dba_objects where rownum<1001;

Table created.

SQL> create index idx_test on test(object_id);

Index created.

SQL> select file_id, block_id, blocks from dba_extents where owner = ‘LILC‘ and segment_name = ‘IDX_TEST‘;

FILE_ID   BLOCK_ID  BLOCKS

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

6 6032       8

从第4个块开始存储,构造坏块,

RMAN>  recover datafile 6 block 6035 clear;

Starting recover at 23-SEP-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=75 device type=DISK

allocated channel: ORA_DISK_2

channel ORA_DISK_2: SID=14 device type=DISK

Finished recover at 23-SEP-15

[[email protected] ~]$ dbv userid=grid/grid file=+DATA/phub/datafile/llc01.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Sep 23 08:51:16 2015

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

DBVERIFY - Verification starting : FILE = +DATA/phub/datafile/llc01.dbf

Page 6035 is marked corrupt

Corrupt block relative dba: 0x01801793 (file 6, block 6035)

Bad check value found during dbv:

Data in bad block:

type: 6 format: 2 rdba: 0x01801793

last change scn: 0x0000.001e13c3 seq: 0x1 flg: 0x04

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

consistency value in tail: 0x13c30601

check value in block header: 0xc307

computed block checksum: 0x5f27

DBVERIFY - Verification complete

Total Pages Examined         : 655360

Total Pages Processed (Data) : 7507

Total Pages Failing   (Data) : 0

Total Pages Processed (Index): 1181

Total Pages Failing   (Index): 0

Total Pages Processed (Other): 646167

Total Pages Processed (Seg)  : 0

Total Pages Failing   (Seg)  : 0

Total Pages Empty            : 504

Total Pages Marked Corrupt   : 1

Total Pages Influx           : 0

Total Pages Encrypted        : 0

Highest block SCN            : 0 (0.0)

验证是否是该索引出现坏块:

SQL> SELECT tablespace_name, segment_type, owner,segment_name, partition_name FROM dba_extents WHERE file_id=6 and 6035 between block_id AND block_id+blocks-1;
TABLESPACE_NAME SEGMENT_TY OWNER    SEGMENT_NAME   PARTITION_NAME
--------------- ---------- -------- -------------- ------------------------------
LLCINDEX   LILC     IDX_TEST

此时如果全表扫描,是正常的,索引扫描报错:

SQL> select object_id from test;

1000 rows selected.

Execution Plan

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

Plan hash value: 1357081020

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

| Id  | Operation  | Name | Rows  | Bytes | Cost (%CPU)| Time |

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

|   0 | SELECT STATEMENT  | |  1000 | 13000 |     6   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| TEST |  1000 | 13000 |     6   (0)| 00:00:01 |

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

Note

-----

- dynamic sampling used for this statement (level=2)

Statistics

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

0  recursive calls

0  db block gets

81  consistent gets

0  physical reads

0  redo size

17797  bytes sent via SQL*Net to client

1250  bytes received via SQL*Net from client

68  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

1000  rows processed

SQL> select object_id from test where object_id<100;

select object_id from test where object_id<100

*

ERROR at line 1:

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

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

索引状态仍然是有效:

SQL> select status from dba_indexes where index_name=‘IDX_TEST‘;

STATUS

--------

VALID

可以加hint全表扫描就不会报错了:

SQL> select /*+ full(test) */object_id from test where object_id<100;

98 rows selected.

Execution Plan

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

Plan hash value: 1357081020

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

| Id  | Operation  | Name | Rows  | Bytes | Cost (%CPU)| Time |

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

|   0 | SELECT STATEMENT  | |    65 |   845 |     6   (0)| 00:00:01 |

|*  1 |  TABLE ACCESS FULL| TEST |    65 |   845 |     6   (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

1 - filter("OBJECT_ID"<100)

Note

-----

- dynamic sampling used for this statement (level=2)

Statistics

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

0  recursive calls

0  db block gets

23  consistent gets

0  physical reads

0  redo size

2137  bytes sent via SQL*Net to client

590  bytes received via SQL*Net from client

8  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

98  rows processed

解决办法:在线重建索引

SQL> alter index idx_test rebuild online;

Index altered.

SQL> select object_id from test where object_id<100;

98 rows selected.

Execution Plan

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

Plan hash value: 1128569081

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

| Id  | Operation | Name     | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT |    | 98 |  1274 |  2   (0)| 00:00:01 |

|*  1 |  INDEX RANGE SCAN| IDX_TEST | 98 |  1274 |  2   (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

1 - access("OBJECT_ID"<100)

Note

-----

- dynamic sampling used for this statement (level=2)

Statistics

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

0  recursive calls

0  db block gets

9  consistent gets

0  physical reads

0  redo size

2137  bytes sent via SQL*Net to client

590  bytes received via SQL*Net from client

8  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

98  rows processed

通过DBV和 RMAN

[[email protected] ~]$ dbv userid=grid/grid file=+DATA/phub/datafile/llc01.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Sep 23 09:25:38 2015

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

DBVERIFY - Verification starting : FILE = +DATA/phub/datafile/llc01.dbf

Page 6035 is marked corrupt

Corrupt block relative dba: 0x01801793 (file 6, block 6035)

Bad check value found during dbv:

Data in bad block:

type: 6 format: 2 rdba: 0x01801793

last change scn: 0x0000.001e13c3 seq: 0x1 flg: 0x04

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

consistency value in tail: 0x13c30601

check value in block header: 0xc307

computed block checksum: 0x5f27

DBVERIFY - Verification complete

Total Pages Examined         : 655360

Total Pages Processed (Data) : 7507

Total Pages Failing   (Data) : 0

Total Pages Processed (Index): 1179

Total Pages Failing   (Index): 0

Total Pages Processed (Other): 646169

Total Pages Processed (Seg)  : 0

Total Pages Failing   (Seg)  : 0

Total Pages Empty            : 504

Total Pages Marked Corrupt   : 1

Total Pages Influx           : 0

Total Pages Encrypted        : 0

Highest block SCN            : 0 (0.0)

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:35

List of Datafiles

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

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

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

6    FAILED 0              504          655364          1974761

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

Block Type Blocks Failing Blocks Processed

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

Data       0              7507

Index      1              1177

Other      0              646172

validate found one or more corrupt blocks

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

Finished backup at 23-SEP-15

SQL> analyze index lilc.idx_test validate structure;

Index analyzed.

RMAN> recover datafile 6 block 6035;

Starting recover at 23-SEP-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=73 device type=DISK

allocated channel: ORA_DISK_2

channel ORA_DISK_2: SID=141 device type=DISK

finished standby search, restored 1 blocks

starting media recovery

media recovery complete, elapsed time: 00:00:03--从备库修复

Finished recover at 23-SEP-15

删除索引后,重新创建索引,坏块仍然存在,但是索引可以使用

SQL> drop index idx_test;

Index dropped.

RMAN> backup check logical validate datafile 6;

Starting backup at 23-SEP-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=141 device type=DISK

allocated channel: ORA_DISK_2

channel ORA_DISK_2: SID=13 device type=DISK

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:35

List of Datafiles

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

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

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

6    FAILED 0              504          655364          1977414

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

Block Type Blocks Failing Blocks Processed

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

Data       0              7507

Index      1              1177

Other      0              646172

validate found one or more corrupt blocks

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

Finished backup at 23-SEP-15

时间: 2024-11-13 00:15:22

Oracle 索引出现坏块处理的相关文章

oracle block corrupt 坏块

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

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

学习笔记:Oracle dul数据挖掘 导出Oracle11G数据文件坏块中表中

试验模拟导出Oracle 11G数据库中数据文件坏块中表中的数据 以前一直以为dul对应的版本只能恢复最高的数据库版本一致,今天测试发现dul 10可以恢复11g最新版的数据库.模拟环境 SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition

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

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

Oracle数据库坏块的恢复

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

对Oracle数据库坏块的理解

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

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

oracle数据坏块检测

1.使用dbv检查 D:\oradata\eygle>dbv file=EYGLE.DBF blocksize=8192 DBVERIFY: Release 10.1.0.4.0 - Production on 星期六 6月 11 17:36:37 2005 Copyright (c) 1982, 2004, Oracle.  All rights reserved. DBVERIFY - 开始验证: FILE = EYGLE.DBF 页 219 标记为损坏 Corrupt block rela

Oracle 处理坏块

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