dbv工具可以用來(lái)驗(yàn)證數(shù)據(jù)文件的有效性，在數(shù)據(jù)庫(kù)恢復(fù)之前可以使用該命令對(duì)備份文件進(jìn)行有效性檢查，
成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比馬尾網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式馬尾網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋馬尾地區(qū)。費(fèi)用合理售后完善，十余年實(shí)體公司更值得信賴。
防止因備份文件本身的問(wèn)題導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法恢復(fù)。
當(dāng)然，dbv命令也可以對(duì)在線的數(shù)據(jù)文件進(jìn)行檢查。
注意，dbv工具只可以對(duì)數(shù)據(jù)文件進(jìn)行檢查，無(wú)法使用它完成控制文件和日志文件的檢查。
1.dbv命令語(yǔ)法
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.
參考自O(shè)racle官方文檔
2.查看幫助文檔
從語(yǔ)法定義中我們看到“HELP = { Y | N }”選項(xiàng)，我們可以使用它查看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.體驗(yàn)dbv工具的效果
1）查看系統(tǒng)中的數(shù)據(jù)文件名稱
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工具對(duì)users01.dbf進(jìn)行檢查
（1）使用最簡(jiǎn)單的參數(shù)
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)
在實(shí)際使用中重點(diǎn)關(guān)注以下信息：
Total Pages Failing (Data) : 0
Total Pages Failing (Index): 0
Total Pages Failing (Seg) : 0
Total Pages Marked Corrupt : 0
如果以上信息返回結(jié)果不為0，需要重點(diǎn)關(guān)注！及時(shí)排查原因。
（2）如果指定logfile參數(shù)，檢查結(jié)果將只記錄在日志文件中，屏幕上不顯示
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.
此時(shí)可以使用SQL*Plus的edit命令查看生成的日志文件內(nèi)容。
sys@ticket ed dbv_users01.log
如果自己搞不定可以找詩(shī)檀軟件專業(yè)ORACLE數(shù)據(jù)庫(kù)修復(fù)團(tuán)隊(duì)成員幫您恢復(fù)!
詩(shī)檀軟件專業(yè)數(shù)據(jù)庫(kù)修復(fù)團(tuán)隊(duì)
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檢測(cè)到存在物理壞塊問(wèn)題，包括其檢測(cè)數(shù)據(jù)塊中的checksum不正確，或者tail_chk信息不正確等。 ORA-1578 is reported when a block is thought to be corrupt on read.
Block
數(shù)據(jù)塊
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錯(cuò)誤常見(jiàn)于從INDEX或其他途徑獲得的ROWID,到數(shù)據(jù)表中查詢發(fā)現(xiàn)沒(méi)有對(duì)應(yīng)的記錄。
該錯(cuò)誤可能因?yàn)閿?shù)據(jù)表與其索引存在不一致，也可能是分區(qū)的數(shù)據(jù)表本身存在問(wèn)題。
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
數(shù)據(jù)行
Understanding The ORA-1410
Summary Of Bugs Containing ORA 1410
OERR: ORA 1410 “invalid ROWID”
ORA-8103
該ORA-8103可能由多個(gè)BUG引起，例如LOB在10.2.0.4之前可能會(huì)由于BUG覆蓋了另一張表的segment header，導(dǎo)致出現(xiàn)ORA-8103錯(cuò)誤。
診斷該問(wèn)題可以從數(shù)據(jù)表的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
數(shù)據(jù)塊
ORA-8103 Troubleshooting, Diagnostic and Solution
OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution
ORA-8102 ORA-8102常見(jiàn)于索引鍵值與表上存的值不一致。 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 對(duì)表和索引做交叉驗(yàn)證時(shí)發(fā)現(xiàn)問(wèn)題 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 由于采用過(guò)nologging/unrecoverable選項(xiàng)的redo生成機(jī)制，且做過(guò)對(duì)應(yīng)的recover，導(dǎo)致數(shù)據(jù)塊中被填滿了0XFF，導(dǎo)致報(bào)錯(cuò)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
數(shù)據(jù)塊
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，對(duì)應(yīng)到數(shù)據(jù)表時(shí)發(fā)現(xiàn)不存在數(shù)據(jù)行錯(cuò)誤。
一把是一致性度consistent read問(wèn)題
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] 主要問(wèn)題是redo和數(shù)據(jù)塊中的信息不一致 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不匹配，問(wèn)題可能存在與回滾段中或者對(duì)象本身存在訛誤 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] 主要是發(fā)現(xiàn)一個(gè)數(shù)據(jù)塊的SCN甚至超過(guò)了當(dāng)前SCN，常規(guī)解決途徑有調(diào)整SCN等，但11.2以后Oracle公司使較多調(diào)整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] 訪問(wèn)一個(gè)回滾段頭以便確認(rèn)事務(wù)是否已提交時(shí)，發(fā)現(xiàn)XID有問(wèn)題 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、首先打開(kāi)PL/SQL Developer軟件，新建sql窗口。
2、打開(kāi)修改oracle存儲(chǔ)過(guò)程，該存儲(chǔ)過(guò)程有一個(gè)輸入?yún)?shù)（pid）跟一個(gè)輸出參數(shù)(name)，即通過(guò)用戶id查詢用戶名稱并將名稱返回。
3、調(diào)試存儲(chǔ)過(guò)程，找到剛剛修改的存儲(chǔ)過(guò)程右擊并點(diǎn)擊【test】選項(xiàng)。
4、在打開(kāi)的窗口內(nèi)修改id值并點(diǎn)擊左上角的倒三角形圖標(biāo)開(kāi)始調(diào)試。按【CTRL+N】進(jìn)行單步進(jìn)入調(diào)試，【CTRL+O】單步調(diào)試，【CTRL+T】退出調(diào)試，也可以點(diǎn)擊調(diào)試工具進(jìn)行調(diào)試。
5、變量查看，在窗口下方可輸入變量名稱觀察變量的變化情況。
6、調(diào)試完成后就可以檢查調(diào)試結(jié)果，可以在調(diào)試結(jié)果中查看錯(cuò)誤。
【Oracle數(shù)據(jù)恢復(fù)】ORA-01578錯(cuò)誤解析
一般認(rèn)為ORA-1578是 數(shù)據(jù)塊物理壞塊/損壞的一種，不同于邏輯損壞/壞塊，其錯(cuò)誤信息如下：
[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
這個(gè)1578一般 會(huì)伴隨ORA-1110出現(xiàn)，一旦ORACLE讀取到存在損壞的塊就會(huì)報(bào)出:
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
斷裂的數(shù)據(jù)塊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
或者錯(cuò)誤的校驗(yàn)和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
或者錯(cuò)誤的塊頭
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專業(yè)數(shù)據(jù)庫(kù)修復(fù)團(tuán)隊(duì)成員幫您恢復(fù)!
Oracle DBA神器：PRM-DUL災(zāi)難恢復(fù)工具可以直接從這種受損的Oracle數(shù)據(jù)庫(kù)中將數(shù)據(jù)拯救出來(lái)。
當(dāng)你的數(shù)據(jù)庫(kù)因?yàn)镺RA-00600/ORA-07445或其他ORA-報(bào)錯(cuò)，或丟失關(guān)鍵的system表空間數(shù)據(jù)文件，或ASM diskgroup損壞時(shí)均可以考慮采用PRM-DUL來(lái)做恢復(fù)。PRM-DUL采用獨(dú)創(chuàng)的DataBridge恢復(fù)技術(shù)，直接從數(shù)據(jù)文件中抽取數(shù)據(jù)后可以像DBLINK那樣直接插入到新建數(shù)據(jù)庫(kù)中，而無(wú)需數(shù)據(jù)落地成為DMP文件占用空間。
重慶分公司
重慶分公司
