- 浏览: 959198 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
孤星119:
好熟悉的数据库字段啊, 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace:
quxiaoyong 写道遇到个问题,网上一搜,全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong:
遇到个问题,网上一搜,全他妈这篇文章。你转来转去的有意思吗?
数据库连接错误ORA-28547 -
hctech:
关于version count过高的问题,不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace:
invalid 写道写的不错,我根据这个来安装,有点理解错误了 ...
AIX 配置vncserver
数据库中的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等待事件的原因有以下几种:
事务过度的提交,即应用程序过度commit或者rollback。
存储I/O资源紧张,导致lgwr进程写速度缓慢。
CPU资源紧张,lgwr进程获得不了响应的CPU时间片。
RAC节点之间SCN同步。
RAC节点之间CR块传递。
控制文件争用。
不同的原因,其解决方法会不同,当多种原因混合在一起时,则需要进行综合考虑。
事务过度提交
事务过度提交是引起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_count
2 from v$event_histogram
3 where event = 'log file parallel write';
EVENT WAIT_TIME_MILLI WAIT_COUNT
---------------------------------------------------
log file parallel write 1 22677
log file parallel write 2 424
log file parallel write 4 141
log file parallel write 8 340
log file parallel write 16 1401
log file parallel write 32 812
log file parallel write 64 391
log file parallel write 128 21
log 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: CF–contention等待事件时,前台进程可能会出现LOG FILE SYNC等待。AWR报告部分数据如下所示:
由于LGWR进程写日志的过程中需要更新控制文件。当RMAN操作比较频繁时(如利用RMAN批量删除归档),服务器进程也会更新控制文件,所以多个会话同时更新控制文件时可能会引起enq:CF–contention等待事件。当LGWR进程获得不了CF锁时,可能导致LOG FILE SYNC等待。这个案例再次表明了Oracle是一台巨大的同步机器,看起来风马牛不相及的东西,往往存在着相互因果关系。
事务过度的提交,即应用程序过度commit或者rollback。
存储I/O资源紧张,导致lgwr进程写速度缓慢。
CPU资源紧张,lgwr进程获得不了响应的CPU时间片。
RAC节点之间SCN同步。
RAC节点之间CR块传递。
控制文件争用。
不同的原因,其解决方法会不同,当多种原因混合在一起时,则需要进行综合考虑。
事务过度提交
事务过度提交是引起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_count
2 from v$event_histogram
3 where event = 'log file parallel write';
EVENT WAIT_TIME_MILLI WAIT_COUNT
---------------------------------------------------
log file parallel write 1 22677
log file parallel write 2 424
log file parallel write 4 141
log file parallel write 8 340
log file parallel write 16 1401
log file parallel write 32 812
log file parallel write 64 391
log file parallel write 128 21
log 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: CF–contention等待事件时,前台进程可能会出现LOG FILE SYNC等待。AWR报告部分数据如下所示:
由于LGWR进程写日志的过程中需要更新控制文件。当RMAN操作比较频繁时(如利用RMAN批量删除归档),服务器进程也会更新控制文件,所以多个会话同时更新控制文件时可能会引起enq:CF–contention等待事件。当LGWR进程获得不了CF锁时,可能导致LOG FILE SYNC等待。这个案例再次表明了Oracle是一台巨大的同步机器,看起来风马牛不相及的东西,往往存在着相互因果关系。
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 513BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 436Oracle管理云服务(OMC)的大数据平台,自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 4162019年7月22日,受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 783某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1349性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 464从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 1899数据库的启动是一个相当复杂的过程。比如,Oracle在启动之前 ... -
怎么样彻底删除数据库?
2018-09-18 11:10 546Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 803LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1192“一朝被蛇咬,十年怕井绳”。在没被“蛇”咬之前,很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1083在DTCC 2018发表《如何落地智能化运维》演讲,主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 527问题一:ping不通问题 在虚拟机上安装好linux系统后, ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 888即日起,不定期更新《OracleDBA实战攻略》一书电子版,请 ... -
Oracle 12c新特性
2018-05-11 10:33 848查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3921操作系统:RHEL6.5 数据库版本:11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 62911g rac安装在二节点跑脚本一般会报此错误: 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 750故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2466由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈buffer cache的优化思路
2014-03-05 11:22 1647BUFFER CACHE作为数据块缓冲区,不是一块简单的内存区 ...
相关推荐
log file sycn是ORACLE里最普遍的等待事件之一,一般log file sycn的等待时间都非常短 1-5ms,不会有什么问题,但是一旦出问题,往往都比较难解决。什么时候会产生log file sync等待?
Tuning 'log file sync' event waits In this blog entry, we will discuss strategies and techniques to resolve 'log file sync' waits. This entry is intended to show an approach based upon scientific ...
Oracle log file sync等待事件优化浅析.pdf
ib_logfile0ib_logfile0ib_logfile0
图文并茂,非常详细的介绍Log File Sync机制,对oracle调优很有帮助
LogToFile ↓支持一下 Android a simple and practical to print to local phone logs Log files open source The log file is written to the tools, the priority SD card -> external memory -> internal ...
my logfile c source codemy logfile c source codemy logfile c source codemy logfile c source codemy logfile c source codemy logfile c source codemy logfile c source code
log file sync(ms) db file scattered read(ms) #IO WorkLoad Oracle IOPS Oracle MBPS db file sequential read db file scattered read log file parallel write log file sync physical reads physical writes ...
install.log文件,找到卸载工具unwise32.exe,双击打开,即可实现方便轻松干净完全卸载。
Mysql可以正常启动,但innodb的表无法使用 在错误日志里你会看到如下输出: InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes 现在需要做的事情就是把原来的 innodb 的ib_logfile×...
本人常用C++类 日志文件类 LogFile.rar 本人将陆续上传多年来经常复用的C++代码,指在抛砖引玉。 上分是为了请各位留言和评价。
两步,帮助大家很容易实现卸载... (1)下载压缩包并解压得到install.log文件 (2)找到License的默认安转路径,找到卸载工具unwise32.exe,双击打开,选择(1)步下载的install.log文件,并点击next,即可实现完全卸载
强烈推荐,arcgis卸载出现,install.log文件复制到bin目录,找到卸载工具unwise32.exe
debug log file.log
logfile
Memtester Logfile Sample 4.3.0
fileSync = require('gulp-file-sync'); gulp.task('sync', function() { gulp.watch(['src/*.*'], function() { fileSync('src', 'dest', {recursive: false}); }); });API 列表fileSync('...
新版本的log_to_file,可以将收到的csi数据以时间戳命名。
NTFS取代了文件分配表(FAT)文件系统,为Microsoft的Windows系列操作系统提供文件系统。NTFS对FAT和HPFS(高性能文件系统)作了若干改进,...NTFS 是一个日志文件系统,使用 NTFS 日志($Logfile)记录卷更改元数据。