RAC 性能分析 - 'log file sync' 等待事件

简介

本文主要讨论 RAC 数据库中的‘log file sync‘ 等待事件。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)

https://blogs.oracle.com/Database4CN/entry/rac_%E6%95%B0%E6%8D%AE%E5%BA%93%E4%B8%AD%E7%9A%84_log_file_sync

RAC 性能分析 - 'log file sync' 等待事件

时间: 2024-10-06 08:23:38

RAC 性能分析 - 'log file sync' 等待事件的相关文章

ORACLE AWR报告之 log file sync等待事件优化的总结【转自ITPUB】

来自白大师(白鳝)对log file sync等待事件优化的总结,供各位puber们学习参考: 一. log file sync平均等待事件时间超过7ms,如果等待时间过长,说明log write每次写入的时间过长,如果能够优化redo日志文件存储,使之存放在更快的磁盘上,就可以减少这个等待事件的单次等待时间.(RAID 5--> RAID 10)   当无法通过优化redo日志的I/O性能来解决问题,或者优化了redo日志的I/O性能后还是无法达到我们的预期,那么该如何处理呢? 二. 有经验的

log file sync等待超高案例浅析

监控工具DPA发现海外一台Oracle数据库服务器DB Commit Time指标告警,超过红色告警线(40毫秒左右,黄色告警是10毫秒,红色告警线是20毫秒),如下截图所示,生成了对应的时段的AWR报告,发现Top 5 Timed Events里面,log file sync等待事件的平均等待时间为37毫秒,log file parallel write等待事件的平均等待时间为40毫秒 如果对Tanel Poder::Understanding LGWR, Log File Sync Wait

log file sync等待超高一例

这是3月份某客户的情况,原因是server硬件故障后进行更换之后,业务翻译偶尔出现提交缓慢的情况.我们先来看下awr的情况. 我们能够看到,该系统的load profile信息事实上并不高,每秒才21个transaction.先来看看top5events: 从top 5event,我们能够发现,log file sync的avg wait很之高,高达124ms.大家应该知道,对于绝大多数情况 下,log file sync的平均等待时间是小于5ms的,这个值有点高的离谱. 我们知道,产生log

oracle之 等待事件LOG FILE SYNC (awr)优化

log file sycn是ORACLE里最普遍的等待事件之一,一般log file sycn的等待时间都非常短 1-5ms,不会有什么问题,但是一旦出问题,往往都比较难解决.什么时候会产生log file sync等待?常见有以下几种:1)commit操作2)rollback操作3)DDL操作(DDL操作实施前都会首先进行一次commit)4)DDL操作导致的数据字典修改所产生的commit5)某些能递归修改数据字典的操作:比如查询SEQ的next值,可能会导致修改数据字典.一个典型的情况是,

log file sync 事件(转)

log file sync log file sync等待时间发生在redo log从log buffer写入到log file期间. 下面对log file sync做个详细的解释. 何时发生日志写入: 1.commit或者rollback 2.每3秒 3.log buffer 1/3满或者已经有1M的redo数据. 更精确的解释:_LOG_IO_SIZE 大小默认是LOG_BUFFER的1/3,当log buffer中redo数据达到_LOG_IO_SIZE 大小时,发生日志写入. 4.DB

Oracle之 等待事件log file sync + log file parallel write (awr优化)

这是3月份某客户的情况,原因是server硬件故障后进行更换之后,业务翻译偶尔出现提交缓慢的情况.我们先来看下awr的情况. 我们能够看到,该系统的load profile信息事实上并不高,每秒才21个transaction.先来看看top5events: 从top 5event,我们能够发现,log file sync的avg wait很之高,高达124ms.大家应该知道,对于绝大多数情况 下,log file sync的平均等待时间是小于5ms的,这个值有点高的离谱. 我们知道,产生log

log buffer space等待事件

最近,我们有台服务器在delete操作期间发现一直在等待log buffer space,其他节点就没与这个问题.经查,向重做缓冲区上写入重做记录的进程,为了确保拥有重做缓冲区内必要的空间,需要获得redo allocation锁存器.已获得redo allocation锁存器的状态下,在想要得到重做缓冲区时,若没有适当的剩余空间,则需要等到直到获得空间为止.这时,根据情况等待两种事件.如果当前正在使用的重做日志文件已满,因此无法获得剩余空间,LGWR就会执行日志文件切换,服务器进程则等待log

oracle9i statspack 报告 分析 direct path read 等待事件

DB Name         DB Id    Instance     Inst Num Release     Cluster Host ------------ ----------- ------------ -------- ----------- ------- ------------ LIXORA          1409317108 LIXORA                1 9.2.0.1.0   NO      lixora-DATA Snap Id     Sna

遇到direct path sync等待事件

在使用hvr测试 大表同步的时候,遇到direct path sync等待事件,经过查询官方文档,http://docs.oracle.com/cd/E11882_01/server.112/e40402/waitevents003.htm#REFRN00538 有说明如下: direct path sync During Direct Path write operations the data is asynchronously written to the database files.