读书笔记：数据库日志问题解析：为什么我的数据库突然变慢了？-CSDN博客

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

本文为个人学习《Expert Oracle Database Architecture Techniques and Solutions for High Performance and Productivity（第四版本》一书过程中的笔记与理解分享，仅用于学习与交流，部分内容参考原书观点并结合>实际经验进行整理。若涉及版权问题，请联系删除或沟通处理。也请大家支持购买原版书籍。

数据库日志问题解析：为什么我的数据库突然变慢了？

常见问题：无法分配新日志文件

很多DBA和开发人员都遇到过这样的场景：数据库突然变得异常缓慢，查看服务器日志时发现类似这样的警告信息：

Thread 1 cannot allocate new log, sequence 1466
Checkpoint not complete
Current log# 3 seq# 1465 mem# 0: /.../...redo03.log

这种情况通常发生在两种场景下：

检查点未完成：DBWn进程(数据库写入进程)还没完成数据检查点操作
归档未完成：ARCn进程(归档进程)还没把重做日志复制到归档目录

当数据库试图重用在线重做日志文件但发现不能使用时，就会出现这个问题。这时数据库对用户来说几乎完全停止响应，因为系统没有地方记录用户正在做的修改了。

为什么会发生这种情况？

想象一下这样的场景：

你开始往数据库批量导入大量数据
前1000条记录很快完成
然后系统开始变得断断续续：快速处理1000条，卡住，再处理1000条，又卡住…

这种"走走停停"的现象很可能是由于重做日志文件配置不当造成的。很多默认安装的数据库(“初始数据库”)都把重做日志设置得太小，无法处理实际工作负载。

解决方案

方案一：优化DBWn进程性能

启用异步I/O
使用DBWn I/O从属进程
配置多个DBWn进程
检查系统I/O，把"过热"磁盘上的数据分散开

优点：不需要修改逻辑或结构就能提升性能
缺点：几乎没有

方案二：增加重做日志文件数量

给系统更多"喘息空间"
推迟"检查点未完成"情况的发生

优点：消除系统"卡顿"现象
缺点：会占用更多磁盘空间

方案三：增大重做日志文件大小

延长重做日志文件的使用周期
特别适合有"突发性"日志生成的情况(如夜间批处理)

优点：同方案二
缺点：同方案二

方案四：调整检查点频率

使用较小的缓冲区缓存
调整相关参数(FAST_START_MTTR_TARGET等)

优点：缩短故障恢复时间
缺点：可能导致更频繁的磁盘写入

块清除问题：为什么SELECT也会产生写入？

这是一个很反直觉的现象：有时候执行SELECT查询也会产生redo日志，甚至导致DBWn进程把数据块再次写入磁盘。这其实是"块清除"机制在起作用。

块清除是什么？

当我们修改数据时，Oracle会在数据块头记录事务信息。提交时，Oracle会尝试清除这些信息(称为"提交清除")。但如果：

修改的块数超过缓冲区缓存的10%
或者这些块已经不在缓存中

Oracle就会跳过清除操作，等到下次访问这些块时再清除。这就是为什么有时候SELECT也会产生redo日志。

实际案例

假设我们：

创建一个每行独占一个块的表
插入10000行数据并提交
第一次全表扫描会产生约800KB的redo
第二次扫描就不会产生redo了

这是因为第一次扫描时Oracle需要清除块上的事务信息，而第二次时所有块都已经干净了。

如何避免？

对于数据仓库系统，在批量加载后：

立即运行分析查询或报表
使用DBMS_STATS收集统计信息
这些操作会自然地完成块清除工作。

日志性能优化建议

如果发现"日志文件同步"等待时间过长，可能是日志系统存在瓶颈。常见原因包括：

硬件问题：
- 重做日志放在慢速设备上
- 使用RAID-5(适合读但不适合写)
配置问题：
- 重做日志与其他活跃文件共用设备
- 文件系统双重缓冲

最佳实践：日志磁盘布局

理想情况下应该准备5-6块专用磁盘：

磁盘组	用途	磁盘
组1	重做日志	磁盘1+3
组2	重做日志	磁盘2+4
组3	归档日志	磁盘5(+6)

这样设计的好处：

LGWR(日志写入进程)和ARCn(归档进程)永远不会互相干扰
读写操作完全分离
最大化I/O吞吐量

总结

数据库日志系统是保证数据安全的关键组件，但也常常成为性能瓶颈。通过合理配置重做日志大小、数量和存储方案，可以显著提升数据库的稳定性和性能。记住，预防胜于治疗，在系统设计阶段就做好规划，远比出现问题后再补救要高效得多。

------------------作者介绍-----------------------
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)