欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 财经 > 创投人物 > Oracle如何解决LATCH:CACHE BUFFERS CHAINS

Oracle如何解决LATCH:CACHE BUFFERS CHAINS

2025/5/21 21:31:18 来源:https://blog.csdn.net/weixin_46593978/article/details/148082476  浏览:    关键词:Oracle如何解决LATCH:CACHE BUFFERS CHAINS

CACHE BUFFERS CHAINS LATCH主要用于保护HASH CHAIN结构。一个CACHE BUFFERS CHAINS LATCH保护着多条HASH CHAIN。可以通过查看隐含参数_db_block_hash_latches的值或者查询vlatch_children视图获得系统中CACHE BUFFER CHAIN LATCH的数量。目前系统中CACHE BUFFER CHAIN LATCH的数量为262144个,如下所示:

SQL> select count(*) from v$latch_children where name='cache buffers chains';

通过查看隐含参数_db_block_hash_buckets得知当前系统的HASH BUCKET数量为8388608,由于HASH BUCKETS和HASH CHAIN是一一对应关系,这也就意味着目前一个CACHE BUFFERS CHAINS LATCH需要保护8388608/262144=32个HASH CHAIN。由于CACHE BUFFERS CHAINS LATCH和HASH BUCKETS的数量随着BUFFER CACHE的增大而增多,所以随着BUFFER CACHE的增大,不同的数据块可能会被进一步分散到不同的HASH CHAIN中,从而降低HASH CHAIN争用的概率,从这个角度来说,在系统资源充足的前提下,增大BUFFER CACHE 没坏处。
前面提到,CACHE BUFFERS CHAINS LATCH主要用于保护HASH CHAIN内存结构,在以下两种情况下服务器进程需要获得CACHE BUFFERS CHAINS LATCH:
服务进程需要扫描HASH CHAIN中的数据块时。
服务器进程将数据块挂载到HASH CHAIN时。
LATCH: CACHE BUFFERS CHAINS等待事件的P1和P1RAW值表示CACHE BUFFERS CHAINS LATCH的地址,当发生LATCH: CACHE BUFFERS CHAINS等待事件时,可以通过V S E S S I O N W A I T 的 P 1 R A W 和 X SESSION_WAIT的P1RAW和X SESSIONWAITP1RAWXBH、DBA_OBJECTS关联来获取引起LATCH: CACHE BUFFERS CHAINS的对象,如下所示:
select sid, p1raw, p2, p3, seconds_in_wait, wait_time, state from v$session_wait
where event = ‘latch free’ order by p2, p1raw;–Oracle 10g以上latch free用cache buffers chains代替

– Using the P1RAW from the above example (00000400837D7800).
select a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name from xKaTeX parse error: Expected 'EOF', got '#' at position 143: …ct hladdr, file#̲, dbablk, tch, …bh
where obj in (select obj from x$bh where hladdr = ‘070000003469A7D8’
minus select object_id from dba_objects
minus select data_object_id from dba_objects) and
hladdr = ‘070000003469A7D8’
order by 4;
当发生LATCH:CACHE BUFFERS CHAINS等待事件时,不能简单地扩大隐含参数_db_block_hash_latches来缓减CACHE BUFFERS CHAINS LATCH争用,而是应该进一步定位发生该问题的深层次原因。一般来讲,发生LATCH:CACHE BUFFERS CHAINS等待事件主要有以下2个原因:
低效的SQL。如多个进程同时大范围扫描表和索引。
HOT BLOCK。指的是多个并发进程同时读取同一个数据块 值得注意的是,如果单条SQL执行效率很高但多个进程并发执行时由于出现LATCH: CACHE BUFFERS CHAINS等待事件而导致性能下降,那么在这种情况下是无法根本性解决CACHE BUFFERS CHAINS LATCH争用的。简单设想一下,如果众多并发进程同时通过BUFFER CACHE读取一个数据块,由于该数据块受CACHE BUFFERS CHAINS LATCH保护,每个会话读取该数据块时都需要申请该LATCH,那么该LATCH的争用将不可避免。要解决这种类型的性能故障,只有重新调整应用,别无他法。
从Oracle 9i起,读取HASH CHAIN中某些类型的数据块(如唯一索引的根块)时,可以通过SHARED模式获取CACHE BUFFERS CHAINS LATCH,从而在一定程度减少LATCH:CACHE BUFFERS CHAINS等待事件的发生。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

热搜词