利用SQL Profiler處理開銷較大的查詢

原文:

利用sql profiler處理開銷較大的查詢

當sql server的效能變差時，最可能發生的是以下兩件事：

sql server的目標是在最短時間內將結果集返回給使用者。為此，sql server查詢優化器生成乙個成本效益高的查詢執行計畫。查詢優化器計算許多因素的權重，包括執行查詢所需要的cpu、記憶體以及磁碟i/o的使用情況-這些均來自於由索引維護或過程中生成的統計。通常開銷最低的計畫有最少的i/o，因為i/o操作代價昂貴。

邏輯讀提供指出了查詢產生的記憶體壓力。它還提供了磁碟壓力指標，因為記憶體頁面必須在操作查詢中被備份，在第一次資料訪問期間寫入，並且在記憶體瓶頸時被移到磁碟上。查詢的邏輯讀數量越大，磁碟壓力的可能性就越大。過多的邏輯頁面也增加了cpu用於管理這些頁面的負載。

導致大量邏輯讀的查詢通常在相應的大資料集上得到鎖。即使讀也需要在所有資料上的共享鎖。這些查詢阻塞了其他請求修改這些資料的查詢，但是不阻塞讀取資料的查詢。因為這些查詢固有的開銷並且需要長時間執行，他們持續地阻塞其他查詢。被阻塞的查詢進一步阻塞查詢，引入了資料中的阻塞鏈。

識別開銷較大的查詢並優化它們有如下意義：

其中開銷較大的查詢可以被分為如下兩類：

1、單次執行開銷較大的查詢

可以分析sql profiler跟蹤輸出檔案來識別開銷較大的查詢。比如，如果對識別執行大量的邏輯讀的查詢感興趣，應該在跟蹤輸出的reads資料列上排序。

跟蹤輸出如下：

在某些情況下，可能從系統監視器輸出中識別cpu上的大壓力。cpu上的壓力可能是因為大量cpu密集型操作，如儲存過程重編譯、總計函式、資料排序、雜湊連線等。在這種情況下，應該在cpu列上排序profiler跟蹤輸出以識別使用大量處理器週期的查詢。

2、多次執行開銷較大的查詢

在將跟蹤輸入儲存到檔案以後，先將跟蹤資料匯入到一張表：

select
*into
tracetable
from ::fn_trace_gettable('
d:\123.trc
',default)

然後執行以下語句：

select
count(*) as
totalexecutions,eventclass,
cast(textdata as
nvarchar(max
)) textdata,
sum(duration) as
duration_total, 
sum(cpu) as cpu_total, sum(reads) as
reads_total, 
sum(writes) as
writes_total 
from
tracetable 
group
by eventclass,cast(textdata as
nvarchar(max
)) order
by reads_total desc

指令碼中的totalexecutions列指出了查詢被執行的次數，reads_total列指出了該查詢多次執行所進行的讀操作的總數。注意ntext不支援group by,因此要轉換一下型別。

這個方法識別出來的開銷較大的查詢比profiler識別出的單次執行的開銷較大查詢更好地指出了負載。例如，乙個需要50個讀操作的查詢可能執行1000次。這個查詢本身被認為足夠經濟了，但是執行的讀操作總是是5萬，這不能被認為是經濟的。優化這個查詢降低讀運算元，即使每次執行減少10次，讀運算元也將降低1萬次。這比優化乙個5千次讀操作的查詢更有利。

從sys.dm_exec_query_stats檢視中得到相同的資訊只需要乙個查詢：

select

ss.sum_execution_count

,t.text

,ss.sum_total_elapsed_time

,ss.sum_total_worker_time

,ss.sum_total_logical_reads

,ss.sum_total_logical_writes

from (select

s.plan_handle

,sum

(s.execution_count) sum_execution_count

,sum

(s.total_elapsed_time) sum_total_elapsed_time

,sum

(s.total_worker_time) sum_total_worker_time

,sum

(s.total_logical_reads) sum_total_logical_reads

,sum

(s.total_logical_writes) sum_total_logical_writes

from

sys.dm_exec_query_stats s

group

bys.plan_handle)as

sscross

order

by sum_total_logical_reads desc

這比所有收集跟蹤資料所需要的工作要容易得多，那麼為什麼還要使用跟蹤資料？使用跟蹤的主要原因是精確性。sys.dm_exec_query_stats檢視是給定計畫已經存在於記憶體中時的流動總計，時間點並不精確。另一方面，跟蹤是執行的任何時間段的歷史記錄。甚至可以在資料庫中加入跟蹤，並且擁有一系列可以比依靠給定的瞬間更精確地生成總計的資料。但是對定位效能問題的理解關注是查詢執行緩慢的時點，這是sys.dm_exec_query_stats不可替代的場合。

3、識別執行緩慢的查詢

如果執行緩慢的查詢的響應時間變得不可接受，那麼應該分析效能下降的原因。但是不是所有執行緩慢的查詢都是由於資源問題造成的，其他需要關心的因素如阻塞也可能導致緩慢的查詢。

為了發現執行緩慢的查詢，在duration列上分組跟蹤輸出。

跟蹤輸出如下：

對於執行緩慢的系統，應該注意優化過程前後執行緩慢的持續查詢時間。應用優化技術之後，應該計算在系統上的總體效能。優化步驟可能負面地影響其他查詢，使其變慢。

利用SQL Profiler處理開銷較大的查詢

利用SQL Profiler處理開銷較大的查詢

SQL Profiler跟蹤基礎知識一

利用CPU多核處理

利用SQL Profiler處理開銷較大的查詢

利用SQL Profiler處理開銷較大的查詢

SQL Profiler跟蹤 基礎知識一

利用CPU多核處理

相關推薦

SQL Profiler跟蹤基礎知識一