redo的內容

oracle透過redo來實同快速提交,一方面是因為redo log file可以連續,順序地快速寫出,另外一個方面

也和redo記錄的精簡內容有關.

為了瞭解redo的內容,先需要了解兩個概念:改變向量和重做記錄

改變向量(change vector)

改變向量表示對資料庫內某一個資料塊所做的一次變更.改變向量(change vector)中包含了變更的資料

塊的版本號,事務操作程式碼,變更從屬資料塊的地址(DBA)以及更新後的資料.例如,一個update事務包含

一系列的改變向量,對於資料塊的修改是一個向量,對於回滾段的修改又是一處向量.

重做記錄(redo record)

重做記錄通常由一組改變向量組成,是一個改變向量的集合,代表一個資料庫的變更(insert,update,delete

等操作),構成資料庫變更的最小恢復單位.例如,一個update的重做記錄包括相應的回滾段的改變向量和相應

的資料塊的改變向量等.

假定發出了一個更新語句;

update scott.emp set sal=4000 where empno=7788;

看一下這個語句是怎麼執行的

1.檢查empno=7788記錄在buffer cache中是否存在,如果不存在則讀取到buffer cache中.

2.在回滾表空間的相應回滾段事務表上分配事務槽,這個操作需要記錄redo資訊.

3.從回滾段讀入或者在buffer cache中建立sal=3000的前映象,這需要產生redo資訊並記入redo log buffer

4.修改sal=4000,這是update的資料變更,需要記入redo log buffer

5.當使用者提交時,會在redo log buffer記錄提交資訊,並在回滾段標記該事務為非啟用(Inactive)

下面透過珍上具體的試驗來再現這個過程.

1.先透過switch logfile切換日誌,使用sys使用者進行日誌切換,使得接下來的更新可以使用新的日誌.

SQL> alter system switch logfile;

System altered.

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

---------- ---------- ---------- ---------- ---------- --- ----------------

FIRST_CHANGE# FIRST_TIME

------------- ------------

1 1 14 52428800 1 NO ACTIVE

801067 03-JAN-14

2 1 15 52428800 1 NO CURRENT

813289 04-JAN-13

3 1 13 52428800 1 NO INACTIVE

764715 30-DEC-13

2.更新並提交事務

SQL> select * from scott.emp a where a.empno=7788;

EMPNO ENAME JOB MGR HIREDATE SAL COMM

---------- ---------- --------- ---------- ------------ ---------- ----------

DEPTNO

----------

7788 SCOTT ANALYST 7566 19-APR-87 3000

20

SQL> update scott.emp set sal=4000 where empno=7788;

1 row updated.

SQL> commit;

Commit complete.

3.使用sys使用者在另外的session轉儲日誌檔案:

SQL> alter system dump logfile '/u01/app/oracle/product/10.2.0/oradata/jingyong/redo02.log';

System altered.

SQL> select

2 d.value||'/'||lower(rtrim(i.instance,

3 chr(0)))||'_ora_'||p.spid||'.trc' trace_file_name

