理解redo(6)日志却的流程和直接路径加载的REDO分析

当server process得到redo allocation latch进行redo log buffer分配之前,需要先嗅一下redo log file是否有足够的空间。倘若空间不足,则sp会发送switch log file的请求,然后坐等log file switch completion事件的完成了。

日志却请求发出后,CKPT会进行一次增量检查点事件,而LGWR开始进行日志却换工作。

具体流程如下:

1)LGWR进程会通过控制文件中的双向链表,查找到一个可用的REDO LOG文件,作为新的CURRENT REDO LOG。
算法如下:

日志文件是inactive,并且已经归档了
优先使用unused日志文件组

2)将redo log buffer中还未写入的redo entries flush到current online redo log file,并且将最后一条redo entries的SCN作为本日志文件的high SCN记录在redo log header里面,然后关闭current online redo log file。

3)进行第二次控制文件事务,将刚刚关闭的REDO LOG标识为ACTIVE(这是个增量检查点事件,之所以标识为active,是因为它所保护的dirty buffer可能还未写到数据文件,如果已经全部写到磁盘了,则可以标识为inactive)将新的当前REDO LOG标识为CURRENT,如果数据库处于归档模式,还要将老的日志组记录到控制文件归档列表记录中,并且通知ARCn对该日志文件进行归档。

4)LGWR打开新的日志组的所有成员,在日志文件头记录当前日志sequence#和第一个redo block 的SCN(LOW SCN)

5)LGWR修改SGA中的标志位,允许生成新的REDO LOG信息

综上所述,日志切换是一种较为昂贵的操作。因为在却换期间,对数据库所有的交易都将被阻塞。但是加大REDO LOG文件大小和丢失数据的多少是无关的。理由:

1)redo entries是顺序写入的,写入一个和写入多个,对于恢复而言是一样的
2)存储故障,受影响的肯定是所有的REDO LOG文件

ARCHIVE模式下,直接路径加载会记录REDO。在非ARCHIVE LOG 模式下,直接路径加载这个动作不会记录REDO,但是ORACLE由于系统改动需要维护段、区、表空间等而会产生REDO的。

下面将redo log file给dump出来

09:29:36 sys@ORCL (^ω^) conn hr/hr
已连接。
09:34:57 hr@ORCL (^ω^) create table test as select * from dba_objects where 1=2;

表已创建。

09:35:41 hr@ORCL (^ω^) select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 2804230

09:36:06 hr@ORCL (^ω^) select group#,status from v$log;

    GROUP# STATUS
---------- --------------------------------
         1 CURRENT
         2 INACTIVE
         3 INACTIVE

09:36:26 hr@ORCL (^ω^) col member for a72
09:36:36 hr@ORCL (^ω^) select group#,member from v$logfile;

    GROUP# MEMBER
---------- ------------------------------------------------------------------------
         3 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_3_7TQZWZOY_.LOG
         3 D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_3_7TQZ
           X11D_.LOG

         2 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_2_7TQZWXO2_.LOG
         2 D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_2_7TQZ
           WYPH_.LOG

         1 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_1_7TQZWVDD_.LOG
         1 D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_1_7TQZ
           WWJ8_.LOG


已选择6行。
09:37:24 hr@ORCL (^ω^) select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 2804353

09:37:59 hr@ORCL (^ω^) insert /*+append*/ into test select * from dba_objects;

已创建50453行。

09:39:15 hr@ORCL (^ω^) commit;

提交完成。

09:39:21 hr@ORCL (^ω^) select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 2804521

09:39:29 hr@ORCL (^ω^) alter system dump logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_1_7TQZWVDD_.LOG'
09:40:25   2  scn min 2804353 scn max 2804521;

系统已更改。

09:40:57 hr@ORCL (^ω^) conn / as sysdba
已连接。
09:41:09 sys@ORCL (^ω^) archive log list
数据库日志模式            存档模式
自动存档             启用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     3
下一个存档日志序列   5
当前日志序列           5
09:41:19 sys@ORCL (^ω^) alter system dump logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_1_7TQZWVDD_.LOG'
09:43:23   2  scn min 2804230 scn max  2804521;

系统已更改。

