ITPub博客

首页 > Linux操作系统 > Linux操作系统 > log file sync(日志文件同步) 与 Log file parallel write 等待事件

log file sync(日志文件同步) 与 Log file parallel write 等待事件

原创 Linux操作系统 作者:tolywang 时间:2011-06-09 11:30:48 0 删除 编辑

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...操作                                          
—热备份可能创建大量的重做信息,所以热备份应该在非高峰时间运行,并且尽可能将表空间排除在热备份模式外

 

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

下一篇: parse calls
请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13780268