oracle坏块修复
Oracle 数据库中的出现坏块问题该如何处理_光环大数据培训

reserved.DBVERIFY - 验证正在开始 : FILE = system01.dbfDBVERIFY - 验证 完成 检查的页总数 :32000 处理的页总数(数据) :13261 失败的
页总数(数据) :0 处理的页总数(索引) :2184 失败的页总数(索引) :0 处理 的页总数(其它) :1369 处理的总页数 (段) 的页总数 数 :0 注:因为 dbv 要求 file 后面跟的必须是一个文件扩展名,所以如果用裸 设备存储的,就必须使用 ln 链接裸设备到一个文件,然后再用 dbv 对这个链 接文件进行检查。 : 0 失败的总页数 (段) : 0空
索引或者分区索引 5 常用的处理方法有: 1 (9i 以上版本可用) 3
通过 ROWID RANGE SCAN 保存数据 4
光环大数据
光环大数据--大数据培训&人工智能培训 用 DBMS_REPAIR5 使用 EVENT
光环大数据--大数据培训&人工智能培训 Oracle 数据库中的出现坏块问题该如何处理_光环大数据培训
光环大数据是国内知名的 IT 培训机构,大数据培训,数据分析培训、人工 智能培训等课程全国领先,帮助学员提升技术水平并保障就业,深受学员喜爱, 获得业界的一致好评。
数据字典中的坏块是不会发现的 2. 如果只是对数据库中比较重要的表进行坏块检查,可以使用 ANALYZE
TABLE tablename VALIDATE STRUCTURE CASCADE 的方法来检测坏块,它执行坏 块的检查,但是不会标记坏块为 corrupt,检测的结果保存在 USER_DUMP_DEST 目录下的用户 trace 文件中。 3. 使用 Oracle 的专门工具 dbv 来检查坏块,具体的语法如下:
使用Oracle BMR(块介质恢复)功能快速恢复数据

使用BMR功能快速修复数据坏块Oracle提供了许多方法检测和修补数据库中的数据坏块,而BMR就是其中之一,其它方法还包括Analyze语句、dbv命令以及DBMS_REPAIR等。
DBMS_REPAIR包仅仅对transaction层和data层的坏块(即逻辑损坏的块)起作用,对物理上损坏的块,在它被读到缓冲区中时就已被标识出来了,而DBMS_REPAIR会忽略所有被标识为坏了的块。
要快速修复物理损坏的数据块,可以通过BMR功能来完成。
块介质恢复的最大好处在于可以降低平均恢复时间(MTTR) ,因为介质恢复的最小可恢复单位从数据文件缩小到块。
如果已知数据库中只有少量的块需要介质恢复,则最有效的方式是有选择地进行还原,只恢复需要恢复的块。
而且该技术提高了介质恢复期间的数据可用性,因为在数据恢复期间,数据文件可以保持联机状态,只有正在恢复的数据块是不可访问的。
使用BMR之前,需要对保护的数据进行备份。
在执行BMR时,只需要简单地执行blockrecover 命令就可以了,例如编号为4的数据文件的数据块385发生了损坏,修复时可以如下:RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 385;下面通过一个实例来讨论BMR的使用。
一、建立测试环境首先建立一个测试用的表T1,T1的结构如下:SQL> desc t1Name Null? Type--------------------------------------------------- -------- ---------------------COL1 NUMBERCOL2 CHAR(1000)将COL2的数据类型设置为CHAR(1000)只是为了让每个行记录占用的空间更多,这样我们可以使用较少的记录填充多个数据块。
为该测试表填入一部分测试数据:SQL>insert into t1 select rownum,rownum from dual connect by rownum<=20;上述语句使用了层次查询语句。
oracle数据库表损坏解决办法

