昨天运维组的同时反映有套系统用户反映很慢，需要协助帮忙检查什么原因引起的性能问题。导出了从8点到11点的AWR报告进行分析，发现等待事件里大部分的指标都正常，就是buffer busy wait的平均等待有点高，大概在20毫秒左右。初步判断可能是该系统有某些热点表大部分功能都用到，导致频繁的读、改、写操作，由于同一个数据块被大量的进程同时尝试访问写入，最终引起了buffer busy wait事件。

继续向下分析AWR报告中对于引起buffer busy wait事件的相关对象列表，发现某个用户登录日志表做出了百分之80以上的贡献。看起来，此表的索引或数据的保存方式存在需要优化的空间。查看该表的结构，发现该表建立有两个单键索引。通过SELECT COUNT(1)方式观察该表的数据变化情况，发现该表的数据量并不大，但是变化很频繁。由于该表属于日志记录表，不会涉及到”范围统计“类的相关操作，因此，为了降低热点数据块的争用，应该打散数据分布。

处理方式：1、删除原有的索引，重新在相关列上建立反向索引(REVERSE)。

2、对数据表进行分析操作。例如：                               exec dbms_stats.gather_table_stats(ownname => 'scott',tabname => 'work_list',estimate_percent => 10,method_opt=> 'for all indexed columns') ;