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 异常关机,掉电,终止服务异常关机,掉电,终止服务使进程异常终止,而破坏数据块的完整性,导致坏块产生。
注:这也是为什么突然断电会导致数据库无法启动由上可见,坏块的形成原因复杂。
当出现坏块时,为了找到确切的原因,需要大量的分析时间和排查操作,甚至需要多次重现才能找出根本原因。
但当故障发生在生产系统上,我们为了减少停机时间,会尽快实施应急权变措施以保证系统的可用性,这样就破坏了故障现场,对根本原因的分析因而也更加困难了。
Oracle--DBV命令行工具用法详解及坏块修复

Oracle--DBV命令⾏⼯具⽤法详解及坏块修复⼀,介绍DBV(DBVERIFY)是提供的⼀个命令⾏⼯具,它可以对数据⽂件物理和逻辑两种⼀致性检查。
但是这个⼯具不会检查索引记录和数据记录的匹配关系,这种检查必须使⽤analyze validate structure命令。
这个⼯具有如下特点:以只读的⽅式打开数据⽂件,在检查过程中不会修改数据⽂件的内容。
可以在线检查数据⽂件,⽽不需要关闭数据库。
不能检查控制⽂件和⽇志⽂件,只能检查数据⽂件。
这个⼯具可以检查ASM⽂件,但数据库必须Open状态,并且需要通过USERID指定⽤户,⽐如:dbvfile=+DG1/ORCL/datafile/system01.dbf userid=system/sys在许多UNIX平台下,DBV要求数据⽂件有扩展名,如果没有可以通过建⽴链接的⽅法,然后对链接的⽅法,然后对链接⽂件进⾏操作,⽐如:ls -n /dev/rdsk/mydevice /tmp/mydevice.dbf某些平台,DBV⼯具不能检查超过2GB的⽂件,如果碰到DBV-100错误,请先检查⽂件⼤⼩,MOS Bug 710888对这个问题有描述。
DBV只会检查数据块的正确性,但不会关系数据块是否属于哪个对象。
对于祼设备建议指定END参数,避免超出数据⽂件范围。
⽐如:dbv FILE=/dev/rdsk/r1.dbf END=<last_block_number>。
可以在v$datafile视图中⽤bytes字段除以块⼤⼩来获得END值。
参数含义缺省值FILE要检查的数据⽂件名没有缺省值START检查起始数据块号数据⽂件的第⼀个数据块END检查的最后⼀个数据块号数据⽂件的最后⼀个数据块BLOCKSIZE数据块⼤⼩,这个值要和数据库的DB_BLOCK_SIZE参数值⼀缺省值8192致LOGFILE检查结果⽇志⽂件没有缺省值FEEDBAK显⽰进度0PARFILE参数⽂件名没有缺省值USERID⽤户名、密码没有缺省值SEGMENT_ID段ID,参数格式<tsn.segfile.segblock>没有缺省值⼆,简单使⽤[oracle@oracle01 oracle01]$ dbv file=test01.dbf--最好是绝对路径,这⾥是进⼊到对应⽬录下,所以⽤相对路径DBVERIFY: Release 11.2.0.4.0- Production on Mon May 1315:21:422019Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.DBVERIFY - Verification starting : FILE=/u01/app/oracle/oradata/oracle01/test01.dbfDBVERIFY - Verification completeTotal Pages Examined : 1280 --( 检查总页数)Total Pages Processed (Data) : 5 --(处理的总页数(数据))Total Pages Failing (Data) : 0 --(总页数失败(数据))Total Pages Processed (Index): 0 --(处理的总页数(索引))Total Pages Failing (Index): 0 --(总页⾯失败(索引))Total Pages Processed (Other): 136 --(处理的总页数(其他))Total Pages Processed (Seg) : 0 --(处理的总页数(Seg))Total Pages Failing (Seg) : 0 --(总页数失败(Seg)Total Pages Empty : 1139 --(总页数空)Total Pages Marked Corrupt : 0 --(总页数标记为损坏)Total Pages Influx : 0 --(总页⾯数量)Total Pages Encrypted : 0 --(加密总页数)Highest block SCN : 11638862 (0.11638862) --(最⾼块SCN) 这个⼯具报告使⽤的是page作为单位,含义和data block相同。
ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案一、引言ORACLE 数据库是一款广泛应用于企业级应用系统的关系数据库管理系统。
然而,在数据库运行过程中,可能会浮现各种故障,如数据损坏、性能下降、连接问题等。
本文将提供一些常见的 ORACLE 数据库故障解决方案,以匡助管理员快速解决问题并恢复数据库的正常运行。
二、故障解决方案1. 数据损坏数据库数据损坏可能导致数据丢失或者无法访问。
以下是一些常见的数据损坏问题及解决方案:- 数据块损坏:使用RMAN 工具进行数据块检查,并使用备份数据进行恢复。
- 表空间损坏:使用RMAN 工具进行表空间检查,并使用备份数据进行恢复。
- 表或者索引损坏:使用 DBMS_REPAIR 工具进行修复,或者从备份中恢复受损的对象。
2. 性能下降数据库性能下降可能导致用户体验差和系统响应延迟。
以下是一些常见的性能下降问题及解决方案:- 确保数据库服务器具有足够的硬件资源,如 CPU、内存和磁盘空间。
- 优化 SQL 查询语句,使用索引、避免全表扫描等。
- 定期采集和分析数据库性能指标,如等待事件、锁定和死锁等,以找出性能瓶颈并采取相应措施。
3. 连接问题连接问题可能导致用户无法连接到数据库或者连接超时。
以下是一些常见的连接问题及解决方案:- 检查数据库监听器是否运行,并确保监听器配置正确。
- 检查网络连接是否正常,如网络配置、防火墙设置等。
- 检查数据库实例是否正常启动,并检查数据库服务是否处于运行状态。
4. 容灾和备份恢复容灾和备份恢复是数据库管理的重要方面,以确保数据的可靠性和可恢复性。
以下是一些常见的容灾和备份恢复问题及解决方案:- 使用 Oracle Data Guard 实现数据库的冗余和自动故障转移。
- 定期进行数据库备份,并测试备份的可恢复性。
- 在灾难发生时,使用备份进行数据库恢复,并确保恢复过程的可靠性和完整性。
5. 安全性问题数据库安全性问题可能导致数据泄露、未授权访问等风险。
Oracle数据库块损坏的恢复——浅析BBED在数据库恢复中的应用

Cmue DSfwr n p letos op tr C o t a e a d A p ia in
2 1 年第 2 期 01 l
从 h l l ep a l的输 出中 ,我们 可 以看到 全 部的 b e b d的语法 ,
最 常用 的有 以下几 个 :
A C8 A A^ AA 从 fA E AA P从
bl k di oc e t。
正 式使 用 B E B D之前 ,需要先 创建 两个 配 置文 件 , 文件 内容如
一
R P I 手段 进行 恢复 。本文将 着 重介 绍 OA L EAR等 R CE的 BE B D工具在 bo k损坏 情况 下的使 用 。 lc
二 、B E BD介绍 B E (l c rw rn d tr To )是 OA L B D B o kB o ea dE io o 1 R CE的一款 内
[rc e lnx i] ct f lls .x o a 1 @ i u 1 b n ¥ a i e i t t t
1 / rd t/r 1s seO .b 34 78 0 o aa ao c/ y tm 1df 15 20 2 / rd t/r lud ts 1d f 14 56 0 o aa ao c/ no bO .b 08 7 0
[rc el nx ] b dp r ie/ r ceb e .a o a l@ iu l ¥b e af 1= oa l/ bd pr
P so as w rd: B ED s o B > hw FI # LE
B OC # L K
1
I
计算 b ok ce ku ( lc 的 hc sm 校验和 )m df 之后 bo k ,o iy l c
ORACLE8I数据库中数据坏块的解决方法

O AC E R L 数据 库 在 运 行 过 程 中 , 会 出现 数 据 块 损 坏 的 情 常
况 。当坏 块 出现 时 , 只能 通 过 恢 复 之 前 的备 份 数 据 来 挽 回丢 失 的 数据 。但 是 , 果 系 统 用 户 在 出现 错 误 时 没 有 及 时 通 知D A 如 B
Ab t a t T i r ce d s u s s h w t a d e o e o r l c o r p in n a r c e d t l n e c i e o sr c h s at l ic se o o h n l n r mo e bo k c r t s o n O a l a a f e a d d s r s s me i u o i b
ACL E
—
这 是 目前 最 简单 的方 法 。
( ) 用 R WI n cn 方 法 找 出 坏 块 的 边 界 , 后 2使 O D r g sa 的 a 然 提 出数 据 。
SD . a I >o 文件 , 入 以下 语 句 : v n = 1 2 1t c a e r 加 “ e t ” 0 3 a en m e r
事 件 12 1 以在 ssi 级 或 is n e 设 置 。 03 可 es n o nt c级 a 如果 只是 要 执 行 一 个 C eta l a eet 句 ,在 ssi 级设 置 事 件 就 可 ra tb sslc e 语 es n o
以了 : 果要使 如 E p r 份 表 数 据 , 好 在is n e 设 置 事 xo 备 t 最 nt c 级 a
1 2 1T 0 3 RAC E NAME CON EX ORE R,L VEL 1 ” 然 T TF VE E 0: .
Oracle DBMS_REPAIR包修复损坏数据块

ACTION => sys.dbms_repair.create_action,
ቤተ መጻሕፍቲ ባይዱABLESPACE => 'NMCPMTS');
END;
PL/SQL 过程已成功完成。
BEGIN
DBMS_REPAIR包不但可以检测出坏块,根据表被索引的情况,还可以用来在一定程度上恢复坏块中的数据。
需要注意,DBMS_REPAIR包没有进行授权,默认情况下,只有sys用户可以执行。
下面通过一个完整的例子来说明DBMS_REPAIR包的使用。
第一步:构造测试环境
首先建立一个测试用表空间,由于需要用UltraEdit打开数据文件修改部分内容来模拟错误,因此数据文件要建的小一些。
db_block_size integer 16384
BLOCK的大小是16k。
SQL> SELECT TO_CHAR(6*16384, 'XXXXXX') FROM DUAL;
TO_CHAR
-------
18000
SQL> SELECT TO_CHAR(7*16384, 'XXXXXX') FROM DUAL;
TO_CHAR
-------
1C000
用UltraEdit打开数据文件,将文件定位18000h处(以二进制方式打开,如果没有用二进制打开,可以使用CTRL+H快捷键切换)。根据上面的计算,可以得出,我们要找到记录在18000h和1C000h之间。
Number类型123在数据库存放方式为03C20218,03表示占有三位,C2表示最高位是百位,02表示最高位上是1,18表示低位上是23。(如果对Oracle的基本数据类型的存储格式感兴趣,可以参考我在论坛上的帖子)
用ORACLE8i修复数据库坏块的三种方法

