一次壞塊的處理過程(一)
最近在一個資料庫遇到了壞塊,以下是處理過程。
一、壞塊的發現及處理
.......
Corrupt block relative dba: 0x00925026 (file 2, block 1200166)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x00925026
last change scn: 0x0578.15b7ebf7 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x33da0602
check value in block header: 0xf8d0
computed block checksum: 0xd82e
Reread of blocknum=1200166, file=+DATA/dwrac/datafile/dwdata_1m01.dbf. found same corrupt data
Reread of blocknum=1200166, file=+DATA/dwrac/datafile/dwdata_1m01.dbf. found same corrupt data
Reread of blocknum=1200166, file=+DATA/dwrac/datafile/dwdata_1m01.dbf. found same corrupt data
Reread of blocknum=1200166, file=+DATA/dwrac/datafile/dwdata_1m01.dbf. found same corrupt data
Reread of blocknum=1200166, file=+DATA/dwrac/datafile/dwdata_1m01.dbf. found same corrupt data
......
用dbv檢查也證實了這一點。
[oracle@dwdb02 admin]$ dbv file="+DATA/dwrac/datafile/dwdata_1m01.dbf" start=502554 end=1217134 userid=admin/sdoadmin123 blocksize=16384
DBVERIFY: Release 10.2.0.5.0 - Production on Thu Feb 17 14:50:13 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = +DATA/dwrac/datafile/dwdata_1m01.dbf
Page 502554 is marked corrupt
Corrupt block relative dba: 0x0087ab1a (file 2, block 502554)
Bad header found during dbv:
Data in bad block:
type: 11 format: 2 rdba: 0x00800001
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000b01
check value in block header: 0x85d8
computed block checksum: 0x0
......
DBVERIFY - Verification complete
Total Pages Examined : 714581
Total Pages Processed (Data) : 567369
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 143342
Total Pages Failing (Index): 0
Total Pages Processed (Other): 3866
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 0
Total Pages Marked Corrupt : 4
Total Pages Influx : 0
Highest block SCN : 0 (0.0)
10g以後rman備份發現的壞塊資訊可以在v$database_block_corruption查到。
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
---------- ---------- ---------- ------------------ ---------------
2 1217134 1 0 FRACTURED
508 2386314 1 0 FRACTURED
517 1115970 1 0 FRACTURED
2 1200166 1 0 FRACTURED
51 401698 1 0 FRACTURED
61 306642 1 0 FRACTURED
2 502554 1 0 FRACTURED
2 1213658 1 0 FRACTURED
34 701050 1 0 FRACTURED
60 347166 1 0 FRACTURED
FRACTURED意味著資料塊是物理損壞,遇到這種情況,如果有備份的話最好是從備份恢復,甚至可以用rman做塊級恢復,如
blockrecover datafile 2 block 1217134;
或者:
blockrecover corruption list;
不幸的是,這個資料庫是一個新庫,沒有正式上線,也還沒有上備份。沒辦法,只能看看損壞的物件是什麼了。
--由於庫太大,直接查dba_extents太慢,因此備份dba_extents到表dbextnet再查詢。
SQL> select * from dbextent where file_id=2 and 1213658 between block_id and block_id+blocks-1;
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
------------------------------ -------------------------------------------------------------------------------- ------------------------------ ------------------ ------------------------------ ---------- ---------- ---------- ---------- ---------- ------------
CREATER_USER WIDGET_NEWUSE_IX2 INDEX DWDATA_1M 995 2 1213637 1048576 64 2
SQL> select * from dbextent where file_id=2 and 502554 between block_id and block_id+blocks-1;
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
------------------------------ -------------------------------------------------------------------------------- ------------------------------ ------------------ ------------------------------ ---------- ---------- ---------- ---------- ---------- ------------
CREATER_USER WIDGET_NEWUSE_IX2 INDEX DWDATA_1M 1787 2 502533 1048576 64 2
萬幸的是,這裡損壞的只是索引,把索引rebuild就可以。如果損壞的是表,則可能需要用到其他手段,如dbms_repare包來處理了。
SQL> alter index creater_user.WIDGET_NEWUSE_IX2 rebuild online parallel 16 tablespace dwdata_10m_1 nologging;
Index altered
......
注意:這裡要用rebuild online,否則rebuild可能會讀取原索引作為源來重建新索引,這樣的話新建的索引也是損壞的。
全部處理完畢後,確認是否還有物件損壞。
SQL> select * from dba_extents E,v$database_block_corruption c where e.file_id=c.file# and c.block# between e.block_id and e.block_id+e.blocks-1;
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
------------------------------ -------------------------------------------------------------------------------- ------------------------------ ------------------ ------------------------------ ---------- ---------- ---------- ---------- ---------- ------------ ---------- ---------- ---------- ------------------ ---------------
以上查詢返回結果為空,表示沒有資料庫物件損壞,第一階段處理完畢。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/231499/viewspace-1046125/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一次壞塊的處理過程(二)
- 一次ORACLE資料庫undo壞塊處理Oracle資料庫
- 記一次PMML檔案的處理過程
- Oracle壞塊處理Oracle
- 記一次ceph pg unfound處理過程
- 一次併發處理過程, 基於 RedisRedis
- 記一次Nodejs安全工單的處理過程_20171226NodeJS
- 記一次linux主機中病毒處理過程Linux
- 一次線上問題處理過程記錄
- 記一次線上服務CPU 100%的處理過程
- [20190718]12c壞塊處理一例.txt
- 一個簡單易用的資料庫壞塊處理方案資料庫
- 【BLOCK】Oracle壞塊處理命令參考BloCOracle
- MySQL資料庫INNODB表損壞修復處理過程分享MySql資料庫
- 記一次12c pdb打補丁失敗處理過程
- python中PCA的處理過程PythonPCA
- 一次Oracle監聽無法動態註冊處理過程排查分析Oracle
- 如何處理Oracle資料庫中的壞塊問題(轉)Oracle資料庫
- DOM在Ahooks中的處理過程Hook
- Flink流處理過程的部分原理分析
- 一起ORA-00028案例的處理過程
- 【原始碼】Redis命令處理過程原始碼Redis
- 一次奇怪的的bug排查過程
- Oracle資料庫處理壞塊問題常用命令Oracle資料庫
- 【PHP】一次請求過程的解析PHP
- 線上的一次fullgc排查過程GC
- 記一次 GitLab 的遷移過程Gitlab
- 詳述一條SQL引發的高CPU故障處理過程SQL
- GC析構物件和列表的處理過程GC物件
- 【Tomcat】Tomat 處理請求的過程(圖解)Tomcat圖解
- MySQL儲存過程的異常處理方法MySql儲存過程
- fastHttp服務端處理請求的過程ASTHTTP服務端
- 處理一次k8s、calico無法分配podIP的心路歷程K8S
- Ceph pg unfound處理過程詳解
- 大資料的處理是怎樣的過程大資料
- Oracle資料庫出現ORA-19566 LOB壞塊的處理記錄Oracle資料庫
- 記一次nodejs開發CLI的過程NodeJS
- 記一次前端面試的全過程前端面試