構建並修復邏輯損壞塊和物理損壞塊

原創 ezbit 2020-02-24 20:51

Oracle數據塊的損壞可以分爲物理損壞和邏輯損壞,參照

http://blog.csdn.net/yidian815/article/details/39990803

 

物理損壞和邏輯損壞發生的場景不同，因此處理的方式方法也就不同。在很多情況下,相同的損壞塊處理方法對於物理損壞和邏輯損壞會產生不同的結果。對於物理損壞的模擬是比較容易的，而對邏輯損壞的模擬卻不常見。

 

物理損壞：

要模擬物理損壞，我們只需直接手工編輯物理塊既可（通過UTRAEDIT\BBED等），如

SQL> select object_name,dbms_rowid.rowid_block_number(rowid) from t1 where rownum < 9;

OBJECT_NAME		       DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------ ------------------------------------
ICOL$								 20
I_USER1 							 20
CON$								 20
UNDO$								 20
C_COBJ# 							 20
I_OBJ#								 20
PROXY_ROLE_DATA$						 20
I_IND1								 20

8 rows selected.
BBED> set file 5
	FILE#          	5

BBED> set block 20
	BLOCK#         	20

BBED> finr /c PROXY
BBED-00200: invalid keyword (finr)


BBED> find /c PROXY
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20               Offsets: 4223 to 4734           Dba:0x01400014
------------------------------------------------------------------------
 50524f58 595f524f 4c455f44 41544124 5f32ff02 c11c02c1 1c05494e 44455807 
 786e0414 09191d07 786e0414 09191d13 32303130 2d30342d 32303a30 383a3234 
 3a323805 56414c49 44014e01 4e014e2c 000c0749 5f555345 5223ff02 c10c02c1 
 0c05494e 44455807 786e0414 09191d07 786e0414 09191d13 32303130 2d30342d 
 32303a30 383a3234 3a323805 56414c49 44014e01 4e014e2c 000c0649 5f434f4c 
 31ff02c1 2e02c12e 05494e44 45580778 6e041409 191d0778 6e041409 191d1332 
 3031302d 30342d32 303a3038 3a32343a 32380556 414c4944 014e014e 014e2c00 
 0c07495f 43434f4c 32ff02c1 3802c138 05494e44 45580778 6e041409 191d0778 
 6e041409 191d1332 3031302d 30342d32 303a3038 3a32343a 32380556 414c4944 
 014e014e 014e2c00 0c07495f 43444546 33ff02c1 3502c135 05494e44 45580778 
 6e041409 191d0778 6e041409 191d1332 3031302d 30342d32 303a3038 3a32343a 
 32380556 414c4944 014e014e 014e2c00 0c07495f 49434f4c 31ff02c1 2902c129 
 05494e44 45580778 6e041409 191d0778 6e041409 191d1332 3031302d 30342d32 
 303a3038 3a32343a 32380556 414c4944 014e014e 014e2c00 0c07495f 43444546 
 31ff02c1 3302c133 05494e44 45580778 6e041409 191d0778 6e041409 191d1332 
 3031302d 30342d32 303a3038 3a32343a 32380556 414c4944 014e014e 014e2c00 

 <32 bytes per line>