在进行SUN CLUSTER双机切换、意外断电或其它情况下,有时会发生共享盘MOUNT不上的情况,需要使用FSCK对共享盘进行修复。
修复完成后,在数据库启动过程中,却又出现“数据块损坏,无法启动数据库”的现象,此时,可以根据不同的数据块损坏类型,检测并修复错误。
在此介绍三种使用Oracle8i修复损坏数据块的方法。
一、数据块损坏,错误代码为ORA-01578ORA-1115 I/O ERROR READING BLOCK通常后跟ORA-737X错误与操作系统错误(如UNIX中的错误号5)产生原因:1.硬件问题(磁盘控制器问题或磁盘问题)2.物理级的数据块损坏(通常由前一原因造成)3.处理巨型文件时,后跟错误代码ORA-7371确定故障原因与恢复的方法:1.查看alert.log文件中其它ORA-1115错误的发生情况:1) 如果指向不同磁盘的文件,则是磁盘控制器的问题,查看V$DATAFILE,有哪些文件位于该控制器下,转到第二步。
2) 如果指向相同磁盘的不同文件,则是磁盘的问题,转到第二步。
3) 如果指向同一个文件,执行以下语句查找文件名:SELECT SEGMENT_NAME,SEGMENT_TYPE FROM DBA_EXTENTSWHERE FILE_ID=<文件号> AND <块号> BETWEEN BLOCK_IDAND BLOCK_ID+BLOCKS-1;其中,文件号与块号是ORA-1115中指出的,如果该查询持续指向某表或索引,则重建它们即可。
2.如果文件是SYSTEM表空间,或处于NOARCHIVELOG模式,关闭数据库,转到第四步。
3.如果数据库处于ARCHIVELOG模式,仍应关闭数据库,如果不能关闭数据库,则将相应的数据文件脱机:ALTER DATABASE DATAFILE '文件名' OFFLINE;4.试着将数据文件拷贝到别的磁盘。
总结了10种_Oracle_文件损坏及恢复的过程

