数据库坏块

⑴ 请问Oracle数据库恢复怎么弄啊，oracle数据库中数据文件出现坏块，求解

Oracle因为结构复杂在日常工作中经常会碰到因非正常退出、网络不稳定或病毒等原因造成的Oracle数据库损坏。损坏了的数据库会造成软件运行不稳定，出现各种运行错误

⑵ 我们单位用的是oracle数据库 现在发现数据库老有坏块 请问oracle里要怎么检测坏块呢

虽然我们也可以通过dbv(dbfileverify)工具做到对单个数据文件的坏块检测，但是直接使用RMAN的”;”结合V$DATABASE_BLOCK_CORRUPTION视图要方便地多。

Script:

1)$rmantarget/nocatalog

2)RMAN>run{
allocatechanneld1typedisk;
allocatechanneld2typedisk;
allocatechanneld3typedisk;
allocatechanneld4typedisk;
;
}

3)select*fromV$DATABASE_BLOCK_CORRUPTION;

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

⑶ 遇到大规模oracle坏块该怎么处理

最近一两个月，一直有场景化运维、场景化大数据分析的声音围绕在耳畔，以Gdevops全球敏捷运维峰会杭州站上新炬网络执行副总裁程永新的“ 一切没有场景驱动的运维平台建设都是假大空！ ”最为振聋发聩。我们一直在谈技术，谈原理，谈内核，总以为“懂了”这些的人，就势必能广阔天地大有所为。

技术固然重要，但偏离了业务/应用场景的技术，无法呈现业务价值的技术就非常不重要。

技术也应该是场景驱动的，对于运维技术人员来说，离开场景学习的所谓高深技术，只是浪费时间。所以新同事进入一个新团队后，能使技术更好发挥作用的环境、流程的考核会占据了另外的三分之二。

今天来谈谈Oracle坏块问题。 坏块问题，相信做过两三年Oracle维护、支持的DBA都会遇到过，即使从来没遇到过的，看过Oracle 官方文档的甚至是会度娘或者谷哥的，应该也知道基本的处理手段。

这是我内部分享的一个简单思维导图，如果有遗漏，欢迎在后面评论补充。

面试的时候通常是这么问的：你了解Oracle坏块么？坏块为什么会产生？描述一下你处理过的坏块案例细节？如果你负责的好几个数据库都突然发生了坏块，你会怎么做？

通常，前面几个问题的回答都不会太差。但是最后一个问题的回答，鲜有能出众的。原因在于面太窄，思维太窄。如果这个时候你还要一个个库的去看alert日志，那么显然就走错了方向。

现实情况就是，我们的数据库可能是五六十套，或者上百套，你一套套库的去看这些日志里的报错的块，再根据块找到对象，确定是表还是索引，再去用坏块的修复手段去修复…….那么，所有人都会被你害了。

我们经历过，花了两天的时间，都没修复完一个库中几万个坏块的情况，在其他大牛还在哼哧哼哧做恢复的时候，我向领导提议启用了新的方案，在大老板没有完全失去耐性的情况下恢复了业务。

真正正确的做法是，如果确定坏块数量为数众多，赶紧停业务，切灾备，后面再补数据。 灾备是干什么吃的，养库千日，用库一时，就在这个时候了！

非常可惜的是，大多数来面试的DBA会非常纠结于用block recover，还是用dbms_repair，还是用BBED，还是……

那么，什么时候往上申报，要切灾备？

且不谈许多公司的灾备形同虚设，关键时候不敢切的事情。就算这些灾备都是实实在在可用的，恐怕也不是说切立即就能切的，切灾备涉及到应用、网络、主机、存储等多方面的调整。

那么多久应该切呢？ 一般的企业从故障处理开始，预估2小时之内不能让业务恢复正常运行的，应该申报切灾备。当然，如果是金融行业，特别是证券基金行业，1分钟之内故障还没恢复，就要知会证监会，半个小时没有恢复就会受到同行业通报，所以要切就应该在这个时间之内申报。

问题又回到了原点。你得先有规划，作为企业的重要系统，你得先建设灾备环境，而且是有效的灾备，并且应该事先有一个灾备切换预案。

作为DBA来说，动作敏捷的检查数据库的情况，并及时汇报非常重要。其实这里，又想说自动运维平台了。通过简单的按钮点点，就能快速知道告警日志里的坏块涉及什么对象，是不是就好很多呢？

继续往回看，面试的问题是什么？是多个数据库同时发现大量坏块。

作为一个经验丰富的运维管理人员，第一反应应该是，为什么会同时发生呢？显然是由于外因导致的。因此做好容灾切换，业务恢复使用的第一时间，应该去看看这些数据库共同的基础是不是同样的存储、同样的存储管理软件、卷管理软件。

依我的经验，大部分多个库同时出现坏块，都坏在存储管理软件身上。

有一次是Storage Foundation做卷复制的时候出现了软件bug，IBM、Oracle、symentec等众多厂家在“问题作战室”里整整呆了一个月，各家公司二线、三线出具各种证据自己没问题，最后最后才找到蛛丝马迹，揪出来。

还有一次稍微容易些，存储软件状态恢复后坏块没有恢复，一个个系统通过fsck命令来进行的修复。你说，这是什么类型的坏块呢？

