Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

999

积分

1

好友

942

主题
1#
发表于 2013-11-17 19:43:33 | 查看: 4657| 回复: 3
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)

下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569     邮箱:service@parnassusdata.com
2#
发表于 2013-11-22 11:02:53
不错 赞一个

回复 只看该作者 道具 举报

3#
发表于 2013-11-26 15:49:59
感谢。很需要这种原理性的学习

回复 只看该作者 道具 举报

4#
发表于 2013-12-5 23:14:32
程序上我们一般采用批量提交,单个提及就出这个等待。

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-21 10:18 , Processed in 0.054479 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569