latch:cache buffers chains
发生cache buffers chains锁存器争用的代表性情况是:低效的sql和hot block.
低效的sql:
每个逻辑读取需要一个latch get操作和一个cpu.从latch get例程中获得的唯一方法是获得锁存器.必须确定争用cache buffers chains锁存器的sql语句,并且调整它们以减少逻辑读取的数量.每次executions都带有高buffer_gets的sql语句的主要原因.
适当地使用parallelquery也能成为减少cache buffers chains锁存器争用的方法.parallel query不经过sga,而是直接读取数据文件
上所需的数据,因此高速缓冲区的扫用问题本身不存在.但是parallel query是为了处理大量数据使用的,所以不推荐为锁存器争用的一般解决方案.
hot block:
(1)通过赋予较高的pctfree值或使用小块,减少块争用.
(2)使用partition方法尽量将行物理地插入到另外的块.
(3)只对有问题的块行删除后再执行插入工作,此方法只对表可行.
解决表的cache buffers chains锁存器争用相对比较容易,因为分散行的方法非常多.但索引上的争用问题相当复杂.
latch:cache buffers lru chain
oracle在如下情况下必须获得cache buffers lru chain锁存器.
(1)进程欲读取还没有装载到内存上的块时,通过查询lru列分配到所需空闲缓冲区,在此过程中需要cache buffers lru chain锁存器.
(2)dbwr为了将脏缓冲区记录到文件上,查询lruw列,将相应缓冲区移动到lru列的过程中也要获得cache buffers lru chain锁存器.以下情况将脏缓冲区记录到文件里.oracle 进程为了获得空闲缓冲区,向dbwr请求记录脏缓冲区时;oracle进程为执行parallel query或tablespace backup,truncate/drop等工作,请求记录相关对象的脏缓冲区时;由于周期性或管理上的原因检查点(checkpointing)被执行 时.
cache buffers lru chain锁存器争用的最重要的原因是过多请求空闲缓冲区.低效的sql语句是过多请求空闲缓冲区的最典型情况,若多个会话同时执行低效的sql语句,则 在查询空闲缓冲区过程中和记录脏缓冲区的过程中,为了获取buffers lru chain锁存器发生争用.调整语句,减少逻辑读和物理读.
cache buffers chains和cache buffers lru chain的差别是:若是多个会话同时扫描同一个表或索引时,则发生cache buffers chains锁存器争用的概率高,因为对相同chain发生了争用.但是多个会话同时扫描不同表或索引时,发生cache buffers lru chains锁存器争用的概率高.cache buffers lru chain争用的另一个重要特点就是伴随着物理i/o.
高速缓冲区过小或检查点周期过短时,也会增加cache buffers lru chain争用.
buffer busy waits/ready by other session
发生物理i/o后将新块加载到sga需要创建新的缓冲区,因此最实创建缓冲区的进程以exclusive模式获得buffer lock.
减少select/select引起的read by other session等待的方法,整理结果如下:
应该通过对sql进行优化,以便能以最少的i/o获得所需的结果.
若sga大小(或高速缓冲区大小)比系统全局的i/o小,就不能只通过sql调优解决问题,还需要增加sga物理大小.
select/update引起的buffer lock争用会在如下情况下发生:
特定进程修改特定表,数据的过去映象记录在撤销块.
很多进程试图同时(或之后)读取已修改的数据.
撤销块争用的原因在于oracle的最基本的机制中的一致性读取.select会话读取数据块时,由于执行了update成为已修改状态,
基本上利用撤销块读取过去状态的数据.这就是一致性读取,在此过程中创建cr块.这时,许多会话在同一时刻试图读取撤销块,撤销块发生与 select/select情况相同状况的buffer lock争用,因此发生对read by other session事件的等待.
insert/insert引起的buffer lock争用,大部份是错误的空闲列的值引发的.
减少因insert/insert引起的buffer busy wait等待的方法:
如果在不能使用assm环境下,考虑系统的负荷适当赋予freelists,freelist groups值,与空闲列相关的属性使用缺省值将相当危险.
9i以上版本起尽量使用assm,使用assm时,在任何环境下都能避免非常严重的性能下降.
update/update引发buffer lock争用时有多种多样的解决方法,发生buffer lock争用的根本原因就是不同的行位于同一个块,因此将不同行分散到不同块,这就是最普遍使用的解决方法.(1)取较高的pctfree值(2)利用 partitioning方法将各行物理分配到其它的块(3)使用较小的块.
减少buffer lock争用的方法:
(1)减少select/select引发的read by other session等待的最好方法是通过sql的最优化利用最少的i/o获得需要的结果.如果通过这个操作也不能解决问题,就应该检查sga大小适当与否.
(2)select/update引发的read by other session等待与select/select引起的read by other session等待的解决方法相同.
(3)insert/insert引发的buffer busy waits等待,通过使用适当的段空间管理方法得以解决.oracle 9i以上版本推荐使用assm.
oracle 8i则要合理设定freelists值.与事务量相比freelists值过小时,buffer lock引起的争用广泛出现.光靠freelists值不能解决问题时,调高_bump_highwater_mark_count隐含数值也是有帮助的.
(4)update/update引发的buffer busy waits等待,可以通过采用避免对相同块同时执行update的方法得以解决.创建把update形式考虑周全的最优的partitioning,将成 为最好的解决方法.通过取高pctfree或使用较小的块可以将块分散,因此能减少buffer lock争用.但必须通过测试检验是否有负面影响.
write complete waits
write complete waits等待与buffer busy waits等待相同,可以通过buffer lock争用引起的等待进行分类.dbwr将脏缓冲区记录到磁盘上的期间,对缓冲区以exclusive模式占有buffer lock.这时,读取或修改缓冲区的其它进程需要等待此项工作结束,这时等待write
complete waits 事件.
write complete waits等待普遍出现时,与其说是应用程序的问题,不如说是dbwr性能问题的可能性非常高.实际上,服务器进程读取正在写入到磁盘的缓冲区的概率不高,妈便如此还存在等待,这说明dbwr将脏缓冲区的数据写入磁盘的时间过长.
dbwr性能缓慢的理由:
(1)i/o系统的性能缓慢时.如果dbwr上显示的db file parallel write等待时间较长,就可以判断存在i/o系统问题.在dbwr上,db file parallel write等待时间变长,则服务器进程连续经历free buffer waits等待或write complete waits等待.大家都知道,组合使用祼设备和异步i/o是改善i/o性能的最好方法.os层面上使用direct i/o也有助于性能.使用direct i/o时,cpu数量若充分多,应该调整db_writer_processes值,可以增加dbwr的数量.oracle的基本dbwr数量等于 cpu_count/8.
(2)dbwr的工作量过多时.频繁发生检查点时,dbwr的活动量过多,因此dbwr的性能可能下降.dbwr的性能下降,导致系统全局性能下降,取过 小的fast_start_mttr_target值时,频繁发生增量检查点.重做日志文件过小时,发生频繁的日志文件切换,因此检查点工作会增 加.parallel query引发direct path read时,还有truncdate,drop,host backup时也会发生检查点.虽然i/o系统不存在性能问题,但还是出现write complete waits等待,就应该查看是否存在给dbwr带来不必要的负荷的因素.
(3)作为间接改善dbwr性能的方法,也被推荐适当使用多重缓冲池.通过提高高速缓冲区的效率,以此降低内存上的数据写入到磁盘上的频度,进而降低write complete waits等待发生的概率.
free buffer waits
发生free buffer waits等待的理由:
(1)低效的sql
(2)过小的高速缓冲区
(3)dbwr的性能下降
enq:tc-contention
tc:thread checkpoint lock或tablespace checkpoint lock
enq:tc-contention等待即使在没有多个进程引起争用的情况下,也可以发生.只有在进行由服务器进程引发的检查点工作同步过程中发生.
enq:tc-contention等待发生的代表案例:parallel query,tablespace host backup.
paralle query发生检查点的原因是slave session引起的direct path read.
以下三种情况下使用direct path read(或physical read direct)方式的读取
(1)内存区域上不能完成排序工作时,在临时段的区域里存储和读取的过程中,发生direct path write,direct path read.这时的等待事件可通过direct path read temp,direct path write temp观察.
(2)slave session为了扫描直接读取的数据文件时,使用direct path read.这时等待事件通过direct path read事件观察.
(3)若判断是因i/o系统的性能下降,导致不能将块以足够块的速度读取,oracle为了临时方便会使用direct path read.
执行alter tablespace ...begin backup后,将属于此表空间的所有高速缓冲区的脏块记录到磁盘上,这个过程经历enq:tc-contention等待.
enq:ci-contention,enq:ro-contention
ci:cross instance
oracle对特定表执行truncate之前,应对位于高速缓冲区上的表数据的脏缓冲区执行检查点工作.因为即使在执行truncate过程中发生故 障,也需要能恢复数据.扫行truncate的服务器进程,需要等到truncate工作结束,通常是通过enq:ci-contention等待现象观 察的.
解决方法:
(1)升级为oracle 10gr2.10gr2上大幅改善了对象检查点算法,因此它引起的性能问题大大减少.
(2)改善dbwr的性能.
(3)确认sga是否过大.为执行检查点检索脏缓冲区,高速缓冲区越大,需要管理的脏缓冲区量也越多.
truncate或drop等删除对象使用空间的工作,一直等到因ckpt和dbwr彻底删除,在这期间等待enq:ro-fast object reuse事件.
发生cache buffers chains锁存器争用的代表性情况是:低效的sql和hot block.
低效的sql:
每个逻辑读取需要一个latch get操作和一个cpu.从latch get例程中获得的唯一方法是获得锁存器.必须确定争用cache buffers chains锁存器的sql语句,并且调整它们以减少逻辑读取的数量.每次executions都带有高buffer_gets的sql语句的主要原因.
适当地使用parallelquery也能成为减少cache buffers chains锁存器争用的方法.parallel query不经过sga,而是直接读取数据文件
上所需的数据,因此高速缓冲区的扫用问题本身不存在.但是parallel query是为了处理大量数据使用的,所以不推荐为锁存器争用的一般解决方案.
hot block:
(1)通过赋予较高的pctfree值或使用小块,减少块争用.
(2)使用partition方法尽量将行物理地插入到另外的块.
(3)只对有问题的块行删除后再执行插入工作,此方法只对表可行.
解决表的cache buffers chains锁存器争用相对比较容易,因为分散行的方法非常多.但索引上的争用问题相当复杂.
latch:cache buffers lru chain
oracle在如下情况下必须获得cache buffers lru chain锁存器.
(1)进程欲读取还没有装载到内存上的块时,通过查询lru列分配到所需空闲缓冲区,在此过程中需要cache buffers lru chain锁存器.
(2)dbwr为了将脏缓冲区记录到文件上,查询lruw列,将相应缓冲区移动到lru列的过程中也要获得cache buffers lru chain锁存器.以下情况将脏缓冲区记录到文件里.oracle 进程为了获得空闲缓冲区,向dbwr请求记录脏缓冲区时;oracle进程为执行parallel query或tablespace backup,truncate/drop等工作,请求记录相关对象的脏缓冲区时;由于周期性或管理上的原因检查点(checkpointing)被执行 时.
cache buffers lru chain锁存器争用的最重要的原因是过多请求空闲缓冲区.低效的sql语句是过多请求空闲缓冲区的最典型情况,若多个会话同时执行低效的sql语句,则 在查询空闲缓冲区过程中和记录脏缓冲区的过程中,为了获取buffers lru chain锁存器发生争用.调整语句,减少逻辑读和物理读.
cache buffers chains和cache buffers lru chain的差别是:若是多个会话同时扫描同一个表或索引时,则发生cache buffers chains锁存器争用的概率高,因为对相同chain发生了争用.但是多个会话同时扫描不同表或索引时,发生cache buffers lru chains锁存器争用的概率高.cache buffers lru chain争用的另一个重要特点就是伴随着物理i/o.
高速缓冲区过小或检查点周期过短时,也会增加cache buffers lru chain争用.
buffer busy waits/ready by other session
发生物理i/o后将新块加载到sga需要创建新的缓冲区,因此最实创建缓冲区的进程以exclusive模式获得buffer lock.
减少select/select引起的read by other session等待的方法,整理结果如下:
应该通过对sql进行优化,以便能以最少的i/o获得所需的结果.
若sga大小(或高速缓冲区大小)比系统全局的i/o小,就不能只通过sql调优解决问题,还需要增加sga物理大小.
select/update引起的buffer lock争用会在如下情况下发生:
特定进程修改特定表,数据的过去映象记录在撤销块.
很多进程试图同时(或之后)读取已修改的数据.
撤销块争用的原因在于oracle的最基本的机制中的一致性读取.select会话读取数据块时,由于执行了update成为已修改状态,
基本上利用撤销块读取过去状态的数据.这就是一致性读取,在此过程中创建cr块.这时,许多会话在同一时刻试图读取撤销块,撤销块发生与 select/select情况相同状况的buffer lock争用,因此发生对read by other session事件的等待.
insert/insert引起的buffer lock争用,大部份是错误的空闲列的值引发的.
减少因insert/insert引起的buffer busy wait等待的方法:
如果在不能使用assm环境下,考虑系统的负荷适当赋予freelists,freelist groups值,与空闲列相关的属性使用缺省值将相当危险.
9i以上版本起尽量使用assm,使用assm时,在任何环境下都能避免非常严重的性能下降.
update/update引发buffer lock争用时有多种多样的解决方法,发生buffer lock争用的根本原因就是不同的行位于同一个块,因此将不同行分散到不同块,这就是最普遍使用的解决方法.(1)取较高的pctfree值(2)利用 partitioning方法将各行物理分配到其它的块(3)使用较小的块.
减少buffer lock争用的方法:
(1)减少select/select引发的read by other session等待的最好方法是通过sql的最优化利用最少的i/o获得需要的结果.如果通过这个操作也不能解决问题,就应该检查sga大小适当与否.
(2)select/update引发的read by other session等待与select/select引起的read by other session等待的解决方法相同.
(3)insert/insert引发的buffer busy waits等待,通过使用适当的段空间管理方法得以解决.oracle 9i以上版本推荐使用assm.
oracle 8i则要合理设定freelists值.与事务量相比freelists值过小时,buffer lock引起的争用广泛出现.光靠freelists值不能解决问题时,调高_bump_highwater_mark_count隐含数值也是有帮助的.
(4)update/update引发的buffer busy waits等待,可以通过采用避免对相同块同时执行update的方法得以解决.创建把update形式考虑周全的最优的partitioning,将成 为最好的解决方法.通过取高pctfree或使用较小的块可以将块分散,因此能减少buffer lock争用.但必须通过测试检验是否有负面影响.
write complete waits
write complete waits等待与buffer busy waits等待相同,可以通过buffer lock争用引起的等待进行分类.dbwr将脏缓冲区记录到磁盘上的期间,对缓冲区以exclusive模式占有buffer lock.这时,读取或修改缓冲区的其它进程需要等待此项工作结束,这时等待write
complete waits 事件.
write complete waits等待普遍出现时,与其说是应用程序的问题,不如说是dbwr性能问题的可能性非常高.实际上,服务器进程读取正在写入到磁盘的缓冲区的概率不高,妈便如此还存在等待,这说明dbwr将脏缓冲区的数据写入磁盘的时间过长.
dbwr性能缓慢的理由:
(1)i/o系统的性能缓慢时.如果dbwr上显示的db file parallel write等待时间较长,就可以判断存在i/o系统问题.在dbwr上,db file parallel write等待时间变长,则服务器进程连续经历free buffer waits等待或write complete waits等待.大家都知道,组合使用祼设备和异步i/o是改善i/o性能的最好方法.os层面上使用direct i/o也有助于性能.使用direct i/o时,cpu数量若充分多,应该调整db_writer_processes值,可以增加dbwr的数量.oracle的基本dbwr数量等于 cpu_count/8.
(2)dbwr的工作量过多时.频繁发生检查点时,dbwr的活动量过多,因此dbwr的性能可能下降.dbwr的性能下降,导致系统全局性能下降,取过 小的fast_start_mttr_target值时,频繁发生增量检查点.重做日志文件过小时,发生频繁的日志文件切换,因此检查点工作会增 加.parallel query引发direct path read时,还有truncdate,drop,host backup时也会发生检查点.虽然i/o系统不存在性能问题,但还是出现write complete waits等待,就应该查看是否存在给dbwr带来不必要的负荷的因素.
(3)作为间接改善dbwr性能的方法,也被推荐适当使用多重缓冲池.通过提高高速缓冲区的效率,以此降低内存上的数据写入到磁盘上的频度,进而降低write complete waits等待发生的概率.
free buffer waits
发生free buffer waits等待的理由:
(1)低效的sql
(2)过小的高速缓冲区
(3)dbwr的性能下降
enq:tc-contention
tc:thread checkpoint lock或tablespace checkpoint lock
enq:tc-contention等待即使在没有多个进程引起争用的情况下,也可以发生.只有在进行由服务器进程引发的检查点工作同步过程中发生.
enq:tc-contention等待发生的代表案例:parallel query,tablespace host backup.
paralle query发生检查点的原因是slave session引起的direct path read.
以下三种情况下使用direct path read(或physical read direct)方式的读取
(1)内存区域上不能完成排序工作时,在临时段的区域里存储和读取的过程中,发生direct path write,direct path read.这时的等待事件可通过direct path read temp,direct path write temp观察.
(2)slave session为了扫描直接读取的数据文件时,使用direct path read.这时等待事件通过direct path read事件观察.
(3)若判断是因i/o系统的性能下降,导致不能将块以足够块的速度读取,oracle为了临时方便会使用direct path read.
执行alter tablespace ...begin backup后,将属于此表空间的所有高速缓冲区的脏块记录到磁盘上,这个过程经历enq:tc-contention等待.
enq:ci-contention,enq:ro-contention
ci:cross instance
oracle对特定表执行truncate之前,应对位于高速缓冲区上的表数据的脏缓冲区执行检查点工作.因为即使在执行truncate过程中发生故 障,也需要能恢复数据.扫行truncate的服务器进程,需要等到truncate工作结束,通常是通过enq:ci-contention等待现象观 察的.
解决方法:
(1)升级为oracle 10gr2.10gr2上大幅改善了对象检查点算法,因此它引起的性能问题大大减少.
(2)改善dbwr的性能.
(3)确认sga是否过大.为执行检查点检索脏缓冲区,高速缓冲区越大,需要管理的脏缓冲区量也越多.
truncate或drop等删除对象使用空间的工作,一直等到因ckpt和dbwr彻底删除,在这期间等待enq:ro-fast object reuse事件.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28539951/viewspace-1264948/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/28539951/viewspace-1264948/
417
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