作为有经验的DBA，要解决问题，但不要急着去敲命令，站在更高点的位置来看待问题，可能会事半功倍。

很不幸的前两天，某个朋友公司核心数据库“莫名奇妙”地遇到中止了。原因不方便说，但是据说等故障恢复完之后，朋友已经抽了好几包烟了。

我们先来看看，是由于LGWR终止了数据库（ 注：做了一些脱敏处理 ）。

但是，重启数据库却发现数据库启动不了，发现众多数据文件发生了坏块，数据库根本不能open：

同时伴随着类似的内部错误：

怎么破？通过当天的数据库备份结合归档进行恢复，远远比去修复坏块要快。

⑷ Oracle 数据库中的出现坏块问题，该如何处理

oracle数据库的坏块问题是个让人比较头痛的问题，主要分为逻辑坏块和物理坏块，逻辑坏块就是数据文件里的逻辑关系出现的混乱，这一般是由于数据库的BUG导致的。物理坏块就是数据文件中的数据不存在任何意义，没有任何逻辑和结构，造成物理坏块多因为服务器IO系统故障导致的。

⑸ oracle检查数据库是否有坏块的命令

dbv是检查物理上是否有坏块的命令

#su - oracle
#dbv file=/oracleruanko/app/oracle/oracle/proct/10.2.0/ruanko/dbs/ruankotest blocksize=8192

DBVERIFY: Release 10.2.0.1.0 - Proction on Fri May 28 09:56:37 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

DBVERIFY - Verification starting : FILE = /oracleruanko/app/oracle/oracle/proct/10.2.0/ruanko/dbs/ruankotest

⑹ ORACLE使用dbv工具检验数据文件是否有坏块

dbv工具可以用来验证数据文件的有效性，在数据库恢复之前可以使用该命令对备份文件进行有效性检查，
防止因备份文件本身的问题导致数据库无法恢复。
当然，dbv命令也可以对在线的数据文件进行检查。
注意，dbv工具只可以对数据文件进行检查，无法使用它完成控制文件和日志文件的检查。
1.dbv命令语法
dbverify ::=
dbv [ USERID=username/password ]
FILE = filename
| { START = block_address | END = block_address }
| BLOCKSIZE = integer
| HIGH_SCN = integer
| LOGFILE = filename
| FEEDBACK = integer
| HELP = { Y | N }
| PARFILE = filename
End of description.
参考自Oracle官方文档http://download.oracle.com/docs/cd/E11882_01/server.112/e10701/img_text/dbverify.htm
2.查看帮助文档
从语法定义中我们看到“HELP = { Y | N }”选项，我们可以使用它查看dbv的帮助信息。
ticket@secDB /home/oracle$ dbv help=y
DBVERIFY: Release 11.2.0.1.0 - Proction on Wed Mar 31 19:47:36 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Keyword Description (Default)
----------------------------------------------------
FILE File to Verify (NONE)
START Start Block (First Block of File)
END End Block (Last Block of File)
BLOCKSIZE Logical Block Size (8192)
LOGFILE Output Log (NONE)
FEEDBACK Display Progress (0)
PARFILE Parameter File (NONE)
USERID Username/Password (NONE)
SEGMENT_ID Segment ID (tsn.relfile.block) (NONE)
HIGH_SCN Highest Block SCN To Verify (NONE)
(scn_wrap.scn_base OR scn)
帮助信息中描述了dbv命令的使用方法，不赘述。
3.体验dbv工具的效果
1）查看系统中的数据文件名称
sys@ticket> col name for a60
sys@ticket> select name from v$datafile;
NAME
------------------------------------------------------------
/oracle/ora11gR2/oradata/ticket/system01.dbf
/oracle/ora11gR2/oradata/ticket/sysaux01.dbf
/oracle/ora11gR2/oradata/ticket/undotbs01.dbf
/oracle/ora11gR2/oradata/ticket/users01.dbf
2）使用dbv工具对users01.dbf进行检查
（1）使用最简单的参数
sys@ticket> !dbv file=/oracle/ora11gR2/oradata/ticket/users01.dbf
DBVERIFY: Release 11.2.0.1.0 - Proction on Wed Mar 31 19:50:59 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle/ora11gR2/oradata/ticket/users01.dbf

DBVERIFY - Verification complete
Total Pages Examined : 35520
Total Pages Processed (Data) : 33029
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 20
Total Pages Failing (Index): 0
Total Pages Processed (Other): 402
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 2069
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 9291961 (0.9291961)
在实际使用中重点关注以下信息：
Total Pages Failing (Data) : 0
Total Pages Failing (Index): 0
Total Pages Failing (Seg) : 0
Total Pages Marked Corrupt : 0
如果以上信息返回结果不为0，需要重点关注！及时排查原因。
（2）如果指定logfile参数，检查结果将只记录在日志文件中，屏幕上不显示
sys@ticket> !dbv file=/oracle/ora11gR2/oradata/ticket/users01.dbf logfile=dbv_users01.log
DBVERIFY: Release 11.2.0.1.0 - Proction on Wed Mar 31 19:52:20 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
此时可以使用SQL*Plus的edit命令查看生成的日志文件内容。
sys@ticket> ed dbv_users01.log