今天某个库出现了cache buffers chain,最近应用没啥变更,怎么会突然出现呢,当然latch:cache buffers chain的作用是db cache中Find data很重要的latch,不管逻辑读,物理读(也要经历逻辑读),如果link或者unlink一个buffer到不同的Hash Bucket,再或者pin,unpin一个buffer,都要获得相关bucket上相关的cache buffers chain latch。所以,关联到sql上,正如我们通常说的,调sql的一个目标就是减少资源的消耗,包括降低逻辑读,如果某个sql的读的块很多,那么和其它在访问相同数据的session就会争夺cache buffers chain latch(因为决定buffer被连接到那个bucket里面是由block的信息决定的,一个cache buffers chain latch会保护多个bucket,如果很多访问一个bucket里面的buffer,此时就会导致次latch的争用,也就是我们说的热块)所以,应用最近没啥变更,可以肯定是某些sql走错了执行计划。
我们收集统计信息是按照segment_size大于150M,并且每天的变化量超过20%的对象才会收集统计信息。所以对于有些对象没达到这个
收集的条件,统计信息可能是很久以前的或者是缺失,数据变化较大的时候,可能导致执行计划错误。
查看下当时ASH信息:
select sql_id,count(*)
from dba_hist_active_sess_history
where event='latch: cache buffers chains' and sample_time between
to_date('2012-08-02:16:00:00',‘YYYY-MM-DD:HH24:MI:SS') and to_date('2012-08-02:16:10:00',‘YYYY-MM-DD:HH24:MI:SS')
group by sql_id
order by 2 desc;
SQL_ID COUNT(*)
0a3zj3m5h72rb 6098
3xyq2hqdd3akj 24
9rt5b6s9ry50q 16
很明显,sql_id:0a3zj3m5h72rb嫌疑比较大,看看执行计划:
当前的执行计划: 【Linux公社 http://www.linuxidc.com 】
SQL_ID 0a3zj3m5h72rb
--------------------
select M.LOG_ID,M.STATE,M.SESSION_ID,M.IP,M.LOGOUT_DATE,M.LOGIN_DATE,M.STAFF_COD
MAC ,M.ROWID as MROWID___ from SEC_LOGIN_LOG_201208 M where M.SESSION_ID = :1
order by M.LOG_ID DESC
Plan hash value: 177413507
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | |
| 1 | TABLE ACCESS BY INDEX ROWID| SEC_LOGIN_LOG_201208 | 1 | 146 |
| 2 | INDEX FULL SCAN DESCENDING| PK_SEC_LOGIN_LOG_201208 | 1 | |
--------------------------------------------------------------------------------
当然这个sql很简单,执行计划也很简单,我们先看下这个表上索引的信息:
INDEX_NAME BLEVEL COLUMN_NAME COL_POS DISTINCT_KEYS NUM_ROWS FACTOR PAR LAST_ANALYZE
------------------------- ---------- ----------------------- ------------- ---------- ---------- --- ------------
IDX_SEC_LOGIN_LOG2_201208 2 LOGOUT_DATE 1 106719 393830 376028 NO 01-AUG-12
IDX_SEC_LOGIN_LOG_201208_3 2 LOGIN_DATE 1 123557 496287 419906 NO 01-AUG-12
IDX_SEC_LOGIN_LOG1_201208 2 SESSION_ID 1 384049 384049 383848 NO 01-AUG-12
PK_SEC_LOGIN_LOG_201208 2 LOG_ID 1 496292 496292 451386 NO 01-AUG-12
- 大小: 33.7 KB
分享到:
相关推荐
一个进程在对数据块执行add, remove, search, inspect, read 或者modify之前需要首先获得cache buffers chains latch. 有两条规则跟oracle访问数据块时的cache buffers chains相关. 每一个logical read都会造成一...
Cache Buffers Chain
Protocol Buffers 2.4.1 jar
Google Protocol Buffers 在 c# 中的应用
google Protocol Buffers
Protocol Buffers What is it? Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and...
Before we look at how SQL Server uses and manages its memory, we need to ensure a full understanding of the more common memory related terms. The following definitions will help you understand how SQL...
google protocol buffers 官网中文教程
中文翻译Google Protocol Buffers中文教程中文翻译Google Protocol Buffers中文教程中文翻译Google Protocol Buffers中文教程中文翻译Google Protocol Buffers中文教程
Google.ProtocolBuffers.dll类库
Google.ProtocolBuffers动态库反编译生成的源代码,用于学习。
ProtocolBuffers 英文版PDF 不懂别下
Protocol Buffers Java开发包(protobuf-java-2.3.0.jar)
前端开源库-protocol-buffers协议缓冲区,node.js的协议缓冲区
ProtocolBuffers在即时通讯系统中的应用研究_田源.pdf
Protocol Buffers v3.0.0-alpha-1(Java) release 版本和源代码
Protocol Buffers - 谷歌的数据交换格式
Google Protocol Buffers浅析
Fast Buffers