oracle数据库表损坏解决办法10.9上午,我和同事小汪一起到foshan,诊断解决数据坏块的问题,问题:用户查询一个表时,报数据文件有坏块目标:用户可以接受丢失这些坏块的数据,但该数据文件其它的好块应该可以查询数据。
下面是具体的步骤:1.询问用户徐工出错的表名,收集出错信息出错表名:fsgazhjf.fsgazhjf_tac_20061018trace文件中的出错信息:***Corrupt block relative dba: 0xb8428b33 (file 737, block 166707)Fractured block found during user buffer readData in bad block -type: 6 format: 2 rdba: 0xb8428b33last change scn: 0x0000.0a66398d seq: 0x1 flg: 0x00consistency value in tail: 0xbddc0601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***2.根据出错块id,查询出该块对应的物理表,跟第一步收集的比对select * from dba_extentswhere file_id=737 and block_id <= 166707 and (block_id + blocks - 1) >= 166707;FSGAZHJF FSGAZHJF_TAC_20061018 TABLE FSGAZHJF_GSM_10 1201 737 166665 1048576 128 737结果:的确是该表:FSGAZHJF_TAC_20061018,用户FSGAZHJF,表空间FSGAZHJF_GSM_103.查询该表,看报错信息是否和第一步一致select count(1) from fsgazhjf.fsgazhjf_tac_20061018;结果:果然报错4.收集该表的所有索引select * from dba_indexes where owner='FSGAZHJF' and lower(table_name)='fsgazhjf_tac_20061018';no rows结果:无索引5.用dbv工具来check bad blockSQL> select file_id||' '||file_name from dba_data_files where file_id=737;FILE_ID||''||FILE_NAME--------------------------------------------------------------------------------------------------737 K:ORADATAORA8FSGAZHJF_GSM_10_50.DBFC:>dbv file='K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF' blocksize=8192 logfile='h:dbv.log'DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006(c) Copyright 2000 Oracle Corporation. All rights reserved.DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006(c) Copyright 2000 Oracle Corporation. All rights reserved.DBVERIFY - 检验开始:FILE = K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF标记为损坏的页面166708***Corrupt block relative dba: 0xb8428b34 (file 0, block 166708) Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xcf012b08last change scn: 0x0000.0a91bf69 seq: 0x1 flg: 0x00consistency value in tail: 0x0ccc0601check value in block header: 0x0, block checksum disabledspare1: 0x0, spare2: 0x0, spare3: 0x0***标记为损坏的页面166709***Corrupt block relative dba: 0xb8428b35 (file 0, block 166709) Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xce00e7e9last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00 consistency value in tail: 0x0ce80601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***标记为损坏的页面166710***Corrupt block relative dba: 0xb8428b36 (file 0, block 166710) Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xce00e7ealast change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00 consistency value in tail: 0x0ce80601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***标记为损坏的页面166711***Corrupt block relative dba: 0xb8428b37 (file 0, block 166711)Bad header found during dbv:Data in bad block -type: 6 format: 2 rdba: 0xce00e7eblast change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00consistency value in tail: 0x39910601check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0***DBVERIFY - 完成检验检查的页面总数:262144处理的页面总数(数据):262010失败的页面总数(数据):0处理的页面总数(索引):0失败的页面总数(索引):0处理的页面总数(其它):9空的页面总数:120标记损坏的页面总数:4汇集的页面总数:0检查结果:4个坏块,块号是166708 ~ 166711 ,经查询,发现都在一个extent里,属于同一张表6.开始打标记具体过程:C:>sqlplus sys/change_on_installSQL*Plus: Release 8.1.7.0.0 - Production on 星期四11月9 12:18:08 2006(c) Copyright 2000 Oracle Corporation. All rights reserved.连接到:Oracle8i Enterprise Edition Release 8.1.7.4.1 - ProductionWith the Partitioning optionJServer Release 8.1.7.4.1 - ProductionSQL>execdbms_repair.admin_tables('REPAIR_TABLE',1,1,'USERS');PL/SQL 过程已成功完成。
ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案引言概述:ORACLE 数据库是目前企业常用的一种数据库管理系统,但在使用过程中难免会遇到各种故障。
本文将介绍一些常见的 ORACLE 数据库故障,并提供相应的解决方案,帮助读者更好地应对数据库故障。
一、数据库连接问题1.1 连接超时:当数据库连接超时时,可以通过增加连接超时时间的方式解决。
在 ORACLE 数据库中,可以通过修改 sqlnet.ora 文件中的SQLNET.INBOUND_CONNECT_TIMEOUT 参数来设置连接超时时间。
1.2 连接被拒绝:如果数据库连接被拒绝,可能是由于数据库实例未启动、监听器未启动或者网络故障等原因导致。
解决方案包括启动数据库实例、启动监听器以及检查网络连接是否正常。
1.3 连接池问题:当数据库连接池达到最大连接数时,新的连接请求会被拒绝。
解决方案包括增加连接池的最大连接数、释放闲置连接以及优化数据库连接的使用。
二、数据丢失问题2.1 意外删除数据:当数据被意外删除时,可以通过数据库备份和恢复的方式解决。
可以使用RMAN 工具进行数据库备份,并在需要时使用备份进行恢复操作。
2.2 数据库文件损坏:当数据库文件损坏时,可以使用 RMAN 工具进行数据库文件的修复。
RMAN 提供了诊断和修复数据库文件的功能,可以帮助解决数据库文件损坏的问题。
2.3 数据库坏块:当数据库出现坏块时,可以使用 RMAN 工具进行坏块的修复。
RMAN 提供了坏块检测和修复的功能,可以帮助解决数据库坏块问题。
三、性能问题3.1 慢查询:当数据库查询变慢时,可以通过优化查询语句、创建索引、增加硬件资源等方式解决。
可以使用 Explain Plan 工具来分析查询语句的执行计划,找出慢查询的原因,并进行相应的优化。
3.2 死锁:当数据库出现死锁时,可以通过锁等待超时、死锁检测和解锁等方式解决。
可以使用 V$LOCK 和 V$SESSION 视图来查看当前的锁信息,并根据情况进行相应的解锁操作。
Oracle数据库文件损坏修复(断电情况下)

