应用事件探查器优化SQL Server系统(4)

上面的例子采样于一家大型公司的业务系统。该系统的问题是应用程序运行缓慢，SQL Server 服务器的CPU高居不下（8个CPU都在90%～100%间波动）。我使用PSSDIAG工具采样2小时左右的数据，然后运行read80trace和usp_GetAccessPattern得出上面的结果。报表一目了然。存储过程DBO.x_DEDUP_PROC在两小时内共运行75次，却占用了90.8％的CPU资源，94.6%的Reads，从访问模式的角度，该存储过程正是导致CPU高和系统性能慢的关键语句。一旦优化了该存储过程，系统的性能问题将迎刃而解。你也许有疑问，两小时内共运行75次,不是很频繁啊。其实你看看这条存储过程的平均CPU时间是681961毫秒，大概11分钟左右。也就是说一个CPU两小时内最多可以执行（60*2）/11＝10条左右，该系统总共有8个CPU，即使全部CPU都用来运行该语句，那么最多也就是10*8＝80条左右。上面执行总数是75，说明该存储过程一直在连续不断地运行。

那么该系统运行最频繁的语句是什么呢？我从结果中摘取另外一部分如下（图 2）：

从上表可以看出，最频繁运行的语句是

USE xb SET QUOTED_IDENTIFIER,ANSI_NULL_DFLT_ON…

显然这是一条执行环境配置语句，没有参考价值。倒是另外两条占用语句总数8.2%的语句值得关注：

　　SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……
　　SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……

在这个例子中，因为关键语句DBO.x_DEDUP_PROC非常突出，甚至上面的两条语句都可以忽略了。

让我们再多看一个例子（图 3）：

从上面的例子中, 可以得出关键的语句是:

SELECT COUNT(*) FROM GTBL7MS
　　SELECT CaseNO FROM PATIENTDATA_sum WHERE MRN = @P1

后续的检查发现相关的表没有有效的索引，加上索引后性能立即整体地提高了不少.。解决了这两个语句，需要使用同样的手段继续分析和优化，直到系统的性能能够接受为止.。注意性能调优是一个长期的过程，你不太可能一两天就可以把所有的问题都解决。也许一开始可以解决80%的问题，但是后面20%的问题却需要另外80%的时间。