oracle三種類型壞塊的處理思路總結（沒有物理備份）

標籤：oracle 壞塊

壞塊的發生，很罕見，但生產系統偶爾還是會出現。如果有物理備份，處理起來相對簡單，直接進行塊級recover即可，但如果只有邏輯備份呢？處理起來要分四種情況，在此總結一下：

一、塊的data部分壞了，在sql執行掃描到這個塊的時候會報ORA-01578：

ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 21, block # 12)
ORA-01110: data file 21: ‘/u01/app/oracle/oradata/RWDB_production/T6.DBF‘

但是，這種壞塊不會影響資料庫重啟，只是在重啟到open階段的時候會報：

Thu Nov 20 10:39:00 CST 2014
Corrupt Block Found
         TSN = 26, TSNAME = CORRUPT
         RFN = 21, BLK = 12, RDBA = 88080396
         OBJN = 591083, OBJD = 591083, OBJECT = USER_TAB, SUBOBJECT =
         SEGMENT OWNER = RWUSER, SEGMENT TYPE = Table Segment

db在open的時候會掃描資料檔案的狀態，這裡可以清楚地看到是什麼類型的段、什麼使用者、什麼對象出現了壞塊。還可以用dbv工具進一步check：

[[email protected]]/u01/app/oracle/admin/RWDB>dbv file=/u01/app/oracle/oradata/RWDB_production/T6.DBF

DBVERIFY - Verification complete

Total Pages Examined         : 25
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 11
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 13
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 1132783081 (0.1132783081)

這裡也可以清楚地看到Total Pages Marked Corrupt為1，即有1個壞塊。

處理：

這種類型的壞塊，處理辦法有很多，support上的建議辦法如下：

1、用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS處理，即跳過壞塊。

2、用CTAS建一個暫存資料表，上面壞了的表為user_tab，可建一個暫存資料表user_tab_tmp

3、將user_tab表重新命名：alter table user_tab rename to user_tab_corrupt

4、將user_tab_tmp改為生產系統正式表：alter table user_tab_tmp rename to user_tab

5、重建user_tab表的索引

這種恢複辦法，那個壞塊裡面的資料會丟掉。如果是每天都進行邏輯備份，還可以將現在的user_tab與昨天邏輯備份裡面的user_tab進行比對，以最大限度恢複資料。

二、datafile的head塊壞了（1號塊）

一個8k block大小的資料檔案，我們用ultraedit開啟，以16進位方式顯示，其中00000000~00001ff0是0號塊，後面開始是1號塊，即這個資料檔案的head塊。這個塊壞了就相當危險，資料庫重啟會直接報錯：

SQL> conn /as sysdba;
Connected to an idle instance.
SQL> startup;
ORACLE instance started.

Total System Global Area  935329792 bytes
Fixed Size                  2100680 bytes
Variable Size             385876536 bytes
Database Buffers          541065216 bytes
Redo Buffers                6287360 bytes
Database mounted.
ORA-01122: database file 24 failed verification check
ORA-01110: data file 24: ‘/u01/app/oracle/oradata/RWDB_production/T9.DBF‘
ORA-01210: data file header is media corrupt

可以看到，資料庫打不開了。

alert報下面的東西：
Thu Nov 20 15:11:10 CST 2014
ALTER DATABASE OPEN
Read of rdba: 0x06000001 (file 24, block 1) failed with ORA-01210.
Hex dump of (file 24, block 1) in trace file /u01/app/oracle/admin/RWDB/udump/rwdb_ora_5850.trc
Corrupt block relative dba: 0x06000001 (file 24, block 1)
Bad header found during datafile header read
Data in bad block:
 type: 49 format: 1 rdba: 0x31000031
 last change scn: 0x0000.00000000 seq: 0x31 flg: 0x31
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000b01
 check value in block header: 0x3131
 block checksum disabled
Trying reread from disk.
Reread of rdba: 0x06000001 (file 24, block 1) failed with ORA-01210
ORA-1122 signalled during: ALTER DATABASE OPEN...

dbv也可以檢測到：

[[email protected]]/u01/app/oracle/admin/RWDB/bdump>dbv file=/u01/app/oracle/oradata/RWDB_production/T9.DBF

DBVERIFY - Verification complete

Total Pages Examined         : 25
Total Pages Processed (Data) : 1
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 10
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 13
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 1132794574 (0.1132794574)

如果半夜幹升級割接（要重啟伺服器），遇到這種問題，身邊又沒有DBA，還是很棘手的，業務直接就會中斷，如果是HA的系統，壞的datafile又剛好在磁陣上，那麼通過切換也無法解決這個問題，因為oracle資源群組就起不來。對於非歸檔模式的資料庫，解決方案如下：

SQL> ALTER DATABASE DATAFILE ‘/u01/app/oracle/oradata/RWDB_production/T9.DBF‘ OFFLINE DROP;

Database altered.

SQL> alter database open;

Database altered.

這裡，先不管資料丟失與否，先啟動了資料庫再說，免得故障鬧大！：）

三、datafile的os head塊壞了（0號塊）

什麼是datafile的0號塊？官方稱之為作業系統的頭塊，裡面的東西不是oracle寫的，是作業系統記錄的檔案大小等檔案系統相關的資訊。0號塊壞了，可以正常重啟資料庫，沒問題。但是，如果哪一天遇到緊急問題需要重建控制檔案，將會面臨報錯：

ORA-27047: unable to read the header block of file

對於0號塊的檢測，用前面的dbv根本檢測不出來（dbv命令貌似不檢測0號塊），需要用dbfsize來檢測：

[[email protected]]/u02/backup>dbfsize /u01/app/oracle/oradata/RWDB_production/T8.DBF
/u01/app/oracle/oradata/RWDB_production/T8.DBF: Header block magic number is bad

這裡會提示一個什麼magic號壞了。

解決方案：

resize一下有問題的資料檔案大小，os block head就會被重寫，問題可以解決。

alter database datafile ‘/u01/app/oracle/oradata/RWDB_production/T8.DBF‘ resize <new size>

四、整個datafile都壞了（各種壞塊的綜合體）

筆者曾遇到過一次，整個檔案都壞了，這種問題，可看做是以上壞塊情況的集體爆發。

如：

dbvfile=/data1/app/oracle/oradata/RWDB/IRDBRoamerTS_01.dbf

Total Pages Examined         : 1926

Total Pages Processed (Data) : 0

Total Pages Failing   (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing   (Index): 0

Total Pages Processed (Other): 0

Total Pages Processed (Seg)  : 0

Total Pages Failing   (Seg) : 0

Total Pages Empty            : 0

Total Pages Marked Corrupt  : 1926

Total Pages Influx           : 0

Highest block SCN            : 0 (0.0)

這裡可以看到，總共檢測了1926個塊，全壞了。如果遇到資料庫重啟，就無法open成功。

如果有RMAN備份，這種情況就很簡單，直接restore、recover壞的資料檔案就行。如果沒有物理備份，就要先用上面第二種情況的解決辦法先把資料庫開啟，然後再恢複資料。恢複資料的方法，與第二種裡面又有所不同，既然這個檔案裡的塊都壞了，再skip哪個塊就沒意義了。恢複資料的步驟如下：

1、看看這個dbf裡面有哪些對象

2、用最新的邏輯備份將上面的對象impdp進新的資料表空間（如果IRDBRoamerTS_01不是資料表空間下的唯一檔案，也可以不用建新的資料表空間）

本文出自 “資料庫” 部落格，請務必保留此出處http://weikle.blog.51cto.com/3324327/1582760

oracle三種類型壞塊的處理思路總結（沒有物理備份）