色如果火熱火熱
② SQLServer巡檢內容
緩沖區是創建數據頁面的緩沖頁面池，這一般是SQL server內存池中最大的部分。這個計數器應該盡可能高。
低值表示只有少數的請求是在緩沖區，其他請求是在磁碟獲取服務
這種情況發生可能是SQL server還在准備狀態下，或緩沖區的增長需求超過最大可用內存，因此如果此值比較低，應該考慮為系統增加內存。
每好一個檢查點操作移到磁碟的頁面數量，這些值應該相當低，高值意味著緩沖中更多的頁面被標記為臟頁面。
臟頁面是在緩沖區中被修改的頁面。一旦被修改，就標記為臟並在下一個檢查點被寫回磁碟。
如果這個計數器較高說明系統發生大量的寫入操作，可能是I/O問題的徵兆。
記錄了緩沖區管理器的Lazy write進程每秒寫入的緩沖區數量。這個進程會把時間較長的臟頁面從緩沖區中刪除，將內存釋放
數值過高說明I/O有問題或是內存問題。
頁面平均壽命，表示一個不被引用的頁面在緩沖池中停留的時間。數值低意味著頁面從緩沖區中被移走
降低了緩沖的效率並指出內存壓力的可能。
值高說明內存短缺，需要將進度掛起等待內存空閑
表示SQLServer希望消耗的動態內存總數。
當前分配給SQLerver的總內存。 如果低於Target Server Memory
那麼可能是SQLserver內存需求很低，伺服器最大內存設置的太低
均使用性能監視器添加指標查看
方法參考：
https://blog.csdn.net/mingzai624/article/details/51348434
%disk time 磁碟時間百分比 平均值<85%
CurrentDiskQueueLength 當前磁碟隊列長度 平均值<2
disk Transfers/sec 每秒磁碟傳輸數量 平均值<100
Disk Bytes/sec 每秒傳輸位元組數 平均值<每秒10MB(該值需通過磁碟性能測試評估，不同磁碟指標不同)
avg.disk sec/read(write) 每次磁碟讀寫所需平均時間 平均值<10毫秒
%process Time 處理器時間百分比 平均值<80%
%privileged time 特權時間百分比 平均值<10%
windows server 包括用戶模式和特權模式兩種 %privileged time為20%-25%表明系統正在進行大量的IO操作，一個專用的SQLserver系統%privileged time不能超過10%
sqlserver:SQL Statistics Batch Requests/sec 每秒接收到的sql命令批數 根據機器配置 一般1000為繁忙，超過1000應注意
SQL Compilations/sec sql編譯次數 <100
SQL Reompilations/sec sql重編譯次數
Network interface bytes Total/sec 每秒總傳輸位元組數 平均值<NIC容量的50%
NetworkSegment %net utilization 網路利用率 平均值<80%
參考：
https://www.cnblogs.com/dahaoran/p/9447131.html
③ C/S結構使用SQLServer資料庫,在沒有網路的情況下,怎麼樣正常使用客戶端
像帶有離線功能的這種設計，你需要有一個本地資料庫，同時有一個內建的隊列。也就是說，當你執行本地操作的時候，你操作的是本地的資料庫，但同時還有一個線程在不停地讀取你的本地資料庫上傳至服務端。如果網路不通的情況下，就只是暫存在本地資料庫中，而不啟動線程讀取隊列。當網路連通了，你就需要去執行上傳了。
需要注意的是，你執行的本地操作最好別有出現並發操作的可能，比如說某個維護項，A用戶執行了離線修改，B用戶執行了離線刪除，那聽誰的？所以如果只是離線操作的情況，應當注意限制某些功能。
④ 如何測試sqlserver性能
對於DBA來講，我們都會做新伺服器的性能測試。我會從TPC的基準測試入手，使用HammerDB做整體性能評估（前身是HammerOra），跟廠商數據對比。再使用DiskSpd針對性的測試磁碟IO性能指標（前身是SQLIO），再到SQLIOSIM測試存儲的完整性，再到ostress並發壓力測試，對於資料庫伺服器遷移，我們還會收集和回放Profiler Trace，並收集期間關鍵性能計數器做對比。
下面我著重談談使用HammerDB的TPC-C來做SQL Server基準測試。
自己寫負載測試代碼很困難
為了模擬資料庫的負載，你想要有多個應用程序用戶和混合數據讀寫的語句。你不想總是對單一行更新相同的值，或者只是重復插入假的值。
自己動手使用Powershell、C#等語言寫負載測試腳本也不是不可能，只是太消耗時間，你需要創建或者恢復資料庫，並做對應的測試。
免費而簡單的壓測SQL Server：使用HammerDB模擬OLTP資料庫負載
HammerDB是一個免費、開源的工具，允許你針對SQL Server、Oracle、MySQL和PostgreSQL等運行TPC-C和TPC-H基準測試。你可以使用HammerDB來針對一個資料庫生成腳本並導入測試。HammerDB也允許你配置一個測試運行的長度，定義暖機階段，對於每個運行的虛擬用戶的數量。
首先，HammerDB有一個自動化隊列，讓你將多個運行在不同級別的虛擬用戶整合到一個隊列--你可以以此獲得在什麼級別下虛擬用戶性能平穩的結果曲線。你也可以用它來模擬用於示範或研究目的的不同負載。
用於SQL Server上的HammerDB的優缺點
HammerDB是一個免費工具，它也極易訪問和快速的啟動基準測試和模擬負載的方法。它的自動程序特性也是的運行工作負載相當自動。
主要缺點是它有一個學習曲線。用戶界面不是很直觀，需要花費時間去習慣。再你使用這個工具一段時間之後，將會更加容易。
HammerDB也不是運行每一個基準測試。它不運行TPC-E基準，例如，SQL Server更熱衷於當前更具發展的OLTP基準TPC-E。如果你用HammerDB運行一個TPC-C基準，你應該理解它不能直接與供應商提供的TPC-C基準結果相比較。但是，它是免費的、快速的、易用的。
基準測試使用案例
基準測試負載不能精確模擬你的應用程序的特點。每個負載是唯一的，在不同的系統有不同的瓶頸。對於很多使用案例，使用預定義的基準測試仍然是非常有效的,包括以下性能的比較：
多個環境（例如：舊的物理伺服器，新的虛擬環境）
使用各種因素的不同及時點（例如：使用共享存儲和共享主機資源的虛擬機的性能）
在配置改變前後的點
當然，對一個資料庫伺服器運行基準測試可以影響其他SQL Server資料庫或者相同主機上其他虛擬機的性能，在生產環境你確保有完善的測試計劃。
對於自學和研究來說，有預配置的負載非常棒。
開始使用基準測試
你可以從閱讀HammerDB官方文檔的「SQL Server OLTP Load Testing Guide」開始。
⑤ sqlserver broker 什麼意思
SQL Server Service Broker 你可以理解為一種 資料庫隊列的 東西.
非同步處理的.
例如我要執行一個耗時比較長的存儲過程.
普通的執行方法, 是我 執行了, 然後我等著伺服器處理完了, 才能繼續干別的事情.
SQL Server Service Broker 則是以一種隊列非同步處理的機制來完成.
我需要執行一個很耗時的處理.
那麼可能就是向某個 隊列, 發送一個消息, 然後立即就返回了.
這個時候, 我可以做其他的查詢處理.
等伺服器執行完畢後, 再向我發一個消息, 告訴我 執行的結果.
⑥ 關於Sqlserver資料庫 鎖機制的小疑問，下種情況是否需要加入鎖機制
不需要，就算確實用戶同時執行，資料庫的操作機制是有隊列的，所以不存在並發情況。
鎖基本用不到，我反正開發了5年了沒用到過。
你要了解死鎖發生的情況，一般是用事務的時候可能會碰到死鎖，你申請了A資源，鎖住了A然後申請B資源，其他人申請了B資源，然後申請A，這樣就互不相讓，導致A,B資源都不可訪問了，不過其他數據我不知道，SQLSERVER發生這種死鎖不是一直鎖死的，過幾分鍾就會發現這個死鎖，把鎖釋放掉，2個事務都失敗。
⑦ sqlserver關於動態執行sql問題
set @flag3=@flag3+1;
set @temp1=DATEADD(M,1,@temp1);
set @temp3=@temp1;
在你循環中賦值的語句，你是想每次循環賦不同的時間，但是在你用exec調用時，只能傳入最後計算好的唯一的值，這樣可能就查詢不到數據了吧，不然你拼接成字元串吧
⑧ sqlserver 在對象上的許可權設置有哪些動作分別是什麼意義
以下粘貼自SQL Server 的幫助信息，文字太多不能貼全，你自己可在幫助中查到更多信息。
-----------------------------
每個 SQL Server 安全對象都有可以授予主體的關聯許可權。本主題提供了下列信息：
許可權命名約定
與特定的安全對象相關的許可權
SQL Server 許可權
許可權檢查演算法
示例
許可權命名約定
下面介紹命名許可權時遵循的一般約定：
CONTROL
為被授權者授予類似所有權的功能。被授權者實際上對安全對象具有所定義的所有許可權。也可以為已被授予 CONTROL
許可權的主體授予對安全對象的許可權。因為 SQL Server 安全模型是分層的，所以 CONTROL 許可權在特定范圍內隱含著對該范圍內的所有安全對象的
CONTROL 許可權。例如，對資料庫的 CONTROL
許可權隱含著對資料庫的所有許可權、對資料庫中所有組件的所有許可權、對資料庫中所有架構的所有許可權以及對資料庫的所有架構中的所有對象的許可權。
ALTER
授予更改特定安全對象的屬性（所有權除外）的許可權。當授予對某個范圍的 ALTER
許可權時，也授予更改、創建或刪除該范圍內包含的任何安全對象的許可權。例如，對架構的 ALTER 許可權包括在該架構中創建、更改和刪除對象的許可權。
ALTER ANY
<伺服器安全對象>，其中的伺服器安全對象可以是任何伺服器安全對象。
授予創建、更改或刪除伺服器安全對象的各個實例的許可權。例如，ALTER
ANY LOGIN 將授予創建、更改或刪除實例中的任何登錄名的許可權。
ALTER ANY
<資料庫安全對象>，其中的資料庫安全對象可以是資料庫級別的任何安全對象。
授予創建、更改或刪除資料庫安全對象的各個實例的許可權。例如，ALTER
ANY SCHEMA 將授予創建、更改或刪除資料庫中的任何架構的許可權。
TAKE OWNERSHIP
允許被授權者獲取所授予的安全對象的所有權。
IMPERSONATE <登錄名>
允許被授權者模擬該登錄名。
IMPERSONATE <用戶>
允許被授權者模擬該用戶。
CREATE <伺服器安全對象>
授予被授權者創建伺服器安全對象的許可權。
CREATE <資料庫安全對象>
授予被授權者創建資料庫安全對象的許可權。
CREATE
<包含在架構中的安全對象>
授予創建包含在架構中的安全對象的許可權。但是，若要在特定架構中創建安全對象，必須對該架構具有
ALTER 許可權。
VIEW DEFINITION
允許被授權者訪問元數據。
REFERENCES
表的 REFERENCES 許可權是創建引用該表的外鍵約束時所必需的。
對象的 REFERENCES
許可權是使用引用該對象的 WITH SCHEMABINDING 子句創建 FUNCTION 或 VIEW
時所必需的。
適用於特定安全對象的許可權
下表列出了主要的許可權類別以及可應用這些許可權的安全對象的種類。
許可權
適用於
SELECT
同義詞
表和列
表值函數 [Transact-SQL 和公共語言運行時 (CLR)] 和列
視圖和列
VIEW CHANGE TRACKING
表
架構
UPDATE
同義詞
表和列
視圖和列
REFERENCES
標量函數和聚合函數（Transact-SQL 和 CLR）
Service Broker 隊列
表和列
表值函數（Transact-SQL 和 CLR）和列
視圖和列
INSERT
同義詞
表和列
視圖和列
DELETE
同義詞
表和列
視圖和列
EXECUTE
過程（Transact-SQL 和 CLR）
標量函數和聚合函數（Transact-SQL 和 CLR）
同義詞
CLR 類型
RECEIVE
Service Broker 隊列
VIEW DEFINITION
過程（Transact-SQL 和 CLR）
Service Broker 隊列
標量函數和聚合函數（Transact-SQL 和 CLR）
同義詞
表
表值函數（Transact-SQL 和 CLR）
視圖
ALTER
過程（Transact-SQL 和 CLR）
標量函數和聚合函數（Transact-SQL 和 CLR）
Service Broker 隊列
表
表值函數（Transact-SQL 和 CLR）
視圖
TAKE OWNERSHIP
過程（Transact-SQL 和 CLR）
標量函數和聚合函數（Transact-SQL 和 CLR）
同義詞
表
表值函數（Transact-SQL 和 CLR）
視圖
CONTROL
過程（Transact-SQL 和 CLR）
標量函數和聚合函數（Transact-SQL 和 CLR）
Service Broker 隊列
同義詞
表
表值函數（Transact-SQL 和 CLR）
視圖
⑨ 在SQLserver裡面「命名管道」是什麼意思
SQL Server中的命名管道(named pipe)及其使用
1. 什麼是命名管道？
與TCP/IP（傳輸控制協議或internet協議）一樣，命名管道是一種通訊協議。它一般用於區域網中，因為它要求客戶端必須具有訪問伺服器資源的許可權。
要解釋這個問題，我還是摘錄微軟官方的資料比較好
http://msdn.microsoft.com/zh-cn/library/ms187892.aspx
若要連接到 SQL Server 資料庫引擎，必須啟用網路協議。Microsoft SQL Server 可同時通過多種協議處理請求。客戶端用單個協議連接到 SQL Server。如果客戶端程序不知道 SQL Server 正在偵聽哪個協議，可以配置客戶端按順序嘗試多個協議。使用 SQL Server 配置管理器啟用、禁用以及配置網路協議。
Shared Memory
Shared Memory 是可供使用的最簡單協議，沒有可配置的設置。由於使用 Shared Memory 協議的客戶端僅可以連接到同一台計算機上運行的 SQL Server 實例，因此它對於大多數資料庫活動而言是沒用的。如果懷疑其他協議配置有誤，請使用 Shared Memory 協議進行故障排除。
注意：
使用 MDAC 2.8 或更早版本的客戶端不能使用 Shared Memory 協議。如果這些客戶端嘗試使用，將自動切換為 Named Pipes 協議。
TCP/IP
TCP/IP 是 Internet 上廣泛使用的通用協議。它與互連網路中硬體結構和操作系統各異的計算機進行通信。TCP/IP 包括路由網路流量的標准，並能夠提供高級安全功能。它是目前在商業中最常用的協議。將計算機配置為使用 TCP/IP 可能會很復雜，但大多數聯網的計算機已經配置正確。若要配置未在 SQL Server 配置管理器中出現的 TCP/IP 設置，請參閱 Microsoft Windows 文檔。
Named Pipes 是為區域網而開發的協議。內存的一部分被某個進程用來向另一個進程傳遞信息，因此一個進程的輸出就是另一個進程的輸入。第二個進程可以是本地的（與第一個進程位於同一台計算機上），也可以是遠程的（位於聯網的計算機上）。
VIA
虛擬介面適配器 (VIA) 協議和 VIA 硬體一同使用。有關如何使用 VIA 的信息，請與硬體供應商聯系。
Named Pipes 與 TCP/IP 套接字
在快速區域網 (LAN) 環境中，傳輸控制協議或 Internet 協議 (TCP/IP) 套接字客戶端和 Named Pipes 客戶端在性能方面不相上下。但是，網路速度越慢[如在廣域網 (WAN) 或撥號網路上]，TCP/IP 套接字客戶端與 Named Pipes 客戶端的性能差異越明顯。這是因為進程間通信 (IPC) 的機制在對等項間的通信方式不同。
對於 Named Pipes，通常網路通信交互性更強。一個對等方直到另一個對等方使用讀取命令請求數據時才發送數據。在開始讀取數據前，網路讀取一般包括一系列窺視 Named Pipes 的信息。這在慢速網路中可能開銷非常大，並會導致過多的網路流量，其他的網路客戶端反過來也會受到影響。
闡明所討論的是本地管道還是網路管道也很重要。如果伺服器應用程序在運行 SQL Server 實例的計算機的本地運行，則可以選擇本地 Named Pipes 協議。本地 Named Pipes 以內核模式運行且速度非常快。
對於 TCP/IP 套接字，數據傳輸的效率更高，開銷也更少。數據傳輸還可以利用 TCP/IP 套接字性能增強機制的優點，例如窗口化、延遲確認等。這在慢速網路中可能非常有益。對於應用程序的不同類型，這類性能差異可能非常大。
TCP/IP 套接字還支持積壓隊列。試圖連接到 SQL Server 時，與可能導致管道忙錯誤的 Named Pipes 相比，該隊列可以帶來有限的平穩效果。
通常，TCP/IP 在慢速 LAN、WAN 或撥號網路中效果較好。而當網路速度不成問題時，Named Pipes 則是更好的選擇，因為其功能更強、更易於使用並具有更多的配置選項。
啟用協議
該協議必須在客戶端和伺服器上都啟用才能正常工作。伺服器可以同時監聽所有已啟用的協議的請求。客戶端計算機可以選取一個協議，或按照 SQL Server 配置管理器中列出的順序嘗試這些協議。
注意：
Microsoft SQL Server 不支持 Banyan VINES 順序包協議 (SPP)、多協議、AppleTalk 或 NWLink IPX/SPX 網路協議。以前使用這些協議連接的客戶端必須選擇其他協議才能連接到 SQL Server。
實際上，命名管道在SQL Server配置管理器中看起來是下面這樣。其實，在安裝好SQL Server之後就自動會有一個管道名稱。你當然也可以修改該名稱的。
2. 為什麼用命名管道？
使用命名管道的原因一般有兩個方面
提高速度
假設同樣在區域網中，那麼使用命名管道協議會比TCP/IP協議快一些。
增加安全性
因為命名管道是只能用於區域網的，那麼如果伺服器關閉了TCP/IP協議而僅啟用命名管道，就可以避免一些安全隱患
3. 如何使用命名管道？
要使用命名管道連接到SQL Server，客戶端代碼中的連接字元串大致的語法是這樣的
"server=.;database=northwind;uid=sa;pwd=pass@word;Network Library=dbnmpntw"
如果伺服器是命名實例，則
"server=.\instanceName;database=northwind;uid=sa;pwd=pass@word;Network Library=dbnmpntw"
【注意】必須在伺服器啟用named pipe協議，並且啟動Broswer服務
為了避免在連接字元串中這么麻煩，也為了避免泄露我們連接數據的一些機密信息。SQL Server Native Client還支持定義別名
⑩ 怎樣查出SQLServer的性能瓶頸
SQLServer性能監控
這套性能優化的清單將至少准科學的幫助你找出你的SQLServer任何明顯的性能問題。說是這樣說，SQLServer的性能調優仍然是很困難的。我試圖用這套清單去找出「容易」的sqlserver性能問題，困難的留待稍後。我這樣做是因為很容易將容易和困難的的性能調優問題搞混。通過列出一個「容易」的性能調優范圍，就很容易的將這些問題解決，一旦解決了這些容易的問題，那麼你就能集中去解決更困難的問題。
使用這個SQLServer性能調優清單的一個好處是，它將不僅僅告訴你目前最容易解決的性能問題是什麼，而且還幫助你正確的去解決。在某種程度上，你可以選擇不同的順序進行。換句話說，你可以故意做出特殊的決定而不是按照清單通常的順序進行。某種意義上說你是對的，不是所有的性能調優建議都適合所有的情形。另外，你的決定是基於你的資源限制，例如沒有足夠的錢去買滿足負荷的硬體。如果真是那樣的話，你就別無選擇了。還有，你的決定可能基於一些政治原因，那是你不得不作出的改變。不管怎樣，你需要知道你能做什麼，使用這個性能調優清單找出你能改變的范圍並做出相應的改變提升你的SQLServer的性能。
一般來說，你將在你的每一個SQL伺服器上執行這個清單。如果遇到清單中的一些問題，這會花掉你一些時間。我建議你從目前性能問題最多的的伺服器開始，然後當你有時間的時候按照自己的思路去解決其他伺服器。
一旦你完成了，可仍然有很多事情要去做。記住，這些只是一些容易的。一旦你完成了這些容易的，接下來你需要花時間去解決更困難問題。這個是另一篇文章要解決的問題了。
怎樣進行你的SQLServer性能調優呢?
為了使其變得容易，我把它們分成了以下幾個部分：
？ 使用性能監視器找出硬體瓶頸
？ SQLServer硬體性能監控列表
？ 操作系統性能監控列表
？ SQLServer2000配置性能監控列表
？ 資料庫配置設置性能監控列表
？ 索引性能監控列表
？ 應用程序和T-SQL性能監控列表
？ SQLServer資料庫作業性能監控列表
？ 使用Profiler找出低效的查詢
？ 怎樣最好的實現SQLServer性能監控
管理你的SQLServe性能的最好方法是首先回顧上面每一部分的內容，把它們列印出來。然後完成每一部分的內容，寫下你收集到的結果。你也可以按照你喜歡的順序進行。上面的步驟僅僅列出了我執行的順序，因為那樣通常能達到一個比較好的效果。
性能監控列表
計數器名稱 均值 最小值 最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections
在上表輸入你的結果.
使用性能監視器找出SQLServer硬體瓶頸
開始SQLServer性能調優的最佳地方就是從性能監視器（系統監視器）開始。通過一個24小時的周期對一些關鍵的計數器進行監控，你將對你SQLServer伺服器的硬體瓶頸了如指掌。
一般來說，使用性能監視器去創建一個一些關鍵的計數器的24小時周期的監控日誌。當你決定創建這個日誌的時候，你需要選擇一個典型的24小時的周期，例如，選擇一個典型的比較忙的日期，而不是周日或節假日。
一旦你將這些捕獲的數據形成日誌後，在性能監視器的圖形界面下會顯示計數器的推薦值。你在上表中記下均值、最小值、峰值。做完這些後，用你的結果跟下面的分析比較。通過你的結果和下面的建議值進行比較，你將能快速的找到你的SQLServe正在經歷的潛在的硬體瓶頸。
關鍵性能計數器說明
下面是不同關鍵性能計數器的一個討論，它們的建議值和為了幫助解決硬體瓶頸問題的一些選項。注意我已經限制了性能監視器需要監視的一些關鍵計數器。我這么做是因為在本文我們的目的是為了容易的找到顯而易見的性能問題，許多其他的性能監視器計數器你能在本網站其他地方找到。
Memory: Pages/sec
這個計數器記錄的是每秒鍾內存和磁碟之間交換的頁面數。交換更多的頁面、超過你伺服器承受的更多的I/O，將輪流降低你SQLserver的性能。你的目的就是盡量將頁面減少到最小，而不是消除它。
如果你的伺服器上SQLServer是最主要的應用程序，那麼這個值的理想范圍是0～20之間。可能很多時候你看到的值都會超過20。這個值一般要保持在每秒的平均頁數在20以下。
如果這個值平均總是超過20，其中最大的一個可能是內存瓶頸問題，需要增加內存。通常來說，更多的內存意味著需要執行的頁面更少。
在大多數情況下，伺服器決定SQLServer使用的適當內存的大小，頁面將平均小於20。給SQLServer適當的內存意味著伺服器的緩存命中率（Buffer Hit Cache Ratio 這個稍後會講到）達到99％或者更高。如果在一個24小時的周期里你的sqlserver的緩存命中率達到99％或者更高，但是在這個期間你的頁面數總是超過20，這意味著你或許運行了其他的程序。如果是這樣的情況，建議你移除這些程序，使SQLServer是你的伺服器的最主要的程序。
如果你的sqlserver伺服器沒有運行其他程序，並且在一個24小時的周期里頁面數總是超過20，這說明你應該修改你對SQLServer的內存設置了。將其設置為「動態配置SQLServer的內存」，並且最大內存設置得高一些。為了達到最優，SQLServer將盡可能的獲得多的內存以完成自己的工作，而不是去和其他的程序爭奪內存。
Memory: Available Bytes
另一個檢查SQLServer是否有足夠的物理內存的方法是檢查Memory Object: Available Bytes計數器。 這個值至少大於5M，否則需要添加更多的物理內存。在一個專門的SQLServer伺服器上，SQLServer試圖維持4-10M的自由物理內存，其餘的物理內存被操作系統和SQLServer使用。當可用的物理內存接近5M或者更低時，SQLServer最可能因為缺少內存而遇到性能瓶頸。遇此情況，你需要增加物理內存以減少伺服器的負荷，或者給SQLServer配置一個合適的內存。
Physical Disk: % Disk Time
這個計數器度量磁碟陣列繁忙程度（不是邏輯分區或磁碟陣列上獨立的磁碟）。它提供一個對磁碟陣列繁忙程度相對較好的度量。原則上計數器% Disk Time的值應該小於55%。如果持續超過55%（在你24小時的監控周期里大約超過10分鍾），說明你的SQLServer有I/O瓶頸。如果你只是偶爾看到，也不必太擔心。但是，如果經常發生的話（也就是說，一個小時出現好幾次），就應該著手尋找增加伺服器I/O性能或者減少伺服器負荷的解決之道了。一般是為磁碟陣列增加磁碟，或者更好更快的磁碟，或者給控制器卡增加緩存，或者使用不同版本的RAID，或者更換更快的控制器。
在NT4.0上使用該計數器之前，確認在NT命令提示符下輸入diskperf -y，重啟伺服器，以便手動打開。在NT4.0下第一次必須將該計數器打開，Windows2000默認是打開的。
Physical Disk: Avg. Disk Queue Length
除了觀察物理磁碟的% Disk Time計數器外，還可以用Avg. Disk Queue Length計數器。磁碟陣列中的各個磁碟的該值如果超過2（在你24小時的監控周期里大約超過10分鍾），那麼你的磁碟陣列存在I/O瓶頸問題。象計數器% Disk Time一樣，如果只是偶爾看到，也不必太擔心。但是，如果經常發生的話，就應該著手尋找增加伺服器I/O性能的解決之道了。如前所述。
你需要計算這個值，因為性能監視器不知道你的磁碟陣列中有多少物理磁碟。例如，如果你有一個6個物理磁碟組成的磁碟陣列，它的Avg.
Disk Queue Length值為10，那麼實際每個磁碟的值為1.66（10/6＝1.66），它們都在建議值2以內。
在NT4.0上使用該計數器之前，確認在NT命令提示符下輸入diskperf -y，重啟伺服器，以便手動打開。在NT4.0下第一次必須將該計數器打開，Windows2000默認是打開的。
一起使用這兩個計數器將幫助你找出I/O瓶頸。例如，如果% Disk Time的值超過55%，Avg. Disk Queue Length計數器值超過2，伺服器則存在I/O瓶頸。
Processor: % Processor Time
處理器對象： % Processor Time計數器對每一個CPU可用，並針對每一個CPU進行檢測。同樣對於所有的CPU也可用。這是一個觀察CPU利用率的關鍵計數器。如果% Total Processor Time計數器的值持續超過80%（在你24小時的監控周期里大約超過10分鍾），說明CPU存在瓶頸問題。如果只是偶爾發生，並且你認為對你的伺服器影響不大，那沒問題。如果經常發生，你應該減少伺服器的負載，更換更高頻率的CPU，或者增加CPU的數量或者增加CPU的2級緩存（L2 cache）。
System: Processor Queue Length
根據% Processor Time計數器，你可以監控Processor Queue Length計數器。每個CPU的該值如果持續超過2（在你24小時的監控周期里大約超過10分鍾），那麼你的CPU存在瓶頸問題。例如，如果你的伺服器有4個CPU，Processor Queue Length計數器的值總共不應超過8。
如果Processor Queue Length計數器的值有規律的超過建議的最大值，但是CPU利用率相對不是很高，那麼考慮減少SQLServer的"max worker threads"的配置值。Processor Queue Length計數器的值高的可能原因是有太多的工作線程等待處理。通過減少"maximum worker threads"的值，強迫線程池踢掉某些線程，從而使線程池得到最大的利用。
一起使用計數器Processor Queue Length和計數器% Total Process Time，你可以找到CPU瓶頸，如果都顯示超過它們的建議值，可以確信存在CPU瓶頸問題。
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server Buffer中的計數器Buffer Cache Hit Ratio用來指出SQLServer從緩存中而不是磁碟中獲得數據的頻率。在一個OLTP程序中，該比率應該超過90%，理想值是超過99%。如果你的buffer cache hit ratio低於90%，你需要立即增加內存。如果該比率在90%和99%之間，你應該認真考慮購買更多的內存了。如果接近99%，你的SQLServer性能是比較快的了。某些情況下，如果你的資料庫非常大，你不可能達到99%，即使你在伺服器上配置了最大的內存。你所能做的就是盡可能的添加內存。
在OLAP程序中，由於其本身的工作原理，該比率大大減少。不管怎樣，更多的內存總是能提高SQLServer的性能。
SQL Server General: User Connections
既然sqlserver的使用人數會影響它的性能，你就需要專注於sqlserver的General Statistics Object: User Connections計數器。它顯示sqlserver目前連接的數量，而不是用戶數。
如果該計數器超過255，那麼你需要將sqlserver的"Maximum Worker Threads" 的配置值設置得比預設值255高。如果連接的數量超過可用的線程數，那麼sqlserver將共享線程，這樣會影響性能。"Maximum Worker Threads"需要設置得比你伺服器曾經達到的最大連接數更高。