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  相關內容的含義

CHANGE	Change number
TYP	Change type
CLS	Class
AFN	Absolute File Number
DBA	Relative Database Block Address
SCN	System Change Number
SEQ	Sequence Number (relative to SCN)
OP	Operation Code

 

B． 改變記錄的長度

C． 改變記錄的實際內容

 

Operation Codes

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

 

Level	Description
4	Block Cleanout
5	Transaction Layer (Undo)
10	Index Operation
11	Table Operation (DML)
13	Block Allocation
14	Extent Allocation
17	Backup Management
18	Online Backup
19	Direct Load
20	Transaction Metadata (LogMiner)
22	Space Management (ASSM)
23	Block Write (DBWR)
24	DDL Statement

 

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