Oracle坏块问题处理 Oracle坏块修复 Oracle坏块怎么办

最新推荐文章于 2024-06-18 02:01:59 发布

Mc顽固份子

最新推荐文章于 2024-06-18 02:01:59 发布

阅读量1.7k

点赞数

分类专栏：阿里云文章标签： oracle 数据库 bug 扩展数据

阿里云专栏收录该内容

416 篇文章 0 订阅

订阅专栏

点击查看全文

Oracle数据库出现坏块现象是指：在Oracle数据库的一个或多个数据块（一个数据块的容量在创建数据库时由db_block_size参数指定，缺省为8K）内出现内容混乱的现象。由于正常的数据块都有固定的合法内容格式，坏块的出现，导致数据库进程无法正常解析数据块的内容，进而使数据库进程报错乃至挂起，并级联导致整个数据库实例出现异常。

一、坏块分类

物理坏块：也可以称为介质坏块,指的是块格式本身是坏的，块内的数据没有任何意义。

逻辑坏块：指的是块内的数据在逻辑是存在问题。比如说索引块的索引值没有按从小到大排列。物理坏块一般是由于内存问题、OS问题、IO子系统问题和硬件引起，逻辑坏块一般是是由于Oracle Bug等原因引起。

另据metalink文档Identify the corruption extension using RMAN/DBV/ANALYZE etc [ID 836658.1]，有如下分类：

Datafile Block Corruption - Physical/Logical

Table/Index Mismatch

Extents Inconsistencies

Data Dictionary Inconsistencies

可见除了物理和逻辑坏块，还有一些逻辑不一致的情况出现(TABLE / INDEX Mismatch)，在本文档不做过多讨论。

二、产生原因

坏块产生的原因大致有以下几种：

2.1 硬件问题

Oracle进程在处理一个数据块时，首先将其读入物理内存空间，在处理完成后，再由特定进程将其写回磁盘；如果在这个过程中，出现内存故障，CPU计算失误，都会导致内存数据块的内容混乱，最后反映到写回磁盘的数据块内容有误。同样，如果存储子系统出现异常，数据块损坏也就随之出现了。

2.2 操作系统BUG

由于Oracle进程对数据块的读写，都是以操作系统内核调用（system call）的方式完成的，如果操作系统在内核调用存在问题，必然导致Oracle进程写入非法的内容。

2.3 操作系统的I/O错误或缓冲问题

2.4 内存或paging问题

Oracle软件BUG。

Oracle软件特定版本上，可能出现导致数据块的内容出现异常BUG。

2.5 非Oracle进程扰乱Oracle共享内存区域

如上文所述，在当数据块的内容被读入主机的物理内存时，如果其他非Oracle进程，对Oracle使用的共享内存区域形成了扰乱，最终导致写回磁盘的数据块内容混乱。

2.6 异常关机，掉电，终止服务

异常关机，掉电，终止服务使进程异常终止，而破坏数据块的完整性，导致坏块产生。（注：这也是为什么突然断电会导致数据库无法启动）

由上可见，坏块的形成原因复杂。当出现坏块时，为了找到确切的原因，需要大量的分析时间和排查操作，甚至需要多次重现才能找出根本原因。但当故障发生在生产系统上，我们为了减少停机时间，会尽快实施应急权变措施以保证系统的可用性，这样就破坏了故障现场，对根本原因的分析因而也更加困难了。

三，如何判断坏块

3.1 Alert日志后台日志

3.2 rman命令

RMAN> BACKUP CHECK LOGICAL VALIDATE DATAFILE 数据文件号;

SQL>select * from v$database_block_corruption where file#=4;

3.3 dbv工具

$dbv file=/u01/app/oracle/oradata/PROD/user01.dbf

3.4 确定坏块对象信息

SQL>Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=数据文件号 and 块号 between block_id and block_id+blocks-1;

3.5 ora错误

SQL> select count(*) from t1;

select count(*) from t1

第 1 行出现错误:

ORA-01578: ORACLE 数据块损坏 (文件号 7, 块号 131)

ORA-01110: 数据文件 7: 'E:\WH.DBF'

