sql执行计划错误之cache buffers chain
分享个小案例：
今天某个库出现了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信息：
SQL_ID 0a3zj3m5h72rb--------------------select M.LOG_ID,M.STATE,M.SESSION_ID,M.IP,M.LOGOUT_DATE,M.LOGIN_DATE,M.STAFF_CODas MROWID___ from SEC_LOGIN_LOG_201208 M where M.SESSION_ID = :1 order by M.LPlan hash value: 1455286942--------------------------------------------| Id | Operation | Name | Rows | Bytes--------------------------------------------| 0 | SELECT STATEMENT | | || 1 | SORT ORDER BY | | 1 | 108| 2 | TABLE ACCESS BY INDEX ROWID| SEC_LOGIN_LOG_201208 | 1 | 108| 3 | INDEX RANGE SCAN | IDX_SEC_LOGIN_LOG1_201208 | 1 |--------------------------------------------小小sql,其实平时即使遇到大的sql，复杂的，多表连接的，执行计划几百行的，都一样，收集相关的对象的信息是必不可少的。
