故障排除："log file sync"等待 (文档 ID 1626301.1)
原文：https://www.cnblogs.com/muzisanshi/p/11933539.html
什么是'log file sync'等待事件？
当一个用户会话提交，那个用户产生的所有redo需要从内存刷新到重做日志文件，使事务对数据库的修改永久化。
在提交时，用户会话会通知 LGWR 把日志缓冲区中的信息写到重做日志文件（当前所有未被写入磁盘的 redo 信息，包括本次会话的 redo 信息）。当 LGWR 发现写操作完成后，它会通知用户会话。当等待 LGWR 通知确认所有 redo 已经安全的保存到磁盘的过程时，用户会话会等待'log file sync'。
用户会话显示等待'log file sync'，是用户会话通知 LGWR 和 LGWR 通知用户的写操作完成之间的时间。
注意在11.2及以上版本，LGWR会在默认的post/wait模式和polling模式之间自动切换。在polling模式下，写操作的进展会维护在一个内存结构中，等待'log file sync'的会话可以不时检查这个内存结构看是否自己所发起的事务对应的redo已经写入磁盘。这时，等待时间会从用户会话通知 LGWR开始到会话自己发现对应的redo已经写入磁盘结束。
需要注意的是，如果已有一个正在进行的同步，其他需要提交的会话（为了保存日志信息）也需等待 LGWR，进而也将等待'log file sync'？Document:34592.1 WAITEVENT: "log file sync"
其中的最常见的原因：
- 影响 LGWR 的 I/O 性能问题
- 过多的应用程序 commit
这些原因以及如何解决它们详情概述如下：
Document:34583.1 WAITEVENT: "log file parallel write" Reference Note
结合事件“log file sync”看同步操作消耗在 IO 的时间，由此推断，有多少处理时间消耗在 CPU 上。
上面的例子显示了'log file sync' 和 'log file parallel write' 都有很高的等待时间
如果'log file sync'的时间消耗在'log file parallel write'上的比例高，那么大部分的等待时间是由于 IO（等待 redo 写入）。应该检查 LGWR 在 IO 方面的性能。作为一个经验法则，'log file parallel write'平均时间超过 20 毫秒, 意味着 IO 子系统有问题。（当然这个时间对于拥有更多cache的现代的存储系统以及SSD, NVRAM来说会更小）
Document 301137.1)来确定是否系统中存在间歇性物理IO缓慢。如果可以确定存在间歇性物理IO缓慢, 那么你需要与磁盘提供商一起来解决这个问题。
Document:601316.1 LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4 Database
Document:602066.1 How To Maintain and/or Add Redo Logs
Document:779306.1 How To Add/Increase The Size Of Redo Log Files In Rac Environment?
Document 1541136.1 Waits for "log file sync" with Adaptive Polling vs Post/Wait Choice Enabled
Document 34592.1 WAITEVENT: "log file sync" Reference Note
下列文件可以帮助特定环境下的已知问题：
Document 1229104.1 LOG FILE SYNC WAITS SPIKES DURING RMAN ARCHIVELOG BACKUPS
Document 1541136.1 Waits for "log file sync" with Adaptive Polling vs Post/Wait Choice Enabled
Sparc:
Document 1523164.1 SPARC: Reducing High Waits on 'log file sync' on Oracle Solaris SPARC by Increasing Priority of Log Writer
Document 1205673.1 'Log File Sync' problem on a Sun Server: A Typical Source for LOGFILE SYNC Performance Problems
Document 10318123.8 Bug 10318123 - Solaris: LGWR regularly stalls for 3 seconds at a time
AIX:
Document 1318709.1 AIX: Things To Check When Seeing Long Log File Sync Time in 11.2
Veritas/Symantec ODM:
Document 1278149.1 Intermittent Long 'log file sync' Waits on Veritas ODM, LGWR Posting Long Write Times, I/O Portion of Wait Minimal
Document 13551402.8 High "log file parallel write" and "log file sync" after upgrading 11.2 with Veritas/Symantec ODM
SUSE Linux:
Document 1942134.1 Higher Log File Synch After OS Upgrade from SUSE Linux Enterprise Server SLES11 SP1 to SLES11 SP3
Exadata:
关于不要把redo放置在SSD/Flash存储上（除了Engineered System）的信息请参考以下文档的第11页
http://www.oracle.com/technetwork/database/exadata/exadata-smart-flash-cache-366203.pdf
Document:1064487.1 Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql)
Document:387174.1 MAA - Data Guard Redo Transport and Network Best Practices.
在主数据库和备用数据库的设置信息可以通过从以下文档的脚本来收集：
Document:241374.1 Script to Collect Data Guard Primary Site Diagnostic InformationDocument:241438.1 Script to Collect Data Guard Physical Standby Diagnostic Information