oracle数据库修复（Oracle数据库突然断电数据库无法启动怎么修复）
本文目录
- Oracle数据库突然断电数据库无法启动怎么修复
- 误删除Oracle数据库恢复，怎么办
- 如何从完好的oracle数据文件恢复oracle数据库要实际能操作的，我只有dbf文件 20个g
- oracle数据库恢复，提示ORA-01110: 数据文件 35: ’’
- oracle数据库中的表被truncate掉了，怎么恢复
- 请问oracle数据库恢复怎么办啊 求解
- Oracle数据库的备份及恢复策略研究
- oracle数据库恢复 要怎么做呢
- 怎么修复数据库 修复数据库坏块方法
- Oracle数据库打不开 该怎么办我们公司的oracle数据库坏了 打不开了，该如何处理
Oracle数据库突然断电数据库无法启动怎么修复
断电后可能会出现以下情况：
1 数据文件，控制文件等损坏
2 出现坏块
3 Oracle BUG
4 启动服务器后磁盘没有自动挂载
根据不同情况，解决方式也不同，有备份可以还原或修复文件和坏块，或通过隐含参数跳过一致性检查启动数据库；
误删除Oracle数据库恢复，怎么办
你可以试试PRM for Oracle。
ParnassusData Recovery Manager(以下简耐弊称PRM)是企业级ORACLE数据灾难恢复软件，可直接从Oracle9i,10g,11g,12c的数据库数据文件(datafile)中抽取还原数据表上的数据，而不昌迟族需要通过ORACLE数据库实例上执行**L来拯救数据。ParnassusDataRecovery Manager是一款基于J**A开发的绿色软件，无需安装，下载解压后便可直接使用。
恢复场景1 误Truncate表的常规恢复
D公司的业务维护人员由于误将产品数据库当做测试环境库导致错误地TRUNCATE了一张表上的所有数据，DBA尝试恢复但是发觉最近的备份不可旦薯用，导致无法从备份中恢复出该数据表上的记录。 此时DBA决定采用PRM来恢复已经被TRUNCATE掉的数据。
由于该环境中 所有数据库文件均是可用且健康的，用户仅需要 字典模式下加载SYSTEM表空间的数据文件以及被TRUNCATED表的数据文件即可，例如：
create table ParnassusData.torderdetail_his1 tablespace users as
select * from parnassusdata.torderdetail_his;
**L》 desc ParnassusData.TORDERDETAIL_HIS
Name Null? Type
----------------------- -------- --------------
SEQ_ID NOT NULL NUMBER(10)
SI_STATUS NUMBER(38)
D_CREATEDATE CHAR(20)
D_UPDATEDATE CHAR(20)
B_ISDELETE CHAR(1)
N_SHOPID NUMBER(10)
N_ORDERID NUMBER(10)
C_ORDERCODE CHAR(20)
N_MEMBERID NUMBER(10)
N_SKUID NUMBER(10)
C_PROMOTION NVARCHAR2(5)
N_AMOUNT NUMBER(7,2)
N_UNITPRICE NUMBER(7,2)
N_UNITSELLINGPRICE NUMBER(7,2)
N_QTY NUMBER(7,2)
N_QTYFREE NUMBER(7,2)
N_POINT**ET NUMBER(7,2)
N_OPERATOR NUMBER(10)
C_TIMESTAMP VARCHAR2(20)
H_SEQID NUMBER(10)
N_RETQTY NUMBER(7,2)
N_QTYPOS NUMBER(7,2)
select count(*) from ParnassusData.TORDERDETAIL_HIS;
COUNT(*)
----------
984359
select bytes/1024/1024 from dba_segments where segment_name=’TORDERDETAIL_HIS’ and owner=’PARNASSUSDATA’;
BYTES/1024/1024
---------------
189.71875
**L》 truncate table ParnassusData.TORDERDETAIL_HIS;
Table truncated.
**L》 select count(*) from ParnassusData.TORDERDETAIL_HIS;
COUNT(*)
----------
0
启动PRM ，并选择 Tools =》 Recovery Wizard
点击Next
在此TRUNCATE场景中并未采用ASM存储，所以仅需要选择 《Dictionary Mode》字典模式即可：
如何从完好的oracle数据文件恢复oracle数据库要实际能操作的，我只有dbf文件 20个g
这可能是部分刚接手的运维人员 或者代维人员所要遇到的问题， 一个老的数据库只剩下DBF文件了，要如何恢复其中的数据？
其实这个问题 分成好多种情况，请自行对号入座：
1）数据库所有的DBF文件都在，没有缺失，也没有损坏
这个情况是最简单的 自己建一个参数文件INIT.ORA，并基于这些DBF文件去创建控制文件，然后尝试打开数据库即可。如果说数据文件都是干净的CLEAN的，那么直接可以打开。如果数据文件是DIRTY的，这里由于没有REDO LOG了，所以需要以隐藏参数等方式打开数据库。
2) 数据库DBF有少量缺失，缺失主要是非SYSTEM01.DBF的数据文件，没有损坏
这种情况在 1)的基础上将缺失的数据文件OFFLINE DROP掉就好了，因为对应的数据文件都没了，那么丢了对应数据文件上的数据也很正常
3) 数据库DBF有少量缺失，缺失主要是非SYSTEM01.DBF的数据文件，非SYSTEM01.dbf的数据文件有少量损坏
这种情况在 2)的基础上打开数据库问题并不大，但打开数据库后 由于其他表空间数据文件上有少量损坏，所以具体访问用户数据时可能出现ORA-1578、ORA-8103、ORA-1410、ORA-00600等错误，还是比较容易克服的
4) 数据库DBF有少量缺失，缺失主要是非SYSTEM01.DBF的数据文件，SYTEM01.DBF有损坏
这种情况下打开数据库就不容易了，可能需要用到BBED技术去修改SYSTEM01.DBF，以便才能打开数据库
5) 只有部分DBF，其中还缺失了SYSTEM01.DBF
这种情况不要指望能打开数据库，只能使用PRM-DUL之类的软件 来直接抽取数据
以上情况1）~4) 只要SYSTEM01.DBF还在或者损坏的不是太严重，那么都可以由专业技术人员去打开数据库后导出数据，但是在情况5）下只能使用DUL类工具去抽取数据了。
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
oracle数据库恢复，提示ORA-01110: 数据文件 35: ’’
回复有问题，你是dmp恢复的吧，这样的话要求数据库名字，数据库文件存放的路径都要和原来的一样。你要恢复这个数据库，先建立数据库名字，和数据库表空间，表空间位置，错误里已经提示出来了。然后就是数据库导入命令指定建立的这个数据库。
oracle数据库中的表被truncate掉了，怎么恢复
如果是重要的表，且不允许丢任何数据，则先根据 truncate 的大概时间点，（可从 dba_objects 中的 last_ddl_time 做为一个参考。） 然后，使用 logminer 从归档日志（如果是刚 truncate 不久，则为从相应的在线日志）中找到 truncate 命令执行的 scn 值。 在另一个环境中，从物理备份，恢复 system表空间，undo 表空间，含被 truncate 的表空间的数据文件，并 recover 至前面查出的 truncate 执行时的 scn 值 -1 的 scn 值。这样，则恰好修复至执行 truncate 动作前一点。接着，从恢复出的环境中 export 表, 再 import 入生产库即可。 如果是不重要的表，则从历史备份中导出，导入即可。
请问oracle数据库恢复怎么办啊 求解
racle数据库恢复,主要包括
(1)系统崩溃只剩下数据文件的情况下的恢复,甚至没有system表空间而只有数据表空间的情况下的恢复.只要提供数据文件就可恢复.
(2) undo system 表空间损坏数据恢复 .
(3) 非归档或者归档模式下误 delete 数据的恢复、误删除表空间的恢复、 drop truncate update 表的恢复 .
(4) 数据库中有大量CLOB BLOB对象数据恢复等情况以及各种ora-错误的修复.
Oracle数据库的备份及恢复策略研究
多工联机重作日志文件
每个数据库实例都有其自己的联机重作日志组 在操作数据库时 Oracle首先将数据库的全部改变保存在重作日志缓冲区中 随后日志记录器进程（LGWR）将数据从系统共用区**A（System Global Area）的重作日志缓冲区写**机重作日志文件 在磁盘崩溃或实例失败时 可以通过与之相关的联机重作日志来保护数据库 将损失降至最低 但Oracle在默认的方式下只创建一组重作日志文件（每一组只有一个项目文件） 为了减少丢失这些重要的重作日志文件的危险 因此需要对其进行镜像拷贝
在Oracle级多工联机重作日志文件 即增加多个文件到每个组以便镜像数据 这样I/O故障或写丢失只损坏一个拷贝 从而保证了LGWR后台进程至少能够向一个成员写入信息 数据库仍然可以继续运行 同时应保证日志组的成员不应驻存在同一物理设备上 因为这将削弱多重日志文件的作用
镜像拷贝控制文件
控制文件描述通用的数据库结构 它存储了大量数据库状态信息 包括物理结构和联机重作日志文件在当时的名称 位置 状态 控制文件在数据库启动时被Oracle实例读取 保持打开并随着操作而文件内容更新 直到实例关闭为止 在它打开的过程中能够同步需要恢复的信息 包括检查点信息 因此若损坏或丢失了控制文件 Oracle将不能继续工作 因此应在系统中保持控制文件的多个拷贝 且这些拷贝应置于安装于不同磁盘***下的不同磁盘设备中
由于Oracle没有提供对控制文件多工的完整支持 因此应在对控制文件使用操作系统或硬件镜像 即在修改初始化文件的control_files参数后重新启动数据库前 应将控制文件复制到定义的新位置 否则数据库启动时将会出错
激活归档进程
当数据库运行于NOARCHIVELOG模式下时 只能在完全关闭数据库后进行数据库的一致备份 并且同时禁用了联机重作日志的存档 这样在Oracle实例失败时只能将数据库修复到最近的完整数据库备份时的那一点上 不能在失效点处对实例进行恢复 而在ARCHIVELOG模式下 数据库不仅可以进行一致备份 还可以在数据库打开的情况下进行联机备份 通过数据库的备份和联机与存档的重作日志文件 用户可以恢复所有已提交的事务 并允许将数据库恢复到指定的时间 SCN或日志系列号处 增大了恢复的灵活性 减少了故障时的数据丢失 因此数据库应运行于ARCHIVELOG模式
在ARCHIVELOG模式下为了防止文件损坏和介质故障 应把日志归档到不同的磁盘上 这可以通过在初始化文件中为归档重作日志指定多个目标实现
数据库实施较大改变时备份
因为控制文件中保存了数据库的模式结构信息 因此在对数据库进行较大改变（包括改变表结构 增加 删除日志文件或数据文件等）时应立即备份控制文件及相应的数据文件
使用RESETLOGS选项打开数据库后进行备份
在以RESETLOGS选项打开数据库后 应对整个数据库进行脱机或联机的备份 否则将不能恢复重置日志后的改变
当以RESETLOGS选项打开数据库时 Oracle将抛弃恢复中没有应用的重复信息 并确保永远不再运用 同时还将初始化控制文件中关于联机日志和重作线程的信息 清除联机日志中的内容 因此 RESETLOGS前的归档日志的序列号将与RESETLOGS后的Oracle控制文件的要求值不相符（备份文件中的检查点比控制文件中的检查点旧） 即在恢复中不能应用以前的归档日志文件 从而导致RESETLOGS操作之前的备份在新形体中无用
避免备份联机重作日志文件
由于文中提出了多工联机重作日志文件且数据库运行于ARCHIVELOG模式 ARCH进程能够将联机重作日志归档 因此不必对其进行备份 若用备份的联机重作日志文件重建它 可能会引起日志文件序列号的混乱 从而破坏数据库 得到适得其反的结果
重置联机日志
在进行了不完全恢复或用备份控制文件进行恢复后 应重置联机日志
为了确保数据库的一致性 必须保证在恢复后所有数据文件都恢复到同一个时间点 但不完全恢复可能导致数据文件中具有一个与其它文件不同的检查点 导致数据库的一致性受到破坏 同样 备份的控制文件中保存的SCN和计数器与当前日志文件中的值可能不同 从而也破坏了数据库的一致性 因此应在进行完上述两项操作后重置联机日志
数据库的逻辑备份
以上所述备份都为物理备份 是实际物理数据库文件从一处拷贝到另一处的备份 除此之外还可使用Oracle提供的导出实用程序进行数据库的逻辑备份 Oracle同时还提供了相应的导入实用程序重建逻辑备份中保存的信息
逻辑备份只拷贝数据库中的数据 而不记录数据位置的备份过程 它利用**L语句 从数据库中导出数据到一个存放在合适位置的外部文件中 同时并可检测到数据块的损坏 因此可用其作为物理备份的补充
备份策略考虑到如今大部分信息系统每周的业务是 × 操作 因此采用联机备份 否则可每隔一定时间进行一次脱机备份
应用上述规则 可得出下述典型的备份策略
①镜像拷贝重作日志文件
②镜像拷贝控制文件
③激活归档进程 即以ARCHIVELOG模式操作数据库
④每天进行数据库的部分联机备份（每天进行数据库的完全热备份将无畏地增加数据库的负担且没有必要 同时也增加了数据库恢复时的灵活性）
⑤每隔一周或几周进行一次数据库的逻辑备份
实际项目应用
当数据库中的文件达到一定数量后 DBA可能记不住该备份的文件的名或位置 因此 若能使备份过程自动化可有效地减轻DBA的负担 同时不会遗漏应备份的文件 应用自动批处理文件及脚本文件可实现备份 恢复的自动化 下面简介了在实际项目开发中应用本文所提出的自动备份 恢复策略 通过实际应用 证明了该策略的正确性和可行性
（ ）下述脚本实现联机重作日志的多工
connect 账户名/密码 alter database ktgis add logfile member 日志文件的存储位置 to group 联机日志组号; shutdown immediate startup pfile=初始化文件的存放位置 exclusive mount; 装载数据库且不打开 alter database archivelog; 激活归档进程 alter database open; exit
（ ）下列VB代码自动建立联机备份的批处理文件及相应的脚本文件
Set adoTmp = objConnect Execute( select tablespace_name from sys dba_data_files ) 得到数据库中的表空间名 Dim lnum As Long Dim lnum As Long lNum = FreeFile Open 自动备份批处理文件路径 For Binary As lNum lnum = FreeFile Open onlinebegin sql For Binary As lnum onlinebegin sql为设置表空间进入热备份模式的脚本文件文件名 lnum = FreeFile Open onlineend sql For Binary As lnum onlinebegin sql为结束表空间热备份模式的脚本文件文件名 strTmp = connect 账户名/密码 & Chr( ) & Chr( ) Put lnum strTmp strTmp = shutdown immediate & Chr( ) & Chr( ) Put lnum strTmp strTmp = startup pfile=初始化文件的存放位置exclusive mount; & Chr( ) & Chr( ) Put lnum strTmp strTmp = alter database archivelog; & Chr( ) & Chr( ) Put lnum strTmp strTmp = alter database open; & Chr( ) & Chr( ) Put lnum strTmp strTmp = connect 账户名/密码 & Chr( ) & Chr( ) Put lnum strTmp strTmp = Oracle服务管理器路径 & @ & onlinebegin sql & Chr( ) & Chr( ) 在服务管理器中执行脚本文件onlinebegin sql Put lNum strTmp Do While Not adoTmp EOF Set adoTmp = objConnect Execute( select file_name from sys dba_data_files where tablespace_name= & adoTmp Fields( ) & ) 得到当前表空间所对应的所有数据文件名 通过循环即可得到所有表空间所对应数据文件名 若只备份指定的表空间 可指定表空间名从而得到其对应的物理数据文件 strTmp = alter tablespace & adoTmp Fields( ) & begin backup; & Chr( ) & Chr( ) 将表空间置于热备份模式 Put lnum strTmp strTmp = Oracle的ocopy exe工具全路径 & adoTmp Fields( ) & & 备份文件存放路径 & Chr( ) & Chr( ) Put lNum strTmp strTmp = alter tablespace & adoTmp Fields( ) & end backup; & Chr( ) & Chr( ) 表空间恢复正常模式 Put lnum strTmp adoTmp MoveNext Loop strTmp = Oracle服务管理器路径 & @ & onlineend sql & Chr( ) & Chr( ) 在服务管理器中执行脚本文件onlineend sql Put lNum strTmp strTmp = exit & Chr( ) & Chr( ) 退出服务管理器 Put lnum strTmp strTmp = alter system switch logfile; & Chr( ) & Chr( ) 强制日志转换 使Oracle创建一个归档日志文件 Put lnum strTmp strTmp = exit & Chr( ) & Chr( ) Put lnum strTmp Close Set adoTmp = Nothing Set adoTmp = Nothing
运行得到的自动批处理文件 即可自动进行数据库的联机备份
（ ）在从备份中恢复数据文件后 执行下列脚本将数据库的恢复程序
connect账户名/密码 shutdown abort startup mount pfile=初始化文件的存放位置; 装载数据库 set autorecovery on; 打开自动恢复 recover database; alter database open; 打开数据库
结束语
lishixinzhi/Article/program/Oracle/201311/18527oracle数据库恢复 要怎么做呢
Oracle数据恢复专题
备份恢复是Oracle中永恒的话题， 只要有数据 就有备份恢复的需求。 而在国内对于备份以及备份的可用性往往被企业所忽视。这造成了再数据库恢复上存在着东西方的差异。 更多的老外DBA把经历花在对Oracle内部原理和性能优化的研究上。
oracle data block structure
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
而我们国内 DBA似乎必须要精通一门额外的技术==》 在没有任何备份的情况下 恢复Oracle数据库中数据的技术！ 虽然这在大多数情况下是屠龙之技， 但很多时候却又变成了衡量一个DBA技术水准的标准了，(这样不好.. 不好)。
当然也并不是说 这种无备份下的数据恢复是无技术含金量的，实际上它们很需要对Oracle数据文件、数据块及其数据结构的理解，以及对数据字典构成的了解。
这里我们总结Oracle数据恢复专题的专题，包括一些在无备份情况下的数据恢复：例如PRM-DUL和BBED工具恢复等技术。
【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题
【数据恢复】ORA-600一例
Oracle rman中set newname可能很慢
如何清除Oracle控制文件中的无用记录，例如v$archived_log中的deleted归档日志记录
如何找回被create or replace覆盖的PL/**L对象
Archivelog Completed Before VS UNTIL TIME
ASM丢失disk header导致ORA-15032、ORA-15040、ORA-15042 Diskgroup无法mount
Overcome ORA-600 open database
数据恢复:解决ORA-600一例
清理RMAN Catalog恢复目录
如何rename datafile name中存在乱码的数据文件
11g新特性recover corruption list
解决ORA-01578错误一例
Script:收集介质恢复诊断信息
如何重建SYSAUX表空间上的对象
Oracle数据恢复:解决ORA-00600: ORA-00704: bootstrap process failure错误一例
Script:检查数据库当前是否有备份操作在执行中
数据恢复：模拟2个逻辑坏块
Script:收集Oracle备份恢复信息
Oracle备份恢复:Rman Backup缓慢问题一例
了解rman catalog的兼容性
Oracle内部错误:ORA-00600一例
使用bbed解决ORA-01189错误
Fractured block found during backing up datafile
手动递增SCN号的几种方法：How to increase System Change Number by manual
DBMS_REPAIR example
Oracle的损坏/坏块 主要分以下几种：
ORA-1578
ORA-8103
ORA-1410
ORA-1499
ORA-1578
ORA-81##
ORA-14##
ORA-26040
ORA-600 Errors
Block Corruption
Index Corruption
Row Corruption
UNDO Corruption
Control File
C***istent Read
Dictionary
File/RDBA/BL
怎么修复数据库 修复数据库坏块方法
修复数据库坏块
dbv
你也可以用dbv工具看一下你现在其他的数据文件有没有还有坏块的
dbv file=’yourfilename’
恢复方法：
当Oracle数据库出现坏块时，Oracle会在警告日志文件（alert_SID.log）中记录坏块的信息：
ORA-01578: ORACLE data block corrupted (file # 7, block # )
ORA-01110: data file : ’/oracle1/oradata/V920/oradata/V816/users01.dbf’
其中，＜AFN＞代表坏块所在数据文件的绝对文件号，代表坏块是数据文件上的第几个数据块
出现这种情况时，应该首先检查是否是硬件及操作系统上的故障导致Oracle数据库出现坏块。在排除了数据库以外的原因后，再对发生坏块的数据库对象进行处理。
1．确定发生坏块的数据库对象
SELECT tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id =
AND between block_id AND block_id+blocks-1;
2．决定修复方法
如果发生坏块的对象是一个索引，那么可以直接把索引DROP掉后，再根据表里的记录进行重建；
如果发生坏块的表的记录可以根据其它表的记录生成的话，那么可以直接把这个表DROP掉后重建；
如果有数据库的备份，则恢复数据库的方法来进行修复；
如果表里的记录没有其它办法恢复，那么坏块上的记录就丢失了，只能把表中其它数据坏上的记录取出来，然后对这个表进行重建。
3．用Oracle提供的DBMS_REPAIR包标记出坏块
exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(’’,’’);
4．使用Create table as select命令将表中其它块上的记录保存到另一张表上
create table corrupt_table_bak
as
select * from corrupt_table;
5．用DROP TABLE命令删除有坏块的表
drop table corrupt_table;
6．用alter table rename命令恢复原来的表
alter table corrupt_table_bak
rename to corrupt_table;
7．如果表上存在索引，则要重建表上的索引
PART2
2014.7.22研究恢复数据库坏块：
Oracle调用标准C的系统函数，对数据块进行读写操作，因此，坏块是有可能由以下几种原因产生：
硬件的I/O错误
操作系统的I/O错误或缓冲问题
内存或paging问题
磁盘修复工具
一个数据文件的一部分正在被覆盖
Oracle试图访问一个未被格式化的系统块失败
数据文件部分溢出
Oracle或者操作系统的bug
遇到“ORA-01578:ORACLE data block corrupted”错误
处理方法：1.rman的recover命令可以在数据库保持open状态下只恢复受损的数据块
2.如果没有备份，万不得已之下也可以采用DBMS_REPAIR包的存储过程将受损坏块隔离，同时尽可能地挽救部分数据。
rman backup命令也是检查坏数据块的好工具 一旦读取ORA-19566 即可有问题
此时可用backup validate tablespace user观察详细的信息，可查看到坏块数与跟踪文件
grep‘corrupt’/u01/app/oracle/diag/rdbms/br/br/trace/**.trc
恢复数据块：rman》recover datafile 5 block 203；
批量恢复受损的数据块：recover corruption list;
数据块坏块一号坏块，需要做：
run{
sql ’alter database datafile 5 offline’;
restore datafile 5;
recover datafile 5;
sql’alter database datafile 5 online’
}
使用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命令删除相关表，之后重建表最后导入数据。
使用DBMS_REPAIR恢复
用DBMS_REPAIR当然也会丢失数据。这里不做详细的介绍，有兴趣的可以查看oracle的在线文
3、使用dbms_repair包进行坏块处理
1）首先建立repair_table,用于存放dbms_repair.check_object检测出来的坏块信息
**L》 declare
2begin
3dbms_repair.admin_tables
4(table_name =》 ’REPAIR_TABLE’,--表名
5table_type =》 dbms_repair.repair_table,
6action =》 dbms_repair.create_action,
7tablespace =》 ’USERS’);--用于指定该表存放的表空间
8end;
9/
PL/**L 过程已成功完成。
**L》 col owner format a10
**L》 col object_name format a20
**L》 col object_type format a20
**L》 select owner, object_name, object_type
2from dba_objects
3where object_name like ’%REPAIR_TABLE’;
OWNEROBJECT_NAMEOBJECT_TYPE
---------- -------------------- --------------------
SYSREPAIR_TABLETABLE
SYSDBA_REPAIR_TABLEVIEW
Oracle自动创建了一个DBA_REPAIR_TABLE视图。
2）使用dbms_repair.check_object进行坏块检测
**L》 set serveroutput on size 100000;
**L》 declare
2rpr_count int;
3begin
4rpr_count := 0;
5dbms_repair.check_object(
6schema_name =》 ’SYS’,--指定对象模式，也就是对象的所有者
7object_name =》 ’TEST’,--指定对象名，也就是表名
8repair_table_name =》 ’REPAIR_TABLE’,
9corrupt_count =》 rpr_count);
10dbms_output.put_line(’repair block count: ’
11||to_char(rpr_count));
12end;
13/
repair block count: 4
PL/**L 过程已成功完成。
**L》 select object_name, block_id, corrupt_type, marked_corrupt,
2corrupt_description, repair_description
3from repair_table;
OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR
-------------------- ---------- ------------ ----------
CORRUPT_DESCRIPTION
-------------------------------------------------------------------------------
REPAIR_DESCRIPTION
-------------------------------------------------------------------------------
TEST196148 TRUE
mark block software corrupt
TEST206148 TRUE
mark block software corrupt
TEST236148 TRUE
mark block software corrupt
TEST316148 TRUE
mark block software corrupt
通过运行dbms_repair.check_object，将坏块信息存放到了repair_table表中，其中有个字段marked_corrupt，用于标识该块是否被标识为坏块，当被标识为true时，即该块被标识为坏块。其中这一步跟oracle文档中的描述有点进入，根据oracle文档，当执行完dbms_repair.check_object时，并不会进行坏块标识，也就是marked_corrupt列的值应该为false，而只有当执行dbms_repair.fix_corrupt_blocks过程后才会进行坏块标识。
3）使用dbms_repair.fix_corrupt_blocks进行坏块标识
**L》 declare
2fix_block_count int;
3begin
4fix_block_count := 0;
5dbms_repair.fix_corrupt_blocks (
6schema_name =》 ’SYS’,
7object_name =》 ’TEST’,
8object_type =》 dbms_repair.table_object,
9repair_table_name =》 ’REPAIR_TABLE’,
10fix_count =》 fix_block_count);
11dbms_output.put_line(’fix blocks count: ’ ||
12to_char(fix_block_count));
13end;
14/
fix blocks count: 0
PL/**L 过程已成功完成。
我们可以见到到fix blocks count=0，即在上一步进行check_object时已经进行了坏块标识了，这一步其实可以省略。（不过没有测试过！）
Oracle数据库打不开 该怎么办我们公司的oracle数据库坏了 打不开了，该如何处理
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
Oracle的损坏/坏块 主要分以下几种：
ORA-1578
ORA-8103
ORA-1410
ORA-1499
ORA-1578
ORA-81##
ORA-14##
ORA-26040
ORA-600 Errors
Block Corruption
Index Corruption
Row Corruption
UNDO Corruption
Control File
C***istent Read
Dictionary
File/RDBA/BL
Error Description Corruption related to:
ORA-1578 ORA-1578一般为Oracle检测到存在物理坏块问题，包括其检测数据块中的checksum不正确，或者tail_chk信息不正确等。 ORA-1578 is reported when a block is thought to be corrupt on read.
Block
数据块
OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note
OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”
Fractured Block explanation
Handling Oracle Block Corrupti*** in Oracle7/8/8i/9i/10g/11g
Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table
ORA-1410
ORA-1410错误常见于从INDEX或其他途径获得的ROWID,到数据表中查询发现没有对应的记录。
该错误可能因为数据表与其索引存在不一致，也可能是分区的数据表本身存在问题。
This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.
Row
数据行
Understanding The ORA-1410
Summary Of Bugs Containing ORA 1410
OERR: ORA 1410 “invalid ROWID”
ORA-8103
该ORA-8103可能由多个BUG引起，例如LOB在10.2.0.4之前可能会由于BUG覆盖了另一张表的segment header，导致出现ORA-8103错误。
诊断该问题可以从数据表的segment header和data_object_id入手。
The object has been deleted by another user since the operation began.
If the error is reproducible, following may be the reas***:-
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).
Block
数据块
ORA-8103 Troubleshooting, Diagnostic and Solution
OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution
ORA-8102 ORA-8102常见于索引键值与表上存的值不一致。 An ORA-08102 indicates that there is a mi**atch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mi**atch.
Index
索引
OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)
ORA-1499 对表和索引做交叉验证时发现问题 An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference.
Index
索引
ORA-1499. Table/Index row count mi**atch
OERR: ORA-1499 table/Index Cross Reference Failure – see trace file
ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inc***istency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mi**atch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is c***istent or if it ‘moves’.
Send the tracefile to support for ****ysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE; Block
OERR: ORA 1498 “block check failure – see trace file”
ORA-26040 由于采用过nologging/unrecoverable选项的redo生成机制，且做过对应的recover，导致数据块中被填满了0XFF，导致报错ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578
Block
数据块
OERR ORA-26040 Data block was loaded using the NOLOGGING option
ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution
ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors
ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled
ORA-1578 ORA-26040 On Awr Table
Errors ORA-01578, ORA-26040 On Standby Database
Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option
ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option
ORA-600
从索引获得的ROWID，对应到数据表时发现不存在数据行错误。
一把是一致性度c***istent read问题
Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mi**atch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 can also be reported due to a c***istent read (CR) problem.
C***istent Read
一致性读
Resolving an ORA-600 error in Oracle 8 and above.
ORA-600 “Index entry Points to Missing ROWID”
ORA-600 主要问题是redo和数据块中的信息不一致 This is called a ‘STUCK RECOVERY’.
There is an inc***istency between the information stored in the redo and the information stored in a database block being recovered. Redo
ORA-600 “Stuck Recovery”
Information Required for Root Cause Analysis of ORA-600 (stuck recovery)
ORA-600 主要是redo记录与回滚rollback/undo的记录不一致 A mi**atch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails. Undo
ORA-600 “Undo Record Number Mi**atch While Adding Undo Record”
Basic Steps to be Followed While Solving ORA-00600 Errors Without Using Unsupported parameter
ORA-600 主要是redo记录与回滚rollback/undo的记录不一致 A mi**atch has been detected between Redo records and Rollback (Undo) records.
We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails. Undo
ORA-600 “seq# mi**atch while adding undo record”
Basic Steps to be Followed While Solving ORA-00600 Errors Without Using Unsupported parameter
Ora-600 When Opening Or Shutting Down A Database
ORA-600 When Trying To Open The Database
ORA-600 transaction id不匹配，问题可能存在与回滚段中或者对象本身存在讹误 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment. Undo/Redo
ORA-600 “XID in Undo and Redo Does Not Match”
ORA-600 Not enough **** space was found when inserting a row into an index leaf block during the application of undo. Index
ORA-600 “insert into leaf block (undo)”
ORA-600 Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 is logged. Control File
ORA-600 “Attempt to access non-existant controlfile entry”
ORA-600 Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption. Block
ORA-600 “Lock count mi**atch”
ORA-600 主要是发现一个数据块的SCN甚至超过了当前SCN，常规解决途径有调整SCN等，但11.2以后Oracle公司使较多调整SCN的方法失效了 A data block SCN is ahead of the current SCN.
The ORA-600 occurs when an SCN is compared to the dependent SCN stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 internal error. Block
ORA-600 “Block SCN is ahead of Current SCN”
ORA 600 DURING STARTUP
ORA-600 访问一个回滚段头以便确认事务是否已提交时，发现XID有问题 We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue OR you might be hitting the following known problem. Undo
