oracle redo internal (2) --- dump內容理解

很多oracle大師對redo做了深入的研究，在此我談談自己對redo內部結構的理解 以下資料庫的版本為10.2.0.1.0 ，首先看看概念.

Redo: 記錄了資料庫的所有歷史變更，它包含資料檔案的所有變更，但不包含引數檔案和控制檔案，

其應用主要有以下四方面：

1. 例項恢復

2. 日誌挖掘

3. Oracle 的流複製

4. Oracle dataguard

以下條件能觸發LGWR 程式將redo log buffer 寫到 redo log

1. 提交的時候（commit)

2．達到1/3滿或者是超過1M

3. 每隔3秒

4. 在dbwr程式些之前

Redo Threads：

每個線上重做日誌都有一個執行緒號和一個序列號，在單例項環境中，

任何時刻只有一個執行緒號， 但是在多節點的RAC中就可能存在多個執行緒號

Redo log files：

一個日誌檔案是由一定數量的固定大小的塊組成，日誌檔案的大小是在

日誌組建立過程中指定，不同的平臺，日誌塊的大小是不同的(主要依賴

作業系統 和 oracle 版本)，在linux和Solaris 中 日誌塊的大小為 512 bytes，

在HP-U中日誌塊的大小為1024 bytes

每個日誌檔案都有一個固定的檔案頭，多數版本中此檔案頭佔2個日誌塊大小，

第一個塊為file header，第二個塊為redo header

第二個塊中記錄的資訊有：

1 資料庫名

2 程式

3 一致性版本號

4 開始時間

5 結束時間

6 開始的SCN

7 結束的SCN (end SCN 實際上是下一個日誌檔案的start SCN)

以下為一個日誌檔案的dump資訊的擷取部分，如下：

DUMP OF REDO FROM FILE '/u01/app/oracle/oradata/gabriel/redo02.log'

Opcodes *.*

RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff //第一個日誌塊

SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff

Times: creation thru eternity

FILE HEADER: // 檔案頭

Compatibility Vsn = 169869568=0xa200100 //一致性版本號

Db ID=3977367663=0xed11d06f, Db Name='GABRIEL' //資料庫名

Activation ID=3977364079=0xed11c26f

Control Seq=2178=0x882, File size=102400=0x19000 //日誌檔案大小

File Number=2, Blksiz=512, File Type=2 LOG // 日誌塊大小

descrip:"Thread 0001, Seq# 0000000051, SCN 0x0000000c2c1c-0x0000000c2cb1"

thread: 1 nab: 0x97 seq: 0x00000033 hws: 0x2 eot: 0 dis: 0

resetlogs count: 0x2c713af2 scn: 0x0000.0006ce7b (446075)

resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000

prev resetlogs count: 0x2184ef74 scn: 0x0000.00000001 (1)

prev resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000

Low scn: 0x0000.000c2c1c (797724) 06/23/2011 12:08:43

Next scn: 0x0000.000c2cb1 (797873) 06/23/2011 12:13:17

Enabled scn: 0x0000.0006ce7b (446075) 03/12/2011 20:09:22

Thread closed scn: 0x0000.000c2c1c (797724) 06/23/2011 12:08:43

Disk cksum: 0x20ba Calc cksum: 0x20ba

Terminal recovery stop scn: 0x0000.00000000

Terminal recovery 01/01/1988 00:00:00

Most recent redo scn: 0x0000.00000000

Largest LWN: 55 blocks

End-of-redo stream : No

Unprotected mode

Miscellaneous flags: 0x0

Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

REDO RECORD - Thread:1 RBA: 0x000033.00000002.0010 LEN: 0x0080 VLD: 0x06 //第一個記錄塊開始， 00000002表示第三個日誌塊

CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1

Block Written - afn: 3 rdba: 0x00c00002 BFT:(1024,12582914) non-BFT:(3,2)

scn: 0x0000.000c296a seq: 0x02 flg:0x04

Block Written - afn: 3 rdba: 0x00c00003 BFT:(1024,12582915) non-BFT:(3,3)

scn: 0x0000.000c296a seq: 0x01 flg:0x04

……………..

Redo Blocks

日誌塊由兩部分組成 16 bytes 的header 和 用來儲存redo記錄的body

REDO RECORD - Thread:1 RBA: 0x000033.00000002.01cc LEN: 0x0064 VLD: 0x02

SCN: 0x0000.000c2c1c SUBSCN: 1 06/23/2011 12:08:48

CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1

Block Written - afn: 3 rdba: 0x00c076d2 BFT:(1024,12613330) non-BFT:(3,30418)

scn: 0x0000.000c2946 seq: 0x01 flg:0x04

Block Written - afn: 3 rdba: 0x00c076d3 BFT:(1024,12613331) non-BFT:(3,30419)

scn: 0x0000.000c2946 seq: 0x01 flg:0x04

