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

2022-07-03 22:08:36

开始我觉得没有过分耗时的语句就不算有性能问题，所以没有关注，后来我又通过语句查看了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

这个也验证了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

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	GC Buffer Busy	% of Capture
PROD	PROD_TBS	Test100		TABLE	117,030	99.99

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

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	Current Blocks Received	%Total
PROD	PROD_TBS	Test100		TABLE	8,320,599	96.20

Back to Segment Statistics

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

总结：

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

码农公寓

相关文章