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

2021-09-22 20:35:33 字數 3344 閱讀 1216

原文:

利用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 server的效能變差時,最可能發生的是以下兩件事 sql server的目標是在最短時間內將結果集返回給使用者。為此,sql server查詢優化器生成乙個成本效益高的查詢執行計畫。查詢優化器計算許多因素的權重,包括執行查詢所需要的c...

SQL Profiler跟蹤 基礎知識一

從開始 所有程式 microsoft sql server 2012 效能工具開啟profiler工具,也可以開啟sql server management studio 工具 sql server profiler。sql profiler 可以理解為 sql server事件探查,乙個sql的監...

利用CPU多核處理

在mysql5.5.x後,可以利用innodb read io threads和innodb write io threads,取代之前的innodb file io threads引數,在linux平台上就可以根據cpu核數來更改相應的引數值,預設是4.比如cpu是2棵8核的,可以設定 innod...