O/S-Error: (OS 23) Data error (cyclic redundancy check)问题处理

RMAN-03002: backup plus archivelog 命令 (在 08/24/2015 03:31:00 上) 失败
ORA-19501: 文件 "XXXXXX.DBF", 块编号 335324 (块大小=8192) 上出现读取错误
ORA-27070: 异步读取/写入失败
OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 23) 数据错误(循环冗余检查)。

类似英文报错：
RMAN-03009: failure of backup command on ORA_DISK_4 channel at 12/27/2006 
19:34:55
ORA-19501: read error on file "\\.\ACTGINDX2", blockno 890881 (blocksize=8192)
ORA-27070: skgfdisp: async read/write failed
OSD-04016: Error queuing an asynchronous I/O request.
O/S-Error: (OS 23) Data error (cyclic redundancy check).

使用dd或者dbv检查数据文件完整性
dbv file=XXXX/XXXX.dbf blocksize=8192
dd if=XXXX/XXXX.dbf of=check.dbf bs=8192（此命令慎用！！）
检查数据文件是否损坏

检查报错的数据文件：
C:\Users\Administrator>dbv file=XXXX.DBF blocksize=8192

DBVERIFY: Release 11.2.0.4.0 - Production on 星期二 8月 25 11:20:22 2015

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

DBVERIFY - 开始验证: FILE =XXXX.DBF

DBV-00600: 致命错误 - [28] [27070] [0] [0]

检查正常的数据文件：
C:\Users\Administrator>dbv file=xxxx.DBF blocksize=8192

DBVERIFY: Release 11.2.0.4.0 - Production on 星期二 8月 25 11:22:54 2015

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

DBVERIFY - 开始验证: FILE = xxxxx.DBF


DBVERIFY - 验证完成

检查的页总数: 352000
处理的页总数 (数据): 168714
失败的页总数 (数据): 0
处理的页总数 (索引): 78722
失败的页总数 (索引): 0
处理的页总数 (其他): 1164
处理的总页数 (段)  : 0
失败的总页数 (段)  : 0
空的页总数: 103400
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 1102691533 (1473.1102691533)

根据报错信息查到相关表：

select owner,segment_name，partition_name from dba_extents where file_id=your_file_id and block_id<=335488 and block_id+blocks-1>=335488

对涉及到的表进行全表扫，并未出现报错信息：
SELECT /*+FULL(XXBC_ORDER_STACK_OUTPUT)*/ count(*) FROM XXBC_ORDER_STACK_OUTPUT
挺奇怪。

建议（慎用！！，先不要使用这种方法，风险太大）：
首先对数据库全备。
备份完，如果有备份和归档可以：
select * from v$database_block_corruption;
确定坏块的文件id和块号，然后使用rman修复
RMAN>blockrecover datafile $file_id block $block_id;



Oracle处理方法：
1 看一下这个文件是否有其它的坏块（不加blocksize参数，逻辑查看）： 
C:\Users\Administrator>dbv file=E:\APP\ADMINISTRATOR\ORADATA\TB5CWMS\TBBCD03.DBF 
DBVERIFY: Release 11.2.0.4.0 - Production on 星期三 8月 26 17:33:36 2015 
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 
DBVERIFY - 开始验证: FILE = E:\APP\ADMINISTRATOR\ORADATA\TB5CWMS\TBBCD03.DBF 
DBVERIFY - 验证完成 
检查的页总数: 390400 
处理的页总数 (数据): 154363 
失败的页总数 (数据): 0 
处理的页总数 (索引): 148171 
失败的页总数 (索引): 0 
处理的页总数 (其他): 1404 
处理的总页数 (段) : 0 
失败的总页数 (段) : 0 
空的页总数: 86462 
标记为损坏的总页数: 0 
流入的页总数: 0 
加密的总页数 : 0 
最高块 SCN : 1471212331 (1473.1471212331) 
2 联系OS管理员，检查磁盘； 
3 查看操作系统的日志，包括system和application的日志； 
4 查看数据库实例的完整的告警日志； 

根据windows系统日志（查看方法：一、开始---控制面板---管理工具---事件查看器---系统日志；二、开始---运行---cmd---eventvwr---即可查看系统日志。）


查找到系统的坏块。
但是对表进行全表扫没有报错，说明涉及到的数据块可能已经cache到内存中，所以如果能尽快将涉及到的数据对象备份，理论上不会造成数据丢失。

但是考虑上次rman备份不一定会把所有坏块全部检查出，考虑使用如下方法检查出所有坏块。
RMAN> RUN 
{ 
SET MAXCORRUPT FOR DATAFILE 10 TO 2 <<<<<============= rman在备份的时候允许的最大坏块，这个格式表示在数据文件10上最多允许有2个坏块，如果超过2个坏块，Rman就会退出备 份 
backup datafile 10; 
.... 
} 
处理思路：
根据扫描出的坏块，查找到数据对象，做备份，然后恢复。

转载于:https://www.cnblogs.com/Clark-cloud-database/p/7814199.html