下载文档原格式
使用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数据库表损坏解决办法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 数据库故障，并提供相应的解决方案，帮助读者更好地应对数据库故障。
一、数据库连接问题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 坏块跳过参数Oracle是一种常用的关系型数据库管理系统，它在数据存储和管理方面具有很高的可靠性和稳定性。
然而，由于各种原因，数据库中的坏块（Bad Block）问题时常出现。
坏块是指数据库在磁盘上存储数据时，出现了物理损坏或逻辑错误，导致数据无法正常读取或写入的情况。
为了解决坏块问题，Oracle提供了一个坏块跳过参数（SKIP_CORRUPT_BLOCKS），可以在数据库运行时忽略坏块，使数据库能够正常运行。
坏块跳过参数可以在数据库实例级别或表空间级别进行设置，以便对整个数据库或特定表空间中的坏块进行跳过处理。
在使用坏块跳过参数之前，我们首先需要确定数据库中存在坏块的情况。
Oracle提供了一些工具和方法来检测和诊断坏块问题。
其中，可以使用RMAN工具进行坏块检测。
RMAN（Recovery Manager）是Oracle提供的一个强大的备份和恢复工具，它可以帮助我们检测和修复数据库中的坏块。
在检测到坏块后，我们可以使用坏块跳过参数来处理这些坏块。
在数据库实例级别设置坏块跳过参数时，可以在初始化参数文件中添加以下参数：```sqlDB_BLOCK_CHECKING = FALSEDB_BLOCK_CHECKSUM = FALSE```这些参数的设置将允许数据库实例忽略坏块，并继续运行。
但是需要注意的是，这种方式只是暂时性的解决方案，它并不能修复坏块，只能使数据库能够继续运行。
另一种方式是在表空间级别设置坏块跳过参数。
可以使用以下语句在表空间中设置坏块跳过参数：```sqlALTER TABLESPACE tablespace_name SKIP_CORRUPT_BLOCKS; ```这将使数据库在读取或写入数据时跳过坏块，并继续进行后续的操作。
但同样需要注意的是，这种方式也只是临时性的解决方案，建议在解决坏块问题后尽快修复坏块。
除了设置坏块跳过参数外，我们还可以通过其他方式来处理坏块问题。
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坏块(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--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 数据库故障解决方案，以匡助管理员快速解决问题并恢复数据库的正常运行。
二、故障解决方案1. 数据损坏数据库数据损坏可能导致数据丢失或者无法访问。
以下是一些常见的数据损坏问题及解决方案：- 数据块损坏：使用RMAN 工具进行数据块检查，并使用备份数据进行恢复。
- 表空间损坏：使用RMAN 工具进行表空间检查，并使用备份数据进行恢复。
- 表或者索引损坏：使用 DBMS_REPAIR 工具进行修复，或者从备份中恢复受损的对象。
2. 性能下降数据库性能下降可能导致用户体验差和系统响应延迟。
以下是一些常见的性能下降问题及解决方案：- 确保数据库服务器具有足够的硬件资源，如 CPU、内存和磁盘空间。
- 优化 SQL 查询语句，使用索引、避免全表扫描等。
- 定期采集和分析数据库性能指标，如等待事件、锁定和死锁等，以找出性能瓶颈并采取相应措施。
3. 连接问题连接问题可能导致用户无法连接到数据库或者连接超时。
以下是一些常见的连接问题及解决方案：- 检查数据库监听器是否运行，并确保监听器配置正确。
- 检查网络连接是否正常，如网络配置、防火墙设置等。
- 检查数据库实例是否正常启动，并检查数据库服务是否处于运行状态。
4. 容灾和备份恢复容灾和备份恢复是数据库管理的重要方面，以确保数据的可靠性和可恢复性。
以下是一些常见的容灾和备份恢复问题及解决方案：- 使用 Oracle Data Guard 实现数据库的冗余和自动故障转移。
- 定期进行数据库备份，并测试备份的可恢复性。
- 在灾难发生时，使用备份进行数据库恢复，并确保恢复过程的可靠性和完整性。
5. 安全性问题数据库安全性问题可能导致数据泄露、未授权访问等风险。
