zoukankan      html  css  js  c++  java
  • log file sync(日志文件同步) 与 Log file parallel write 等待事件

    log file sync(日志文件同步)等待事件具有一个参数:buffer#。在Oracle Database 10g中,这种等待事件位于Commit等待下面。当处理log file sync等待事件时,注意下面的思想:
         ◎ log file sync 等待时间和事务中指(提交或回滚)相关
         ◎ 当进程在log file sync事件上花费大量时间时,这通常表明过多的提交或短事务。


     

    常见的原因、诊断和动作
         Oracle 在SGA中的日志缓冲区中记录事务和块的改变,这是成为生理日志(physiological logging)的方法。通过以各种时间进度将内容写入到日志文件,LGWR进程负责在日志缓冲区中留出空间。


    触发LGWR进程的条件有:
      1. 用户提交
      2. 有1/3重做日志缓冲区未被写入磁盘
      3. 有大于1M的重做日志缓冲区未被写入磁盘
      4. 3秒超时
      5. DBWR 需要写入的数据的SCN大于LGWR记录的SCN,DBWR 触发LGWR写入。

    触发DBWR进程的条件有:
     1. DBWR超时,大约3秒
     2. 系统中没有多余的空缓冲区来存放数据
     3. CKPT 进程触发DBWR

    LGWR是负责把Redo Log buffer写入Redo file的进程,当这个进程启动的时候,会把redo buffer里已经有的redo record写入redo file,而当用户commit或者rollback的时候,会触发这个进程,从而保证用户的提交的数据安全,只有写入到redo file,才能保证这个操作是可以恢复的。 

    只有当某个事务所产生的重做记录全部被写入重做日志文件之后,oracle才认为这个事务已经成功提交.重做记录也可能会在事务提交之前就写入重做日志文件.

    LGWR进程在开始写入下一个重做日志文件之前,必须确认这个即将被覆盖的重做日志文件已经完成如下工作:
    * 如果数据库处于非归档模式,已写满的重做日志文件在被覆盖之前,其中所有重做记录所对应的事务的修改
    操作结果必须已经全部被写入到数据文件中
    * 如果数据库处于归档模式,已写满的重做日志文件在被覆盖之前,不仅要对应所有事务的修改操作结果全部被 写入到数据文件中,还需要等待归档进程完成对它的归档操作

         由用户提交和回滚初始化的写入称为同步写入;其余的写入成为后台写入。log file sync
    等待只和同步写入有关。换句话说,用户进程可能正在处理一个大型的事务并生成许多触发LGWR以执行后台写入的大量重做条目,但用户会话从来不需要等待后台写入的完成。然而,一旦用户会话提交或回滚它的事务且_WAIT_FOR_SYNC参数是TRUE时,进程提交LGWR并在log file sync事件上等待LGWR将当前重做条目(包括提交标记)刷新到日志文件。在这种日志同步期间,LGWR进程在log file parallel write事件上等待同步写入的完成,同时用户会话在log file sync事件上等待同步进程的完成。

    一旦进程进入log file sync等待,就有两种可能性。

    一种可能性是LGWR在日志同步完成时提交前台进程时。

    另一种情况是在等待已超时的时候(一般在1秒内),在这个时刻,前台进程检查当前日志SCN(System Change Number,系统改变号),确定它的提交是否已经传递到磁盘。如果是的话,进程继续处理,否则进程就重新进入等待。


     

    高log file sync等待事件的3个主要原因。
         ①.高提交频率

                解决方法是简单的消除不必要的提交,事务是工作单元。工作单元应该是全部成功或全部失败。
         ②.缓慢的I/O子系统
            较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中,而不是绑定在RAID 5中。
         ③.过大的日志缓冲区
            过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量,允许LGWR变得懒惰,并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数,其默认值是LOG_BUFFER的1/3或1MB,取两者之中较小的值。换句话说,你可以具有较大的日志缓冲区,但较小的_LOG_IO_SIZE将增加后台写入,从而减少log file sync的等待时间。


     

    注意:
         你必须绝对不将参数_WAIT_FOR_SYNC设置为FALSE,即使是在一个开发数据库或测试数据库中,因为不能保证提交的事务在实例失败时可以恢复。人们使用这种特性来避开基准测试。
         一般情况下,log file sync等待是非常频繁的时间。它非常简短,终端用户一般不会注意
    到它。然而,许多这样的事件可能产生较长的响应时间并在v$system_event和v$session_wait
    视图中获得显著的等待统计。使用下面的查询来找到当前的会话,这些会话从登陆开始就花费大量的处理时间在log file sync事件上等待。


    Log file parallel write

    log file parallel write 事件是LGWR进程专属的等待事件,发生在LGWR将log_buffer中的重做日志信息写入联机重做日志文件组的成员文件,LGWR在该事件上等待该写入过程的完成。


    该事件等待时间过长,说明日志文件所在磁盘缓慢或存在争用。

    从两个方面入手解决:

    (1)将日志文件组放置到高速I/O磁盘上。

    (2)尽可能的降低重做数量:
    —尽可能使用Nologging选项,包括create table...as select...操作                                          
    —热备份可能创建大量的重做信息,所以热备份应该在非高峰时间运行,并且尽可能将表空间排除在热备份模式外

  • 相关阅读:
    严重: Parse error in application web.xml file at jndi:/localhost/ipws/WEBINF/web.xml java.lang.NoSuchMethodException: org.apache.catalina.deploy.WebXml
    Failed to install .apk on device 'emulator5554': timeout解决方法
    java.lang.NoClassDefFoundError:org.jsoup.Jsoup
    Conversion to Dalvik format failed: Unable to execute dex:解决方法
    apache Digest: generating secret for digest authentication ...
    Description Resource Path Location Type Project has no default.properties file! Edit the project properties to set one.
    android service随机自启动
    MVC3 安装部署
    EF 4.3 CodeBased 数据迁移演练
    SQL Server 2008开启sa账户
  • 原文地址:https://www.cnblogs.com/sopost/p/2190048.html
Copyright © 2011-2022 走看看