Block Written - afn: 3 rdba: 0x00c076d4 BFT:(1024,12613332) non-BFT:(3,30420)

scn: 0x0000.000c2948 seq: 0x02 flg:0x04

REDO RECORD - Thread:1 RBA: 0x000033.00000003.0040 LEN: 0x0044 VLD: 0x02

SCN: 0x0000.000c2c1c SUBSCN: 1 06/23/2011 12:08:48

CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1

Block Written - afn: 3 rdba: 0x00c00b6b BFT:(1024,12585835) non-BFT:(3,2923)

scn: 0x0000.000c2948 seq: 0x02 flg:0x06

假設RBA: 0x000033.00000002.01cc 為 record A ， RBA: 0x000033.00000003.0040 為 record

B： 則A 在第三個日誌塊的 01cc(16*16+12*16+12= 464 bytes) + LEN: 0x0064(100bytes) +0001(16bytes)(redo block header) = 580 bytes– 512bytes(redo block size)= 0040 (48bytes) 由上計算可知其第四個日誌塊剛好為0040(與record B 的起始地址吻合) 也證明了 每個日誌塊的header 為 16bytes 其實從logfile 的第三個日誌塊也能判斷出 header 為 16bytes

REDO RECORD - Thread:1 RBA: 0x000033.00000002.0010 LEN: 0x0080 VLD: 0x06 // 第三個日誌塊的offset 從0X0010(16) 開始。 呵呵

Redo record:

Redo record 是一個邏輯結構，最大上限為 65536bytes它包含一個 redo record header 和 N個Change vectors, 一個物理的redo block 包含 多個 redo records, 當然一個redo record也可以跨度多個日誌塊。關於redo record 如下：

…………..

REDO RECORD - Thread:1 RBA: 0x000033.0000008f.00c0 LEN: 0x00ec VLD: 0x01

SCN: 0x0000.000c2c99 SUBSCN: 3 06/23/2011 12:12:14

CHANGE #1 TYP:0 CLS:26 AFN:2 DBA:0x0080004f OBJ:4294967295 SCN:0x0000.000c2c99 SEQ: 1 OP:5.1

ktudb redo: siz: 104 spc: 1792 flg: 0x0022 seq: 0x013d rec: 0x32

xid: 0x0005.025.00000189

ktubu redo: slt: 37 rci: 49 opc: 10.22 objn: 239 objd: 239 tsn: 0

Undo type: Regular undo Undo type: Last buffer split: No

Tablespace Undo: No

0x00000000

index undo for leaf key operations

KTB Redo

op: 0x04 ver: 0x01

op: L itl: xid: 0x0001.024.00000118 uba: 0x00800014.00d6.1d

flg: C--- lkc: 0 scn: 0x0000.000c2c62

Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x400689 block=0x0040068a

(kdxlre): restore leaf row (clear leaf delete flags)

key :(15): 07 78 6f 06 17 0d 0d 0a 06 00 40 06 7a 00 00

CHANGE #2 TYP:0 CLS: 1 AFN:1 DBA:0x0040068a OBJ:239 SCN:0x0000.000c2c99 SEQ: 1 OP:10.4

index redo (kdxlde): delete leaf row

KTB Redo

op: 0x01 ver: 0x01

op: F xid: 0x0005.025.00000189 uba: 0x0080004f.013d.32

REDO: SINGLE / -- / --

itl: 2, sno: 0, row size 19

REDO RECORD - Thread:1 RBA: 0x000033.0000008f.01ac LEN: 0x00e4 VLD: 0x01

……………..

由上可知 此redo record 包含2個Change vectors， 由於日誌塊0000008f(8*16+15=143)包含多個redo record，後一個redo record 的偏量offset (01ac) RBA: 0x000033.0000008f.01ac 剛好等於前一個redo record RBA: 0x000033.0000008f.00c0 +LEN: 0x00ec

Change vectors：

記錄了單個資料塊的改變，包括 undo headers, undo blocks, data segment headers, data block. 一個向量包含以下三個部分：

A． 改變向量頭 eg

CHANGE #1 TYP:0 CLS:26 AFN:2 DBA:0x0080004f OBJ:4294967295 SCN:0x0000.000c2c99 SEQ: 1 OP:5.1 相關內容的含義

B． 改變記錄的長度

C． 改變記錄的實際內容

Operation Codes

每個向量都包含一個操作碼(簡稱OP) 如以上change#2 的OP 10.4 表示 delete leaf row , 隨著資料庫版本的更新，OP也在不斷的增加，OP又兩部分組成，第一部分為主碼，後面部分子碼 其主要編號的主題含義如下：

限於篇幅原因，關於詳細的 redo record header，change vector， operation code 後續會詳細介紹。上面內容純屬個人觀點，錯誤之處歡迎大師們指正， 呵呵～～～