log file sync事件

coolyl

写log的是需要时间的啊，你这么大日志才写的话就引起等待了啊

whwlm

最初由 coolyl 发布
[B]写log的是需要时间的啊，你这么大日志才写的话就引起等待了啊 [/B]

1、如果IO的量一样，分多次写应该更耗资源
2、实际上系统每秒钟有10-20个事务，应该不会等到1/3才写盘

biti_rainy

假设暂时lgwr空闲，这时一个较大事务来了
然后当达到1/3  buffer 的时候写磁盘，但这个时候紧接着来了5个小 事务提交
这5个小事务就必须都等待较长时间才能获得lgwr写日志

但是如果较大事务已经在比较空闲的时候写了很大一部分，则可以减少等待时间

不能让lgwr太闲，但由于每次写日志次数过多是有一定代价的，所以一次写日志内容不能太大，但写日志也不能太频繁

通常结合 commit 频繁程度、磁盘分布  结合调整

piner

如果一起写，io当然更拥挤，如果分成很多小块来写，更有利于均衡的io流
------------------
我觉得你最主要的问题还是io，调整io最好了

doctest

我的log file sync 也很大
因为log_buffer很大
但缩小log_buffer就引起大量的allocation retries
为什么会有这么多的allocation retries?有哪些可能性?
谢谢

xiaba

根据文档ALLOCATION RETRY等待事件是当REDO ENTRY从PGA拷贝到LOG BUFFER时系统等待BUFFER空间的事件，这证明系统产生REDO速度超过REDO BUFFER消耗速度，影响因素为BUFFER不够大，或者BUFFER写入LOG FILE 不够快。若增大BUFER又引起REDO LOG SYNC等待事件，也许调整I/O性能才是关键。如将REDO LOG FILE放到单独的磁盘上，采用RAID0+1等。
有时候真的很困惑，不读文档不明白，读了文档更糊涂，ORACLE丫是不是整个一下套，搞出这么读文档象TMD****功，让人走火入魔。整个一歪理邪说。
也许那一天系统能自动判断出问题所在并给出调整办法。而不是给出一大堆EVENT WAIT，STATISTICS砸晕兄弟们，就象偶去看病，丫破医生又是听音又是验血，然后告诉你染色体正常，血压多少，甘油三制多少，白血球多少，我肯定一声大喝，你丫有完没完，我就需要知道两件事，我什么病，怎么治，少在这积极外外。对于用户而言，不关心过程，只关心结果。想想现在的非典，嘿嘿，水货多啊。。。。。。。

doctest

谢谢!
颇有同感!

fable_cao

爽，不过如果系统哪一天这么牛b 的话，我们就都失业了

andy9718

谢谢!

db1

metalink 上的说法：
There are 3 main things you can do to help reduce waits on "log file sync":
Tune LGWR to get good throughput to disk . eg: Do not put redo logs on RAID 5.
If there are lots of short duration transactions see if it is possible to BATCH transactions together so there are fewer distinct COMMIT operations. Each commit has to have it confirmed that the relevant REDO is on disk. Although commits can be "piggybacked" by Oracle reducing the overall number of commits by batching transactions can have a very beneficial effect.
See if any activity can safely be done with NOLOGGING / UNRECOVERABLE options.

IO类的wait event应该看平均等待时间，单纯的数量好像不能说明问题。