13518219792
dbv工具可以用来验证数据文件的有效性，在数据库恢复之前可以使用该命令对备份文件进行有效性检查，
成都创新互联公司-专业网站定制、快速模板网站建设、高性价比马尾网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式马尾网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖马尾地区。费用合理售后完善，十余年实体公司更值得信赖。
防止因备份文件本身的问题导致数据库无法恢复。
当然，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官方文档
2.查看帮助文档
从语法定义中我们看到“HELP = { Y | N }”选项，我们可以使用它查看dbv的帮助信息。
ticket@secDB /home/oracle$ dbv help=y
DBVERIFY: Release 11.2.0.1.0 - Production 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 - Production 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 - Production 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
如果自己搞不定可以找诗檀软件专业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
Consistent 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 Corruptions 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 reasons:-
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 mismatch 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 mismatch.
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 mismatch
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 inconsistency 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 mismatch.
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 consistent or if it ‘moves’.
Send the tracefile to support for analysis.
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[12700]
从索引获得的ROWID，对应到数据表时发现不存在数据行错误。
一把是一致性度consistent read问题
Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch 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 [12700] can also be reported due to a consistent read (CR) problem.
Consistent Read
一致性读
Resolving an ORA-600 [12700] error in Oracle 8 and above.
ORA-600 [12700] “Index entry Points to Missing ROWID”
ORA-600[3020] 主要问题是redo和数据块中的信息不一致 This is called a ‘STUCK RECOVERY’.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered. Redo
ORA-600 [3020] “Stuck Recovery”
Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)
ORA-600[4194] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch 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 [4194] “Undo Record Number Mismatch While Adding Undo Record”
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
ORA-600[4193] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch 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 [4193] “seq# mismatch while adding undo record”
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
Ora-600 [4193] When Opening Or Shutting Down A Database
ORA-600 [4193] When Trying To Open The Database
ORA-600[4137] 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 [4137] “XID in Undo and Redo Does Not Match”
ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo. Index
ORA-600 [6101] “insert into leaf block (undo)”
ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged. Control File
ORA-600 [2130] “Attempt to access non-existant controlfile entry”
ORA-600[4512] 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 [4512] is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption. Block
ORA-600 [4512] “Lock count mismatch”
ORA-600[2662] 主要是发现一个数据块的SCN甚至超过了当前SCN，常规解决途径有调整SCN等，但11.2以后Oracle公司使较多调整SCN的方法失效了 A data block SCN is ahead of the current SCN.
The ORA-600 [2662] 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 [2662] internal error. Block
ORA-600 [2662] “Block SCN is ahead of Current SCN”
ORA 600 [2662] DURING STARTUP
ORA-600[4097] 访问一个回滚段头以便确认事务是否已提交时，发现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
1、首先打开PL/SQL Developer软件，新建sql窗口。
2、打开修改oracle存储过程，该存储过程有一个输入参数（pid）跟一个输出参数(name)，即通过用户id查询用户名称并将名称返回。
3、调试存储过程，找到刚刚修改的存储过程右击并点击【test】选项。
4、在打开的窗口内修改id值并点击左上角的倒三角形图标开始调试。按【CTRL+N】进行单步进入调试，【CTRL+O】单步调试，【CTRL+T】退出调试，也可以点击调试工具进行调试。
5、变量查看，在窗口下方可输入变量名称观察变量的变化情况。
6、调试完成后就可以检查调试结果，可以在调试结果中查看错误。
【Oracle数据恢复】ORA-01578错误解析
一般认为ORA-1578是 数据块物理坏块/损坏的一种，不同于逻辑损坏/坏块，其错误信息如下：
[oracle@oel8 dirdat]$ oerr ora 1578
01578, 00000, "ORACLE data block corrupted (file # %s, block # %s)"
// *Cause: The data block indicated was corrupted, mostly due to software
// errors.
// *Action: Try to restore the segment containing the block indicated. This
// may involve dropping the segment and recreating it. If there
// is a trace file, report the errors in it to your ORACLE
// representative
这个1578一般 会伴随ORA-1110出现，一旦ORACLE读取到存在损坏的块就会报出:
SQL select * from scott.emp;
select * from scott.emp
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 11, block # 34) 这里的FILE#是 RFN
ORA-01110: data file 6:'/home/oracle/corrclass.dbf' 这里的是AFN
断裂的数据块Fractured Block：
Corrupt block relative dba: 0x0380e573 (file 14, block 58739)
Fractured block found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0380e573
last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04
consistency value in tail: 0x00780601
check value in block header: 0x8739, computed block checksum: 0x2f00
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data
或者错误的校验和checksum
Corrupt block relative dba: 0x0380a58f (file 14, block 42383)
Bad check value found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0380a58f
last change scn: 0x0288.7784c5ee seq: 0x1 flg: 0x06
consistency value in tail: 0xc5ee0601
check value in block header: 0x68a7, computed block checksum: 0x2f00
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0380a58f (file 14, block 42383) found same corrupted data
或者错误的块头
Corrupt block relative dba: 0x0d805a89 (file 54, block 23177)
Bad header found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0d805b08
last change scn: 0x0692.86dc08e3 seq: 0x1 flg: 0x04
consistency value in tail: 0x08e30601
check value in block header: 0x2a6e, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0d805a89 (file 54, block 23177) found valid data
一些可能引起ORA-1578的BUG 列表如下：
如果自己搞不定可以找ASKMACLEAN专业数据库修复团队成员帮您恢复!
Oracle DBA神器：PRM-DUL灾难恢复工具可以直接从这种受损的Oracle数据库中将数据拯救出来。
当你的数据库因为ORA-00600/ORA-07445或其他ORA-报错，或丢失关键的system表空间数据文件，或ASM diskgroup损坏时均可以考虑采用PRM-DUL来做恢复。PRM-DUL采用独创的DataBridge恢复技术，直接从数据文件中抽取数据后可以像DBLINK那样直接插入到新建数据库中，而无需数据落地成为DMP文件占用空间。
