详解log file sync等待事件.docx_第1页
详解log file sync等待事件.docx_第2页
详解log file sync等待事件.docx_第3页
详解log file sync等待事件.docx_第4页
详解log file sync等待事件.docx_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

数据库中的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。根据实践经验,引起log file sync等待事件的原因有以下几种:n 事务过度的提交,即应用程序过度commit或者rollback。n 存储I/O资源紧张,导致lgwr进程写速度缓慢。n CPU资源紧张,lgwr进程获得不了响应的CPU时间片。n RAC节点之间SCN同步。n RAC节点之间CR块传递。n 控制文件争用。不同的原因,其解决方法会不同,当多种原因混合在一起时,则需要进行综合考虑。事务过度提交事务过度提交是引起log file sync等待事件的主要原因之一。前面提到,默认情况下,当事务提交时,LGWR进程会将事务相关的日志条目立即写至redolog中,直到日志写成功之后才显示提交成功。所以事务提交越频繁,触发LGWR进程写操作越频繁,引起log file sync等待时间的可能性越大。所以当由于事务过度提交引起log file sync等待事件时,最好的解决方法是修改应用,将小事务变成大事务。可在很多情况下,修改应用不是很简单的事情,需要应用厂商配合。当应用厂商配合程度不足时,我们就需要在DB端想办法了。所幸的是从Oracle 10g开始,Oracle推出了新的数据库参数commit_write用于控制LGWR进程写日志操作,其默认值为空,表示wait和immediate。也可以将其在线修改(即参数值修改后不需要重启数据库就能生效)成nowait和batch,表示事务提交时,LGWR进程并不马上将事务相关条目写至日志文件中,而是异步模式将相关条目批量(batch)写至日志文件中。所以采用这种方法,在缓减了log file sync等待事件的同时,数据库异常宕机后可能会引起数据丢失,所以要引起注意!当然使用临时表或者NOLOGGING选项,尽可能少产生redo日志,也是解决log file sync等待事件的方法之一。存储I/O资源紧张LGWR进程写redolog特征是连续顺序小I/O写,存储的IOPS能力对其影响最大。当存储I/O资源紧张时,LGWR进程写日志的速度就受到明显影响,从而出现log file sync等待事件。如果要确定是否是存储I/O资源紧张导致log file sync等待事件,我们通常情况下只要检查以下两方面:(1)检查存储的I/O资源是否紧张,如在AIX系统中可以通过topas命令观察磁盘的繁忙程度,如下所示:(2)检查系统每次等待log file parallel write等待事件和log file sync等待事件的时间差,如果两者时间接近,则说明存储I/O资源紧张是引起log file sync等待事件的主要原因。log file parallel write等待事件和log file sync等待事件的关系如下图所示:我们可以通过V$EVENT_HISTOGRAM视图观察log file parallel write等待事件消耗时间的分布情况,如下所示:SQL select event, wait_time_milli,wait_count2 from v$event_histogram3 where event = log file parallel write;EVENT WAIT_TIME_MILLI WAIT_COUNT-log file parallel write 1 22677log file parallel write 2 424log file parallel write 4 141log file parallel write 8 340log file parallel write 16 1401log file parallel write 32 812log file parallel write 64 391log file parallel write 128 21log file parallel write 256 6当由于存储I/O资源紧张而导致log file sync等待事件时,我们可以采取以下措施:1、如果有空闲的物理磁盘,且这些物理磁盘的I/O性能能满足系统要求,那么将logfile在线迁移至空闲物理盘中。如果空间允许,还可以考虑将数据库的UNDO表空间在线迁移至其他盘,从而释放I/O压力。2、如果在线日志设置了多组member,为了减少LGWR写日志操作,可以考虑删除其他member,只保留一组。CPU资源紧张主机CPU资源紧张从而导致LGWR进程获得不了CPU时间片也可能导致log file sync等待事件。某系统由于主机CPU资源紧张,而出现较多的log file sync等待事件,CPU资源如下所示:数据库的AWR报告显示log file sync等待比较严重,如下所示:事实上,LGWR进程写存储的速度并不慢,log file parallel write等待事件每次才等待2ms,如下所示:针对CPU资源紧张而导致log file sync等待事件,有以下几种解决方案:1、增加CPU资源,优化消耗CPU资源的语句,这是效果最为明显的解决方法,但同时成本也较高。2、在操作系统级别使用renice命令提交LGWR进程优先级,如果存在多颗CPU,为减少LGWR进程轮询CPU时间,可以将其绑定在某颗CPU上运行。3、在数据库级别设置隐含参数_high_priority_processes提高LGWR进程优先级。RAC节点之间SCN同步在RAC数据库中为了一致性读,需要将Commit SCN同步/传播到所有的节点上。SCN同步/传播的主要方法有两种:Lamport SCN 和 immediate commit propagation。其中immediate commit propagation这种方式就也被称为BOC(Broadcast On Commit)。Oracle 10gR1 及以下版本默认使用Lamport SCN,Lamport SCN方式即一个节点上的commit SCN 不保证立刻同步/传播到所有节点,也就是说可能延时同步/传播,对于一些实时性要求高的RAC数据库Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/传播到所有节点,手动修改参数MAX_COMMIT_PROPAGATION_DELAY=1。从Oracle 10gR2开始默认使用immediate commit propagation (BOC),即一个节点上的commit SCN 立刻同步/传播到所有节点(受隐含参数_immediate_commit_propagation控制,默认为true)。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。RAC节点之间SCN传递的指标可以在AWR报告中观察,如下所示:当log file sync等待事件是由于RAC节点之间SCN同步引起的,其解决方法如下:1、检查LMS进程数量是否足够。2、检查系统CPU资源是否足够。3、检查RAC节点之间的私有通信是否正常。4、设置隐含参数_immediate_commit_propagation为false,禁用immediate commit propagation特性。RAC节点之间CR块传递Oracle为了保证Instance Recovery实例恢复机制,而要求每一个current block在本地节点local instance被修改后(modify/update) 必须要将该current block相关的redo 写入到logfile 后(要求LGWR必须完成写入后才能返回),才能由LMS进程传输给其他节点使用。如下图所示:某客户数据库出现log file sync等待事件,正是由于这种机制引起的。AWR报告如下所示:当出现这种情况时,其解决方法如下:1、修改应用尽量减少跨节点取数据。2、修改隐含参数_cr_server_log_flush为fasle(默认为true),关闭CR块节点传输特性。控制文件争用LGWR进程写日志的同时会在控制文件中记录写进度。当控制文件争用而出现enq: CFcontention等待事件时,前台进程可能会出现LOG FILE

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论