檢測oracle數(shù)據(jù)庫壞塊的方法

更新時間：2016年05月26日 10:14:16 作者：囧囧友

這篇文章主要介紹了檢測oracle數(shù)據(jù)庫壞塊的方法的相關(guān)資料，非常不錯具有參考借鑒價值,需要的朋友可以參考下

檢測oracle數(shù)據(jù)庫壞塊的辦法：

1、使用DBV(DB File Verify)工具;

2、使用RMAN(Recovery Manager)工具;

DBV(DB File Verify)工具：

外部命令，物理介質(zhì)數(shù)據(jù)結(jié)構(gòu)完整性檢查；

只能用于數(shù)據(jù)文件（offline或online），不支持控制文件和重做日志文件的塊檢查；

也可以驗證備份文件（rman的copy命令備份或操作系統(tǒng)CP命令備份）；

進入盤符，然后執(zhí)行以下腳本:

D:\app\Administrator\oradata\orcl>dbv file=ZL9MTLBASE.DBF blocksize=8192;

RMAN(Recovery Manager)工具：

邏輯數(shù)據(jù)結(jié)構(gòu)完整性檢查；

在線使用Recovery Manager掃描壞塊和備份時，需要數(shù)據(jù)庫運行在歸檔模式（archive log），否則只能在數(shù)據(jù)庫未打開（mount）的情況下進行；

RMAN>backup check logical validate datafile n ;

以上命令可以檢查數(shù)據(jù)文件是否包含壞塊，同時并不產(chǎn)生實際的備份輸出。

而且當使用Recovery Manager進行實際的數(shù)據(jù)庫備份時，同時也就進行了壞塊檢查。

直接使用RMAN的命令：backup validate check logical database;

結(jié)合V$DATABASE_BLOCK_CORRUPTION視圖更方便。

1)、rman target / nocatalog

2)、RMAN> spool log to 'd:/dbbak/rmanlog.log';---指定輸出rman日志文件

RMAN> run {
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
backup validate check logical database;
};

3)、select * from V$DATABASE_BLOCK_CORRUPTION;

4) 、--If V$DATABASE_BLOCK_CORRUPTION contains rows please run this query to find the objects that contains the corrupted blocks:

SELECT e.owner,
e.segment_type,
e.segment_name,
e.partition_name,
c.file#,
greatest(e.block_id, c.block#) corr_start_block#,
least(e.block_id + e.blocks - 1, c.block# + c.blocks - 1) corr_end_block#,
least(e.block_id + e.blocks - 1, c.block# + c.blocks - 1) -
greatest(e.block_id, c.block#) + 1 blocks_corrupted,
null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id <= c.block# + c.blocks - 1
AND e.block_id + e.blocks - 1 >= c.block#
UNION
SELECT s.owner,
s.segment_type,
s.segment_name,
s.partition_name,
c.file#,
header_block corr_start_block#,
header_block corr_end_block#,
1 blocks_corrupted,
'Segment Header' description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner,
null segment_type,
null segment_name,
null partition_name,
c.file#,
greatest(f.block_id, c.block#) corr_start_block#,
least(f.block_id + f.blocks - 1, c.block# + c.blocks - 1) corr_end_block#,
least(f.block_id + f.blocks - 1, c.block# + c.blocks - 1) -
greatest(f.block_id, c.block#) + 1 blocks_corrupted,
'Free Block' description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id <= c.block# + c.blocks - 1
AND f.block_id + f.blocks - 1 >= c.block#
order by file#, corr_start_block#;

5)、

SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = &fileid
and &blockid between block_id AND block_id + blocks - 1;

告警日志中快速識別：

遇到壞塊問題時，數(shù)據(jù)庫的異常表現(xiàn)通常有：

報告ORA-01578錯誤。

報告ORA-1110錯誤。

報告ORA-00600錯誤。其中，第一個參數(shù)為2000-8000，Cache layer 2000 – 4000，Transaction layer 4000 – 6000，Data layer 6000 - 8000。

Trace文件中出現(xiàn)Corrupt block dba: 0x160c5958 . found。分析對象失敗。

后臺進程,如DBWR，LGWR出現(xiàn)長時間異常等待，如LGWR wait for redo copy。

以上所述是小編給大家介紹的檢測oracle數(shù)據(jù)庫壞塊的方法，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

您可能感興趣的文章: