对-IO-及-CPU-使用率-一次小优化.doc

对-IO-及-CPU-使用率-一次小优化 对 IO 和 CPU 使用率 的一次小优化对 IO 和 CPU 使用率 的一次小优化 端午放假之后，从6月7日开始，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 160 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 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 的版本，在 的版本已经修复过了。 我的DB 去年做过升级。 现在的版本是，所以不太可能是这个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 这个警告是在 之后才有的，当log write 超过500ms，就会出现这个警告。 LGWR Is Generating Trace file with Warning Log Write Time 540ms, Size 5444kb In Database /tianlesoftware/archive/2011/06/10/6537196.aspx 昨天晚上收到的报警短信CPU 更是超过了90%，有时还是100%。 今天早上到公司收了下监控邮件。 发现归档比昨天又增加了2G。 这个明显不太正常。就是业务增长，也不应该是这个长法。 在CPU 超过90%的时候，根据Linux pid 抓到了SQL 语句。 然后查看了对应的表。 有400多万的记录。 然后从6月1号到6月10号的记录就有370w。 数据很不正常，问同事这几天可有