3.6 关于以上排查方法的区别和优缺点

1）RMAN的BACKUP CHECK LOGICAL VALIDATE DATAFILE

该命令可以设置并行度PARALLELISM，即使是对一个数据文件检查也可以多个通道并行，所以效率是比较高的；和dbv相比，该方法也可以通过v$session_longops更加方便的完成进度监控；且rman会把坏块信息保存到控制文件 (v$database_block_corruption, v$backup_corruption)，通过sql可以很好的完成对应表空间、数据文件、对象的统计。

使用该方法的前提是需要数据库运行于归档模式，如果是非归档的话只能在mount下使用。

2） Dbv

Dbv执行块级的检测，所以这个工具无法检查如INDEX versus TABLE mismatches的情况；也无法做到自动并行；结果在os以平面文件的形式存储，不易统计。

3） ANALYZE TABLE .. VALIDATE STRUCTURE CASCADE

该命令是会在表上加tm锁，但是不影响dml。

关于该命令，SQL Reference解释如下：

Specify ONLINE to enable Oracle Database to run the validation while DML operations are ongoing within the object. The database reduces the amount of validation performed to allow for concurrency.

Note:

When you validate the structure of an object ONLINE, Oracle Database does not collect any statistics, as it does when you validate the structure of the object OFFLINE.

Specify OFFLINE, to maximize the amount of validation performed. This setting prevents INSERT, UPDATE, and DELETE statements from concurrently accessing the object during validation but allows queries. This is the default.

也就是该命令不会收集任何统计信息，不会引起sql执行计划的突变；性能方面，对于大并发的系统可能会有轻微影响。

由于dbv和rman都比较贴近底层，在mount时候就可以做，可见这两个工具都是比较贴近块级检测的，所以在做logical inconsistents(TABLE / INDEX Mismatch)方面的检测，还是需要ANALYZE TABLE .. VALIDATE STRUCTURE CASCADE这个方法。

在metalink上面有文档，可以利用该工具，在表空间级别完成检测，大大提高了检测效率，文档为SCRIPT: VALIDATE.SQL to ANALYZE .. VALIDATE STRUCTURE objects in a Tablespace [ID 100419.1]。

实际上dbv、rman、validate structure均可以检测出一定程度的逻辑讹误，但是最可靠的还是db_block_checksum=true情况下的validate structure [online]验证命令。从另一个角度来说，普通的dbv只能做单一的检测，而无法做到交叉地检验，从而了解表和索引上的不一致问题，但是validate structure online却可以做到。

所以在日常检测，考虑到效率和可靠性等，最好用rman+validate structure来完成。

四，如何修复坏块

4.1 无备份情况

4.1.1 EXP/IMP方式

4.1.2 通过内部事件跳过坏块

SQL>Alter system set events='10231 trace name context forever,level 10';

$exp userid=wh/wh file=t1.dump tables=t1

SQL>drop table t1;

$imp userid=wh/wh file=t1.dump tables=t1

4.1.3 DBMS_REPAIR包

a)创建表

SQL>BEGIN

DBMS_REPAIR.ADMIN_TABLES (

TABLE_NAME => 'REPAIR_TABLE01',

TABLE_TYPE => dbms_repair.repair_table,

ACTION => dbms_repair.create_action,

TABLESPACE => 'WH');

END;

b)收集坏块信息

DECLARE num_corrupt INT;

BEGIN

num_corrupt := 0;

DBMS_REPAIR.CHECK_OBJECT (

SCHEMA_NAME => 'WH',

OBJECT_NAME => 'T1',

REPAIR_TABLE_NAME => 'REPAIR_TABLE01',

corrupt_count => num_corrupt);

DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));

END;

c)查看结果

SQL> select object_name, block_id, corrupt_type, marked_corrupt,corrupt_description,repair_description from repair_table01;

d)跳过坏块

BEGIN

DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (

SCHEMA_NAME => 'WH',

OBJECT_NAME => 'T1',

OBJECT_TYPE => dbms_repair.table_object,

FLAGS => dbms_repair.SKIP_FLAG);

END;

注：这两种方法均是跳过坏块，而不去修复，数据有丢失。

