我们的文章会在微信公众号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)
扫一扫
698
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
