eygle Eygle.
FAQ · Oracle12c/11g 2009-11-12

10.2.0.4 LGWR Trace Warning: Log Write Time

今天在客户的环境中,发现LGWR的跟踪文件中包含了如下一些记录:
*** 2009-10-19 13:13:51.534
Warning: log write time 720ms, size 3KB
*** 2009-10-20 10:33:27.372
Warning: log write time 510ms, size 2KB
*** 2009-10-21 02:00:01.159
Warning: log write time 10521085310ms, size 8KB
*** 2009-10-22 10:35:57.932
Warning: log write time 570ms, size 1KB
*** 2009-11-03 10:36:52.851
Warning: log write time 610ms, size 2KB
*** 2009-11-03 10:36:54.938
Warning: log write time 860ms, size 2KB
*** 2009-11-12 08:23:25.525
Warning: log write time 750ms, size 1KB
这些信息提示,数据库的日志写出现较长的等待,超过500ms的写出会被记录,一般来说是IO存在问题,写出缓慢所致。

检索Metalink,发现这是10.2.0.4中引入的,如果确认硬件没有问题则可以忽略之。
注意,在备份时间,凌晨两点,这个LOG写出延时达到了恐怖的数字:10521085310ms
事实上不可能是这么长的等待,因此我想这是Oracle诊断输出的一个Debug信息,忘了去掉而已吧。

Metaliink Note:601316.1

-The End-


By eygle 2009-11-12 13:05 评论 (6)
eygle
eygle

前Oracle ACE Director,云和恩墨创始人。技术为骨,历史为脉,人文为魂。

返回首页

6 Comments

这个信息我也见过,而且是客户系统老是在某个时间范围内瞬间磁盘利用率很高,导致应用出现积压,最后确认为存储链路问题,其他时间段看IO也是没啥问题 DD 测试啥的 ORION都是好的。

*** 2009-08-18 10:07:30.540
Warning: log write time 91960ms, size 1KB

根据压力和存储链路切换测试结果及存储日志中的错误信息,确定存储光纤通道存在问题的可能性比较大,最终对交易系统作了以下调整:
1、 更换了节点1连接控制器B, port 1的光纤线。
2、 更换了存储控制B, port 1的光纤模块

目前为止,没有出现过,最好检查下存储日志,监控一段时间内的磁盘使用情况。我们是用NMON收集的。

大师观察的细致,敏感度。。。