本文探讨了在向数据库表中批量插入数据时如何优化提交策略以避免Log Buffer Space等待事件的发生。通过实验发现，适当调整批量提交的数量可以在确保性能的同时避免日志缓冲区溢出。
当向一张表中插入大量数据时，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/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