BBED> dump /v
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20      Offsets: 4223 to 4734  Dba:0x01400014
-------------------------------------------------------
 50524f58 595f524f 4c455f44 41544124 l PROXY_ROLE_DATA$
 5f32ff02 c11c02c1 1c05494e 44455807 l _2........INDEX.
 786e0414 09191d07 786e0414 09191d13 l xn......xn......
 32303130 2d30342d 32303a30 383a3234 l 2010-04-20:08:24
 3a323805 56414c49 44014e01 4e014e2c l :28.VALID.N.N.N,
 000c0749 5f555345 5223ff02 c10c02c1 l ...I_USER#......
 0c05494e 44455807 786e0414 09191d07 l ..INDEX.xn......
 786e0414 09191d13 32303130 2d30342d l xn......2010-04-
 32303a30 383a3234 3a323805 56414c49 l 20:08:24:28.VALI
 44014e01 4e014e2c 000c0649 5f434f4c l D.N.N.N,...I_COL
 31ff02c1 2e02c12e 05494e44 45580778 l 1........INDEX.x
 6e041409 191d0778 6e041409 191d1332 l n......xn......2
 3031302d 30342d32 303a3038 3a32343a l 010-04-20:08:24:
 32380556 414c4944 014e014e 014e2c00 l 28.VALID.N.N.N,.
 0c07495f 43434f4c 32ff02c1 3802c138 l ..I_CCOL2...8..8
 05494e44 45580778 6e041409 191d0778 l .INDEX.xn......x
 6e041409 191d1332 3031302d 30342d32 l n......2010-04-2
 303a3038 3a32343a 32380556 414c4944 l 0:08:24:28.VALID
 014e014e 014e2c00 0c07495f 43444546 l .N.N.N,...I_CDEF
 33ff02c1 3502c135 05494e44 45580778 l 3...5..5.INDEX.x
 6e041409 191d0778 6e041409 191d1332 l n......xn......2
 3031302d 30342d32 303a3038 3a32343a l 010-04-20:08:24:
 32380556 414c4944 014e014e 014e2c00 l 28.VALID.N.N.N,.
 0c07495f 49434f4c 31ff02c1 2902c129 l ..I_ICOL1...)..)
 05494e44 45580778 6e041409 191d0778 l .INDEX.xn......x
 6e041409 191d1332 3031302d 30342d32 l n......2010-04-2
 303a3038 3a32343a 32380556 414c4944 l 0:08:24:28.VALID
 014e014e 014e2c00 0c07495f 43444546 l .N.N.N,...I_CDEF
 31ff02c1 3302c133 05494e44 45580778 l 1...3..3.INDEX.x
 6e041409 191d0778 6e041409 191d1332 l n......xn......2
 3031302d 30342d32 303a3038 3a32343a l 010-04-20:08:24:
 32380556 414c4944 014e014e 014e2c00 l 28.VALID.N.N.N,.

 <16 bytes per line>

BBED> modify /c abcde
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20               Offsets: 4223 to 4734           Dba:0x01400014
------------------------------------------------------------------------
 61626364 655f524f 4c455f44 41544124 5f32ff02 c11c02c1 1c05494e 44455807 
 786e0414 09191d07 786e0414 09191d13 32303130 2d30342d 32303a30 383a3234 
 3a323805 56414c49 44014e01 4e014e2c 000c0749 5f555345 5223ff02 c10c02c1 
 0c05494e 44455807 786e0414 09191d07 786e0414 09191d13 32303130 2d30342d 
 32303a30 383a3234 3a323805 56414c49 44014e01 4e014e2c 000c0649 5f434f4c 
 31ff02c1 2e02c12e 05494e44 45580778 6e041409 191d0778 6e041409 191d1332 
 3031302d 30342d32 303a3038 3a32343a 32380556 414c4944 014e014e 014e2c00 
 0c07495f 43434f4c 32ff02c1 3802c138 05494e44 45580778 6e041409 191d0778 
 6e041409 191d1332 3031302d 30342d32 303a3038 3a32343a 32380556 414c4944 
 014e014e 014e2c00 0c07495f 43444546 33ff02c1 3502c135 05494e44 45580778 
 6e041409 191d0778 6e041409 191d1332 3031302d 30342d32 303a3038 3a32343a 
 32380556 414c4944 014e014e 014e2c00 0c07495f 49434f4c 31ff02c1 2902c129 
 05494e44 45580778 6e041409 191d0778 6e041409 191d1332 3031302d 30342d32 
 303a3038 3a32343a 32380556 414c4944 014e014e 014e2c00 0c07495f 43444546 
 31ff02c1 3302c133 05494e44 45580778 6e041409 191d0778 6e041409 191d1332 
 3031302d 30342d32 303a3038 3a32343a 32380556 414c4944 014e014e 014e2c00 

 <32 bytes per line>
