理解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的对比：
