Rss订阅
SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……
SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……
在这个例子中，因为关键语句DBO.x_DEDUP_PROC非常突出，甚至上面的两条语句都可以忽略了。
让我们再多看一个例子（图 3）：
图 3：输出结果采样三
从上面的例子中, 可以得出关键的语句是:
SELECT COUNT(*) FROM GTBL7MS
SELECT CaseNO FROM PATIENTDATA_sum WHERE MRN = @P1
后续的检查发现相关的表没有有效的索引，加上索引后性能立即整体地提高了不少.。解决了这两个语句，需要使用同样的手段继续分析和优化，直到系统的性能能够接受为止.。注意性能调优是一个长期的过程，你不太可能一两天就可以把所有的问题都解决。也许一开始可以解决80%的问题，但是后面20%的问题却需要另外80%的时间。
使用usp_GetAccessPattern的一些技巧usp_GetAccessPattern的输出报表包含了非常丰富的信息。分析报表的时候需要有大局观。你也可以有目的性地选择你需要的信息。如果是CPU性能瓶颈的系统，那么你需要关注CPU占用比例高的那类语句。如果是磁盘IO出现性能瓶颈那么你需要找到那些Reads占用比例大而且平均reads也很高的语句。需要注意的是有时候运行频繁的语句未必就是你需要关注的关键语句。一个最理想的情况是关键语句正好就是最频繁的语句。有时候即使最频繁语句占用的资源比例不高，但如果还可以优化，那么因为放大效应，微小的优化也会给系统带来可观的好处。
在使用usp_GetAccessPattern的时候多结合@duration_filter参数使用。因为参数以毫秒为单位，建议参数不要小于1000，而应该是1000的倍数 如3000，5000等。该参数常常会给出非常有意思的输出。该输出和不带参数运行的结果会有某些重叠。重叠出现的语句通常正是需要关注的语句。要注意运行最多最密的语句未必有超过1000毫秒的执行时间，所有带参数运行的结果有可能不包括最频繁语句。我常常同时交叉分析四个结果，一个是不带参数运行得到的，另三个分别是使用1000，3000和5000毫秒为参数运行的结果。比较分析这四个结果往往使我对数据库系统的访问模式有非常清晰透彻的理解。
运行存储过程时你也许会碰到int整数溢出的错误。这是因为表tblBatches 中的reads,CPU 和writes字段是int而不是bigint。可以运行如下语句进行修正：
上一页 [1] [2] [3] [4] [5] [6] [7] 下一页
- 相关新闻
- 用户评论
- 推广服务