现场情况:1、数据库没有作归档,2、数据都存放在system表空间3、没有备份状况:操作系统由于磁盘原因出现宕机,用户强行按电源关闭系统,数据库无法启动。
处理:Sql代码1.SQL> recover database;2.ORA-00283: recovery session canceled due to errors3.ORA-12801: error signaled in parallel query server P0024.ORA-10562: Error occurred while applying redo to data block (file# 1, block#4568)5.ORA-10564: tablespace SYSTEM6.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'7.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 5768.ORA-00600: internal error code, arguments: [6101]9.检查日志信息如下:Oracle代码1.Mon Nov 1915:38:5020072.ALTER DATABASE RECOVER database3.Mon Nov 1915:38:5020074.Media Recovery Start5. parallel recovery started with 3 processes6.Mon Nov 1915:38:5020077.Recovery of Online Redo Log: Thread 1 Group 3 Seq 16 Reading mem 08. Mem# 0 errs 0: /opt/oracle/oradata/orcl/redo03.log9.Mon Nov 1915:38:50200710.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:11.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []12.Mon Nov 1915:38:50200713.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:14.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []15.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)16.ORA-10564: tablespace UNDOTBS117.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'18.ORA-10560: block type 'KTU UNDO BLOCK'19.Mon Nov 1915:38:51200720.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:21.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []22.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)23.ORA-10564: tablespace UNDOTBS124.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'25.ORA-10560: block type 'KTU UNDO BLOCK'26.Mon Nov 1915:38:51200727.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:28.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 4568)29.ORA-10564: tablespace SYSTEM30.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'31.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 57632.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []33.Mon Nov 1915:38:54200734.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:35.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []36.Mon Nov 1915:38:54200737.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:38.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)39.ORA-10564: tablespace SYSTEM40.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'41.ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 23742.ORA-00607: Internal error occurred while making a change to a data block43.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []44.Mon Nov 1915:38:54200745.Media Recovery failed with error 1280146.ORA-283 signalled during: ALTER DATABASE RECOVER database ...从上面信息中抓取了一个信息:Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)针对这个错误解决如下:Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# string, block# string)2.Cause: See other errors on error stack.3.Action: Investigate why the error occurred and how important isthe data block. Media and standby database recovery usually ca n continue if user allows recovery to corrupt this data block。
oracle 故障恢复案例

oracle 故障恢复案例Oracle故障恢复案例1. 数据库实例崩溃恢复某公司的Oracle数据库实例突然崩溃,导致所有业务无法正常运行。
经过专业技术人员的分析,发现是由于服务器硬件故障导致的。
为了恢复数据库,技术人员采取了备份恢复的方式,通过使用备份数据文件和重做日志文件,成功将数据库实例恢复到崩溃前的状态。
2. 数据文件损坏的恢复某公司的数据库中的一个数据文件损坏,导致部分数据无法正常访问。
为了解决这个问题,技术人员首先通过文件系统级别的工具检查数据文件的完整性,并确定了损坏的范围。
然后,他们使用备份数据文件和重做日志文件进行恢复,成功修复了损坏的数据文件,并使数据库恢复正常。
3. 表空间故障的恢复某公司的数据库中的一个表空间突然出现故障,导致表空间中的所有表无法访问。
为了解决这个问题,技术人员首先通过Oracle的故障自诊断工具诊断表空间故障的原因,并确定了故障的范围。
然后,他们使用备份的表空间文件和重做日志文件进行恢复,成功修复了故障的表空间,并使其正常运行。
4. 数据库日志文件损坏的恢复某公司的数据库日志文件突然损坏,导致数据库无法正常启动。
为了恢复数据库,技术人员首先检查了日志文件的完整性,并确定了损坏的范围。
然后,他们使用备份的日志文件进行恢复,成功修复了损坏的日志文件,并使数据库恢复正常。
5. 控制文件丢失的恢复某公司的数据库控制文件丢失,导致数据库无法正常启动。
为了解决这个问题,技术人员首先通过文件系统级别的工具检查控制文件的完整性,并确定了丢失的范围。
然后,他们使用备份的控制文件进行恢复,成功恢复了丢失的控制文件,并使数据库正常启动。
6. 数据库块损坏的恢复某公司的数据库中的一个数据块突然损坏,导致数据库无法正常读取该块的数据。
为了解决这个问题,技术人员首先通过Oracle的故障自诊断工具诊断数据块故障的原因,并确定了损坏的范围。
然后,他们使用备份的数据块进行恢复,成功修复了损坏的数据块,并使数据库恢复正常。
ORACLE坏块(ORA-01578)模拟与处理方法

ORACLE坏块(ORA-01578)模拟与处理方法一。
.什么是数据库的坏块首先我们来大概看一下数据库块的格式和结构——数据库的数据块有固定的格式和结构,分三层cache layer,transaction layer,data layer。
在我们对数据块进行读取写入操作的时候,数据库会对要读写的数据块做一致性的检查,其中包括数据块的类型、数据块的地址信息、数据块的SCN号以及数据块的头部和尾部。
如果发现其中有不一致的信息,那数据库就会标记这个数据块为坏块了。
数据库的坏块分为两种,逻辑坏块和物理坏块。
二.模拟坏块SQL> conn systemSQL> create tablespace corrupt datafile 'C:\corrupt.dbf' size 200k;SQL> create table corrupt_tab tablespace corrupt as select * from all_users;SQL> alter table corrupt_tab modify(user_id primary key);SQL> select extent_id,file_id,block_id,blocks from dba_extents2 where owner='SYSTEM' and segment_name='CORRUPT_TAB';EXTENT_ID FILE_ID BLOCK_ID BLOCKS---------- ---------- ---------- ----------0 8 17 8上述查询说明,这个表具有一个区间EXTNET_ID 0,位于8号文件,从块号17开始,大小为8个块。
SQL> conn / as sysdbaSQL> shutdown immediate;用UE编辑器模拟出物理或逻辑坏块。
oracle坏块修复

Oracle 坏块总结收藏Oracle数据库出现坏块现象是指:在Oracle数据库的一个或多个数据块(一个数据块的容量在创建数据库时由db_block_size参数指定,缺省为8K)内出现内容混乱的现象。
由于正常的数据块都有固定的合法内容格式,坏块的出现,导致数据库进程无法正常解析数据块的内容,进而使数据库进程报错乃至挂起,并级联导致整个数据库实例出现异常。
一.坏块的产生原因坏块产生的原因大致有以下几种:1.1 硬件问题Oracle进程在处理一个数据块时,首先将其读入物理内存空间,在处理完成后,再由特定进程将其写回磁盘;如果在这个过程中,出现内存故障,CPU计算失误,都会导致内存数据块的内容混乱,最后反映到写回磁盘的数据块内容有误。
同样,如果存储子系统出现异常,数据块损坏也就随之出现了。
1.2 操作系统BUG由于Oracle进程对数据块的读写,都是以操作系统内核调用(system call)的方式完成的,如果操作系统在内核调用存在问题,必然导致Oracle进程写入非法的内容。
1.3 操作系统的I/O错误或缓冲问题1.4 内存或paging问题Oracle软件BUGOracle软件特定版本上,可能出现导致数据块的内容出现异常BUG。
1.5 非Oracle进程扰乱Oracle共享内存区域如上文所述,在当数据块的内容被读入主机的物理内存时,如果其他非Oracle进程,对Oracle 使用的共享内存区域形成了扰乱,最终导致写回磁盘的数据块内容混乱。
1.6 异常关机,掉电,终止服务异常关机,掉电,终止服务使进程异常终止,而破坏数据块的完整性,导致坏块产生。
注:这也是为什么突然断电会导致数据库无法启动由上可见,坏块的形成原因复杂。
当出现坏块时,为了找到确切的原因,需要大量的分析时间和排查操作,甚至需要多次重现才能找出根本原因。
但当故障发生在生产系统上,我们为了减少停机时间,会尽快实施应急权变措施以保证系统的可用性,这样就破坏了故障现场,对根本原因的分析因而也更加困难了。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Oracle 坏块总结收藏Oracle数据库出现坏块现象是指:在Oracle数据库的一个或多个数据块(一个数据块的容量在创建数据库时由db_block_size参数指定,缺省为8K)内出现内容混乱的现象。
由于正常的数据块都有固定的合法内容格式,坏块的出现,导致数据库进程无法正常解析数据块的内容,进而使数据库进程报错乃至挂起,并级联导致整个数据库实例出现异常。
一.坏块的产生原因坏块产生的原因大致有以下几种:1.1 硬件问题Oracle进程在处理一个数据块时,首先将其读入物理内存空间,在处理完成后,再由特定进程将其写回磁盘;如果在这个过程中,出现内存故障,CPU计算失误,都会导致内存数据块的内容混乱,最后反映到写回磁盘的数据块内容有误。
同样,如果存储子系统出现异常,数据块损坏也就随之出现了。
1.2 操作系统BUG由于Oracle进程对数据块的读写,都是以操作系统内核调用(system call)的方式完成的,如果操作系统在内核调用存在问题,必然导致Oracle进程写入非法的内容。
1.3 操作系统的I/O错误或缓冲问题1.4 内存或paging问题Oracle软件BUGOracle软件特定版本上,可能出现导致数据块的内容出现异常BUG。
1.5 非Oracle进程扰乱Oracle共享内存区域如上文所述,在当数据块的内容被读入主机的物理内存时,如果其他非Oracle进程,对Oracle 使用的共享内存区域形成了扰乱,最终导致写回磁盘的数据块内容混乱。
1.6 异常关机,掉电,终止服务异常关机,掉电,终止服务使进程异常终止,而破坏数据块的完整性,导致坏块产生。
注:这也是为什么突然断电会导致数据库无法启动由上可见,坏块的形成原因复杂。
当出现坏块时,为了找到确切的原因,需要大量的分析时间和排查操作,甚至需要多次重现才能找出根本原因。
但当故障发生在生产系统上,我们为了减少停机时间,会尽快实施应急权变措施以保证系统的可用性,这样就破坏了故障现场,对根本原因的分析因而也更加困难了。
二.坏块的预防坏块问题破坏性大,但并非不可预防。
2.1 在网站,Oracle定期发布基于特定软件版本的“已知问题(known issues)说明”。
对于可能导致坏块的Oracle软件BUG,在Oracle公司内部,是作为高严重级别的问题进行处理,在“已知问题(known issues)说明”中,这些BUG以严重(Noticable)问题标出(标记为*或+),部分问题,Oracle还会发布警告(Alert)通告。
在文档中,Oracle会提供相应的补丁或应对措施。
2.2 Oracle提供备份恢复工具-Recovery Manager,提供了扫描文件检查坏块的功能。
在Recovery Manager界面中,使用:RMAN> BACKUP CHECK LOGICAL V ALIDATE DATAFILE n ;可以检查数据文件是否包含坏块,同时并不产生实际的备份输出。
2.3 Dbv工具检查注:因为dbv要求file后面跟的必须是一个文件扩展名,所以如果用裸设备存储的,就必须使用ln链接裸设备到一个文件,然后再用dbv对这个链接文件进行检查。
ANAL YZE TABLE tablename V ALIDATE STRUCTURE CASCADE它执行坏块的检查,但是不会标记坏块为corrupt,检测的结果保存在USER_DUMP_DEST 目录下的用户trace文件中。
2.4 利用exp工具导出整个数据库可以检测坏块对以下情况的坏块是检测不出来的:HWM以上的坏块是不会发现的索引中存在的坏块是不会发现的数据字典中的坏块是不会发现的结合数据库性能综合考虑db_block_checksum和db_blockchecking参数。
当我们使用Recovery Manager进行实际的数据库备份时,同时也就进行了坏块检查。
但要注意的是,在线使用Recovery Manager扫描坏块和备份时,需要数据库运行在归档模式(archive log),否则只能在数据库未打开的情况下进行。
对于操作系统问题和硬件故障,则需要相应厂商的配合支持。
同时,避免在数据库主机运行其他用户进程,避免异常停机,也会减少坏块发生的几率。
三.坏块故障的识别遇到坏块问题时,数据库的异常表现通常有:报告ORA-01578错误。
报告Ora-1110错误。
报告ORA-00600错误,其中,第一个参数为2000-8000,Cache layer 2000 –4000,Transaction layer 4000 –6000,Data layer 6000 - 8000。
Trace文件中出现Corrupt block dba: 0x160c5958 . found。
分析对象失败。
后台进程,如DBWR,LGWR出现长时间异常等待,如“LGWR wait for redo copy”。
四.Oracle数据块损坏恢复总结可以用DBV 命令来检测是否有坏块:在恢复前使用DBV命令检查数据文件是否存在坏块dbv file=d:\oracle\oradata\mydb\RONL Y.DBF blocksize=8192查看数据坏块所在数据文件号及块号可以对表进行一次全表扫描,如:select count(*) from tablename;关于DBV 命令的具体使用,请参考blog:/tianlesoftware/archive/2009/12/16/5015164.aspx4.1 没有备份的情况下:4.1.1、使用exp/imp恢复在这种情况下肯定会造成数据的丢失,在这种情况下应采取将数据导出然后重建表再进行导入的方法,来尽量恢复损坏数据块中的数据,但是在有坏块的情况下是不允许导出的,如下命令:Exp test/test file=t.dmp tables=t;导出命令在执行中会报ORA-01578错误,在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏,如:ORA—01578:ORACLE 数据块损坏(文件号4,块号35)针对以上的提示首先查询那些对象被损坏:Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 between block_id and block_id+blocks-1;如果被损坏的块是索引,通常可以通过索引重建来解决,如果损坏的是数据(segment_type 为table),那么通过设置如下内部事件使得Exp操作跳过坏块。
Alter session set events=’10231 trace name context forever,level 10’;然后重新执行导出命令,导出相关的表,然后执行Drop Table命令删除相关表,之后重建表最后导入数据。
4.1.2、使用DBMS_REPAIR恢复用DBMS_REPAIR当然也会丢失数据。
这里不做详细的介绍,有兴趣的可以查看oracle的在线文档4.2 使用Rman进行恢复:首先要存在Rman的最新备份集,然后执行如下命令:RMAN>backup validate datafile 4;检查4号数据文件是否存在坏块执行查询:select * from v$database_block_corruption where file#=4;如果4号文件存在坏块的话,那么将在结果集中有所显示,会显示损坏的块号,根据显示结果执行如下命令进行恢复:RMAN>blockrecover datafile 4 block 35 from backupset;该命令执行后即可恢复坏块,并且不会造成数据丢失,但是要求数据库必须要运行在归档模式下,否则RMAN无法发挥作用,而且通过RMAN做过最新的数据库备份4.3 使用bbed恢复使用bbed恢复时必须有数据文件的拷贝。
bbed就是英文block browse edit的缩写,用来直接查看和修改数据文件数据的一个工具。
BBED在windows 8i中在$ORACLE_HOME/bin下可以找到,9i中似乎未随软件发布,故在windows没有这个工具,linux下需要编译:然后把$ORACLE_HOME/rdbms/lib加到环境变量的PATH里面,就可以直接在命令中bbed 了。
BBED的缺省口令为blockedit,For Oracle Internal Use only 请谨慎使用Oracle不做技术支持。
BBED具体的使用,参考blog:/tianlesoftware/archive/2009/12/14/5006580.aspx五.如何查找坏块所含的数据表名称和数据的rowid关于Rowid 的相关知识参看blog:/tianlesoftware/archive/2009/12/16/5020718.aspx5.1. 首先肯定知道那个数据文件坏了,查出该文件的file_id,relative_fno,tablespace_name利用dba_data_files可以查询file_id(整个数据库唯一序号),RELATIVE_FNO(相对一个表空间内的序号)5.2. 找到坏块的ID(可以运行dbverify实现),假设找到的坏块ID为1234。
5.3.运行下面的查询,根据,坏块的file_id,block id查找该块对应的owner,segment_type, segment_name等信息select owner,file_id,segment_name, segment_type, block_id, blocksfrom dba_extentswhere file_id=13 and block_id<=1234 and (block_id + blocks- 1) >= 1234;5.4. 根据坏块的file_id,owner,segment_name,block_id,如果是数据表的话,用下面的查询来得到对应坏块的rowid假设owner : DA VEsegment_name: BLfile_id : 13block_id : 162运行下面的查询来获得该块所含的rowid(如果没有索引,可能就不能用下面的方式了):select /*+ index(DA VE, i_test) */ rowidfrom DA VE.BLwhere dbms_rowid.rowid_to_absolute_fno(rowid,'DA VE','BL')=13and dbms_rowid.rowid_block_number(rowid)=162;六,如何模拟坏块DBA 的基本知识,制造坏块的方法很多的,可以用ultraedit,也可以用dd命令,同时也呆以用orapatch工具6.1 orapatch 工具:$orapatch open tools001.dbf writepatch>set hex --要用十六进制patch>display 177 --orapatch以512字节为工作模式,假定想破坏第11个block即为:8k/512*11+1(file header)patch>find 00400003 --选一个要编辑的点patch>modify 00400002 --破坏patch>exit6.2 用编辑器打开datafile 以8192 字节为一大小(db 的block是8192)下面是一个block 的开始的20个字节和结尾的 4 个字节06 02 00 00 08 00 c0 02 6c 43 0d 00 00 00 01 0200 00 00 00 -- block head06 02 6c 43 -- block tail 这里有scn(6c 43) 的情况和block (06)的类型(01) 和head 的seq: 0x01 对应,只要改block尾部的4个字节中的或block开始的对应字节任何一个就一定会有ora-1578,但如果数据库有ora-1578的error不一定是这样引起的btw :UE不是很好用winhex吧不错喔6.3 BBED 工具BBED具体的使用,参考blog:/tianlesoftware/archive/2009/12/14/5006580.aspx七.如何利用dbms_repair来标记和跳过坏块但是当数据量很大,或7*24的系统时,我们使用dbms_repair来处理。