RAC中一次混乱的性能诊断过程5

开始我觉得没有过分耗时的语句就不算有性能问题，所以没有关注，后来我又通过语句查看了CLUSTER等待的SQL语句如下：

select wait_class_id, wait_class, count(*) cnt

   from dba_hist_active_sess_history

   where snap_id between 7744 and 7745

   group by wait_class_id, wait_class

   order by 3

select event_id, event, count(*) cnt from dba_hist_active_sess_history

  where snap_id between 7744 and 7745 and wait_class_id=3871361733

  group by event_id, event

  order by 3;

   select sql_text from dba_hist_sqltext where sql_id in

   (select sql_id from dba_hist_active_sess_history

   where snap_id between 7744 and 7745

   and event_id in (661121159)

   group by sql_id);

   最后得出的语句是：

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

select ti.serialno itemNo,       ti.insuredcode

这个也验证了AWRRPT的结果，然后我转向查看SEGMENT信息，我这里只给出了语句一部分，我查看了语句完全相同。

Segments by Global Cache Buffer Busy

• % of Capture shows % of GC Buffer Busy for each top segment compared
• with GC Buffer Busy for all segments captured by the Snapshot

Back to Segment Statistics
Back to Top

Back to Segment Statistics
Back to Top

Segments by Current Blocks Received

• Total Current Blocks Received: 8,649,348
• Captured Segments account for 99.6% of Total

Back to Segment Statistics

我这里给出了第一行，我觉得可以说明问题了，然后我查看了语句，发现语句确实包含了TEST100这个表，这完全说明前期的分析是不对的。真正引起集群等待的原因是对TEST100块进行传递的结果，一切都是它的问题。最后我查看了这些语句，这些语句都对表TEST100进行FULL TABLE SCAN，所以我觉得只要改善了TEST100 的FULL TABLE SCAN应该可以解决一些问题了。不知道大家觉得如何？

总结：

在RAC的性能诊断中，特别是涉及到集群等待事件比如GC BUFFER BUSY这样的事件，不要片面的认为这个问题一定是由逻辑读最高的语句引起的，很可能最耗时最高逻辑读的语句不是引起问题的根源。最好结合集群等待对象和语句进行分析。同时通过语句提取信息进行验证。