总结了10种_Oracle_文件损坏及恢复的过程Oracle数据库是一个关系数据库管理系统(RDBMS),用于存储和管理大量结构化数据。
然而,由于各种原因,Oracle数据库文件可能会损坏,这可能导致数据库无法正常工作。
为了解决这个问题,需要进行文件的恢复过程。
下面总结了10种Oracle文件损坏及恢复的常见过程:1.数据文件丢失:如果数据文件丢失,可以从最近的备份还原数据文件,并进行恢复。
2. 数据文件坏块:在Oracle数据库中,可以使用DBVERIFY工具来检查数据文件的坏块。
如果坏块小部分,可以使用RMAN进行恢复。
如果坏块较多,可能需要考虑重新创建数据文件。
3.日志文件丢失:如果日志文件丢失,可以使用备份中的归档日志文件进行恢复。
如果没有备份,可以使用增量备份或物理备份进行恢复。
4.日志文件坏块:使用DBVERIFY工具可以检查日志文件的坏块。
如果发现坏块,可以尝试使用RMAN进行恢复,或者由管理员手动修复坏块。
5.控制文件丢失:如果控制文件丢失,可以从备份中还原控制文件,并使用RECOVER命令进行数据库恢复。
6.控制文件坏块:使用DBVERIFY工具检查控制文件的坏块。
如果找到坏块,可以使用备份恢复控制文件,或者手动修复坏块。
7.数据库文件或表空间重命名:如果数据库文件或表空间被重命名,可以使用ALTERDATABASERENAME命令更改文件或表空间的名称。
8. 恶意软件或数据损坏:如果Oracle数据库中的数据被恶意软件感染或损坏,必须进行杀毒和修复操作。
首先,应使用杀毒软件对系统进行全面扫描,以确保杀死所有恶意软件。
然后,可以使用RMAN进行数据恢复。
9.操作错误:有时,由于误操作或错误的命令,数据库文件可能会被损坏。
在这种情况下,可以从备份中还原损坏的文件,并执行相关的恢复操作。
10. 数据库崩溃:如果Oracle数据库发生崩溃,可能需要使用RMAN 进行恢复。
首先,必须使用备份进行数据库重建,然后使用RMAN进行恢复。
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数据库是甲骨文公司的一款关系数据库管理系统,目前在数据库市场上仍占有主要份额,很多企业在使用Oracle数据库的过程中,经常会遇到数据库坏块的问题。
很多用户就会疑问了,Oracle数据库坏块问题具体指什么了?我们又该如何解决数据库坏块问题呢?
很多不了解Oracle数据库的用户都不清楚数据库具体的结构,从而对其出现的故障也无从下手。
其实,数据库的数据块有固定的格式和结构,分三层:cache layer、transaction layer、data layer。
在我们对数据块进行读取写入操作的时候,数据库会对要读写的数据块做一致性的检查,其中包括:数据块的类型、数据块的地址信息、数据块的SCN号以及数据块的头部和尾部。
如果发现其中有不一致的信息,那数据库就会标记这个数据块为坏块了。
当数据库出现坏块情况时,数据库的告警日志文件里面会存在一些报错信息,用户可以根据这些信息判断数据库是否存在坏块问题。
当Oracle数据库出现坏块问题后,可能会对数据字典表、回滚段表、临时段、用户数据表和索引等内容造成一定的影响,所以当Oracle数据库出现坏块问题后,用户需要立即采取相应措施解决坏块问题。
坏道处理的方法比较复杂,针对不同原因造成的坏道问题,处理的方法也各有不同,所以对于用户来说,解决Oracle数据库坏道问题是一个难点,一旦处理不当,可能会对Oracle 数据库造成二次破坏,造成用户更大的损失。
所以当用户出现Oracle数据库坏块问题后,要立刻咨询专业的数据恢复机构,让专业的数据库恢复专家帮助修复数据库,解决数据丢失的烦恼。
Oracle坏块故障葵花宝典

