数据库负载急剧提高的应急处理(二) （r9笔记第55天)

对于之前碰到的一个数据库负载急剧提升的问题，做了应急处理之后，我们需要再冷静下来，来看看是哪些地方出现了问题，还需要哪些改进。    而在数据库的会话层面没有发现任何的抖动，这一点就很难解释的通了。执行的大体情况如下。

SQL ID	% Activity	Row Source	% RwSrc	Top Event	% Event	SQL Text
ag4b2tb6yxscc	31.29	MERGE	28.83	log file switch completion	24.86	MERGE INTO TEST_OPENPLATFORM_U...
ag4b2tb6yxscc	31.29	TABLE ACCESS - BY INDEX ROWID	1.04	log file switch completion	1.04
134zhd24d9p0y	10.68	** Row Source Not Available **	10.68	log file switch completion	8.88	insert into TEST_USER_INFO (CI...
fw8tvzm9zc48g	6.14	MERGE	5.01	log file switch completion	3.88	MERGE INTO CYUC_USER_LOGIN_TOK...
5nn5amat9hfjm	3.97	TABLE ACCESS - FULL	3.12	CPU + Wait for CPU	3.12	MERGE INTO TEST_OPENPLATFORM_B...
351tx6bsgk1un	3.50	TABLE ACCESS - FULL	3.31	CPU + Wait for CPU	3.31	MERGE INTO TEST_GUEST_USER_INF...

看到这个这个报告，我有些迷惑了，不知道问题的瓶颈在哪里了，因为top 1的SQL本身已经优化过，已经是最优的方式了，执行频率要高一些，而下面的两个标黄的语句仔细查看，是存在性能隐患的语句，但是执行频率相对来说不高，占用的比例也不高。

      8点    9点     10点    11点   12点   

Elapsed Time (s)	Executions	Elapsed Time per Exec (s)	%Total	%CPU	%IO	SQL Id	SQL Text
1,521.05	6,464	0.24	22.07	0.72	1.94	ag4b2tb6yxscc	MERGE INTO TEST_OPENPLATFORM_U...
69.84	1,980	0.04	1.01	6.77	8.20	5nn5amat9hfjm	MERGE INTO TEST_OPENPLATFORM_B...
507.27	1,304	0.39	7.36	3.32	0.00	351tx6bsgk1un	MERGE INTO TEST_GUEST_USER_INFO...

有了这些数据支撑，就可以明白问题的大体情况，原本系统的SWAP争用已有，但是最近比较严重，而在问题发生时间段里，问题更加严重，主要就是因为一个本 来负载不是很高的SQL执行频率从1000多提升到了6000多，执行计划中显示是全表扫描，好几百万数据的大表来说还是很明显的问题。而对于这个语句的 优化其实倒不是很难，关键有针对性的分析就尤为重要了。