09:44:03 sys@ORCL (^ω^) conn hr/hr
已连接。
09:45:58 hr@ORCL (^ω^) select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 2804801

09:46:07 hr@ORCL (^ω^) insert  /*+ APPEND */ into text select * from dba_objects;
insert  /*+ APPEND */ into text select * from dba_objects
                           *
第 1 行出现错误:
ORA-00942: 表或视图不存在


09:47:42 hr@ORCL (^ω^) insert  /*+ APPEND */ into test select * from dba_objects;

已创建50453行。

09:47:53 hr@ORCL (^ω^) commit;

提交完成。

09:47:58 hr@ORCL (^ω^) select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 2805155

09:48:10 hr@ORCL (^ω^) select group#,status from v$log;

    GROUP# STATUS
---------- --------------------------------
         1 CURRENT
         2 INACTIVE
         3 INACTIVE

09:48:50 hr@ORCL (^ω^) alter system dump logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_1_7TQZWVDD_.LOG'
09:49:32   2  scn min 2804801 scn max 2805155;


把OP号为19.1部分内容摘入如下:

REDO RECORD - Thread:1 RBA: 0x000005.00003627.019c LEN: 0x2024 VLD: 0x01
SCN: 0x0000.002ad2e0 SUBSCN:  1 08/19/2012 10:05:48
CHANGE #1 TYP:1 CLS: 1 AFN:4 DBA:0x01006015 OBJ:53846 SCN:0x0000.002ad2e0 SEQ:  1 OP:19.1
Direct Loader block redo entry
Block header dump:  0x08a90000
 Object id on Block? Y
 seg/obj: 0xd256  csc: 0x00.2ad2df  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1006009 ver: 0x01 opc: 0
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.01d.000002ae  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
 
data_block_dump,data header at 0x3bae8288
===============
tsiz: 0x1f80
hsiz: 0xc8
pbl: 0x3bae8288
bdba: 0x08a90000
     76543210