SQL> alter system flush buffer_cache;

System altered.

SQL> select object_name,dbms_rowid.rowid_block_number(rowid) from t1 where rownum < 9;
select object_name,dbms_rowid.rowid_block_number(rowid) from t1 where rownum < 9
                                                             *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 20)
ORA-01110: data file 5: '/home/app/oraten/oradata/oraten/tbs101.dbf'

而對物理損壞的修復也非常簡單( 上面修改的並不是第7條記錄)：

BBED> sum apply
Check value for File 5, Block 20:
current = 0xb5e0, required = 0xb5e0
SQL> alter system flush buffer_cache;

System altered.

SQL> select object_name,dbms_rowid.rowid_block_number(rowid) from t1 where object_name like '%abcde%';

OBJECT_NAME		       DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------ ------------------------------------
I_abcde_ROLE_DATA$_2						 20

對於邏輯損壞的模擬，確實比較麻煩，因爲只有oracle才知道數據塊的內部邏輯結構。今天我們嘗試模擬一種邏輯錯誤。我們指定oracle的數據是以row爲單位存儲在數據塊中的，而每個row的第一個byte具有特殊含義，該字節的每一個位都表示不同的含義，如下圖

如果我們通過bbed手工修改該byte的存儲內容，那麼oracle就有可能不能很好的識別該條記錄，從而引發邏輯錯誤。

BBED> set file 5
	FILE#          	5

BBED> set block 20
	BLOCK#         	20

BBED> map /v
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20                                    Dba:0x01400014
------------------------------------------------------------
 KTB Data Block (Table/Cluster)

 struct kcbh, 20 bytes                      @0       
    ub1 type_kcbh                           @0       
    ub1 frmt_kcbh                           @1       
    ub1 spare1_kcbh                         @2       
    ub1 spare2_kcbh                         @3       
    ub4 rdba_kcbh                           @4       
    ub4 bas_kcbh                            @8       
    ub2 wrp_kcbh                            @12      
    ub1 seq_kcbh                            @14      
    ub1 flg_kcbh                            @15      
    ub2 chkval_kcbh                         @16      
    ub2 spare3_kcbh                         @18      

 struct ktbbh, 96 bytes                     @20      
    ub1 ktbbhtyp                            @20      
    union ktbbhsid, 4 bytes                 @24      
    struct ktbbhcsc, 8 bytes                @28      
    b2 ktbbhict                             @36      
    ub1 ktbbhflg                            @38      
    ub1 ktbbhfsl                            @39      
    ub4 ktbbhfnx                            @40      
    struct ktbbhitl[3], 72 bytes            @44      

 struct kdbh, 14 bytes                      @124     
    ub1 kdbhflag                            @124     
    b1 kdbhntab                             @125     
    b2 kdbhnrow                             @126     
    sb2 kdbhfrre                            @128     
    sb2 kdbhfsbo                            @130     
    sb2 kdbhfseo                            @132     
    b2 kdbhavsp                             @134     
    b2 kdbhtosp                             @136     

 struct kdbt[1], 4 bytes                    @138     
    b2 kdbtoffs                             @138     
    b2 kdbtnrow                             @140     

 sb2 kdbr[96]                               @142     

 ub1 freespace[868]                         @334     

 ub1 rowdata[6986]                          @1202    

 ub4 tailchk                                @8188    


BBED> p *kdbr[1]
rowdata[6844]
-------------
ub1 rowdata[6844]                           @8046     0x2c

BBED> set offset 8046
	OFFSET         	8046

BBED> x /rccnncttccccc
rowdata[6844]                               @8046    
-------------
flag@8046: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8047: 0x00
cols@8048:   12

