latch free 三板斧-凯发app官方网站

--正在等什么latch
select name, 'child '||child#, gets, misses, sleeps
from v$latch_children
where addr='&p1raw'
union
select name, null, gets, misses, sleeps
from v$latch
where addr='&p1raw';
--这个似乎更简单
select * from v$latchname
where latch# = &p2;
--整体情况
select * from (
select latch#, name, gets, misses, sleeps
from v$latch
where sleeps>0
order by sleeps desc) where rownum<11;
-- 确定闩锁活动是否集中在集合中的一个特定闩锁上
select addr, latch#, gets, misses, sleeps
from v$latch_children
where sleeps>0
and latch# = &latch_number_wanted
order by sleeps;
如果有多行，需要注意的重要一点是 sleeps 是否合理分布，或者是否有一个或两个子闩锁负责 80% 的 sleeps。如果争用集中在一个或两个子锁上，请记下子latch看到了问题 - 请注意 addr 列
还可以查询
v$latch_holder --是否一直出现相同的会话
v$session_event

awr里看latch 的统计结果

关于此等待事件的专业讲解：
某些会话正在等待闩锁释放等待但无法获得闩锁。闩锁释放等待保护共享池中的缓冲区缓存或库缓存等内存结构。它们被设计为在很短的时间内举行。如果闩锁不可用，会话将进入睡眠状态并稍后重试该操作。等待闩锁可能很昂贵，因为在等待闩锁时会话可能会在 cpu 上旋转。

shared pool latch
共享池闩锁的争用是由于共享池容量不足、sql 未共享或大量使用数据字典。确保共享池对于应用程序负载足够大，并且尽可能共享 sql 语句

library cache latch
库缓存锁存器的争用可能与共享池锁存器的争用有关，因为库缓存位于共享池内。库缓存闩锁争用通常是由于高解析或共享池过小。如果原因是过度的硬解析，那么您需要查看为什么游标被解析得如此之多。由于 oracle 尝试重用以前解析的应用程序代码，因此假设它是可共享的，则不需要重新解析它。如果库缓存中没有 sql 的已解析表示，则 oracle 将需要对 sql 进行硬解析

cache buffers chains
该锁存器用于保护缓冲区缓存中的缓冲区列表。首先固定的进程将获得一个锁存器，因此其他进程不会更改数据。一旦块被取消固定，第二个用户就可以使用它，依此类推。多个会话可能需要同一个块，从而导致争用。
看一看awr中sql ordered by gets中的sql、segments by logical reads中对象

阅读(810) | 评论(0) | 转发(0) |

上一篇：创建索引遇到 ora-08104

下一篇：找达梦数据库端口号

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们