建站
咨詢
售后
建站咨詢
新聞中心
本文主要介紹如何去處理在 Oracle 數(shù)據(jù)庫中出現(xiàn)壞塊的問題，對(duì)于壞塊產(chǎn)生在不同的對(duì)象上，處理的方法會(huì)有所不同，本文將大致對(duì)這些方法做一些介紹。
創(chuàng)新互聯(lián)公司是一家專業(yè)的成都網(wǎng)站建設(shè)公司，我們專注網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì)、網(wǎng)絡(luò)營銷、企業(yè)網(wǎng)站建設(shè)，買鏈接，1元廣告為企業(yè)客戶提供一站式建站解決方案，能帶給客戶新的互聯(lián)網(wǎng)理念。從網(wǎng)站結(jié)構(gòu)的規(guī)劃UI設(shè)計(jì)到用戶體驗(yàn)提高，創(chuàng)新互聯(lián)力求做到盡善盡美。
因?yàn)閿?shù)據(jù)庫運(yùn)行時(shí)間長了，由于硬件設(shè)備的老化，出現(xiàn)壞塊的幾率會(huì)越來越大，因此，做為一個(gè) DBA，怎么去解決數(shù)據(jù)庫出現(xiàn)的壞塊問題就成了一個(gè)重要的議題了。
一：什么是數(shù)據(jù)庫的壞塊
首先我們來大概看一下數(shù)據(jù)庫塊的格式和結(jié)構(gòu)
數(shù)據(jù)庫的數(shù)據(jù)塊有固定的格式和結(jié)構(gòu)，分三層：cache layer，transaction layer，data layer。在我們對(duì)數(shù)據(jù)塊進(jìn)行讀取寫入操作的時(shí)候，數(shù)據(jù)庫會(huì)對(duì)要讀寫的數(shù)據(jù)塊做一致性的檢查，其中包括：數(shù)據(jù)塊的類型、數(shù)據(jù)塊的地址信息、數(shù)據(jù)塊的 SCN 號(hào)以及數(shù)據(jù)塊的頭部和尾部。如果發(fā)現(xiàn)其中有不一致的信息，那數(shù)據(jù)庫就會(huì)標(biāo)記這個(gè)數(shù)據(jù)塊為壞塊了。數(shù)據(jù)庫的壞塊分為兩種，邏輯壞塊和物理壞塊。
二：壞塊對(duì)數(shù)據(jù)庫產(chǎn)生的影響
如果數(shù)據(jù)庫出現(xiàn)壞塊，數(shù)據(jù)庫的告警日志文件里面會(huì)存在有如下的一些報(bào)錯(cuò)信息：Ora-1578 以及 Ora-600 and trace file in bdump directory，其中 Ora-600 錯(cuò)誤的***個(gè)參數(shù)值的范圍是 [2000]-[8000]，不同的值代表著數(shù)據(jù)塊的不同的層出現(xiàn)問題，具體的如下表所示：
Range block layer Cache layer 2000 – 4000 Transaction layer 4000 – 6000 Data layer 6000 - 8000
壞塊產(chǎn)生影響的對(duì)象可能是數(shù)據(jù)字典表、回滾段表、臨時(shí)段、用戶數(shù)據(jù)表和索引等。不同的對(duì)象產(chǎn)生壞塊后的處理方法不盡相同。
三：壞塊產(chǎn)生的原因
Oracle 調(diào)用標(biāo)準(zhǔn) C 的系統(tǒng)函數(shù)，對(duì)數(shù)據(jù)塊進(jìn)行讀寫操作，因此，壞塊是有可能由以下幾種原因產(chǎn)生：
1 硬件的 I/O 錯(cuò)誤 2 操作系統(tǒng)的 I/O 錯(cuò)誤或緩沖問題 3 內(nèi)存或 paging 問題 4 磁盤修復(fù)工具 5 一個(gè)數(shù)據(jù)文件的一部分正在被覆蓋 6 Oracle 試圖訪問一個(gè)未被格式化的系統(tǒng)塊失敗 7 數(shù)據(jù)文件部分溢出 8 Oracle 或者操作系統(tǒng)的 bug
四：壞塊的處理方法
1． 先收集相應(yīng)的關(guān)于壞快的信息
從 AlertSID.log 文件或者從 trace 文件中查找，找到例如以下的一些信息：
- Ora-1578 file# (RFN) block#
- Ora-1110 file# (AFN) block#
- Ora-600 file# (AFN) block#
* 其中 RFN 表示的是 relative_fno
*AFN 表示的是 file_id
- Select file_name,tablespace_name,file_id “AFN”,relative_fno “RFN”
- From dba_data_files;
- Select file_name,tablespace_name,file_id, relative_fno“RFN”
- From dba_temp_files;
2． 確定存在壞塊的對(duì)象是什么：
- SELECT tablespace_name, segment_type, owner, segment_name, partition_name FROM dba_extents WHERE file_id = and between block_id AND block_id + blocks – 1；
通過上面這個(gè)查詢語句就可以查出當(dāng)前存在壞塊的對(duì)象是什么，是什么類型的對(duì)象。需要注意的是如果是 temp 文件中出現(xiàn)壞塊，是沒有記錄返回的。
3． 根據(jù) 2 中查詢出來的對(duì)象類型確定相應(yīng)的處理方法
出現(xiàn)壞塊的常見對(duì)象有：
1 Sys 用戶下的對(duì)象 2 回滾段 3 臨時(shí)段 4 索引或者分區(qū)索引 5 表
常用的處理方法有：
1 恢復(fù)數(shù)據(jù)文件 2 只恢復(fù)壞的 block（9i 以上版本可用） 3 通過 ROWID RANGE SCAN 保存數(shù)據(jù) 4 使用 DBMS_REPAIR 5 使用 EVENT
4． 具體處理方法的介紹
恢復(fù)數(shù)據(jù)文件方法：
如果數(shù)據(jù)庫是歸檔方式下，并且有完整的物理備份，就可以使用此方法來恢復(fù)。
步驟如下：
1) 先 offline 受影響的數(shù)據(jù)文件，執(zhí)行以下的語句：
ALTER DATABASE DATAFILE 'name_file' OFFLINE；
2) 保留有壞塊的數(shù)據(jù)文件，然后拷貝備份的數(shù)據(jù)文件。如果恢復(fù)的數(shù)據(jù)文件要求路徑不同，執(zhí)行以下的語句：
ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';
3) 恢復(fù)數(shù)據(jù)文件，執(zhí)行以下語句：
RECOVER DATAFILE 'name_of_file';
4) Online 恢復(fù)后的數(shù)據(jù)文件，執(zhí)行以下的語句：
ALTER DATABASE DATAFILE 'name_of_file' ONLINE;
* 只恢復(fù)壞的 block（9i 以上版本可用）
使用這種方法要求數(shù)據(jù)庫版本是 9.2.0 以上，要求配置了 Rman 的 catalog 數(shù)據(jù)庫，數(shù)據(jù)庫為歸檔方式，并且有完整的物理備份。
步驟如下：
使用 RMAN 的 BLOCKRECOVER 命令 ：
Rman>run{blockrecover datafile 5 block 11,16;}
也可以強(qiáng)制使用某個(gè) SCN 號(hào)之前的備份，恢復(fù)數(shù)據(jù)塊。
Rman>run{blockrecover datafile 5 block 11,16 restore until sequence 8505;}
* 通過 ROWID RANGE SCAN 保存數(shù)據(jù)
1) 先取得壞塊中 ROW ID 的最小值，執(zhí)行以下的語句：
SELECT dbms_rowid.rowid_create(1,,,,0) from DUAL;
2）取得壞塊中的 ROW ID 的***值，執(zhí)行以下的語句：
SELECT dbms_rowid.rowid_create(1,,,+1,0) from DUAL;
3）建議一個(gè)臨時(shí)表存儲(chǔ)那些沒有壞塊的數(shù)據(jù)，執(zhí)行以下的語句：
CREATE TABLE salvage_table AS SELECT * FROM corrupt_tab Where 1=2;
4）保存那些不存在壞塊的數(shù)據(jù)到臨時(shí)表中，執(zhí)行以下的語句：
INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM A WHERE rowid < ''；
INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM A WHERE rowid >= '‘;
5) 根據(jù)臨時(shí)表中的數(shù)據(jù)重建表，重建表上的索引，限制。
* 使用 10231 診斷事件，在做全表掃描的時(shí)候跳過壞塊
可以在 session 級(jí)別設(shè)定：
ALTER SESSION SET EVENTS '10231 TRACE NA ME CONTEXT FOREVER, LEVEL 10';
也可以在數(shù)據(jù)庫級(jí)別上設(shè)定，在初始化參數(shù)中加入：
event="10231 trace name context forever, level 10" ，然后重啟數(shù)據(jù)庫。
然后從存在壞塊的表中取出不存在壞塊的數(shù)據(jù)，執(zhí)行以下的語句：
CREATE TABLE salvage_emp AS SELECT * FROM corrupt_table; *** rename 生成的 corrupt_table 為原來表的名字，并重建表上的索引和限制。
* 使用 dbms_repair 包進(jìn)行恢復(fù)
使用 dbms_repair 標(biāo)記有壞塊的表，在做全表掃描的時(shí)候跳過壞塊，執(zhí)行以下的語句：
Execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');
然后使用 exp 工具或者 createtable as select 的方法取出沒有壞塊數(shù)據(jù)，然后重建表，表上的索引和限制。
五：壞塊的預(yù)先發(fā)現(xiàn)的方法
1． 如果要檢測數(shù)據(jù)庫中所有的表，可以利用 exp 工具導(dǎo)出整個(gè)數(shù)據(jù)庫可以檢測壞塊。不過這個(gè)工具有一些缺陷，對(duì)以下情況的壞塊是檢測不出來的：
1 HWM 以上的壞塊是不會(huì)發(fā)現(xiàn)的 2 索引中存在的壞塊是不會(huì)發(fā)現(xiàn)的 3 數(shù)據(jù)字典中的壞塊是不會(huì)發(fā)現(xiàn)的
2． 如果只是對(duì)數(shù)據(jù)庫中比較重要的表進(jìn)行壞塊檢查，可以使用 ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE 的方法來檢測壞塊，它執(zhí)行壞塊的檢查，但是不會(huì)標(biāo)記壞塊為 corrupt，檢測的結(jié)果保存在 USER_DUMP_DEST 目錄下的用戶 trace 文件中。
3． 使用 Oracle 的專門工具 dbv 來檢查壞塊，具體的語法如下：
關(guān)鍵字 說明 (默認(rèn)) ---------------------------------------------------- FILE 要驗(yàn)證的文件 (無) START 起始?jí)K (文件的***個(gè)塊) END 結(jié)束塊 (文件的***一個(gè)塊) BLOCKSIZE 邏輯塊大小 (2048) LOGFILE 輸出日志 (無) FEEDBACK 顯示進(jìn)度 (0) PARFILE 參數(shù)文件 (無) USERID 用戶名 / 口令 (無) SEGMENT_ID 段 ID (tsn.relfile.block) (無)
例如：
Dbv file=system01.dbf blocksize=8192
DBVERIFY: Release 9.2.0.5.0 - Production on 星期六 11 月 27 15:29:13 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - 驗(yàn)證正在開始 : FILE = system01.dbf
DBVERIFY - 驗(yàn)證完成
檢查的頁總數(shù) ：32000
處理的頁總數(shù)（數(shù)據(jù)）：13261
失敗的頁總數(shù)（數(shù)據(jù)）：0
處理的頁總數(shù)（索引）：2184
失敗的頁總數(shù)（索引）：0
處理的頁總數(shù)（其它）：1369
處理的總頁數(shù) (段) : 0
失敗的總頁數(shù) (段) : 0
空的頁總數(shù) ：15186
標(biāo)記為損壞的總頁數(shù)：0
匯入的頁總數(shù) ：0
注：因?yàn)?dbv 要求 file 后面跟的必須是一個(gè)文件擴(kuò)展名，所以如果用裸設(shè)備存儲(chǔ)的，就必須使用 ln 鏈接裸設(shè)備到一個(gè)文件，然后再用 dbv 對(duì)這個(gè)鏈接文件進(jìn)行檢查。
標(biāo)題名稱：Oracle數(shù)據(jù)庫中出現(xiàn)的壞塊問題，該如何處理？
文章路徑：http://www.dlmjj.cn/article/dhhddjo.html