col    0[7] @8049: I_USER1
col    1[0] @8057: *NULL*
col    2[2] @8058: 44 
col    3[2] @8061: 44 
col    4[5] @8064: INDEX
col    5[7] @8070: 2010-04-20 08:24:28 
col    6[7] @8078: 2010-04-20 08:24:28 
col   7[19] @8086: 2010-04-20:08:24:28
col    8[5] @8106: VALID
col    9[1] @8112: N
col   10[1] @8114: N
col   11[1] @8116: N


BBED> set offset 8046
	OFFSET         	8046

BBED> modify /x ff
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20               Offsets: 8046 to 8191           Dba:0x01400014
------------------------------------------------------------------------
 ff000c07 495f5553 455231ff 02c12d02 c12d0549 4e444558 07786e04 1409191d 
 07786e04 1409191d 13323031 302d3034 2d32303a 30383a32 343a3238 0556414c 
 4944014e 014e014e 2c000c05 49434f4c 24ff02c1 1502c103 05544142 4c450778 
 6e041409 191d0778 6e041409 211a1332 3031302d 30342d32 303a3038 3a32343a 
 32380556 414c4944 014e014e 014e0106 5af8 

 <32 bytes per line>

BBED> x /rccnncttccccc
rowdata[6844]                               @8046    
-------------
flag@8046: 0xff (KDRHFN, KDRHFP, KDRHFL, KDRHFF, KDRHFD, KDRHFH, KDRHFC, KDRHFK)
lock@8047: 0x00
cols@8048:    0
ckix@8049:    7



BBED> sum apply
Check value for File 5, Block 20:
current = 0xb533, required = 0xb533

此時我們通過sqlpus查詢並編輯t1

SQL> alter system flush buffer_cache;

System altered.

SQL> select count(*) from t1;

  COUNT(*)
----------
     22944

SQL> select sum(length(object_name)) from t1;

SUM(LENGTH(OBJECT_NAME))
------------------------
		  531915

SQL> update t1 set object_name = rownum;
update t1 set object_name = rownum
       *
ERROR at line 1:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [5], [20], [6251],
[], [], [], []


SQL> rollback;

Rollback complete.

SQL> update t1 set object_name = rownum;
update t1 set object_name = rownum
       *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 20)
ORA-01110: data file 5: '/home/app/oraten/oradata/oraten/tbs101.dbf'

可見此時oracle認爲發生了邏輯錯誤，查看block20的標誌位發現, 邏輯損壞的標記（14字節修改位ff，tailchk中包含ff）已經打上。

BBED> set file 5
	FILE#          	5

BBED> set block 20
	BLOCK#         	20

BBED> set offset 14
	OFFSET         	14

BBED> dump /v count 12
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20      Offsets:   14 to   25  Dba:0x01400014
-------------------------------------------------------
 ff0438b5 00000100 00001ecb          l ..8.........

 <16 bytes per line>

BBED> set offset 8188
	OFFSET         	8188

BBED> dump /v 
 File: /home/app/oraten/oradata/oraten/tbs101.dbf (5)
 Block: 20      Offsets: 8188 to 8191  Dba:0x01400014
-------------------------------------------------------
 ff060000                            l ....

 <16 bytes per line>

而邏輯損壞的修復，通常是使用dbms_repair 包將損壞塊忽略

SQL> exec dbms_repair.skip_corrupt_blocks('SYS','T1');

PL/SQL procedure successfully completed.

SQL> update t1 set object_name=rownum;

22849 rows updated.

SQL> commit;

Commit complete.






發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Oracle: check the structure of a table

Oracle: check the structure of a table named test_table,  just using the follwoing command:   describe test_table;   th

lihongye_10 2020-07-07 06:44:23

（轉）JAVA存儲過程

