ITPub博客

首页 > 数据库 > Oracle > RAC 数据库中的'log file sync' 等待事件

RAC 数据库中的'log file sync' 等待事件

原创 Oracle 作者:zhengbao_jun 时间:2015-01-07 10:32:43 0 删除 编辑
RAC 数据库中的'log file sync' 等待事件要比单机数据库中的'log file sync' 等待事件复杂,主要原因是由于RAC 数据库需要将SCN同步到所有实例。

首先,回顾一下单机数据库中的'log file sync' 等待事件,当user session 提交(commit)时,user session会通知LGWR进程将redo buffer中的信息写入到redo log file,当LGWR进程完成写操作后,LGWR再post(通知)user session 写操作已经完成,user session 接收到LGWR的通知后提交操作才完成。因此user session 在没有收到LGWR post(通知)之前一致处于等待状态,具体的等待事件为'log file sync'。

在RAC数据库中为了一致性读,需要将Commit SCN同步/传播到所有的节点上。SCN同步/传播的主要方法有两种:Lamport SCN 和 immediate commit propagation (BOC)。

10gR1 及以下版本默认使用Lamport SCN,Lamport SCN方式即一个节点上的commit SCN 不保证立刻同步/传播到所有节点,也就是说可能延时同步/传播,对于一些实时性要求高的RAC数据库Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/传播到所有节点,手动修改参数MAX_COMMIT_PROPAGATION_DELAY=1

从10gR2开始默认使用immediate commit propagation (BOC),BOC即一个节点上的commit SCN 立刻同步/传播到所有节点。

介绍 immediate commit propagation (BOC)的工作原理

1. user session 执行提交(commit),user session会通知LGWR进程将redo buffer中的信息写入到redo log file。

2. LGWR进程收到user session通知后,将redo buffer中的信息写入redo log file,同时LGWR 将COMMIT SCN 同步/传播给远程的数据库实例的LMS 进程。

3. 远程数据库实例的LMS将commit SCN同步到本地SCN,然后通知commit实例的LMS,表示SCN 同步已经完成。

4. 当commit 实例的LMS接收到所有远程数据库实例的LMS的通知后,commit 实例的LMS再通知本地的LGWR 所有节点SCN同步已经完成。

5. LGWR 在完成了IO 操作和LMS进程通知后,LGWR通知user session commit 成功。user session在没有收到LGWR通知前,一直处于等待log file sync。

通过以上原理的说明,我们不难看出来导致'log file sync' 等待事件的主要原因有:

1. 磁盘IO 慢导致LGWR进程将redo buffer中的信息写入到redo log file速度慢。

2. user session commit过于频繁。

3. 本地或者远程服务器CPU资源不足,导致LMS和/或者LGWR不能及时得到CPU调度,不能正常工作。

4. RAC私有网络性能差,导致LMS同步commit SCN慢。

5. ORACLE BUG.

分析处理'log file sync' 等待事件时的重要log/信息

1. AWR

例如:AWR中log file sync 的等待时间与log file parallel write的时间基本相同,因此是由于IO问题导致的log file sync.

2. LGWR and LMS process trace file

例如:LGWR trace文件中报出下面的信息,很有可能是IO慢导致的。

Warning: log write time 1000ms, size 2KB

3. OSWatcher <--- 可以帮助我们确认服务器CPU资源使用情况

例如:下面的是OSW中vmstat 的输出,其中runQ中的进程达到48个,表明当时CPU资源是非常紧张的,会导致LMS/LGWR不能获得CPU 调度,导致Log file sync等待。

        procs           memory                   page                              faults       cpu

   r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id

48    22     0  23877753  30244459    0    0     0    0     0    0     0  153454 2184632 114234  38 60  2

48    22     0  23877753  30244094    0    0     0    0     0    0     0  153694 2181493 114887  36 61  3

注:关于OSW的安装配置请参考BLOG中的文章: https://blogs.oracle.com/Database4CN/entry/%E5%88%A9%E5%99%A8osw_oswatcher_black_box_%E4%B9%8B%E7%AE%80%E4%BB%8B%E7%AF%87 4. Alert log

5. Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) [Document 1064487.1]

解决'log file sync' 等待事件主要方法

1. 提高磁盘IO速度

2. 采用批量提交,减少应用commit次数

3. 安装OSWatcher 定位CPU使用率高的进程 搜索4. 采用专用网络,正确设置网络UDP buffer参数

5. 安装最新版本数据库避免bug,具体bug修复的版本参考文档: 

WAITEVENT: "log file sync" Reference Note (Doc ID 34592.1)

如果 你遇到从10.2.0.5升级到11.2出现LOG FILE SYNCS等待事件显著增长的性能问题,那么有必要读一下这篇文章了。
 
在以往的经验中如果遇到这种场景 ,那么 优先考虑设置 “_use_adaptive_log_file_sync”=false, adaptive log file sync是 11.2中提出的一个优化重做日志写的新特性, 在11.2.0.3以后默认为TRUE。
有客户在将”_use_adaptive_log_file_sync”=false后,log file sync等待事件的平均等待时间从10ms 下降到 1~2ms的案例。
 
_use_adaptive_log_file_sync造成性能下降的原因可能是其导致LGWR使用了polling 方式来取代 post/wait,并且polling的间隔是10ms,这个间隔是在代码里写死的。
 
此外如果使用了Veritas/symantec 的ODM的话也需要特别注意:你可能遇到了Bug 13551402  High “log file parallel write” and “log file sync” after upgrading 11.2 with Veritas/Symantec ODM,这个BUG已经确认在11.2.0.3和11.2.0.2上存在。
对于该bug的内部讨论最后确认是由于 11.2中lgwr的 IO使用了一种批量同步I/O接口,导致当配合Veritas/symantec 的ODM一起使用时会导致性能下降。
目前该BUG已经在多个Unix/Linux平台上提供补丁:

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/235507/viewspace-1392998/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 监控索
请登录后发表评论 登录
全部评论

注册时间:2008-08-08

  • 博文量
    209
  • 访问量
    864861