Expert for SQL Server

Expert for SQL Server從伺服器軟硬體環境、參數配置、結構設計計、性能、可用性、備份、安全等各個維度對SQL Server資料庫進行全面的評估和診斷，清晰地了解系統的真實運行狀況，並協助維護人員快速地解決問題。

基本介紹

• 名稱：Expertfor SQL Server
• 適用場景：SQL Server 資料庫

概述

資料庫作為信息系統的根基，支撐著整個套用系統，發揮著非常重要的作用，因此，它的健壯與否直接決定著整個信息系統能否高效、穩定運行。其中SQL Server憑藉著簡單易用性占據了大部分的資料庫市場份額。

從大量用戶群體中總結出大部分SQL Server系統存在以下問題：

1. 快速開發導致的結構設計以及代碼的低效性

2. 參數配置不合理，導致硬體的利用率低下

3. 沒有專業的資料庫DBA(資料庫管理員)來保障資料庫的持續健康運行

4. 公司的資料庫伺服器系統服務於關鍵業務流程，一旦出現故障影響重大

5. 擔心資料庫系統有潛在的嚴重問題，可能會影響其正常運行

6. 面對眾多的系統配置選項及管理任務方案，感覺無從下手

Expert for SQL Server可以做到：

1. 從硬體、作業系統、SQL Server、資料庫配置、高可用及備份、安全、性能七個方面清晰地了解到系統的真實運行狀況，做到“讓你知道真實的自己”。

2. 採用專用的分析工具對數據匯總、分析；

3. 維護人員可以監控關鍵性能指標的趨勢，如資源消耗、資料庫對象、統計數據等，讓維護人員能夠在問題影響最終用戶之前解決問題。

4. 呈現出當前系統的性能指標，定位導致系統性能變慢的原因，並提出性能最佳化後回響速度提升的預期。

5. 為維護人員提供多次、持續的健康檢查及故障處理服務，確保資料庫能穩定、高效運行。

收集原理

1. 伺服器參數檢測

伺服器記憶體參數的配置

最大用戶連線參數是否限制

允許更新參數

鎖參數

打開對象參數

CPU資源調度優先權參數

恢復間隔參數

填充因子參數

相似性掩碼參數

輕量級執行緒參數

工作集參數

遠程存儲過程訪問參數

遠程登錄延時參數

資料庫的自動收縮參數

資料庫的自動關閉參數

資料庫的自動更新統計信息參數

資料庫的恢復模型設定

2. 性能計數器檢測

--1指處理器執行非閒置執行緒時間的百分比,測量處理器繁忙的時間 這個計數器設計成用來作為處理器活動的主要指示器,可以選擇單個CPU實例,也可以選擇Total。30%以上代表存在少許等待現象，60%以上代表等待比較嚴重。

--"\\!HN!\Processor(_Total)\%% Processor Time"

--2磁碟平均的讀佇列，正常指標在1以下，大於1就說明有排隊現象了

--"\\!HN!\PhysicalDisk(_Total)\Avg. Disk Read Queue Length"

--3磁碟平均的寫佇列, 正常指標在1以下，大於1就說明有排隊現象了

--"\\!HN!\PhysicalDisk(_Total)\Avg. Disk Write Queue Length"

--4定義該數值小於15ms為Excellent，介於15～30ms之間為良好，30～60ms之間為可以接 受，超過60ms則需要考慮更換硬碟或 是硬碟的RAID方式了

--"\\!HN!\PhysicalDisk(_Total)\Avg. Disk sec/Transfer"

--5它測量磁碟在採樣間隔期間的空閒時間百分比。如果此計數器低於 20%，則表示磁碟系統處於滿負荷狀態。可考慮將當前的磁碟系統更換為速度更快的磁碟系統。

"\\!HN!\PhysicalDisk(_Total)\% Idle Time"

--6由要求刷新所有髒頁的檢查點或其他操作每秒刷新到磁碟的頁數，如果此值過高，可能是磁碟或時記憶體不足造成的

"\\!HN!\SQLServer:Buffer Manager\Checkpoint pages/sec"

--7惰性編寫器不需要為創建可用緩衝區而頻繁執行檢查點。合理範圍：0

"\\!HN!\SQLServer:Buffer Manager\Lazy writes/sec"

--8快取命中率,在緩衝區高速快取中找到而不需要從磁碟中讀取(物理I/O)的頁的百分比. 如果該值較低則可能存在記憶體不足或不正確的索引

--"\\!HN!\SQLServer:Buffer Manager\Buffer cache hit ratio"

--9每秒發出的物理資料庫頁讀取數。此統計信息顯示的是所有資料庫間的物理頁讀取總數。

--由於物理 I/O 的開銷大，可以通過使用更大的數據快取、智慧型索引、 更有效的查詢或更改資料庫設計等方法，將開銷降到最低

