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%波动。