对 IO 和 CPU 使用率的一次小优化-优快云博客

本文详细探讨了数据库性能下降的原因，包括日志检查点不完整、redo日志组增加、归档日志增长、CPU负载增加等问题。通过AWR报告分析等待事件，发现主要问题是日志同步和并行写入速度慢。同时，存在SQL直接I/O异步IO限制警告，导致写操作延迟。通过检查LGWR日志和调整配置，最终定位到大量业务数据刷入导致的日志写入瓶颈。通过转移历史数据、优化索引、修改SQL语句等措施，解决了性能问题并降低了CPU负载。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

DB就不太稳定，alert log出现了：checkpoint not complete, cannot allocate new log的警告。所以加了一个online redo log group。不过警告并没有因此消失，第二天又加了一组。原来是4组，加了2组之后就有6组。而且每天的归档也比以前增加了1G多。CPU也上升到了50%，高的时候，能波动到80%。

通过AWR报告查看，等待事件排名前2的是：log file sync和log file parallel write。这2个等待事件更写log的速度和用户commit的频率有关。

查看Trace文件，有一些警告信息：

WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128

WARNING:Could not increase the asynch I/O limit to 192 for SQL direct I/O. It is set to 128

看到WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128的警告，怀疑是Oracle的bug。在MOS上搜了半天，只找到一个类似的信息。不过这个bug的版本只争对oracle 10.2.0.4的版本，在10.2.0.5的版本已经修复过了。我的DB去年做过升级。现在的版本是10.2.0.5，所以不太可能是这个bug。

lgwr的trace也有警告：

[oracle@qs-xezf-db1 bdump]$tail -50 xezf_lgwr_11189.trc.bak

*** 2011-06-09 06:02:48.846

Warning: log write time 610ms, size 6KB

*** 2011-06-09 06:02:54.119

Warning: log write time 800ms, size 18KB

*** 2011-06-09 06:02:54.821

Warning: log write time 700ms, size 25KB

......

*** 2011-06-09 22:43:21.961

Warning: log write time 670ms, size 1KB

*** 2011-06-09 23:20:03.613

Warning: log write time 670ms, size 5KB

*** 2011-06-10 00:16:34.240

Warning: log write time 730ms, size 13KB

根据Oracle的说法：

Warning: log write time 730ms, size 13KB这个警告是在10.2.0.4之后才有的，当log write超过500ms，就会出现这个警告。

LGWR Is Generating Trace file with 'Warning Log Write Time 540ms, Size 5444kb' In 10.2.0.4 Database

http://blog.youkuaiyun.com/xujinyang/article/details/6858031

昨天晚上收到的报警短信CPU更是超过了90%，有时还是100%。今天早上到公司收了下监控邮件。发现归档比昨天又增加了2G。这个明显不太正常。就是业务增长，也不应该是这个长法。在CPU超过90%的时候，根据Linux pid抓到了SQL语句。然后查看了对应的表。有400多万的记录。

然后从6月1号到6月10号的记录就有370w。数据很不正常，问同事这几天可有做什么修改，有做大事务的操作没。同事说没有，查看了中间件的log，发现了问题，从昨天晚上0点到今天早上8点，同一个IP地址刷了12w的记录到这张表。前面几天的log没有查看，肯定和这个IP也有关系。很明显是用程序在刷，人工刷不了这么多的记录，和同事商量了下业务流程，想在流程上杜绝这种狂刷的做法。这个需要点时间。

先从这几张表入手，将这张400w的表进行了手工转历史。转移了300w的数据，然后就log表。这个也是重灾区。一共1700w的记录，其中有900万的记录是6月份以后的。转历史之后log表还有900w的记录。

从AWR报告上看到这个log表上的索引有较严重的等待。因为这个表是更新多，查询很少，所有的交易都会写这个log表，更新相当频繁，维护索引的成本明显要大于查询的成本,所以drop掉了这个索引。

数据转历史之后，收集了一下表的统计信息，因为删除了大量的数据，此时的统计信息很明显有变化，不手动更新，CBO还是会使用以前的统计信息。那样执行计划就会有偏差。

在查看了一下CPU，已经降到了20%左右。恢复正常。根据AWR，对占用资源较多的几个SQL语句，做了小修改，建了联合索引。在看CPU已经降到15%左右。CPU这块已经差不多了。

IO这块还是瓶颈。不过lgwr trace出现Warning: log write time 660ms, size 1KB这种警告的周期变长。如果业务流程不改，还是有大量的业务数据刷进来的话，写log还是个大问题。

-------------------------------------------------------------------------------------------------------

对 IO 和 CPU 使用率 的一次小优化

对 IO 和 CPU 使用率的一次小优化