4 from ( select p.spid

5 from sys.v$mystat m,

6 sys.v$session s,sys.v$process p

7 where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p,

8 ( select t.instance from sys.v$thread t,sys.v$parameter v

9 where v.name = 'thread' and

10 (v.value = 0 or t.thread# = to_number(v.value))) i,

11 ( select value from sys.v$parameter

12 where name = 'user_dump_dest') d

13 /

TRACE_FILE_NAME

--------------------------------------------------------------------------------

/u01/app/oracle/admin/jingyong/udump/jingyong_ora_3969.trc

4.獲取trace檔案

從日誌檔案的轉儲資訊中,可以找到這個事務資訊(sid=149,serial#=930)

*** SERVICE NAME:(SYS$USERS) 2013-01-04 17:06:48.813

*** SESSION ID:(149.930) 2013-01-04 17:06:48.813

改變向量1

這是對於回滾段頭的修改,分配事務表，從絕對檔案號為2(AFN:2)可以知道這是UNDO

表空間,透過UBA的DBA換算能力找到相應的block

SQL> SELECT DBMS_UTILITY.data_block_address_file (

2 TO_NUMBER(LTRIM('0x00800099', '0x'), 'xxxxxxxx'))

3 AS file_no,

4 DBMS_UTILITY.data_block_address_block (

5 TO_NUMBER(LTRIM ('0x00800099', '0x'), 'xxxxxxxx'))

6 AS block_no

7 FROM DUAL;

FILE_NO BLOCK_NO

---------- ----------

2 153

REDO RECORD - Thread:1 RBA: 0x00000f.00000023.0010 LEN: 0x0200 VLD: 0x0d

SCN: 0x0000.000c68fd SUBSCN: 1 01/04/2013 17:04:58

CHANGE #2 TYP:0 CLS:35 AFN:2 DBA:0x00800099 OBJ:4294967295 SCN:0x0000.000c6859 SEQ: 1 OP:5.2

ktudh redo: slt: 0x0025 sqn: 0x00000137 flg: 0x0012 siz: 128 fbi: 0

uba: 0x0080106d.0102.29 pxid: 0x0000.000.00000000

CHANGE #4 TYP:0 CLS:36 AFN:2 DBA:0x0080106d OBJ:4294967295 SCN:0x0000.000c6858 SEQ: 1 OP:5.1

ktudb redo: siz: 128 spc: 2418 flg: 0x0012 seq: 0x0102 rec: 0x29

xid: 0x000a.025.00000137

ktubl redo: slt: 37 rci: 0 opc: 11.1 objn: 51148 objd: 51148 tsn: 4

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

Temp Object: No

Tablespace Undo: No

0x00000000 prev ctl uba: 0x0080106d.0102.28

prev ctl max cmt scn: 0x0000.000c61f3 prev tx cmt scn: 0x0000.000c61ff

txn start scn: 0x0000.00000000 logon user: 0 prev brb: 8392808 prev bcl: 0 KDO undo record:

KTB Redo

op: 0x03 ver: 0x01

op: Z

KDO Op code: URP row dependencies Disabled

xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x01000020 hdba: 0x0100001b

itli: 2 ispac: 0 maxfr: 4858

tabn: 0 slot: 7(0x7) flag: 0x2c lock: 0 ckix: 191

ncol: 8 nnew: 1 size: 0

Vector content:

col 5: [ 2] c2 1f

改變向量2

這裡記錄的是前映象資訊,注意到"col 5: [ 2] c2 1f記錄的就是對於col5的修改,修改前的資料值3000(c21f)

SQL> select utl_raw.cast_to_number('c21f') from dual;

UTL_RAW.CAST_TO_NUMBER('C21F')

------------------------------

3000

改變向量3

這裡記錄的是對於資料塊的修改,"col 5: [ 2] c2 29"記錄的是對於col5的修改,

修改後的值為4000(c229)

SQL> select utl_raw.cast_to_number('c229') from dual;

UTL_RAW.CAST_TO_NUMBER('C229')

------------------------------

4000

CHANGE #1 TYP:2 CLS: 1 AFN:4 DBA:0x01000020 OBJ:51148 SCN:0x0000.0006bfdb SEQ: 16 OP:11.5

KTB Redo

op: 0x11 ver: 0x01

op: F xid: 0x000a.025.00000137 uba: 0x0080106d.0102.29

Block cleanout record, scn: 0x0000.000c68f4 ver: 0x01 opt: 0x02, entries follow...

itli: 1 flg: 2 scn: 0x0000.0006bfdb

KDO Op code: URP row dependencies Disabled

xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x01000020 hdba: 0x0100001b

itli: 2 ispac: 0 maxfr: 4858

tabn: 0 slot: 7(0x7) flag: 0x2c lock: 2 ckix: 191

ncol: 8 nnew: 1 size: 0

Vector content:

col 5: [ 2] c2 29

改變向量4

當事務提交之後,記錄的scn資訊,注意這裡標記為"MEDIA RECOVERY MARKER SCN",也就是說,這是一個

可以恢復的時間點,事務的恢復必須以redo record為最小單位

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

session資訊

最前面的部分記錄的是產生這些redo的session資訊

*** 2013-01-04 17:06:48.813

*** SERVICE NAME:(SYS$USERS) 2013-01-04 17:06:48.813

*** SESSION ID:(149.930) 2013-01-04 17:06:48.813

對於redo日誌來說,重做資訊卻相當精簡,oracle只需要記錄那些重構事務必須的資訊(如事務號,檔案號,塊號,

行號,欄位等)即可,這個資料量大大減少

oracle redo檔案記錄的內容

相關文章