(轉載地址:http://blog.csdn.net/vic_wang/article/details/1733796)   利用Java存儲過程簡化數據庫操作 作者：Kuassi Mensah 利用Java存儲過程溝通SQL、XML、

yehangchuan11 2020-07-01 10:28:33

（轉）UTL_DBWS - Consuming Web Services in Oracle 10g

（轉載地址：http://www.oracle-base.com/articles/10g/utl_dbws-10g.php）   In a previous article I presented a method for Consum

yehangchuan11 2020-07-01 10:28:31

資料--使用java、web services進行數據庫編程

1、Oracle官方文檔（11gR2）：Oracle Database Java Developer's Guide   2、另外推薦一本書：《Oracle Database Programming using Java and Web

yehangchuan11 2020-07-01 10:28:31

（轉）ORACLE中非常好用的類型轉換函數CAST

(轉載地址:http://blog.csdn.net/vic_wang/article/details/1709364)   CAST With Collections Using Multiset With A VARRAY CA

yehangchuan11 2020-07-01 10:28:31

（轉）FTP From PL/SQL

（轉載地址：http://www.oracle-base.com/articles/misc/ftp-from-plsql.php）   FTP From PL/SQL Sometimes it's preferable to trigg

yehangchuan11 2020-07-01 10:28:31

（轉）Oracle11g下UTL_TCP包居然用不通了調研

（轉載地址：http://blog.csdn.net/liaojiabo/article/details/6627065）   今天切換到Oracle11g下後，接着使用UTL_TCP與服務程序進行數據交互時，居然報出個ACL訪問控制的問

yehangchuan11 2020-07-01 10:28:31

Oracle的權限管理

權限是指執行特定類型sql命令或是訪問其它方案對象的權利，包括系統權限和對象權限兩種。 1.  系統權限     系統權限是指執行特定類型sql命令的權利。它用於控制用戶可以執行的一個或是一組數據庫操作。比如當用戶具有create tab

wang_zhou_jian 2020-06-30 01:58:31

Oracle表查詢

1.  處理null值      處理 null 值，可以使用 nvl 函數，nvl(comm, 0) 如果 comm 爲空，用 0 代替，否則就是 comm。      例：顯示每個僱員的年工資      select sal*12 +

wang_zhou_jian 2020-06-30 01:58:31

Oracle中的常用命令

Sqlplus是oracle數據庫常用的開發工具，sqlplus中常用的命令如下。 1.  連接命令 (1). conn[ect]        用法：conn 用戶名/密碼@網絡服務名[as sysdba/sysoper]，當用特權用戶

wang_zhou_jian 2020-06-30 01:58:31

PLSQL中的變量使用

在編寫pl/sql程序時，可以定義變量和常量；在pl/sql程序中包括有： (1). 標量類型(scalar) (2). 複合類型(composite) (3). 參照類型(reference) (4). lob(large object

wang_zhou_jian 2020-06-30 01:58:31

oracle block corrupt 壞塊

    總體上來講，oracle的壞塊可以分爲兩種情景：物理損壞和邏輯損壞。物理損壞是由於存儲等原因造成的，致使oracle在處理數據塊時發現塊的checksum不一致。邏輯損壞多是由於oracle的bug或者內存錯誤引起，通過檢測數據塊

ezbit 2020-06-24 03:11:40

oracle public redo thread and private redo thread

複習之前的學習內容，對public redo thread 和 private redo thread 的用處還是比較模糊，網上搜集的資料非常有限，看來有些好東西不跳牆是不行的。 廢話少說，知識點記錄下來： 在rac環境下，每個實例

ezbit 2020-06-24 03:11:40

rman configure命令

記錄rman的命令，備忘 連接到目標數據庫: BACK (DBID=4048592102) 連接到恢復目錄數據庫 RMAN> 2> show all;           --查看參數 RMAN 配置參數爲: CONFIGURE R

ezbit 2020-06-24 03:11:39

取消SQL執行，卻半天不響應是何故

有人問，執行一個大量插入的SQL，類似這種，執行了一陣子，想要取消，很久都沒響應，是怎麼回事？ 很多人看到很久沒響應，慌了，怕執行成功導致錯誤數據插

zhou1862324 2020-06-23 08:02:02