Sql Server2005性能診斷

enjoyasp.net sql server 1 Comment 發表評論 引用：http://technet.microsoft.com/zh-cn/library/cc966540(en-us).aspx Sql Server速度變慢問題主要由三個方面引起，可從這三個方面入手分析問題1，資源瓶頸：CPU、I/O、內存等。2，臨時表瓶頸：tempdb各個數據庫共用，資源緊張時會引起性能降低。3，用戶比較耗時的sql查詢。一，CPU瓶頸分析。瓶頸癥狀：打開perfmon, 監視 processor:% Processor Time若長期>80%，或者任務管理器，說明可能是CPU原因。 1，分析是否是查詢語句引起這里涉及一個動態視圖：sys.dm_exec_query_stats，返回每條查詢語句運行的時間 關鍵欄位有：1）sql_handle:表示包含查詢的批查詢或存儲過程的標記,若sql_handle相同，代表查詢在同個批處理或同一個存儲過程內。可將此值傳入 sys.dm_exec_sql_text中獲取查詢語句。同個存儲過程或批處理語句的sql_handle相同，如何分辨是哪個查詢語句得到了執行， 可用statement_start_offset、statement_end_offset來查出此查詢語句的真容。 2）statement_start_offset：查詢在其批查詢或持久化對象文本中的開始位置 3）statement_end_offset：查詢在其批查詢或持久化對象文本中的結束位置 4）execution_count： 計劃自上次編譯以來所執行的次數。 5）total_worker_time：此計劃自編譯以來執行所用的 CPU 時間總量（以微秒為單位報告，但僅精確到毫秒）。 6）last_execution_time：上次開始執行計劃的時間。 故分析耗CPU語句方法可得出：SELECT TOP 50qs.total_worker_time/qs.execution_count/1000. as [平均消耗CPU 時間(ms)],total_worker_time/1000 AS [總消耗CPU 時間(ms)],execution_count [運行次數],SUBSTRING(qt.text,qs.statement_start_offset/2+1,(case when qs.statement_end_offset = -1then DATALENGTH(qt.text)else qs.statement_end_offset end -qs.statement_start_offset)/2 + 1)as [查詢語句], qt.text [所在存儲過程],qt.dbid, dbname=db_name(qt.dbid),qt.objectid,object_name(qt.objectid,qt.dbid) ObjectNameFROM sys.dm_exec_query_stats qs cross apply sys.dm_exec_sql_text(qs.sql_handle) as qt --WHERE qs.last_execution_time >='2011-08-28 10:00' 限定時間 ORDER BY[平均消耗CPU 時間(ms)] DESC注：測試sys.dm_exec_query_stats 時可先清除緩存DBCC FREEPROCCACHE 再執行查詢語句分析。2，分析是否是重新編譯引起，重新編譯比較費時。 1）perfmon:SQL Server: SQL Statistics: Batch Requests/sec :每秒鐘接收的請求數SQL Server: SQL Statistics: SQL Compilations/sec：每秒鐘的編譯數SQL Server: SQL Statistics: SQL Recompilations/sec：每秒鐘的重新編譯數2）profile:SP:Recompile / SQL:StmtRecompile. 3）sys.dm_exec_query_stats 有一個欄位plan_generation_num，計劃編譯次數，可用此來分析最常編譯的計劃。 select top 25plan_generation_num,SUBSTRING(qt.text,qs.statement_start_offset/2+1,(case when qs.statement_end_offset = -1then DATALENGTH(qt.text)else qs.statement_end_offset end -qs.statement_start_offset)/2 + 1)as stmt_executing,qt.text,execution_count,sql_handle,dbid,db_name(dbid) DBName,objectid,object_name(objectid,dbid) ObjectName from sys.dm_exec_query_stats as qsCross apply sys.dm_exec_sql_text(sql_handle) qt where plan_generation_num >1 --AND qs.last_execution_time >='2011-08-28 10:00' 限定時間 order by plan_generation_num desc二，內存瓶頸分析。瓶頸癥狀：打開perfmon, 監視 Paging File: %Usage長期>80%。Paging File:Usage: 分頁空間使用百分率三，I/O瓶頸分析：癥狀：計數器PhysicalDisk:%Disk Time >80% , Avg.Disk Queue Length:>2 1，%Disk Time :所選磁盤驅動器忙于為讀或寫入請求提供服務所用的時間的百分比。 Avg. Disk Queue Length 指讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。 不過，若出現上述情況，也可以是內存不足引起。2，sys.dm_exec_query_stats 有欄位total_logical_writes：此計劃自編譯后在執行期間所執行的邏輯寫入總次數。total_logical_reads：此計劃自編譯后在執行期間所執行的邏輯寫入總次數。 故查詢最耗I/O的語句為：select top 50 (total_logical_reads/execution_count) as [平均邏輯讀取次數], (total_logical_writes/execution_count) as [平均邏輯寫入次數], (total_physical_reads/execution_count) as [平均對象讀取次數],Execution_count 運行次數, substring(qt.text,r.statement_start_offset/2+1, (case when r.statement_end_offset = -1 then datalength(qt.text) else r.statement_end_offset end - r.statement_start_offset)/2+1) [運行語法] from sys.dm_exec_query_stats as rcross apply sys.dm_exec_sql_text(r.sql_handle) as qt --WHERE r.last_execution_time >='2011-08-28 10:00' 限定時間 order by(total_logical_reads + total_logical_writes) Desc四，tempdb瓶頸。空間資源耗盡引起。 查詢： SelectSUM (user_object_reserved_page_count)*8 as user_objects_kb,SUM (internal_object_reserved_page_count)*8 as internal_objects_kb,SUM (version_store_reserved_page_count)*8 as version_store_kb,SUM (unallocated_extent_page_count)*8 as freespace_kb From sys.dm_db_file_space_usage Where database_id = 2 其中：freespace_kb 要足夠大才可。

總結

以上是生活随笔為你收集整理的Sql Server2005性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。