对于Oracle数据库来说,REDO LOG 对于保证数据的完整性可恢复性起着关键的作用,因此对redo log的保护也是至关重要的,下面对REDO LOG相关的知识进行总结。
1. 原理概念
redo log记录了数据库操作的所有事务(除了direct load和nologging操作只产生少量的redo信息),在数据库发生故障后,对数据库的恢复主要是靠redo log的信息(archive log也是redo log,只不过是备份的而已)。因此,在理论情况下,在归档模式下,只要有有效的归档日志加上有效的在线redo log就可以确保不丢失数据来恢复数据库。
2. redo log和archive log的产生过程
当数据库发生事务时,会把信息记录在log buffer缓存里,当一定条件发生时由LGWR进程把信息从log buffer里写到当前的redo log组里,而日志组间又是循环交替写入的,即当当前日志组满了或发生了switch行为时,切换到下一个日志组,如果在归档模式下,此时ARCn归档进程就会备份刚写满的日志到归档目录里。
那么在什么情况下会发生LGWR写行为呢:
1. 每3秒一次
2. log buffer满1/3时
3. log buffer里的信息量达1M时
4. 发生checkpoint时
因此针对以上触发条件,log buffer一般设置为1~3M。
3. redo log的规划
对redo log的规划也是很讲究的,他涉及到需要考虑的问题很多:
1). 首先要保证不丢失redo log。因此,一个组需要建立多个成员,并镜像到不同的磁盘驱动器上。其实镜像的目的不光是保证redo log不被丢失,还平衡了I/O。
2). 由于redo log写操作非常平凡。因此最好把redo log放到write比较快的磁盘上(RAID 5就不行,写的性能太差),也最好和数据文件分开,可以防止I/O和等待
3). 接下来要考虑的就是log buffer的大小了,一般来说1~3M就可以了,10M以下吧。
4). 最后考虑的是等待事件问题。在归档模式下,在发生日志切换后会启动ARCn进程进行归档,为防止归档很慢,而事务很多写日志很快,导致LGWR和ARCn间的等待问题。可以多设置几个日志组,单个日志成员文件的大小也要适中,这个值一般和事务频率有关,一般来说设置3个组,每个成员100M就行了。
4. 日志切换
日志有自动切换和手工切换。自动一般是写满了才发生。手工的话可以通过以下两条命令来完成:
SQL> alter system switch logfile;
SQL> alter system archive log current;
具体两条命令的区别见:http://space.itpub.net/9466564/viewspace-610391
5. 管理redo log
SQL> select group#, status, member from v$logfile;
GROUP# MEMBER
---------- ------------
3 D:\VMWARE\ORACLE\ORADATA\ORCL\REDO03.LOG
2 D:\VMWARE\ORACLE\ORADATA\ORCL\REDO02.LOG
1 D:\VMWARE\ORACLE\ORADATA\ORCL\REDO01.LOG
SQL> select group#,sequence#,archived,status,first_change# from v$log;
GROUP# SEQUENCE# ARC STATUS FIRST_CHANGE#
---------- ---------- --- ---------------- -------------
1 16 NO CURRENT 646400
2 15 YES INACTIVE 646395
3 14 YES INACTIVE 646362
SQL> select sequence#,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
3 573951 600395
4 600395 622729
5 622729 636162
6 636162 636657
7 636657 636661
8 636661 636664
9 636664 646321
10 646321 646323
11 646323 646341
12 646341 646356
13 646356 646362
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
14 646362 646395
15 646395 646400
13 rows selected.
SQL> select sequence#,FIRST_CHANGE#,NEXT_CHANGE#,RESETLOGS_CHANGE# from v$log_history;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# RESETLOGS_CHANGE#
---------- ------------- ------------ -----------------
1 534907 568104 534907
2 568104 573951 534907
3 573951 600395 534907
4 600395 622729 534907
5 622729 636162 534907
6 636162 636657 534907
7 636657 636661 534907
8 636661 636664 534907
9 636664 646321 534907
10 646321 646323 534907
11 646323 646341 534907
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# RESETLOGS_CHANGE#
---------- ------------- ------------ -----------------
12 646341 646356 534907
13 646356 646362 534907
14 646362 646395 534907
15 646395 646400 534907
15 rows selected.
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/9466564/viewspace-620884/
,如需转载,请注明出处,否则将追究法律责任。