latch:cache buffers chains的优化思路
数据块在buffer cache存放是以linked list方式存放的。当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于buffer cache中,检查相同的SQL语句是否存在于library cache中也是通过hash算法实现的。要判断block是否存在于buffer cache中,就需要扫描linked list(此处都是串行的,不能并发),获取block的信息。而扫描linked list必须获得一个latch,防止并发对linked list照成破坏,如果未能获得该latch,就会在数据库中标记一个latch: cache buffers chains这个等待事件。如果该block存在于buffer cache中就不需要物理读,如果不存在,就需要从磁盘读取该block到buffer cache中。为了能够读取,并修改该block,我们就需要pin住该block,防止并发对于该block造成破坏,所以如果别的session不能获得pin,同时会标记一个buffer busy waits等待事件。
一般产生CACHE BUFFERS CHAINS的原因有几个方面:1、buffer cache太少(也说明SQL语句效率低);2、热块挣用。(从oracle9i开始,对latch:cache buffer chains支持只读共享访问,这可以减少部分争用,但并不能完全消除争用。)
一、buffer cache太少(也说明SQL语句效率低)
应用程序执行多个相同的低效率SQL语句并发会话,这些SQL语句都设法得到相同的数据集。较多的逻辑读意味着较多的latch get操作,从而增加了锁存器争用。多个进程同时扫描大范围的索引或表时,可能广泛地发生cache buffers chains 锁存器争用。每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。
1、查看当前的等待事件 ( latch: cache buffers chains)
SQL> select event, count(*) from v$session
where wait_class <> 'Idle' group by event order by 2;
2、查看 latch: cache buffers chains事件相关的会话信息
SQL> select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='latch: cache buffers chains';
二、热块挣用
当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时,就会产生热块挣用。当多个会话争用cache buffers chains锁存器时,找出是否有热块的最好的方法是检查latch free等待事件的P1RAW参数值。
判断热块挣用的另一种方法是从 v$session_wait 视图获得锁存器地址后进行比较。v$session_wait的P1RAW就相当于子锁存器地址,若从 v$session_wait 视图获得的锁存器地址过多重复出现,就意味着对相应锁存器发生次数偏多,此时可解释为热快引起的争用。如果会话正在相同的锁存器地址上等待,就是热块。
SQL> select sid,p1raw,p2,p3,seconds_in_wait,wait_time,state from v$session_wait
where event='latch: cache buffers chains' order by 3,2;
查看热块的对象:
根据TCH值确认热块。注意块从LRU列表的冷端移动到热端时,TCH值将重置为0,所以判断的时候,要注意TCH为0的块不一定是冷块。
使用P1RAW=00000300DA316800为例子进行关联热快对象。
SQL> select a.hladdr,a.file#,a.dbablk,a.tch,a.obj,b.object_name from x$bh a, dba_objects b
where (a.obj = b.object_id or a.obj = b.data_object_id) and a.hladdr = '00000300DA316800'
union select hladdr,file#,dbablk,tch,obj,null from x$bh
where obj in (select obj from x$bh where hladdr = '00000300DA316800' minus select object_id from dba_objects minus select data_object_id from dba_objects) and hladdr = '00000300DA316800' order by 4;
若没有关于SQL语句的信息,也有方法间接判断是热块引起的问题,还是低效SQL语句引起的问题。v$latch_children视图中,比较子cache buffers chains锁存器相应的 child#、gets、sleeps值, 以此判断特定子锁存器上使用的次数和争用是否集中,利用以下语句,获取sleeps次数高的子锁存器。
SQL> select * from (select addr, child#, gets, sleeps from v$latch_children where name = 'cache buffers chains' order by sleeps desc)
where rownum < =20;
当结果中sleeps的值倾斜较大的时候就说明是热块挣用。
根据sleeps较高的addr确定哪些块是热块。
SQL> select hladdr,obj,(select object_name from dba_objects where (data_object_id is null and object_id = x.obj) or data_object_id = x.obj and rownum = 1) as object_name,dbarfil,dbablk,tch from x$bh x where hladdr ='&p1raw' order by hladdr, obj;
数据块在buffer cache存放是以linked list方式存放的。当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于buffer cache中,检查相同的SQL语句是否存在于library cache中也是通过hash算法实现的。要判断block是否存在于buffer cache中,就需要扫描linked list(此处都是串行的,不能并发),获取block的信息。而扫描linked list必须获得一个latch,防止并发对linked list照成破坏,如果未能获得该latch,就会在数据库中标记一个latch: cache buffers chains这个等待事件。如果该block存在于buffer cache中就不需要物理读,如果不存在,就需要从磁盘读取该block到buffer cache中。为了能够读取,并修改该block,我们就需要pin住该block,防止并发对于该block造成破坏,所以如果别的session不能获得pin,同时会标记一个buffer busy waits等待事件。 一般产生CACHE BUFFERS CHAINS的原因有几个方面:1、buffer cache太少(也说明SQL语句效率低);2、热块挣用。(从oracle9i开始,对latch:cache buffer chains支持只读共享访问,这可以减少部分争用,但并不能完全消除争用。) 一、buffer cache太少(也说明SQL语句效率低) 应用程序执行多个相同的低效率SQL语句并发会话,这些SQL语句都设法得到相同的数据集。较多的逻辑读意味着较多的latch get操作,从而增加了锁存器争用。多个进程同时扫描大范围的索引或表时,可能广泛地发生cache buffers chains 锁存器争用。每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。 1、查看当前的等待事件 ( latch: cache buffers chains) SQL> select event, count(*) from v$session where wait_class <> 'Idle' group by event order by 2; 2、查看 latch: cache buffers chains事件相关的会话信息 SQL> select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='latch: cache buffers chains'; 二、热块挣用 当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时,就会产生热块挣用。当多个会话争用cache buffers chains锁存器时,找出是否有热块的最好的方法是检查latch free等待事件的P1RAW参数值。 判断热块挣用的另一种方法是从 v$session_wait 视图获得锁存器地址后进行比较。v$session_wait的P1RAW就相当于子锁存器地址,若从 v$session_wait 视图获得的锁存器地址过多重复出现,就意味着对相应锁存器发生次数偏多,此时可解释为热快引起的争用。如果会话正在相同的锁存器地址上等待,就是热块。 SQL> select sid,p1raw,p2,p3,seconds_in_wait,wait_time,state from v$session_wait where event='latch: cache buffers chains' order by 3,2; 查看热块的对象: 根据TCH值确认热块。注意块从LRU列表的冷端移动到热端时,TCH值将重置为0,所以判断的时候,要注意TCH为0的块不一定是冷块。 使用P1RAW=00000300DA316800为例子进行关联热快对象。 SQL> select a.hladdr,a.file#,a.dbablk,a.tch,a.obj,b.object_name from x$bh a, dba_objects b where (a.obj = b.object_id or a.obj = b.data_object_id) and a.hladdr = '00000300DA316800' union select hladdr,file#,dbablk,tch,obj,null from x$bh where obj in (select obj from x$bh where hladdr = '00000300DA316800' minus select object_id from dba_objects minus select data_object_id from dba_objects) and hladdr = '00000300DA316800' order by 4; 若没有关于SQL语句的信息,也有方法间接判断是热块引起的问题,还是低效SQL语句引起的问题。v$latch_children视图中,比较子cache buffers chains锁存器相应的 child#、gets、sleeps值, 以此判断特定子锁存器上使用的次数和争用是否集中,利用以下语句,获取sleeps次数高的子锁存器。 SQL> select * from (select addr, child#, gets, sleeps from v$latch_children where name = 'cache buffers chains' order by sleeps desc) where rownum < =20; 当结果中sleeps的值倾斜较大的时候就说明是热块挣用。 根据sleeps较高的addr确定哪些块是热块。 SQL> select hladdr,obj,(select object_name from dba_objects where (data_object_id is null and object_id = x.obj) or data_object_id = x.obj and rownum = 1) as object_name,dbarfil,dbablk,tch from x$bh x where hladdr ='&p1raw' order by hladdr, obj;
latch:cache buffers chains的优化思路的更多相关文章
- 关于latch: cache buffers chains的sql优化
前段时间,优化了一些耗buffer比较多的sql,但是CPU使用率还是没下来 . 查看操作系统CPU使用率 查看awr,发现又有一条超级耗性能的sql冒出来了. 该SQL每次执行耗费3e多个buffe ...
- latch: cache buffers chains故障处理总结(转载)
一大早就接到开发商的电话,说数据库的CPU使用率为100%,应用相应迟缓.急匆匆的赶到现场发现进行了基本的检查后发现是latch: cache buffers chains 作祟,处理过程还算顺利,当 ...
- latch: cache buffers chains故障处理总结
一大早就接到开发商的电话,说数据库的CPU使用率为100%,应用相应迟缓.急匆匆的赶到现场发现进行了基本的检查后发现是latch: cache buffers chains 作祟,处理过程还算顺利,当 ...
- [转帖]深入理解latch: cache buffers chains
深入理解latch: cache buffers chains http://blog.itpub.net/12679300/viewspace-1244578/ 原创 Oracle 作者:wzq60 ...
- 【转载】latch: cache buffers chains
本文转自惜分飞的博客,博客原文地址:www.xifenfei.com/1109.html,支持原创,分享知识! 当一个数据块读入sga区,相应的buffer header会被放置到hash列表上,我们 ...
- Oracle索引失效问题:WHERE C1='' OR C2 IN(SubQuery),并发请求时出现大量latch: cache buffers chains等待
问题描述: 项目反馈某功能响应时间很长,高峰期时系统整体响应很慢... 获取相应的AWR,问题确实比较严重,latch: cache buffers chains等待,因为这些会话SQL执行时间太长, ...
- 案例:latch: cache buffers chains event tuning
前两天对oracle数据库(single instance)进行了迁移升级从10.2.0.4 升到11.2.0.3,有一个项目迁完后第二天,cpu负载升到了130更高(16cpus). 向用户询问后使 ...
- 又是latch: cache buffers chains惹得祸
前言 一大早,客户给我打电话说: xx,应用很慢,查询数据总是超时,让我看看... 根据多年DBA经验,首当其冲的肯定是去查询数据库在这段时间都在干嘛. 分析 导出awr报告分析 1). 数据库在此时 ...
- cache buffers chains latch
cache buffers chains latch 从 Oracle 8i Database 开始, 散列锁存器<-------(1:m)------>hash bucket<-- ...
随机推荐
- HNOI 2008:水平可见直线
Description 在xoy直角坐标平面上有n条直线L1,L2,...Ln,若在y值为正无穷大处往下看,能见到Li的某个子线段,则称Li为 可见的,否则Li为被覆盖的. 例如,对于直线: L1:y ...
- Devexpress 之gridControl双击行事件
MouseDown事件 protected internal void gridControl1_MouseDown(object sender, MouseEventArgs e) { DevExp ...
- Ajax初步实现页面局部内容更替
类似于QQ邮箱的那种局部页面跳转,单页应用常用到,目前很多网页都是这种,但是弊端就是一次加载过多资源,首次加载卡出翔啊
- Android项目开发全程(三)-- 项目的前期搭建、网络请求封装是怎样实现的
在前两篇博文中已经做了铺垫,下面咱们就可以用前面介绍过的内容开始做一个小项目了(项目中会用到Afinal框架,不会用Afinal的童鞋可以先看一下上一篇博文),正所谓麻雀虽小,五脏俱全,这在里我会尽量 ...
- .net常見面試題(四)
1. .Net.C#.VisualStudio之间的关系是什么? .Net一般指的是.Net Framework,提供了基础的.Net类,这些类可以被任何一种.Net编程语言调用,.Net Frame ...
- Python串口操作纸币器1
公司需要纸币器开发,参考纸币器文档和网上的一篇vb版本,代码如下: # -*- coding:utf-8 -*- # Author: Pete Yim<xpHook@gmail.com> ...
- JNI 从C文件向Java文件传递多个参数
JNI C主函数 #include <jni.h> #include <string.h> #include <android/log.h> #include &q ...
- DS1302-演示代码
参考DS1302数据手册,尽管数据手册是英文,但是很有帮助,再结合网上众多的代码写出了下面这个例子,除了涓流充电(trickle charger)功能没使用外,内部的RAM和寄存器功能都使用到了,包括 ...
- Duff and Meat - CF 588A
题目大意:有一个人他有每天需要吃ai千克肉,并且当天肉的价格是pi,问N天后他至少需要花费多少钱买肉. 分析:注意一下,他是可以提前买好肉放着的. 代码如下: #include<iostream ...
- cdn加速对门户网站产生的影响
满意的用户体验是门户网站吸引和留住用户的必备条件.据统计,如果等待网页打开的时间超过8秒,将会有超过30%的用户放弃等待,造成严重的用户流失,降低了用户的体验度和忠诚度.门户网站内容涉及面多,涵盖文字 ...