Oracle坏块故障葵花宝典最近处理了两次典型的ora-01578,ora-01115,ora-01110故障,一次是平湖索引块坏,一次是黄山数据文件坏、blob 数据块坏。
平湖的警告日志文件中有以下信息:ORA-12020: error on auto execute of job 21ORA-01578: ORACLE data block corrupted (file # 10, block # 2558610)ORA-01110: data file 10: 'D:\ORACLE\ORADATA\BS\USERS04.DBF'ORA-12020: error on auto execute of job 1ORA-01578: ORACLE data block corrupted (file # 16, block # 2624066)ORA-01110: data file 16: 'D:\ORACLE\ORADATA\BS\USERS10.DBF'应用软件能够正常使用,偶然会报错ora-01578。
排错过程登录数据库检查:select count(*) from ep_table t where ptime<trunc(sysdate)-30 and alarmtype=0784163select count(*) from ep_table t4281062看来全表扫描正常select from ep_table t where ptime<trunc(sysdate)-31 and ptime>trunc(sysdate)-33 and alarmtype=0 and rownum<10001索引扫描报错了,推断为索引上有坏块!连续查:select owner,file_id,segment_name, segment_type, block_id, blocksfrom dba_extentswhere file_id=16 and block_id<=2624066 and (block_id + blocks- 1) >= 2624066;运气真好重建相关索引后数据库就复原了。
- 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来处理。