latch: cache buffers chains

今天一到早接到报警短信，cpu使用率增至100%，因为是Linux Sever，为了不使Server crash，先登上去杀去部分LOCAL=NO的进程。

接着查看活动的会话：

SELECT
(SELECT b.SQL_TEXT FROM v$sqlarea b WHERE b.SQL_ID=a.SQL_ID
) sqltxt,
(SELECT c.SQL_FULLTEXT FROM v$sqlarea c WHERE c.SQL_ID=a.SQL_ID
) sqlfulltxt,
a.username,
a.LAST_CALL_ET,
a.MACHINE ,
a.command,
a.EVENT,
a.SQL_ID ,
a.SID,
a.SERIAL#,
'alter system kill session '''
|| a.SID
||','
||a.SERIAL#
||''';' AS killstment
FROM v$session a
WHERE a.STATUS = 'ACTIVE'
AND a.USERNAME NOT IN ('SYS', 'SYSTEM')
ORDER BY a.LAST_CALL_ET DESC ,
a.username,
a.MACHINE ,
a.command,
a.EVENT,
a.SQL_ID ,
a.SID

有很多latch: cache buffers chains event
当一个数据块读入sga区，相应的buffer header会被放置到hash列表上，oracle称其为hash chains,chain在中文的意为链条或串的意思，表达就是关连性.如果一个进程想访问或修改hash chain上的block,它首先要获得”cache buffers chains” latch。

原因一：低效率的SQL语句（主要体现在逻辑读过高）

cache buffers chains latch很大程度与逻辑读有关，所以要观注v$sql中BUFFER_GETS/EXECUTIONS大的语句。

同时每一个逻辑读需要一个latch get 操作及一个cpu操作，这样的sql也会很耗cpu资源。

原因二：热块（访问过于频繁）

查找热块：

SELECT OBJECT_NAME,
SUBOBJECT_NAME
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID IN
(SELECT DATA_OBJECT_ID
FROM
(SELECT OBJ DATA_OBJECT_ID,
FILE#,
DBABLK,
CLASS,
STATE,
TCH
FROM X$BH
WHERE HLADDR IN
(SELECT ADDR
FROM
(SELECT ADDR FROM V$LATCH_CHILDREN ORDER BY (GETS + MISSES + SLEEPS) DESC
)
WHERE ROWNUM < 10
)
ORDER BY TCH DESC
)
WHERE ROWNUM < 10
);

但是此次事件是由于一个sql并发，产生大量逻辑读引起的，由于昨晚系统上线，开发没有注意创建表上的索引，致使全表扫描造成大量的逻辑读，创建索引后cpu回到20%波动。