flag=--------
ntab=1
nrow=91
frre=-1
fsbo=0xc8
fseo=0x432
avsp=0x36a
tosp=0x36a
0xe:pti[0]	nrow=91	offs=0
0x12:pri[0]	offs=0x1f36
0x14:pri[1]	offs=0x1eea
0x16:pri[2]	offs=0x1ea1
0x18:pri[3]	offs=0x1e57
0x1a:pri[4]	offs=0x1e09
0x1c:pri[5]	offs=0x1dbe
0x1e:pri[6]	offs=0x1d69
0x20:pri[7]	offs=0x1d1e
0x22:pri[8]	offs=0x1cd2
0x24:pri[9]	offs=0x1c79
0x26:pri[10]	offs=0x1c2f
0x28:pri[11]	offs=0x1be6
0x2a:pri[12]	offs=0x1b93
0x2c:pri[13]	offs=0x1b47
0x2e:pri[14]	offs=0x1afc
0x30:pri[15]	offs=0x1ab1
0x32:pri[16]	offs=0x1a67
0x34:pri[17]	offs=0x1a1b
0x36:pri[18]	offs=0x19d2
0x38:pri[19]	offs=0x1989
0x3a:pri[20]	offs=0x193d
0x3c:pri[21]	offs=0x18f1
0x3e:pri[22]	offs=0x18a8
0x40:pri[23]	offs=0x185e
0x42:pri[24]	offs=0x1812
0x44:pri[25]	offs=0x17c9
0x46:pri[26]	offs=0x1779
0x48:pri[27]	offs=0x1727
0x4a:pri[28]	offs=0x16dc
0x4c:pri[29]	offs=0x1691
0x4e:pri[30]	offs=0x1646
0x50:pri[31]	offs=0x15fa
0x52:pri[32]	offs=0x15b2
0x54:pri[33]	offs=0x155d
0x56:pri[34]	offs=0x150f
0x58:pri[35]	offs=0x14c3
0x5a:pri[36]	offs=0x1474
0x5c:pri[37]	offs=0x142b
0x5e:pri[38]	offs=0x13e0
0x60:pri[39]	offs=0x1396
0x62:pri[40]	offs=0x134c
0x64:pri[41]	offs=0x1301
0x66:pri[42]	offs=0x12b5
0x68:pri[43]	offs=0x126c
0x6a:pri[44]	offs=0x1221
0x6c:pri[45]	offs=0x11d4
0x6e:pri[46]	offs=0x118b
0x70:pri[47]	offs=0x1141
0x72:pri[48]	offs=0x10f5
0x74:pri[49]	offs=0x10a9
0x76:pri[50]	offs=0x105d
0x78:pri[51]	offs=0x1011
0x7a:pri[52]	offs=0xfc6
0x7c:pri[53]	offs=0xf7a
0x7e:pri[54]	offs=0xf21
0x80:pri[55]	offs=0xed4
0x82:pri[56]	offs=0xe88
0x84:pri[57]	offs=0xe3a
0x86:pri[58]	offs=0xdec
0x88:pri[59]	offs=0xda3
0x8a:pri[60]	offs=0xd5a
0x8c:pri[61]	offs=0xd10
0x8e:pri[62]	offs=0xcc0
0x90:pri[63]	offs=0xc72
0x92:pri[64]	offs=0xc22
0x94:pri[65]	offs=0xbd2
0x96:pri[66]	offs=0xb89
0x98:pri[67]	offs=0xb3a
0x9a:pri[68]	offs=0xae7
0x9c:pri[69]	offs=0xa99
0x9e:pri[70]	offs=0xa4d
0xa0:pri[71]	offs=0xa00
0xa2:pri[72]	offs=0x9b2
0xa4:pri[73]	offs=0x965
0xa6:pri[74]	offs=0x918
0xa8:pri[75]	offs=0x8cf
0xaa:pri[76]	offs=0x882
0xac:pri[77]	offs=0x837
0xae:pri[78]	offs=0x7e9
0xb0:pri[79]	offs=0x79c
0xb2:pri[80]	offs=0x74c
0xb4:pri[81]	offs=0x6fa
0xb6:pri[82]	offs=0x6a8
0xb8:pri[83]	offs=0x656
0xba:pri[84]	offs=0x604
0xbc:pri[85]	offs=0x5b7
0xbe:pri[86]	offs=0x56a
0xc0:pri[87]	offs=0x51d
0xc2:pri[88]	offs=0x4d0
0xc4:pri[89]	offs=0x482
0xc6:pri[90]	offs=0x432
block_row_dump:
tab 0, row 0, @0x1f36
tl: 74 fb: --H-FL-- lb: 0x0  cc: 13
col  0: [ 3]  53 59 53
col  1: [ 5]  49 43 4f 4c 24
col  2: *NULL*
col  3: [ 2]  c1 15
col  4: [ 2]  c1 03
col  5: [ 5]  54 41 42 4c 45
col  6: [ 7]  78 69 08 1e 0e 33 19
col  7: [ 7]  78 69 08 1e 0f 1b 13
col  8: [19]  32 30 30 35 2d 30 38 2d 33 30 3a 31 33 3a 35 30 3a 32 34
col  9: [ 5]  56 41 4c 49 44
col 10: [ 1]  4e
col 11: [ 1]  4e
col 12: [ 1]  4e
tab 0, row 1, @0x1eea
tl: 76 fb: --H-FL-- lb: 0x0  cc: 13
col  0: [ 3]  53 59 53
col  1: [ 7]  49 5f 55 53 45 52 31
col  2: *NULL*
col  3: [ 2]  c1 2d
col  4: [ 2]  c1 2d
col  5: [ 5]  49 4e 44 45 58
col  6: [ 7]  78 69 08 1e 0e 33 1a
col  7: [ 7]  78 69 08 1e 0e 33 1a
col  8: [19]  32 30 30 35 2d 30 38 2d 33 30 3a 31 33 3a 35 30 3a 32 35
col  9: [ 5]  56 41 4c 49 44
col 10: [ 1]  4e
col 11: [ 1]  4e


直接路径加载只经过PGA,不过SGA,且数据是在HWM之上的。从上面的trc文件,可知:在归档模式下,DIRECT PATH LOAD时是将整个数据块放入REDO LOG中,从而既大幅度的减少了REDO 的产生量,又保证了不会丢失数据。

下面附一张nologging和logging下不同操作所产生的redo entries的对比:

理解redo(6)日志却的流程和直接路径加载的REDO分析_第1张图片

你可能感兴趣的:(redo)