当向一张表中插入大量数据时,EM中发现有log_buffer_space等待事件。该等待事件是由于重做量超出日志缓冲区而产生的。
下面介绍实验环境:
1. 日志缓冲区默认大小6M。
2. 表的行宽:NUMBER(9)*1+NUMBER(1)*76=85
3. 计划一次插入1百万行。
lgwr什么时候开始空工作的,它要有触发他的动作
A. 重做日志缓冲区的已使用的空间达到三分之一时
B. 当dbwn进程向磁盘写入已修改的缓冲区的时候
C. 每隔3秒钟
D. 用户提交事务处理时的一条提交记录(经常commit会及时刷新重做日志缓冲区空间)
如果我们每50,000行提交一次,那么50,000*85>6M的1/3,因此根据上面的A,将触发LGWR把log_buffer写入redo log,这就是LOG BUFFER SPACE产生的原因!
知道了这点,我们调整为每20,000行提交一次,这样提交前将不会超过日志缓冲区的1/3。
比较一下,单次提交量和时间的区别:
结论,20,000最佳!
注意到:不是越小越好,比如10,000就比20,000花更多时间,批量提交应尽可能越多越好,但不能超过LOG BUFFER的1/3警戒线。
下面介绍实验环境:
1. 日志缓冲区默认大小6M。
2. 表的行宽:NUMBER(9)*1+NUMBER(1)*76=85
3. 计划一次插入1百万行。
lgwr什么时候开始空工作的,它要有触发他的动作
A. 重做日志缓冲区的已使用的空间达到三分之一时
B. 当dbwn进程向磁盘写入已修改的缓冲区的时候
C. 每隔3秒钟
D. 用户提交事务处理时的一条提交记录(经常commit会及时刷新重做日志缓冲区空间)
如果我们每50,000行提交一次,那么50,000*85>6M的1/3,因此根据上面的A,将触发LGWR把log_buffer写入redo log,这就是LOG BUFFER SPACE产生的原因!
知道了这点,我们调整为每20,000行提交一次,这样提交前将不会超过日志缓冲区的1/3。
比较一下,单次提交量和时间的区别:
25,000 | 00:04:37.62 |
50,000 | 00:04:50.34 |
10,000 | 00:04:40.33 |
20,000 | 00:04:35.52 |
结论,20,000最佳!
注意到:不是越小越好,比如10,000就比20,000花更多时间,批量提交应尽可能越多越好,但不能超过LOG BUFFER的1/3警戒线。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22621861/viewspace-1274302/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22621861/viewspace-1274302/