latch: cache buffers chains

上周末三个新系统上线后， AIX 平台下一个两节点的oracle 10.2.04 的RAC cpu使用到了99%。

数据库中出现了大量的等待事件： latch: cache buffers chains。

 

数据库环境：AIX 570 + ORACLE 10.2.04 两节点RAC

中间件： jboss

JDK:

java version "1.5.0_21"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_21-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_21-b01, mixed mode)

 

操作系统：linux

9台linux，共分三组。每三台机器做个集群。

文件系统：ocfs2

 

问题概述： 

 

在系统上线前做过一次数据迁移,迁移后分析了统计信息.上午应用起来后一切正常.

下午开始有反应系统内存溢出,部分系统响应缓慢.登上数据库一看真是惨不忍睹,平时

数据库cpu使用率只有30%左右,今天居然到了99%。随时有宕机的可能。

 

由于多个系统同时出现问题，加之数据库响应慢。再加上昨天上线整整搞了一个通宵。

思维有些混乱。一时间，不知该从何下手。

 

理赔系统启动前部分表没有数据，因此收集到的统计信息相关表的记录数为0.在业务系统启动后

某些表的数据迅速增加，导致数据库执行计划错误。产生大量的latch: cache buffers chains

等待事件。导致rac中两个节点的数据库cpu长时间处于临界状态(cpu资源占用99%)。

 

分析：综合AWR 报告及捕获的TOP SQL分析。对比同一sql在生产库和测试库的执行计划。发现生产库相关

       sql的执行计划要复杂的多。进一步查看相关表的统计信息。与实际count得出的数据对比发现几张

       关键表的统计信息有误。

解决： 对统计信息不正确的表进行统计信息收集。收集完成后，重启相关应用。数据库中的等待事件
      
       latch: cache buffers chains消失。cpu使用率恢复正常。

关键点：如何找到数据库中的等待事件，并分析产生等待事件的原因。并找出合适的解决方法。

总结：1.本次案例诊断在一开始的时候已经怀疑到是统计信息的问题。但考虑到上线前刚对全库收集过统计

          信息所以没有去查看相关表的统计信息。耽误了大量时间。

         2.由于同时上线的新系统较多，系统有内存溢出，宕机的情况。分析系统内存溢出，宕机原因也耗费了

         大量的时间。没有集中精力把问题放在数据库上。也导致问题的解决出现了延迟。