--"\\!HN!\SQLServer:Buffer Manager\Page Reads/sec"

--10指每秒等待工作空間,記憶體授權的進程數. 該計數器應該儘可能接近0,否則預示可能存在著記憶體瓶頸

--"\\!HN!\SQLServer:Memory Manager\Memory Grants Pending"

--11必須等待鎖請求的平均等待時間（毫秒）。如果該指標的值很高，則系統可能正經歷嚴重的資源競爭問題。

--"\\!HN!\SQLServer:Locks(_Total)\Average Wait Time (ms)"

--12未能立即授予的鎖請求數，如果該值始終大於0，則表示事物有問題

--"\\!HN!\SQLServer:Locks(_Total)\Lock Waits/sec"

--13鎖管理器每秒請求的新鎖和鎖轉換數. 通過最佳化查詢來減少讀取次數, 可以減少該計數器的值

--"\\!HN!\SQLServer:Locks(_Total)\Lock Requests/sec"

--14指每秒導致死鎖的鎖請求數. 死鎖對於應用程式的可伸縮性非常有害, 並且會導致惡劣的用戶體驗. 該計數器必須為0

--"\\!HN!\SQLServer:Locks(_Total)\Number of Deadlocks/sec"

--15必須等待授予的閂鎖請求的平均等待時間（毫秒）。

--(平均閂等待時間(毫秒)) 一個SQL Server執行緒必須等待一個閂的平均時間，以毫秒為單位。如果這個值很高，你可能正經歷嚴重的競爭問題

--"\\!HN!\SQLServer:Latches\Average Latch Wait Time (ms)"

--16未能立即授予的閂鎖請求數。

--(閂等待/秒) 在閂上每秒的等待數量。如果這個值很高，表明你正經歷對資源的大量競爭。

--"\\!HN!\SQLServer:Latches\Latch Waits/sec"

--17 批量請求，每秒收到SQL的批處理請求，此數值受（I/O，用戶數據，高速快取大小，請求複雜程式）而定，數值越高表明吞吐量越好

--"\\!HN!\SQLServer:SQL Statistics\Batch Requests/sec"

--18每秒SQL的編譯次數，當用戶達到穩定狀態時，該值應該穩定，如果不穩定，就是大量的用戶，連線與斷開，資源浪費。

--"\\!HN!\SQLServer:SQL Statistics\SQL Compilations/sec"

--19 每秒語句重新編譯的次數，一般情況下，此值越小，越好，如果值偏大，就表明SQL語句的重用性不好，請最佳化SQL語句，多次重編譯會加重CPU負擔

--"\\!HN!\SQLServer:SQL Statistics\SQL Re-Compilations/sec"

--20索引的每秒查找與全表每秒掃描次數

--"\\!HN!\SQLServer:Access Methods\Index Searches/sec"

--"\\!HN!\SQLServer:Access Methods\Full Scans/sec"

--當表上有很多插入動作時，一些頁面會被放滿。為了維護索引上的順序，SQL需要把一頁劈成兩頁，這個動作叫“pagesplit”。當資料庫的修 改比較多，尤其是插入比較多時，pagesplit是難免的。 如果這個值比較高，而你又 覺得他的確對性能有影響，可以考慮定 期重建索引，使用比較小的填充值(fillfactor)
--"\\!HN!\SQLServer:AccessMethods\PageSplit/sec"

--21系統中活動的SQL連線數. 該計數器的信息可以用於找出系統的最大並發用戶數

--"\\!HN!\SQLServer:General Statistics\User Connections"

3. 資源消耗檢測

a) 由於語句運行時間太長而導致的阻塞

b) 表掃描或者索引掃描帶來的阻塞

c) 未結束事務帶來的阻塞

d) 資源消耗類型

4. 查詢語句

a) 執行時間長的語句的分布

b) 消耗CPU高的語句

c) 消耗IO高的語句

d) 和執行計畫進行匹配找到可以最佳化的語句

最佳化原理

1. float和int、char和varchar、binary和varbinary是不兼容的。數據類型的不兼容可能使最佳化器無法執行一些本來可以進行的最佳化操作。

2. 儘量避免在where子句中對欄位進行函式或表達式操作，這將導致引擎放棄使用索引而進行全表掃描

3. 避免使用!=或>、IS NULL或IS NOT NULL、IN ，NOT IN等這樣的操作符因為這會使系統無法使用索引。

4. 不要在where子句中的“=”左邊進行函式、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

5. 索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。

6. 應儘可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若套用系統需要頻繁更新 clustered 索引數據列，那么需要考慮是否應將該索引建為 clustered 索引。

7. 避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。

組成

Expert for SQL Server分為收集和解析兩部分：

收集工具是一個綠色的可執行的檔案，直接放在SQL Server伺服器上運行。

解析工具需要安裝，安裝後打開收集的檔案進行解析。