当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的对比:
分享到:
相关推荐
本文将详细介绍如何在Oracle 9i环境下更改日志文件(redo log files)的路径。 #### 步骤详解 1. **关闭数据库** - 首先需要确保数据库处于关闭状态,以便进行后续操作。 - 使用`shutdown immediate`命令来立即...
MySQL中的日志系统是数据库管理和优化的关键组成部分,它提供了对数据库操作的跟踪和记录,有助于诊断问题、审计和性能分析。下面将详细讨论MySQL中重要的日志类型。 首先,我们来看错误日志(Error Log)。错误...
在Oracle数据库系统中,控制文件(CONTROL FILE)和日志文件(REDO LOG FILE)是极其重要的组件,它们对于数据库的稳定运行和数据安全性起到关键作用。本文将深入讲解如何修改Oracle控制文件和日志文件,确保数据库...
SQL*Loader默认使用直接路径加载,这种模式下,数据直接写入数据文件,跳过了Redo日志,从而提高了导入速度。但要注意,这可能导致并发问题,因为在直接路径加载期间,表可能不可用于其他用户。 8. **使用游标加载...
1. 工作原理:直接路径插入避免了传统的缓冲区高速缓存,减少了I/O操作和redo日志的生成,适用于大批量的数据加载和重装。 2. 适用场景:数据仓库加载、数据迁移、初始化大表等。 3. 注意事项:直接路径插入可能会...
- **文件路径**:指定了日志文件和数据字典文件的存储路径。 #### 5. SyncTask.java分析 - **核心功能**: - `createDictionary()` 方法:用于创建数据字典文件,这是Logminer解析日志文件前的必要步骤。 - `...
数据的加载可以通过各种手段,如直接路径插入或使用SQL*Loader进行大量数据导入。Export和Import工具则用于数据的迁移和备份恢复。用户和权限的管理涉及到用户账户的创建、权限分配和角色的设置,以确保数据安全和...
Oracle数据库的物理存储结构是其高效运行的基础,它由数据文件、控制文件和重做日志文件这三种关键组件组成,这些组件共同确保了数据的可靠性和系统的稳定性。 1. 数据文件 (Data Files, *.dbf) 数据文件是Oracle...
而expdp和impdp是新版本Oracle中的数据泵工具,提供了更高效、更灵活的数据导入导出功能,支持并行执行和直接路径加载,适用于大规模数据的备份和迁移。 Oracle的恢复策略主要包括实例恢复和介质恢复。实例恢复是当...
本文将深入探讨Oracle数据库中与日志管理和表空间管理相关的常用命令,帮助DBA和数据库管理员们更好地理解和应用这些核心功能。 ### 一、日志管理 #### 1. 强制切换日志 在Oracle中,为了确保数据的一致性和完整...
逻辑备份的优势在于灵活性,但恢复速度相对较慢,且不能备份数据库的控制文件和Redo日志。 1. 导出/导入备份 导出(Export)允许将数据和对象从数据库中导出到一个二进制文件(.dmp文件)。导出可以按照表、用户或...
通过指定不同的磁盘路径可以提高日志文件的可靠性和性能。每个日志组至少包含两个成员,以实现冗余。 ##### 4. 添加在线重做日志成员(Adding Online Redo Log Members) ```sql ALTER DATABASE ADD LOGFILE MEMBER...
理解这些操作的流程和最佳实践对于保持数据库的高效运行至关重要。 通过这个手把手教程,你将能够独立完成Oracle 10g数据库实例的创建,并具备基本的数据库管理能力。请确保仔细阅读文档,理解每个步骤,并在实际...
6. **修改日志和TMP文件路径**:由于可能的路径差异,需要在sqlplus环境下更新redo log文件和临时文件(TMP)的路径,以适应新环境。 7. **数据库RECOVER**:执行RECOVER命令,让数据库自动应用归档日志,以达到...
- redolog的管理(添加、删除日志组和成员)。 - 起停数据库,了解数据库起停的各个步骤。 - **层级:** BAND3 - 掌握alert、listner日志的位置以及阅读这些日志的关键点。 - crs资源的管理(单个资源的起停和...
控制文件、redo log文件、数据文件和临时文件应放入新服务器相应的Oracle数据和日志目录。参数文件(PFILE)应放在新数据库的PFILE路径下。 在新服务器上,启动数据库并检查所有文件是否正确加载。如果一切正常,你...
- Recover(恢复):在还原后,使用redo日志的信息来应用未提交的事务,确保数据的一致性。 2. **Oracle实例启动的三个阶段** - NOMOUNT:读取参数文件,验证文件路径。 - MOUNT:读取控制文件,准备加载数据...