一、測試環境
sys@orcl> select file_name from dba_data_files;
FILE_NAME
---------------------------------------------
/u01/app/oracle/oradata/ORCL/system01.dbf
/u01/app/oracle/oradata/ORCL/sysaux01.dbf
/u01/app/oracle/oradata/ORCL/users01.dbf
/u01/app/oracle/oradata/ORCL/undotbs01.dbf
sys@orcl> create tablespace t1 datafile '/u01/app/oracle/oradata/ORCL/t1.dbf' size 10M autoextend off;
Tablespace created.
sys@orcl> create user cy identified by cy account unlock;
User created.
sys@orcl> grant dba to cy;
Grant succeeded.
sys@orcl> alter user cy default tablespace t1;
User altered.
sys@orcl> conn cy/cy
Connected.
cy@orcl> create table t1 as select * from scott.emp;
Table created.
cy@orcl> alter system checkpoint;
System altered.
cy@orcl> set linesize 1000
cy@orcl> select rowid,a.*,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block# from t1 a;
ROWID EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO FILE# BLOCK#
------------------ ---------- -------------------- ------------------ ---------- ------------------- ---------- ---------- ---------- ---------- ----------
AAASAsAAFAAAACDAAA 7369 SMITH CLERK 7902 1980-12-17 00:00:00 800 20 5 131
AAASAsAAFAAAACDAAB 7499 ALLEN SALESMAN 7698 1981-02-20 00:00:00 1600 300 30 5 131
AAASAsAAFAAAACDAAC 7521 WARD SALESMAN 7698 1981-02-22 00:00:00 1250 500 30 5 131
AAASAsAAFAAAACDAAD 7566 JONES MANAGER 7839 1981-04-02 00:00:00 2975 20 5 131
AAASAsAAFAAAACDAAE 7654 MARTIN SALESMAN 7698 1981-09-28 00:00:00 1250 1400 30 5 131
AAASAsAAFAAAACDAAF 7698 BLAKE MANAGER 7839 1981-05-01 00:00:00 2850 30 5 131
AAASAsAAFAAAACDAAG 7782 CLARK MANAGER 7839 1981-06-09 00:00:00 2450 10 5 131
AAASAsAAFAAAACDAAH 7788 SCOTT ANALYST 7566 1987-04-19 00:00:00 3000 20 5 131
AAASAsAAFAAAACDAAI 7839 KING PRESIDENT 1981-11-17 00:00:00 5000 10 5 131
AAASAsAAFAAAACDAAJ 7844 TURNER SALESMAN 7698 1981-09-08 00:00:00 1500 0 30 5 131
AAASAsAAFAAAACDAAK 7876 ADAMS CLERK 7788 1987-05-23 00:00:00 1100 20 5 131
AAASAsAAFAAAACDAAL 7900 JAMES CLERK 7698 1981-12-03 00:00:00 950 30 5 131
AAASAsAAFAAAACDAAM 7902 FORD ANALYST 7566 1981-12-03 00:00:00 3000 20 5 131
AAASAsAAFAAAACDAAN 7934 MILLER CLERK 7782 1982-01-23 00:00:00 1300 10 5 131
14 rows selected.
SELECT ROWID,
DBMS_ROWID.ROWID_OBJECT(ROWID) AS OBJECT,
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) AS FILENUM,
DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) AS BLOCK,
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) AS ROWN
FROM T1;
cy@orcl> select object_id from dba_objects where object_name='T1';
OBJECT_ID
----------------------------
73772
說明：
rowid是指向塊中特定行的指針，ROWID可用于提取轉儲特定塊所需的文件和塊號，對數據進行索引時，
索引塊包含每行的行ID，以便更快地訪問(執行計劃中能看到)，當常規訪問方法失敗時，ROWID也可用于從塊中提取數據
1.1 、rowid結構：
AAASAsAAFAAAACDAAN-->AAASAs(data object number) AAF(relative file number) AAAACD(block number ) AAN(row number)
32bit 10bit 22bit 16bit
說明：
數據庫對象數量不能超過2^32
相對文件號不能超過2^10
單個數據文件可以管理的塊數2^22
單個塊行數不能超過2^16
cy@orcl> select rowid,dump(rowid,1016) from t1;
ROWID DUMP(ROWID,1016)
------------------ ----------------------------------------
AAASAsAAFAAAACDAAA Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,0 --> [00000000 000000001 00100000 00101100] [00000001 01][000000 00000000 10000011] [00000000 00000000]
73772 5 131 0
AAASAsAAFAAAACDAAB Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,1
AAASAsAAFAAAACDAAC Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,2
AAASAsAAFAAAACDAAD Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,3
AAASAsAAFAAAACDAAE Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,4
AAASAsAAFAAAACDAAF Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,5
AAASAsAAFAAAACDAAG Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,6
AAASAsAAFAAAACDAAH Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,7
AAASAsAAFAAAACDAAI Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,8
AAASAsAAFAAAACDAAJ Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,9
AAASAsAAFAAAACDAAK Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,a
AAASAsAAFAAAACDAAL Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,b
AAASAsAAFAAAACDAAM Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,c
AAASAsAAFAAAACDAAN Typ=69 Len=10: 0,1,20,2c,1,40,0,83,0,d
14 rows selected.
1.2、dump 數據塊
方法一
cy@orcl> alter system dump datafile 5 block 131;
System altered.
cy@orcl> select * from v$diag_info;
INST_ID NAME
---------- --------------------------------------------------
VALUE
0
1 Default Trace File
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_84806.trc
0
12 rows selected.
cy@orcl> select file_id,file_name,bytes from dba_data_files;
FILE_ID FILE_NAME BYTES
1 /u01/app/oracle/oradata/ORCL/system01.dbf 4257218560
3 /u01/app/oracle/oradata/ORCL/sysaux01.dbf 671088640
4 /u01/app/oracle/oradata/ORCL/undotbs01.dbf 3795845120
7 /u01/app/oracle/oradata/ORCL/users01.dbf 5242880
5 /u01/app/oracle/oradata/ORCL/t1.dbf 10485760
方法2：
[oracle@19c01:/home/oracle/bbed]$dd if=/u01/app/oracle/oradata/ORCL/t1.dbf bs=8k skip=130 count=1 |od -xv >file.out
3+0 records in
3+0 records out
24576 bytes (25 kB) copied, 6.2261e-05 s, 395 MB/s
dd命令是從磁盤讀取數據，所以dump前需要做一個checkpoint。
二、數據塊結構
2.1、結構
BBED> set dba 5,131
DBA 0x01400083 (20971651 5,131)
BBED> map /v
File: /u01/app/oracle/oradata/ORCL/t1.dbf (5)
Block: 131 Dba:0x01400083
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 --類型
ub1 frmt_kcbh @1
ub2 wrp2_kcbh @2
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
BBED> p kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0x06 --數據塊
ub1 frmt_kcbh @1 0xa2 --in Oracle8, Oracle8i and Oracle9i this is 0x02
ub2 wrp2_kcbh @2 0x0000 --未使用
ub4 rdba_kcbh @4 0x01400083 --relative data block address -->01400083-->[0001010000][000000000010000011]-->131
ub4 bas_kcbh @8 0x02b73cbc --SCN base -->45563068
ub2 wrp_kcbh @12 0x0000 --SCN wrap
ub1 seq_kcbh @14 0x02 --seq#，對于同一個SCN，每次對數據塊的改變而增加，這玩意就站1位，最大也就255
ub1 flg_kcbh @15 0x04 (KCBHFCKV) --flag 0x01 新數據塊 0x02 延遲logging 0x04 check value 0x08 臨時數據塊
ub2 chkval_kcbh @16 0xc874 --塊校驗
ub2 spare3_kcbh @18 0x0000 --未使用
結構說明
type:
01：undo 段頭
02：undo 數據塊
03：保留的undo 頭
04：保留的undo 數據塊
05：數據段頭 (temp，index，data 等等)
06：KTB managed data block (with ITL)
07: 臨時表的數據塊(沒有 ITL)
08: sort key
09: sort run
10: 段自由列表
11: 數據文件頭
flag：
#define KCBHFNEW 0x01 /* new block - zeroed data area */
#define KCBHFDLC 0x02 /* Delayed Logging Change advance SCN/seq */
#define KCBHFCKV 0x04 /* ChecK Value saved-block xor's to zero */
#define KCBHFTMP 0x08 /* Temporary block */
seq_kcbh:如果在同一SCN上有254個更改，則在塊的下一個更改上強制新的SCN分配。255表示壞塊
BBED> set offset 8
OFFSET 8
BBED> d
File: /u01/app/oracle/oradata/ORCL/t1.dbf (5)
Block: 131 Offsets: 8 to 519 Dba:0x01400083
------------------------------------------------------------------------
bc3cb702 00000204 74c80000 01000000 2c200100 ba3cb702 00800000 03003200
bas_kcbh：0x02b73cbc
0x02b73cbc + 0x06 + 0x02-->3cbc0602
2.2、塊結構：
Start dump data blocks tsn: 6 file#:5 minblk 131 maxblk 131
Block dump from cache:
Dump of buffer cache at level 3 for pdb=0 tsn=6 rdba=20971651
BH (0x8e3e5f50) file#: 5 rdba: 0x01400083 (5/131) class: 1 ba: 0x8e1c8000
set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,19
dbwrid: 0 obj: 73772 objn: 73772 tsn: [0/6] afn: 5 hint: f
hash: [0x8ffebfa0,0x6f207238] lru: [0x8e3e5ed0,0x8efeb060]
ckptq: [NULL] fileq: [NULL]
objq: [0x8efeb088,0x65181510] objaq: [0x8efeb098,0x65181500]
st: XCURRENT md: NULL fpin: 'kdswh11: kdst_fetch' fscn: 0x2b73d04 tch: 1
flags: only_sequential_access
LRBA: [0x0.0.0] LSCN: [0x0] HSCN: [0x0] HSUB: [65535]
Printing buffer operation history (latest change first):
cnt: 6
buffer tsn: 6 rdba: 0x01400083 (5/131)
scn: 0x2b73cbc seq: 0x02 flg: 0x04 tail: 0x3cbc0602
frmt: 0x02 chkval: 0xc874 type: 0x06=trans data
說明
Rdba: 相對塊地址 20971651(這是十進制) -->[000101][0000000000000010000011]--> 5 131
Scn: SCN號 0x2b73cbc(這是16進制) -->45563068
Seq: Sequence number:0x02 每次對數據塊的改變而增加，這玩意就站1位，最大也就255，如果在同一SCN上有254個更改，則有必要在塊的下一個更改上強制新的SCN分配。
SEQ -> 0 /* non-logged changes - do not advance seq# */
SEQ -> (UB1MAXVAL-1)/* maximum possible sequence number */ 2^8-1=254
SEQ -> (UB1MAXVAL) /* seq# to indicate a block is corrupt,equal to FF*/ 塊錯誤，標記為255
Flg: Flag (defined in kcbh.h)
Tail: 一致性數據，用于驗證塊的開頭和結尾是否一致相同版本（由SCNBase的低位兩個字節加上塊類型加上SCN序列號組成
Frmt: 8i以前是2，現在變a2
Chkval: DB_BLOCK_CHECKSUM = TRUE的時候用
Type: 塊類型(data, index, kcb.h中定義) 偏移20，不是偏移0那個
3.3、塊頭：
Block header dump: 0x01400083
Object id on Block? Y
seg/obj: 0x1202c csc: 0x0000000002b73cba itc: 3 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1400080 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000000002b73cba
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
Seg/Obj: Seg/Obj ID 0x1202c-->73772 下文 偏移量24
Csc: 最后一次區塊清理時的SCN 偏移28
Itc: itl槽數量 偏移36
Flg: 0 = on the freelist（空閑列表） E:指用的是ASSM(自動段空間管理)
Typ: 1 = DATA; 2 = INDEX
Fsl: ITL TX freelist slot
Fnx: 空閑列表下一個塊，串一串
Itl: Interested transaction list index (ITLs determined by INITRANS and MAXTRANS)
Xid: 由und的段號+undo的槽號+undo槽號的覆蓋次數三部分組成
Uba: Undo address (UndoDBA.SeqNo.RecordNo) undo塊地址+seq+記錄號
Flg: C = Committed; U = Commit Upper Bound; T = Active at CSC;B = Rollback of this UBA gives before image of the ITL.
Lck: 當前事務影響行數
Scn/Fsc: Scn = SCN of commited TX; Fsc = Free space credit (bytes)
BBED> p ktbbh
struct ktbbh, 96 bytes @20
ub1 ktbbhtyp @20 0x01 (KDDBTDATA)
union ktbbhsid, 4 bytes @24
ub4 ktbbhsg1 @24 0x0001202c
ub4 ktbbhod1 @24 0x0001202c
struct ktbbhcsc, 8 bytes @28
ub4 kscnbas @28 0x02b73cba
ub2 kscnwrp @32 0x8000
ub2 kscnwrp2 @34 0x0000
sb2 ktbbhict @36 3
ub1 ktbbhflg @38 0x32 (NONE)
ub1 ktbbhfsl @39 0x00
ub4 ktbbhfnx @40 0x01400080
struct ktbbhitl[0], 24 bytes @44
struct ktbitxid, 8 bytes @44
ub2 kxidusn @44 0xffff
ub2 kxidslt @46 0x0000
ub4 kxidsqn @48 0x00000000
struct ktbituba, 8 bytes @52
ub4 kubadba @52 0x00000000
ub2 kubaseq @56 0x0000
ub1 kubarec @58 0x00
ub2 ktbitflg @60 0x8000 (KTBFCOM)
union _ktbitun, 2 bytes @62
sb2 _ktbitfsc @62 -32768
ub2 _ktbitwrp @62 0x8000
ub4 ktbitbas @64 0x02b73cba
struct ktbbhitl[1], 24 bytes @68
struct ktbitxid, 8 bytes @68
ub2 kxidusn @68 0x0000
ub2 kxidslt @70 0x0000
ub4 kxidsqn @72 0x00000000
struct ktbituba, 8 bytes @76
ub4 kubadba @76 0x00000000
ub2 kubaseq @80 0x0000
ub1 kubarec @82 0x00
ub2 ktbitflg @84 0x0000 (NONE)
union _ktbitun, 2 bytes @86
sb2 _ktbitfsc @86 0
ub2 _ktbitwrp @86 0x0000
ub4 ktbitbas @88 0x00000000
struct ktbbhitl[2], 24 bytes @92
struct ktbitxid, 8 bytes @92
ub2 kxidusn @92 0x0000
ub2 kxidslt @94 0x0000
ub4 kxidsqn @96 0x00000000
struct ktbituba, 8 bytes @100
ub4 kubadba @100 0x00000000
ub2 kubaseq @104 0x0000
ub1 kubarec @106 0x00
ub2 ktbitflg @108 0x0000 (NONE)
union _ktbitun, 2 bytes @110
sb2 _ktbitfsc @110 0
ub2 _ktbitwrp @110 0x0000
ub4 ktbitbas @112 0x00000000
3.4、用戶數據頭
data_block_dump,data header at 0x8e1c807c
===============
tsiz: 0x1f80
hsiz: 0x2e
pbl: 0x8e1c807c
76543210
flag=--------
ntab=1
nrow=14
frre=-1
fsbo=0x2e
fseo=0x1d49
avsp=0x1d1b
tosp=0x1d1b
0xe:pti[0] nrow=14 offs=0
0x12:pri[0] offs=0x1f5a
0x14:pri[1] offs=0x1f2f
0x16:pri[2] offs=0x1f04
0x18:pri[3] offs=0x1edb
0x1a:pri[4] offs=0x1eae
0x1c:pri[5] offs=0x1e85
0x1e:pri[6] offs=0x1e5c
0x20:pri[7] offs=0x1e34
0x22:pri[8] offs=0x1e0e
0x24:pri[9] offs=0x1de3
0x26:pri[10] offs=0x1dbd
0x28:pri[11] offs=0x1d97
0x2a:pri[12] offs=0x1d70
0x2c:pri[13] offs=0x1d49
Tsiz: Total data area size 0x1f80-->8064不到8192
Hsiz: Data header size 0x2e -->46
Pbl: Pointer to buffer holding the block --這是說在內存的地址吧
Bdba: Block relative data block address (RDBA)
Flag: N = pctfree hit(clusters); F = do not put on free list; K = flushable cluster keys
Ntab: Number of tables (>1 in clusters)
Nrow: Number of ROWS
Frre: First free row index entry; -1 = you have to add one 第一個自由行索引條目
Fsbo: Free space begin offset 2e
Fseo: Free space end offset 1d49 這兩句意思是說可以從偏移量1d49寫到2e,倒著存你不能倒著說么
Avsp: Available space in the block 還有7451可以用
Tosp: Total available space when all TXs commit 事務槽空閑出來還能寫多少
Nrow: Number of rows for first table
BBED> p kdbh
struct kdbh, 14 bytes @124
ub1 kdbhflag @124 0x00 (NONE)
sb1 kdbhntab @125 1
sb2 kdbhnrow @126 14
sb2 kdbhfrre @128 -1
sb2 kdbhfsbo @130 46
sb2 kdbhfseo @132 7497
sb2 kdbhavsp @134 7451
sb2 kdbhtosp @136 7451
3.5、數據行
block_row_dump:
tab 0, row 0, @0x1f5a -->8026
tl: 38 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4a 46
col 1: [ 5] 53 4d 49 54 48
col 2: [ 5] 43 4c 45 52 4b
col 3: [ 3] c2 50 03
col 4: [ 7] 77 b5 02 16 01 01 01
col 5: [ 2] c2 09
col 6: *NULL*
col 7: [ 2] c1 15
tab 0, row 1, @0x1f2f -->7983
tl: 43 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4b 64
col 1: [ 5] 41 4c 4c 45 4e
col 2: [ 8] 53 41 4c 45 53 4d 41 4e
col 3: [ 3] c2 4d 63
col 4: [ 7] 77 b5 02 14 01 01 01
col 5: [ 2] c2 11
col 6: [ 2] c2 04
col 7: [ 2] c1 1f
Tab: Table, row, offset
Lb: Lock byte: ITL entry that has this row locked
Cc: Number of columns in this ROW piece
Fb: Flag byte H = head of row piece; K = Cluster key; C = Cluster table member; D = Deleted row;F = First data piece; L = last data piece; P = First column continues from previous
piece; N = Last column continues in next piece
Tl: Row size (number of bytes plus data)
Col: Column data
BBED> p kdbr
sb2 kdbr[0] @142 8026
sb2 kdbr[1] @144 7983
sb2 kdbr[2] @146 7940
sb2 kdbr[3] @148 7899
sb2 kdbr[4] @150 7854
sb2 kdbr[5] @152 7813
sb2 kdbr[6] @154 7772
sb2 kdbr[7] @156 7732
sb2 kdbr[8] @158 7694
sb2 kdbr[9] @160 7651
sb2 kdbr[10] @162 7613
sb2 kdbr[11] @164 7575
sb2 kdbr[12] @166 7536
sb2 kdbr[13] @168 7497
BBED> p *kdbr[0]
rowdata[529]
------------
ub1 rowdata[529] @8150 0x2c
BBED> x /rnccntnnn
rowdata[529] @8150
------------
flag@8150: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8151: 0x00
cols@8152: 8
col 0[3] @8153: 7369
col 1[5] @8157: SMITH
col 2[5] @8163: CLERK
col 3[3] @8169: 7902
col 4[7] @8173: 1981-02-22 00:00:00
col 5[2] @8181: 800
col 6[0] @8184: *NULL*
col 7[2] @8185: 20
BBED> x /r
rowdata[529] @8150
------------
flag@8150: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8151: 0x00
cols@8152: 8
col 0[3] @8153: 0xc2 0x4a 0x46
col 1[5] @8157: 0x53 0x4d 0x49 0x54 0x48
col 2[5] @8163: 0x43 0x4c 0x45 0x52 0x4b
col 3[3] @8169: 0xc2 0x50 0x03
col 4[7] @8173: 0x77 0xb5 0x02 0x16 0x01 0x01 0x01
col 5[2] @8181: 0xc2 0x09
col 6[0] @8184: *NULL*
col 7[2] @8185: 0xc1 0x15
3.6、ASCII對照表
20 , 2c 8 38 D 44 P 50 \ 5c h 68 t 74
! 21 - 2d 9 39 E 45 Q 51 ] 5d i 69 u 75
" 22 . 2e : 3a F 46 R 52 ^ 5e j 6a v 76
# 23 / 2f ; 3b G 47 S 53 _ 5f k 6b w 77
$ 24 0 30 < 3c H 48 T 54 ` 60 l 6c x 78
% 25 1 31 = 3d I 49 U 55 a 61 m 6d y 79
& 26 2 32 > 3e J 4a V 56 b 62 n 6e z 7a
' 27 3 33 ? 3f K 4b W 57 c 63 o 6f { 7b
( 28 4 34 @ 40 L 4c X 58 d 64 p 70 | 7c
) 29 5 35 A 41 M 4d Y 59 e 65 q 71 } 7d
* 2a 6 36 B 42 N 4e Z 5a f 66 r 72 ~ 7e
+ 2b 7 37 C 43 O 4f [ 5b g 67 s 73 ^? 7f
三、關于塊損壞
3.1、塊檢查
? 1、與硬盤做交互的時候需要做一致性檢查，檢查塊版本、dba地址
? 2、一致性檢查如下項：
- 塊頭SCNBase 和seq --bas_kcbh偏移量8，seq_kcbh偏移量14
- 塊尾SCNBase和seq --tailchk 偏移量8188 由SCNBase的低位兩個字節加上塊類型加上SCN序列號組成
- 塊類型 --偏移0就是
Tail: Consistency data used to verify that the beginning and the end of the block are
of the same version (Consists of lower order two bytes of SCNBase plus block Type plus SCN Seq number.)
SCNBase type seq
0x2b73cbc 0x06 0x02 --> 0x3cbc0602
案例：
ORA-600 (4519): Cache layer block type is incorrect
ORA-600 (4136): Check rollback segment block
ORA-600 (4154): Check rollback segment block
3.2、壞塊類型：
介質壞塊：從磁盤讀取的無意義數據
軟壞塊：數據庫系統檢測到不一致后標記為壞塊
seq的最大值為UB1MAXVAL-1（FF-1=255-1=254），因此當為FF就表示為軟壞塊。
3.3、ORA-1578
發現壞塊的時候報出，報出的時候指出文件號和塊號。
通常，ORA-1578錯誤是硬件問題造成的。如果ORA-1578錯誤總是返回相同的參數，則很可能是物理損壞的塊。
如果參數每次都發生變化，則可能存在硬件問題，應檢查內存和頁面空間，并檢查I/O子系統是否存在壞控制器。
獲得十進制塊號后，可以使用UNIX dd命令嘗試從磁盤轉儲塊。如果出現讀取錯誤，這是硬件故障。此外，可以嘗試轉儲該塊幾次，看看是否總能獲得相同的數據。是對I/O子系統或壞控制器的檢查。
3.4損壞的表中提取數據
(1) 使用可以跳過損壞塊的特殊事件。這是迄今為止提取表數據的最簡單的辦法
(2) 使用 ROWID 范圍掃描圍繞損壞的塊進行選擇
(3) 有各種打撈程序/PLSQL 腳本
3.5、ORA-600
-
ORA-600[3374],[a],[b],[c],[d]
寫磁盤的時候檢查出錯誤，在內存損壞，檢查dba,type,version和inc#
-
ORA-600[kcbzpb_1],[d],[kind],[chk]
當塊在內存中損壞時發出信號。唯一導致的原因是內存中的存儲破壞了頭部或尾部。
- kcbzpb_1: 命名內部錯誤，引用源代碼模塊名稱
- d : 塊號
- kind : 損壞類型
- chk : 校驗和標志
-
The ORA-600[3339] error comes with ORA-1578 and means either disk corruption or in-memory corruption after read.
3.6、如何處理：
檢查alert日志和主機日志。使用診斷工具確定損壞類型。使用pacth查看什么問題。多檢查幾次確定是否依舊損壞。恢復數據。
始終嘗試找出錯誤是否是永久性的。多次運行analyze命令，或者在可能的情況下執行關機和啟動，然后重試以執行先前失敗的操作。
找出是否還有更多的損壞。如果遇到一個，可能還有其他損壞的塊。為此，使用DBVERIFY等工具。在嘗試恢復數據之前，請執行塊轉儲作為證據，以確定損壞的實際原因。使用UNIX dd和od-x對壞塊進行十六進制轉儲。
考慮執行重做日志轉儲以檢查對塊所做的所有更改，以便您可以發現何時發生損壞。
注意：請記住，當遇到塊損壞時，建議在驗證硬件后執行介質恢復。
可能出現多種類型的硬件故障：
-
I/O硬件或固件錯誤
-
操作系統I/O或緩存問題
-
內存或分頁問題
-
磁盤修復實用程序
3.7、DBVERIFY
只能檢查數據文件，不能檢查redo。檢查塊一致性。數據庫運行時不應使用DBVERIFY，因為緩存中的塊可能會重新損壞。
Block Checking: DBA = 29360495, Block Type = KTB-managed data block
data header at 0x7f8c98f4c064
kdbchk: the amount of space used is not equal to block size
used=613 fsc=41 avsp=7475 dtu=8129 dtl=8088 (s3=0, typ=6)
Page 367 failed with check code 6110
DBVERIFY - Verification complete
Total Pages Examined : 640
Total Pages Processed (Data) : 75
Total Pages Failing (Data) : 1
Total Pages Processed (Index): 17
Total Pages Failing (Index): 0
Total Pages Processed (Other): 479
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 69
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 2275467 (0.2275467)
Influx：半一致狀態，會重新檢查，表示一開始檢查head和tail不一致，后面一致。因為dbwr正在處理。如果還不一致則是壞塊。
DBVERIFY僅檢查邏輯損壞；也就是說，它使用kcb.h僅檢查header/footer信息。因此，在高水位線以上可能發生損壞。
3.8、Analyze命令
- 做邏輯塊檢查
- 不標記軟損壞，只是報告
- 表示里面有數據或索引
- 對于分區表，Oracle服務器還驗證該行是否屬于正確的分區。如果行未正確排序，則將rowid插入到invalid_rows表中。
SQL> analyze table xxx validate structure cascade;
SQL> analyze index xxx validate structure;
SQL> analyze cluster xxx validate structure;
SQL> analyze table xxx partition (p1) validate structure into invalid_rows;
一個簡單的select語句（select*from
）執行全表掃描，這意味著它讀取所有數據塊，直到表的高水位線。可以使用它來快速檢查當前表數據中的損壞情況。
3.8、診斷事件
event = "10231 trace name context forever, level 10" 全表掃描跳過壞塊
event = "10233 trace name context forever, level 10" 索引范圍掃描跳過損壞的數據或索引塊
event = "10232 trace name context forever, level 10" dump壞塊到trace文件
event = "10210 trace name context forever, level 10" 強制表數據塊邏輯塊檢查，檢查出后標記為軟壞塊
event = "10211 trace name context forever, level 10" 強制索引塊邏輯塊檢查，檢查出后標記為軟壞塊
event = "10212 trace name context forever, level 10" 強制聚簇塊邏輯塊檢查，檢查出后標記為軟壞塊
event = "xxx trace name context forever, level 10"
這三個事件允許潛在的損壞一出現就被發現，并發出錯誤信號；
但是，性能會受到影響，因為檢查塊時會復制這些塊。請注意，所有未通過驗證檢查的塊都立即標記為“軟損壞”，這意味著塊中的數據丟失
這些事件在資源方面是昂貴的；確保在不需要時將其關閉。事件10231和事件10233僅跳過軟損壞塊。
3.9、db_block_checking
可以會話級或者系統級，替代10210、10211、10212，默認false
db_block_checking的設置覆蓋事件10210、10211和10212的任何設置。
如果db_block_checksum設置為true，則DBWn和直接計算校驗和，并在將其寫入磁盤時將其存儲在每個數據塊的緩存頭中。
當隨后讀取塊時，將重新計算校驗和，并使用該計算值檢查存儲值
3.10、exp組件
exp可以用于檢查數據庫的邏輯一致性
執行全表掃描檢索所有數據
exp不能發現高水位以上壞塊，不能發現索引、空閑或臨時區
如果只需要檢查數據的一致性，則在執行導出時不必創建轉儲文件。在UNIX系統上，使用/dev/null作為文件名；
對于OpenVM，使用NULL:，對于Windows NT，使用NUL。執行此操作時，導出實用程序讀取所有數據，但將其寫入空設備。
這是檢查邏輯一致性和檢測物理損壞（在使用的塊中）和邏輯損壞（數據字典問題）的好方法。
exp system/manager file=/dev/null full=y
只讀取高水位以下的用戶數據，部分數據字典，那么不能檢查system表空間
3.11、介質恢復
找出包含損壞塊的絕對數據文件號，然后查詢V$DATAFILE或DBA_data_FILES以檢索文件名。
確保在恢復數據文件的備份之前解決了所有硬件問題。如果磁盤壞了，并且您在另一個磁盤上有足夠的空間，則始終可以將備份放在好的磁盤上，
將數據文件重命名到新位置，然后進行恢復。此外，恢復后，您可能需要檢查恢復的數據文件是否損壞。如果沒有熱備份，則必須返回還原完整冷備份
3.12、塊介質恢復（BMR）
rman>blockrecover datafile 5 block 132;
BMR使用現有的恢復機制將重做流中的更改應用于從適當備份恢復的塊版本。必須使用恢復管理器（RMAN）執行BMR。用于媒體恢復的現有SQL接口不支持BMR。RMAN從可用備份中恢復單個數據塊，并與Oracle server進程協調以恢復這些數據塊。如果維護了備份集存儲庫，RMAN還可以幫助選擇塊的正確備份作為介質恢復的起點。
RMAN使用BLOCKRECOVER命令支持BMR。當用戶遇到塊損壞時，錯誤消息或跟蹤文件將指示哪個塊導致問題。然后，DBA可以使用損壞的塊地址調用此命令，以僅恢復所討論的塊，從而節省大量停機時間和數據不可用性。
3.13、損壞對象
- index:刪除重建
- 回滾段：下個會話覆蓋
- 表：塊中數據丟失
- 刪除重建導入
- 設置10231跳過壞塊export，刪除重建導入
- 用sql把數據推到新建的表
3.14、確定對象名稱
select segment_name, segment_type, relative_fno from dba_extents where file_id = 5 and 2 between block_id and block_id + blocks - 1;
如果有唯一索引,hint rowid做范圍掃描
建表
create table temp as select * from tab_name where 1 = 2;
創建rowid
function rowid_create
(rowid_type IN number, object_number IN number
,relative_fno IN number, block_number IN number
,row_number IN number) return rowid;
插入數據
insert into temp select * from tab_name where rowid < DBMS_ROWID.ROWID_CREATE(1,2168,5,3,0);
insert into temp select * from tab_name where rowid > DBMS_ROWID.ROWID_CREATE(1,2168,5,1,0);
由于塊2已損壞，損壞塊之前的最后一個可能的行ID包含塊在1，而損壞塊之后的第一個行ID則包含在塊3。請使用行號0，因為您不知道塊中有多少行號
非分區表
select object_id from dba_objects where object_name='T1';
分區表
select obj# from tabpart$ where file#=5 and block#=131;
3.15、dbms_repair包
dbms_repair包可以指示但不修復塊損壞，并且可以幫助提取有意義的數據，即使該塊尚未被標記為損壞。
將塊標記為損壞后，必須跳過整個塊。
execute dbms_repair.admin_tables
(table_name => 'REPAIR_TABLE',
table_type => dbms_repair.repair_table,
action => dbms_repair.create_action);
dbms_repair.check_object (schema_name => 'SYSTEM',
object_name => 'T1',
repair_table_name => 'REPAIR_TABLE',
corrupt_count => :count);
select object_name, block_id,corrupt_type, marked_corrupt,corrupt_description, repair_description from repair_table;
使用bbed或者orapatch查看更多信息
「喜歡這篇文章，您的關注和贊賞是給作者最好的鼓勵」
【版權聲明】本文為墨天輪用戶原創內容，轉載時必須標注文章的來源（墨天輪），文章鏈接，文章作者等基本信息，否則作者和墨天輪有權追究責任。如果您發現墨天輪中有涉嫌抄襲或者侵權的內容，歡迎發送郵件至：contact@modb.pro進行舉報，并提供相關證據，一經查實，墨天輪將立刻刪除相關內容。