4.1.4 rman制造坏块,bbed修复坏块

a)建立测试表

SQL> create tablespace test datafile '/home/oracle/oradata/orcl/test.dbf' size 100m;

Tablespace created.

SQL> create table test (a number,b varchar2(20)) tablespace test;

Table created.

SQL> Select rowid,dbms_rowid.rowid_relative_fno(rowid) rel_fno,dbms_rowid.rowid_block_number(rowid) block from test;

ROWID REL_FNO BLOCK

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

AAASwmAAGAAAACHAAA 6 135

AAASwmAAGAAAACHAAB 6 135

AAASwmAAGAAAACHAAC 6 135

AAASwmAAGAAAACHAAD 6 135

AAASwmAAGAAAACHAAE 6 135

AAASwmAAGAAAACHAAF 6 135

6 rows selected.

SQL> alter system checkpoint;

System altered.

b)DBV检测数据文件

[oracle@bjtest ~]$ dbv file=/home/oracle/oradata/orcl/test.dbf blocksize=8192

DBVERIFY: Release 11.2.0.3.0 - Production on Wed Jul 17 06:39:00 2013

DBVERIFY - Verification starting : FILE = /home/oracle/oradata/orcl/test.dbf

DBVERIFY - Verification complete

Total Pages Examined : 12800

Total Pages Processed (Data) : 5

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing (Index): 0

Total Pages Processed (Other): 130

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 12665

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Total Pages Encrypted : 0

Highest block SCN : 911665 (0.911665)

这里创建了test表,数据存储在file 6 block 135 中,现在该block一切正常,本试验就是要通过rman来使得该block corrupt,然后通过bbed来修复

c)bbed查看kcbh

BBED> set dba 6,135

BBED> print kcbh

struct kcbh, 20 bytes @0

ub1 type_kcbh @0 0x06

ub1 frmt_kcbh @1 0xa2

ub1 spare1_kcbh @2 0x00

ub1 spare2_kcbh @3 0x00

ub4 rdba_kcbh @4 0x01800087

ub4 bas_kcbh @8 0x000de931

ub2 wrp_kcbh @12 0x0000

ub1 seq_kcbh @14 0x01

ub1 flg_kcbh @15 0x06 (KCBHFDLC, KCBHFCKV)

ub2 chkval_kcbh @16 0x59c2

ub2 spare3_kcbh @18 0x0000

d)RMAN标记坏块

RMAN> BLOCKRECOVER DATAFILE 6 block 135 clear;

Starting recover at 17-JUL-13

using channel ORA_DISK_1

Finished recover at 17-JUL-13

e)dbv再次检查坏块

[oracle@bjtest ~]$ dbv file=/home/oracle/oradata/orcl/test.dbf blocksize=8192

DBVERIFY: Release 11.2.0.3.0 - Production on Wed Jul 17 06:48:44 2013

DBVERIFY - Verification starting : FILE = /home/oracle/oradata/orcl/test.dbf

Page 135 is marked corrupt

Corrupt block relative dba: 0x01800087 (file 6, block 135)

Bad check value found during dbv:

Data in bad block:

type: 6 format: 2 rdba: 0x01800087

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

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

consistency value in tail: 0xe9310601

check value in block header: 0x59c2

computed block checksum: 0x923b

DBVERIFY - Verification complete

Total Pages Examined : 12800

Total Pages Processed (Data) : 4

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing (Index): 0

Total Pages Processed (Other): 130

Total Pages Processed (Seg) : 0

点击查看全文

Mc顽固份子

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Oracle坏块问题处理 Oracle坏块修复 Oracle坏块怎么办

点击查看全文Oracle数据库出现坏块现象是指：在Oracle数据库的一个或多个数据块（一个数据块的容量在创建数据库时由db_block_size参数指定，缺省为8K）内出现内容混乱的现象。由于正常的数据块都有固定的合法内容格式，坏块的出现，导致数据库进程无法正常解析数据块的内容，进而使数据库进程报错乃至挂起，并级联导致整个数据库实例出现异常。一、坏块分类
复制链接

扫一扫