【轉】怎樣查出SQLServer的性能瓶頸

怎樣查出SQLServer的性能瓶頸

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址

若是你曾經作了很長時間的DBA，那麼你會了解到SQLServe的性能調優不是一個精密的科學。即便是，對於爲最佳的性能找到最佳的配置也是很困難的。這是由於對於調優來講不多東西是絕對的。例如，一個性能調優可能對某一方面有用，但是卻會影響其餘的性能。

我曾經作過DBA，在最後7年的日子裏，我總結了一套SQLServer調優的清單。當第一次進行SQLServer性能調優的時候，能夠用它來做爲一個嚮導。我常常被邀請去檢查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"須要設置得比你服務器曾經達到的最大鏈接數更高。

SQLServer硬件性能監控列表

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址

性能監控列表

SQLServer硬件特徵 相應的描述 
Number of CPUs 
CPU MHz 
CPU L2 Cache Size 
Physical RAM Amount 
Total Amount of Available Drive Space on Server 
Total Number of Physical Drives in Each Array 
RAID Level of Array Used for SQL Server Databases 
Hardware vs. Software RAID 
Disk Fragmentation Level 
Location of Operating System 
Location of SQL Server Executables 
Location of Swap File 
Location of tempdb Database 
Location of System Databases 
Location of User Databases 
Location of Log Files 
Number of Disk Controllers in Server 
Type of Disk Controllers in Server 
Size of Cache in Disk Controllers in Server 
Is Write Back Cache in Disk Controller On or Off? 
Speed of Disk Drives 
How Many Network Cards Are in Server? 
What is the Speed of the Network Cards in Server? 
Are the Network Cards Hard-Coded for Speed/Duplex? 
Are the Network Cards Attached to a Switch? 
Are All the Hardware Drivers Up-to-Date? 
Is this Physical Server Dedicated to SQL Server? 

在上表裏輸入你的值.

監控硬件是早期的重要步驟 

從之前的章節裏（使用性能監視器），你能夠找出一些潛在的硬件性能瓶頸。這一節裏，咱們將查看SQLServer硬件的每個主要組件，以幫助最優化你硬件的性能。 將分如下幾個部分進行： 
？ CPU 
？ Memory 
？ Disk Storage 
？ Network Connectivity 
？ Misc.
做爲監控的一部分，你須要完成上面的列表，這樣，你就會對你的服務器無所不知了。 

CPU

CPU的數量

這第一個是顯而易見的，越多的CPU性能越快。SQLServer2000的標準版支持4個CPU。企業版支持最多32個CPU，具體根據操做系統而定。更多的CPU對於全面提高SQLServer的性能是頗有效的。

對任何一個基於SQLServer的應用程序須要的CPU數量進行估算是很困難的。這是由於每一個應用程序的工做都是不一樣的，而且它們的使用也不一樣。有經驗的DBA老是對應用程序須要什麼樣的CPU有個大概的瞭解，卻很難真正知道須要什麼樣的CPU，直到在真實條件下測試了服務器的配置。
因爲選擇合適的CPU的數量是困難的，因此你能夠考慮下面的原則： 
？ 儘量的購買更多CPU數量的服務器。 
？ 若是你作不到，那麼至少要購買一個能擴展CPU數量的服務器。幾乎因此的SQLServer在工做量增長時都須要更多的動力。
這是一些潛在的假設： 
？ SQLServer將僅僅用來運行一個同時不超過5個用戶的財務應用程序，而且你預期將來兩年不會改變。若是是這樣，單CPU的服務器就足夠用了。若是預期用戶數量在不久會增長的話，那麼你須要考慮購買一個單CPU的，而且擁有可擴展一個CPU數量的服務器以備不時之需。 
？ SQLServer用來運行一個內部的寫程序，這個程序不只僅包括OLTP，並且須要支持繁重的報表需求。預期用戶同時不會超過25個。若是是這樣，你須要考慮一個雙CPU的服務器，可是它應該能夠擴展到4個CPU。「繁重的報表需求」的真正含義是很難預計的。我曾經看到一些至關簡單，可是很差的寫報表，佔用了服務器所有的CPU。 
？ SQLServer運行一個目前用戶爲100到150之間的ERP包。對於象這樣的「重型」程序，詢問推薦的硬件配置。由於他們已經對他們的產品須要的CPU配置有了一個很好的建議。
我能提供一些其餘的例子，可是經過這些我發現：正確預計基於SQLServer的一個特殊的應用程序的CPU的數量是很困難的。你一般應該購買一個比你認爲要大的系統，由於在許多狀況下，一個應用程序的使用需求常常是被低估了的。如今購買一個有多個CPU的大服務器來長期使用也不是很昂貴了，總比你在6到12個月後因爲當初的低估不得不從新替換你整個服務器要划算得多。 

CPU速度 

象CPU的數量同樣，須要的CPU的速度 也是很難估計的。通常說來，儘可能購買最快的CPU。購買速度快的老是好於速度慢的。 

CPU 2級緩存 

我曾經遇到一個比較廣泛的問題：購買2級緩存較小的便宜的CPU好呢，仍是購買2級緩存較大的昂貴的至強CPU好？事實上，在購買2級緩存較小的更快的芯片和購買較大2級緩存的芯片上作出決定是很困難的。這裏有一些規則：
？ 若是你僅有一、2個CPU，那麼儘可能買最快的，其次才考慮2級緩存。若是你必定要選擇2級緩存大小的話，儘可能選擇較大的。 
？ 可是，若是你有4個或更多的CPU，那麼你須要較大2級緩存的CPU，即便它們的速度不過高。這是由於對於一個有4個或更多CPU的服務器來講，要想盡可能讓SQLServer運行良好的話，2級緩存必定要大，不然將浪費額外的CPU。
CPU監控列表 

既然本文是關於你SQLServer目前CPU性能的一個監控，那麼你如今應該關注你目前的服務器是否存在CPU瓶頸。正如在《使用性能監視器找出硬件瓶頸》一文所討論的那樣，你能夠使用性能監視器幫助你找到硬件瓶頸。

若是你CPU目前沒有瓶頸問題，那麼你能夠忽略下一部分關於memory的討論。但若是你的服務器目前存在CPU瓶頸，而且是主要的性能問題，那麼你能夠選擇如下的方法去解決瓶頸：
？ 減小服務器的負荷。能夠經過減小用戶數量、調優查詢、調優索引、除去在服務器上運行的沒必要要的程序來達到目的。另外若是你的產品服務器上還運行有關於報表的程序，將其移到一個專門爲報表作的服務器上。 
？ 若是CPU瓶頸是因爲缺乏服務器內存引發的，請添加更多的內存。這是一個廣泛的問題。 
？ 若是你目前的服務器有更多的CPU插槽，那麼請添加更多的CPU。 
？ 若是能夠的話，用更快的CPU升級你的服務器。 
？ 購買一個新的有更多更快CPU的服務器。
不幸的是，這些方法在處理CPU瓶頸時也不是垂手可得的，固然除非大家公司有足夠的錢。做爲一個DBA來講，你可能惟一能作的就是「減小服務器的負荷」這一項了。 

內存 

在討論完CPU後，如今開始討論內存，不要認爲它不象CPU那麼重要。事實上，內存多是任何SQLServer服務器最重要的硬件部分，它比其餘硬件更能影響SQLServer的性能。
當咱們討論內存的時候，通常指的是物理內存，而不是虛擬內存。SQLServer不是設計來用虛擬內存的，儘管它也能用。 並不是聯合使用操做系統的物理內存和虛擬內存，SQLServer老是儘量的使用物理內存。這主要是爲了提升速度。訪問內存中的數據老是比訪問磁盤上的快得多。

SQLServer不能老是把數據放在內存（SQLServer緩存）中，它也訪問磁盤，就像操做系統管理虛擬內存同樣。但SQLServer的「緩存」機制比操做系統的虛擬內存更快更詭異。

快速的知道SQLServer是否有足夠內存的方法是檢查SQLServer的緩存命中率（在《使用performance Monitor找出硬件瓶頸》一文有過討論）。若是這個計數器爲99%或者更高，說明有足夠的內存。若是這個計數器在90%與99%之間而且你對性能比較樂觀的話，那麼你的SQLServer可能有足夠的內存，可是若是你不滿意服務器性能的話，則須要添加內存了。
若是這個計數器少於90%，關鍵在於性能沒法被接受（若是運行的是OLAP，少於90%一般也沒問題），因此須要添加更多的內存。 SQLServer的物理內存的理想值應該超過服務器上最大數據庫的大小。這老是不可能的，由於許多數據庫是很是大的。若是你正在計算
SQLServer的大小，而且有足夠的預算，那麼儘可能去購買能容納整個數據庫大小的物理內存。假定你的數據庫是4G或者更小，那麼這一般不會成太大的問題。可是若是你的數據庫更大（或者預期會超過4G），那麼你可能容易地提供超過4G的內存。SQLServer2000企業版支持高達64G的內存，沒有太多的服務器支持這麼大的內存。

即便SQLServer的緩存不能容納整個數據庫，SQLServer仍然能快速的獲取數據。99%的緩存命中率意味着SQLServer須要的數據99%的時間都是在緩存中的，性能很是快。例如，我管理一個30G的數據庫，可是服務器僅有4G的內存，而緩存命中率老是高於99.6%。這意味着大多數狀況下用戶沒有同時訪問數據庫裏全部的數據，僅僅一小部分而已，SQLServer也能將常常訪問的數據始終放在緩存中，因此99%的請求在這種狀況下能迅速完成，即便服務器的內存少於數據庫的大小。

那麼，要點是什麼呢？若是你的緩存命中率少於90%，那麼認真的考慮添加更多的內存了。

磁盤存儲器 

在內存以後，磁盤存儲器也是常常影響SQLServer性能的的最重要的因素。 它也是一個複雜的話題。在這部分，我將專一於磁盤存儲器影響性能最容易的地方。 服務器上可用磁盤空間的總量 全部的磁盤陣列至少要20%的可用空間，這樣對性能影響纔不是很大。這是由於NTFS（假定你使用的是該磁盤格式）須要額外的空間才能工做得更好。若是沒有可用空間，那麼NTFS不能運行而且性能會下降。它也會致使更多的磁盤碎片，由於服務器讀寫數據更加可能。
查看你SQLServer的每一塊物理磁盤，檢查一下是否有至少20%或者更多的可用空間。若是沒有，考慮如下方法： 
？ 刪除磁盤上任何不須要的數據（清空回收站、臨時文件、setup文件等等） 
？ 刪除一些數據以留出更多的空間 
？ 添加更多的磁盤空間
每個磁盤陣列的物理磁盤數量 一個磁盤陣列一般由2個或者更多的物理磁盤做爲一個單一的單元一塊兒工做。例如RAID5陣列也許有4個物理磁盤。那麼爲何瞭解你SQLServer的一個或多個磁盤陣列有多少個物理磁盤是很重要的呢？
除鏡像磁盤（兩個物理磁盤一塊兒工做）外，磁盤陣列有越多的物理磁盤，對於磁盤陣列的讀寫就越快。 例如，假如想買一個新的作RAID5的至少有100M可用空間的SQLServer服務器，並要求提供如下兩種不一樣的磁盤陣列配置： 
？ 4個36G的磁盤（可用空間爲108G） 
？ 7個18G的磁盤（可用空間爲108G）
按照要求這二者都符合標準。可是哪種磁盤陣列能提供更快的讀寫性能呢？答案是第二種，即7個18G的磁盤。爲何呢？
通常說來，磁盤陣列中磁盤越多，可用來讀寫的磁盤頭就越多。例如，SCSI磁盤能夠同時讀和寫數據。因此一個磁盤陣列有越多的物理磁盤，該磁盤陣列的讀寫速度就越快。陣列中的每一個磁盤分擔一部分工做量，磁盤越多越好。這兒有一個限制，依賴於磁盤控制器，但一般說來，越多越好。 那麼這對你來講意味着什麼呢？在你查看了你的服務器有多少磁盤陣列、每一個磁盤陣列有多少磁盤後，從新配置目前的磁盤陣列以更好的利用
是否是可行呢？
例如，假定你目前的服務器有2個磁盤陣列用來存儲用戶數據庫。每個是3個18G的磁盤組成的RAID5陣列。這種狀況下，將兩個陣列從新配置成一個由6個18G的磁盤組成的陣列會更好。這不只僅提供了更快的I/O，並且也能得到18G的的磁盤空間。
仔細檢查你目前的配置，你能夠改變不少，也許不能夠。可是若是你能夠改變的話，你將在你改變以後當即從中獲得好處。 SQLServer數據庫一般使用的磁盤陣列的RAID級 或許你已經知道，磁盤陣列有不一樣類型的配置，稱做RAID級別。每一級別都有各自的擁護者和反對者。下面是一些常用的RAID級別的簡單總結，瞭解後你就知道在你的SQLServer怎樣更好的使用它們：
RAID 1 
？ 操做系統（包括虛擬內存）和SQLServer最理想的是運行在RAID1磁盤陣列上。也有人將虛擬內存運行在一個獨立的RAID1磁盤陣列上，可是我對這樣作是否能提供虛擬內存性能表示懷疑，在一個好的配置的服務器上，那不是問題。 
？ 若是你的SQLServer數據庫很是小，全部的數據都能在一個磁盤下存儲，那麼請爲你的數據庫文件存儲考慮RAID1級別。 
？ 理想地，每個獨立的事務日誌應該運行在一個獨立的RAID1磁盤陣列上。這是由於事務日誌在不斷的讀寫，經過放在獨立的磁盤陣列上，因爲連續的磁盤I/O不和更慢的隨機的磁盤I/O混合使用，從而使性能獲得提高。
RAID 5 
？ 儘管這是比較流行的RAID級別，對於最優化SQLServer的I/O性能還不是最好的選擇。若是數據庫的寫操做比例超過10%，大多數OLAP數據庫都是這樣，寫性能會下降，從而傷害整個SQLServer的I/O性能。RAID5最好用於只讀或者大部分時候是讀的數據庫。在微軟的測試發現RAID5比RAID10幾乎要慢50%。
RAID 10 
？ RAID10爲SQLServer數據庫提供了最好的性能，儘管它是最貴的。數據庫的寫操做越多，使用RAID10更重要。 
？ RAID10陣列對於事務日誌也是不錯的選擇，假定它只用來存儲單個事務日誌。
更可能的是，你目前的SQLServer配置不符合上面的建議。某些狀況下，你須要更改你目前的配置以儘可能符合上面的建議，可是大多數狀況下，你可能不得不忍受直到有新的預算去買新的服務器和磁盤陣列。
若是你只能選擇上面的一個 建議的話，我建議你使用RAID10。這將最大化你SQLServer的I/O性能。 

硬件RAID vs. 軟件RAID 

能夠經過硬件或者軟件（經過操做系統）實現RAID。不要使用軟件RAID，會很慢，老是使用硬件RAID，這是不爭的事實。 

磁盤碎片 

若是你在一個嶄新的磁盤陣列上建立了一個新的數據庫，數據庫文件和事務日誌文件會是一個連續的文件。但若是數據庫文件或事務日誌文件
在建立時指定的最大容量裏增加（一般都會超過該容量），隨着時間的推移文件可能會產生碎片。文件碎片（磁盤陣列上分散的許多塊文件）
引發你的磁盤陣列在讀寫數據時變慢，從而影響磁盤I/O的性能。
做爲性能監控的一部分，你須要瞭解你的SQLServer數據庫和事務日誌是怎樣產生碎片的。若是你使用的是Windows2000或者2003，你能夠使用內建的碎片整理工具去分析文件變成碎片的嚴重程度。若是你運行的是NT4.0，那麼你能夠藉助第三方工具如DisKeeper來進行分析。 若是分析結果須要進行碎片整理，則進行。不幸的是，整理SQLServer數據庫和事務日誌的碎片不老是一件容易的事。運行着的文件，象在 SQLServer上運行的數據庫和事務日誌文件，不老是能進行碎片整理。例如，內建的碎片整理工具不能整理SQLServer的MDF和LDF文件，可是DisKeeper8.0在大多數狀況下能夠，而不是所有狀況均可以。這意味着在某些狀況下，爲了整理SQLServer的MDF和LDF文件的碎片，你不得不使SQLServer離線。依賴文件整理的方式、文件的大小、這可能須要花費不少小時。
你真有必要對數據庫文件進行碎片整理嗎？若是你的I/O性能目前比較適中，那麼你不須要進行碎片整理。可是若是你的I/O性能是個瓶頸的話 ，碎片整理是一個提高性能的便捷之道，儘管大多數狀況下會花費一些時間。
理想地，你應該週期性的整理你的SQLServer數據庫和事務日誌碎片。這樣，你能確信沒有I/O性能問題。 

操做系統 

爲了最佳性能，操做系統文件和SQLServer數據庫文件（MDF、LDF文件）不要放在一個磁盤陣列上。另外，操做系統文件應該放在一個支持 RAID一、5或10的磁盤陣列上。
和大多數人同樣，一般我也是在服務器的C盤上安裝操做系統。而且爲了容錯和最好的性能將C盤配置爲RAID1的鏡像磁盤。 在大多數狀況下， 只要你不把操做系統和SQLServer數據文件放在同一個磁盤陣列上，你在服務器上處理操做系統文件就會得到很大的性能。 

SQLServer程序 

象操做系統文件同樣，SQLServer程序也不是很挑剔，只要不和SQLServer數據文件放在同一個磁盤陣列上就行。和操做系統文件一塊兒，我一般將SQLServer程序放在被配置爲RAID1鏡像的C盤。 若是你在配置SQLServer7.0的羣集，那麼SQLServer程序不能安裝在C盤，必須安裝在共享磁盤陣列上。不幸的是這常常和SQLServer的數據文件是同一個磁盤陣列，除非你有足夠的錢僅僅爲提高SQLServer程序性能而購買一個獨立的獨立磁盤陣列。當性能被與數據庫文件在同一磁盤陣列上的SQLServer程序輕微影響時，得到容錯能力也是一個不太壞的折中方案。另外一方面，升級到SQLServer2000羣集是一個不錯的選擇。若是你在配置SQLServer2000羣集，那麼SQLServer程序必須放在本地磁盤上，而不是共享磁盤陣列上，因此性能不成問題。 

虛擬內存 

若是你有一臺SQLServer的專用服務器，而且SQLServer的內存設置爲動態（缺省），那麼虛擬內存將不多用到。這是由於SQLServer一般不會太多的使用它。所以，虛擬內存放在任何一個特定的位置不是關鍵，除了不要放在SQLServer數據文件的同一磁盤陣列上。 一般，我把虛擬內存放在操做系統和SQLServer程序的同一磁盤陣列上，正如我前面所述，它是一個支持RAID一、RAID五、RAID10的磁盤陣列，一般是C盤，這使管理員更容易管理。 若是不是SQLServer專用服務器，除了SQLServer外還運行了其餘程序，因爲其餘程序的緣由，虛擬內存可能會有問題，爲了得到更好的性能，你須要考慮將虛擬內存配置到一個專用的列上。然而，更好的方法是使用一臺SQLServer的專用服務器。 

tempdb數據庫 

若是tempdb數據庫的使用比較繁重，爲了提升磁盤I/O性能，考慮將它移到一個RAID1或者RAID10的獨立磁盤陣列上。不要使用RAID5，由於對於寫操做是慢的，如使用，會對tempdb產生反作用。若是不能提供獨立的磁盤陣列，你有不想將它與數據庫文件放在同一個磁盤陣列上，能夠考慮放在操做系統的那個磁盤上，這將幫助減小I/O的爭奪以提升性能。 若是應用程序很是多的使用tempdb數據庫，從而引發文件增加超過它的缺省大小，那麼你須要將tempdb的缺省大小增長到最近你的應用程序實際使用的tempdb的大小。這是由於每次SQLServer服務從新啓動後，tempdb文件都會按照缺省值重建。當tempdb增加時會花費一些性能資源。經過在SQLServer從新啓動時給tempdb分配一個合適的大小，你沒必要擔憂在使用時超過這個大小了。 另外，在tempdb數據庫裏繁重的操做會下降應用程序的性能。尤爲是在建立一個或多個大的臨時表去查詢或者作聯接時。爲了加速這些查詢，確信tempdb數據庫的AUTOSTATS（自動更新統計信息）選項已打開，而且在這些臨時表上建立一個或多個索引。大多數狀況下，你將發現這能充分加速你的應用程序。但象許多性能建議同樣，測試看看是否有實際的幫助。 

系統數據庫 

系統數據庫（master、msdb、model）沒有大量的讀寫操做，因此把它們和你的SQLServer數據文件放在同一磁盤陣列上一般也沒有性能問題。僅僅一種狀況除外，就是有成百上千用戶的大數據庫。這種狀況下，把系統數據庫放在一個獨立的磁盤陣列上以稍微提升I/O性能。 

用戶數據庫 

爲了最佳性能，用戶數據庫文件放在它們本身的磁盤陣列上（RAID一、5或10），和因此的其餘數據庫文件，包括日誌文件分開。若是再同一個SQLServer上有多個大數據庫的話，考慮爲每個數據庫文件分配一個獨立的磁盤陣列以減小I/O爭奪。 

日誌文件 

理想地，每個日誌文件都應該有它本身獨立的磁盤陣列（RAID1或10，注意RAID5會下降事務日誌寫操做的性能，低於你的預期）。緣由是大多數時候，事務日誌在連續的寫操做，若是磁盤陣列能連續的寫數據的話（沒必要中斷去進行其餘的讀寫操做），那麼連續寫會很快。可是若是你的磁盤陣列不能連續的寫的話，因爲它不得不隨機的執行其餘讀寫操做，連續寫就得不到執行，性能就下降了。 固然，爲每個日誌文件提供一個獨立的磁盤陣列是很昂貴的。那麼至少將全部的日誌文件放在一個磁盤陣列上（RAID1或RAID10），而不要與數據庫文件放在一個磁盤陣列上。連續的寫性能儘管沒有爲每一個日誌文件提供一個獨立的磁盤陣列那樣好，它仍然比試圖與數據庫文件一塊兒競爭磁盤I/O的性能好的多。 

服務器上磁盤控制器的數量 

單個的磁盤控制器，不論它是SCSI仍是fibre，都有一個最大的吞吐量的限制。所以，你須要讓磁盤控制器的數量與你指望的數據吞吐量相匹配。每一個控制器都是不一樣的，我沒法推薦一個明確的解決方案，但最少應該有2個磁盤控制器。一個用於非硬盤設備如CD-ROM、備份設備等等。另外一個用於硬盤。目的是不要將快的和慢的設備放在同一個控制器上。 常用的一個較好的方案是：一個控制器爲非硬盤設備，一個爲RAID1的本地硬盤，第三個（有時更多）用於存放數據庫文件和日誌文件的磁盤陣列。確保不要爲控制器捆綁超過它能處理的更多的磁盤，那樣當它工做的時候，會下降性能。 

服務器上磁盤控制器的類型 

老是儘量的購買最快的磁盤控制器，若是你想要最好的SQLServer性能的話。也許你知道，不一樣的磁盤控制器有不一樣的性能特徵。例如，對於SCSI類型來講，就有Wide SCSI, Narrow SCSI, Ultra SCSI等不一樣的類型。光纖鏈接在更小的層次上，也和上述同樣，不一樣的磁盤控制器有不一樣的性能特色。 因爲控制器的種類不少，我不能作任何明確的建議。一般硬件廠商會提供不一樣的模型供選擇。逐一諮詢各自的利弊，選擇最適合你的那一款。 

服務器上磁盤控制器的緩存大小 

當你購買磁盤控制器的時候，也要考慮它緩存的大小。一些磁盤控制器容許添加額外的磁盤緩存。一般你要購買的磁盤緩存應和控制器能容納 的緩存同樣多。SQLServer對I/O是很是強烈的，因此去作任何能夠提升I/O性能的事，象購買一個大的磁盤緩存，將幫助很大的改善性能。

磁盤控制器上的寫回緩存是開仍是關? 

磁盤控制器上的磁盤緩存提供兩個方法去加速訪問。一個是爲了讀，一個是爲了寫。這其中最重要的是讀，這是大多數SQLServer數據庫花費磁盤I/O時間的地方。另外一方面，一個寫回緩存是用來加速寫操做的，而寫相對於讀來講一般不是不少。不幸的是，大多數狀況下，SQLServer採起寫回緩存不打開，所以，寫回緩存在大多數磁盤控制器上是被關掉的。若是你不那樣，在必定環境下，在SQLServer寫數據後（一旦它寫完數據，它就會認爲是正確地寫的），可能會取得一些髒數據，可是因爲某些緣由（例如電力不夠），寫回緩存不會把數據寫到磁盤上。 一些控制器提供了備份電池以防止這樣的問題，但它們不老是能如預期的那樣工做。我的認爲，寧願要正確的數據雖然寫慢一點，也不要錯誤 的數據，儘管那樣寫更快。 換句話說，我建議你關掉磁盤控制器上的寫回緩存，雖然那樣會對寫性能有一些很是小的影響。 

磁盤轉速 

磁盤陣列裏的磁盤有不一樣的轉速。 正如你所想，爲了最佳的性能，老是購買最快的磁盤。一般是15000轉或更快。另外，不要將不一樣轉速的磁盤放在同一個磁盤陣列裏，那樣會影響性能。 

服務器上的網卡數量是多少? 

幸運的是， 網絡流量一般不會稱爲SQLServer的瓶頸。單個網卡老是足夠用。可是若是你發現網絡流量成問題了（你已經有成百上千個用戶），那麼添加多個網卡老是正確的，這能提升性能。另外，兩個或者更多的網卡能增長冗餘，減小宕機時間。 

網卡速度是多少? 

至少應使用100M的網卡，10M的不能知足你須要的帶寬。若是一個或者更多的100M的網卡不能知足，考慮用G級的網卡。事實上，你可能須要徹底地跳過100M的網卡而僅僅用G級的網卡代替。使用更快的網卡不會增長網絡流量，它僅僅容許更多的流量經過，輪流的容許你的服務器在適宜的性能下運行。 

網卡硬編碼是Speed/Duplex的嗎? 

若是你的SQLServer有兩個10/100或者10/100/1000的網卡，假定是自動識別網卡速度並設置爲適合的，別相信那個能正常的工做。網卡一般不能正確的自識別，老是設置一個小於最佳速度的值或者duplex設置，這樣會影響網絡性能。你須要作的是手工設置卡的速度和duplex設置，以便你能確認它已經正確的設置了。 

網卡是連在交換機上的嗎? 

在一個大的數據中心這是顯而易見的，可是對於小的機構來講，使用一個Hub來鏈接服務器。要是那樣，請認真考慮用適當的交換機替換掉Hub，用可能最高的性能去配置交換機，例如100M而且全雙工通訊。將Hub替換爲交換機後在網絡性能上會有一個戲劇性的不一樣。 

全部硬件的驅動都是最新的嗎?

誠然，這是一個煩人的話題，但它比你認爲的更重要。最大的性能消耗之一是有Bug的驅動（會引發一些奇怪的不常見的問題），不管它們是在磁盤控制器中仍是網卡中，或者別的地方。經過使用最新的驅動，你有可能獲得更好更快的性能的驅動，從而提升SQLServer的性能。 你應該按期的檢查你的硬件是否有新的驅動可用，當你有時間的時候去安裝它們。我本人曾經將一個老的有不少bug的驅動更新後是性能獲得了完全的根本提高。 

SQLServer服務器是專用的嗎? 
前面我間接提到過，SQLServer應該運行在一個專用的服務器上，而不是和其餘應用程序、軟件共享一個服務器。當你將SQLServer和其餘軟件共享時，你迫使SQLServer去爭取物理資源，這樣調優SQLServer性能就更加困難。有不少次我在查找SQLServer性能低下的緣由時都發現是另外一個和SQLServer運行在同一臺服務器上的應用程序的緣故。
性能監控列表 
操做系統性能相關項 你的配置
操做系統版本 
磁盤分區格式是NTFS5.0嗎？ 
NTFS數據文件加密壓縮是否關閉? 
SP是否最新? 
服務器是否有最新的微軟認證的硬件驅動？ 
服務器是不是獨立的服務器？ 
應用程序響應是否設置爲爲後臺訪問最優化性能？ 
安全審計是否打開？ 
服務器的虛擬內存文件PAGEFILE.SYS有多大？ 
沒必要要的服務是否關閉？ 
全部沒必要要的網絡協議是否關閉？ 
是否使用殺毒軟件？ 

在上表輸入你的結果. 

配置Windows服務器是很容易的，但卻很關鍵 

這一部分性能監控將着重於基本的操做系統，爲了得到最佳的SQLServer性能怎樣去優化操做系統。 和SQLServer同樣，Windows服務器也是自我調優的。但咱們也能夠象調優SQLServer同樣，經過調優操做系統來提高性能。在提高操做系統性能的同時，SQLServer的性能也獲得相應的提高。 

是否選擇了性能最佳的操做系統? 

SQLServer能夠運行在NT4.0，win2000和Win2003上，這裏將討論做爲最新版本操做系統的Win2003。對於NT4.0和Win2000，將在其餘的文章裏進行介紹。 若是你想發揮SQLServer最佳的性能，你須要運行在Win2003上，它比2000和4.0提供了更多的性能改善，包括： 
？ 更好利用Intel超線程CPU的能力。 
？ 使用Intel芯片最多可支持32個CPU和64G的內存，使用Itanium芯片最多可支持64個CPU和512G的內存。 
？ I/O通道和磁盤I/O性能獲得充分提高的同時，減小了大量的I/O請求所須要的CPU資源。
若是你還沒升級到2003，儘快升級吧。它會更快更容易的提高SQLServer的性能。 

磁盤分區格式是NTFS 5.0嗎? 

若是你的服務器是新的，Win2000或Win2003也是最近安裝的，呢帽全部的磁盤都是使用NTFS5.0格式化的。可是，若是服務器很老，且運行的是NT4.0，磁盤在升級到Win2000或2003後沒有從新格式化，磁盤格式可能仍是NTFS4.0。 雖然NTFS5.0和4.0沒有太多的不一樣，但升級也是值得的。NTFS5.0包括一些新的加強性能，這意味着在找文件時會訪問更少的磁盤，一般磁盤讀會更快。在Win2000和2003之前，一些DBA將日誌文件所在的磁盤或者磁盤陣列用FAT格式化，由於它比NTFS4.0稍微有些性能提高。在NTFS5.0下就再也不是這樣了，因此全部SQLServer的磁盤都用NTFS5.0格式化以達到最佳性能。 若是目前你在Win2000下用NTFS4.0格式運行你的SQLServer，對於你來講轉到NTFS5.0也許是困難的。若是真是這樣，我建議你沒必要擔憂，性能也不會有太大的傷害。可是若是你將NT4.0升級到2000，你須要用NTFS5.0從新格式化你的磁盤以利用每個在你服務器上能發現的細微的性能提高。 

NTFS數據文件加密壓縮是否關閉？ 

2000下的NTFS5.0支持文件加密和壓縮，在新安裝的Win2000或2003服務器上這兩個值缺省是關閉的。這些特徵確實在有限的環境下提供一些好處，卻不能給SQLServer提供任何好處。事實上，使用一個或二者都用會極大地傷害性能。 正如你所知，SQLServer對I/O很敏感，任何增長磁盤I/O開銷都會影響SQLServer的性能。文件加密和壓縮顯然增長了磁盤I/O開銷，數據文件不論忙閒都得被維護。因此對SQLServer文件不管是壓縮仍是加密，都將極大地影響性能。 若是你做爲DBA接手一個已經存在的SQLServer，你對它又不太熟悉，檢查看看是否有人錯誤地打開了任何一個選項。若是是，關閉它，對全部的服務器用戶來講，他們會認爲你是性能高手。 

SP是否最新? 

每個SP都有一個或更多的性能提高。由於微軟進行了優化，或者修改了之前影響性能的Bug。 微軟發佈sp的時候不要安裝，等測試完成後再安裝。 

服務器是否有微軟最新認證的硬件驅動? 

在不少場合，我在Win2000和2003上都看到引發的性能問題的老的有Bug的硬件驅動。大多數狀況下和磁盤或者網絡驅動有關。 你應該週期性的檢查你的服務器是否有最新的微軟認證的硬件驅動。能夠去硬件廠商的網站查看，或者經過微軟的升級服務。大多數狀況下，你在硬件廠商的網站上能找到新的驅動，但尚未通過微軟的認證。我建議你等待微軟的認證版本。儘管提高性能很重要，但軟件的穩定性也很重要。 

Windows2000服務器是否配置爲獨立的服務器? 

Win2000或2003能夠配置爲獨立的服務器或者域控制器。爲了最佳的性能，SQLServer應該運行在一個獨立的服務器上。這是由於域控制器佔用不少服務器資源，SQLServer的性能就會降低。 

應用程序響應是否設置爲爲後臺服務最優化性能? 

在Win2000裏，控制面板裏的系統圖標的高級標籤下，單擊性能選項，你可配置一個叫做「應用程序響應」的設置。能夠從「應用程序」和「後臺服務」中選擇一個去優化性能。爲了提高SQLServer性能，你應該選擇「後臺服務」，這樣告訴操做系統你須要優先處理後臺程序如SQLServer而不是前臺程序。 在Win2003裏，控制面板裏的系統圖標的高級標籤下，單擊性能下的設置按鈕，單擊高級標籤。在這裏，你能夠象在2000裏那樣設置便可。
你也能夠在這兒更改內存設置爲程序和系統緩存兩者之一。爲了獲得最佳的SQLServer性能，選擇程序。這是告訴操做系統給程序如SQLServer而不是系統緩存分配更多的內存。 作完這些更改，可能須要重啓服務器。 

安全審計是否打開? 

事實上，Win2000和2003能審計服務器上的任何一個活動。許多安全審計確實是關閉的。爲了最好的性能，不要打開另外的審計，不然會增長I/O開銷，和SQLServer競爭I/O。固然，若是你不得不打開，儘量的限制以儘可能減小對性能的影響。 

服務器虛擬內存文件PAGEFILE.SYS有多大? 

微軟建議PAGEFILE.SYS文件設置爲物理內存的1.5倍。正確的數量須要依賴於運行的SQLServer。例如，若是你在運行全文索引服務，微軟建議你設置爲物理內存的3倍。 微軟的建議是一個理想值，決定PAGEFILE.SYS大小的最佳途徑是使用性能監視器監控Page File對象的% Usage計數器的值是多少，而後從新設置PAGEFILE.SYS的大小，最小應該稍微大於性能監視器記錄的實際值，最大值比最小值大50M。 在Win2000中經過右擊個人電腦，選擇屬性，單擊高級標籤，單擊性能選項單擊虛擬內存下的更改按鈕，能夠設置PAGEFILE.SYS的大小。更改後，須要重啓生效。 在Win2003中，經過控制面板的系統圖標的高級標籤，單擊性能下的設置按鈕，而後單擊高級標籤，單擊虛擬內存下的更改按鈕，能夠設置PAGEFILE.SYS的大小。 

沒必要要的服務是否關閉? 

爲了最佳性能，關閉Win2000或2003系統任何一個不須要的服務。這既節約了內存也節約了CPU，從而全面提高SQLServer性能。 下面是一些操做系統服務（不全），一般被認爲是不重要可關閉的。其中一些服務也可沒必要安裝，另一些設置爲「禁止」或「手動啓動」， 這依賴於你服務器的安裝和配置。一些服務僅僅在須要時啓動，因此設置爲手動啓動，當再也不須要的時候關閉。 
？ Alerter 
？ Application Management 
？ Clipbook 
？ Distributed Link Tracking Server 
？ Fax Service 
？ File Replication 
？ FTP Service 
？ Indexing Service 
？ Internet Connection Sharing 
？ Intersite Messaging 
？ Kerberos Key Distribution Center 
？ License Logging Service 
？ Logical Disk Manager Administrative Service 
？ Messenger 
？ Microsoft Search 
？ NetMeeting Remote Desktop Sharing 
？ Network DDE 
？ Network DDE DSDM 
？ Print Spooler Service (if you won't be printing from this server) 
？ QoS RSVP 
？ Remote Access Auto Connection Manager 
？ Remote Procedure Call (RPC) Locator 
？ Routing and Remote Access 
？ RunAsService 
？ Smart Card 
？ Smart Card Helper 
？ SMTP Service 
？ Telnet 
？ Utility Manager 
？ Windows Installer 
？ World Wide Web Service
一般，我老是關閉這些服務，將它們的啓動類型設置爲手動。固然若是你須要任一服務，你沒必要關閉它。 

全部沒必要要的網絡協議是否關閉? 

SQLServer一般只須要TCP/IP協議 。移除SQLServer服務器上其餘沒必要要的網絡協議能夠經過減小網絡流量來減小負荷。 

是否使用殺毒軟件? 

實時的殺毒軟件佔去大量的SQLServer資源，在SQLServer服務器上不建議用，尤爲是在集羣上。

若是你擔憂病毒的話，你能夠天天在不用SQLServer時進行遠程掃描。

SQLServer配置項監控列表

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址


性能監控列表 
SQL Server配置設置 是否高級設置? 是否須要重啓? 缺省值 當前值 
affinity mask Yes Yes 0 
awe enabled Yes Yes 0 
cost threshold for parallelism Yes No 5 
cursor threshold Yes No -1 
fill factor (%) Yes Yes 0 
index create memory (KB) Yes No 0 
lightweight pooling Yes Yes 0 
locks Yes Yes 0 
max degree of parallelism Yes No 0 
max server memory (MB) Yes No 2147483647 
max text repl size (B) No No 65536 
max worker threads Yes Yes 255 
min memory per query (KB) Yes No 1024 
min server memory (MB) Yes No 0 
nested triggers No No 1 
network packet size (B) Yes No 4096 
open objects Yes Yes 0 
priority boost Yes Yes 0 
query governor cost limit Yes No 0 
query wait (s) Yes No -1 
recovery interval (m) Yes No 0 
scan for startup procs Yes No 0 
set working set size Yes Yes 0 
user connections Yes Yes 0 


在上表裏輸入你的結果. 

大多數SQLServer配置設置沒必要更改 

這一節，咱們將討論與性能相關的SQLServer配置設置。能夠使用企業管理器或者系統過程SP_CONFIGURE對這些配置進行設置。 

正如標題所說，大多數狀況下，你不該該修改SQLServer的這些缺省配置。這是由於大部分缺省值能爲大多數SQLServer提供最優的性能。糟糕的是，若是你不知道改變這些值是什麼意思的話，反而可能會影響SQLServer的性能。 

若是你是第一次處理SQLServer，首先應該瞭解各個配置的含義。而後一個一個的更改，跟缺省值比較看有什麼變化。一旦你肯定改變一個配置的值了，接下來你就應該知道爲何要改變它。若是你找不到緣由，或者找到了但緣由不可信，那麼你須要修改回缺省值。接下來象前面那樣去配置每個值，以使其達到最合適。 

本文着重於SQLServer2000，不過大多數建議也適合SQLServer7.0。在SQLServer7.0下試圖採用這些建議前，你須要從SQLServer7.0的幫助文檔中確認。 

SQLServer2000中共有36個不一樣的配置 ，這裏僅僅着重於23個與性能有關的關鍵配置。 

如今開始 

開始查看SQLServer的配置的最簡單的方法是對你的每一個服務器，在查詢分析器裏運行命令SP_CONFIGURE。 

你會看到相似下面的一個表：

name minimum maximum config_value run_value 
----------------------------------- ----------- ----------- ------------ ---------- 
affinity mask -2147483648 2147483647 0 0
allow updates 0 1 0 0
awe enabled 0 1 0 0
c2 audit mode 0 1 0 0
cost threshold for parallelism 0 32767 5 5
cursor threshold -1 2147483647 -1 -1
default full-text language 0 2147483647 1033 1033
default language 0 9999 0 0
fill factor (%) 0 100 0 0
index create memory (KB) 704 2147483647 0 0
lightweight pooling 0 1 0 0
locks 5000 2147483647 0 0
max degree of parallelism 0 32 1 1
max server memory (MB) 4 2147483647 2147483647 2147483647
max text repl size (B) 0 2147483647 65536 65536
max worker threads 32 32767 255 255
media retention 0 365 0 0
min memory per query (KB) 512 2147483647 1024 1024
min server memory (MB) 0 2147483647 0 0
nested triggers 0 1 1 1
network packet size (B) 512 65536 4096 4096
open objects 0 2147483647 0 0
priority boost 0 1 0 0
query governor cost limit 0 2147483647 0 0
query wait (s) -1 2147483647 -1 -1
recovery interval (min) 0 32767 0 0
remote access 0 1 1 1
remote login timeout (s) 0 2147483647 5 5
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 600 600
scan for startup procs 0 1 0 0
set working set size 0 1 0 0
show advanced options 0 1 1 1
two digit year cutoff 1753 9999 2049 2049
user connections 0 32767 0 0
user options 0 32767 0 0 

第一列「Name」是SQLServer配置設置的名稱，第二列「minimum」可用的最小配置，第三列「maximum」是可用的最大配置，第四列「config_value」是該項的設置值（但多是也可能不是SQLServer目前的實際運行值，有些設置須要重啓SQLServer纔有效，有些須要RECONFIGURE WITH OVERRIDE選項運行後纔有效），最後一列「run_value」是目前有效的設置值。若是你在最後一次重啓SQLServer後沒有更改任何值的話，最後兩列的值將是相同的。 

不幸的是，這些配置的缺省值在運行SP_CONFIGURE沒有列出來。爲了方便，本文已列出它們的缺省值。（見最開始的那個表） 

怎樣更改SQLServer配置設置 

SQLServer的這些配置大多數而不是所有能夠在企業管理器中進行修改。可是更簡單的一個途徑是運行SP_CONFIGURE命令去更改這些值，象這樣： 

SP_CONFIGURE ['configuration name'], [configuration setting value]
GO
RECONFIGURE WITH OVERRIDE
GO 

注： 

configuration name指的是配置設置的名稱（見上表）。注意名稱必須用單引號括起來（或者是雙引號，這依賴於查詢分析器的配置）。configuration setting value指的是該配置的具體的數值（不用單引號）。 

一旦運行完SP_CONFIGURE命令，你必須作下面的工做，要麼運行RECONFIGURE選項（用於常規設置），要麼運行RECONFIGURE WITH OVERRIDE選項（用於那些若是你犯錯了就會給你帶來麻煩的設置），不然你的更改不會生效。與其試圖記住何時須要用RECONFIGURE，還不如記住任什麼時候候RECONFIGRE WITH OVERRIDE都適用來得容易，RECONFIGRE WITH OVERRIDE適合於因此的配置。若是你用企業管理器更改了設置，RECONFIGURE WITH OVERRIDE會自動的執行，因此你沒必要再去執行。 

一旦你更改完畢，大多數的設置而不是所有會當即生效，有一些值在運行RECONFIGURE後也不會生效，除非重啓SQLServer的服務。 

在完成本文以前，你應該知道：許多配置屬於「advanced」設置。在使用SP_CONFIGURE命令更改這些值以前，你必須首先更改SQLServer配置中的一項，而後才能去更改那些配置。命令以下：

SP_CONFIGURE 'show advanced options', 1
GO
RECONFIGURE
GO 

僅在你運行上面的代碼後你才能運行SP_CONFIGURE來更改那些高級的SQLServer配置。 

如今你知道怎樣更改這些SQLServer配置選項了，下面看看它們和性能的關係。 

Affinity Mask 

當SQLServer在Windows服務器下運行時，一個SQLServer線程能夠在CPU之間遷移。這個特徵容許SQLServer同時運行多個線程，這樣服務器能夠在多個CPU之間進行更好的負載均衡。每當一個線程從一個CPU移到另外一個CPU，處理器緩存都要重載，大多數狀況下會影響性能。 

在多於4個CPU的負荷繁重的服務器裏，經過特定處理器運行特定的線程來提高性能。這會減小處理器緩存重載次數，提高了服務器的性能。例如你能夠指定SQLServer只運行在一些CPU上，而不是全部可用的CPU上。 

"affinity mask"選項的缺省值是0，這意味着SQLServer容許Windows調度算法設置線程的親和力。換句話說，是操做系統而不是SQLServer決定哪一個線程運行在哪一個CPU上，何時將線程從一個CPU遷移到另外一個CPU。在一個有4個或更少CPU的服務器上，缺省值時最好的設置。對於多於4個CPU的不是過分繁忙的服務器來講，對於最優性能來講缺省值也是最好的設置。 

可是對於多於4個CPU有繁重負荷的服務器來講，因爲一個或者更多的非SQLServer程序和SQLServer同時運行，你須要考慮將"affinity mask"選項的缺省值更改成一個更加合適的值。請注意若是服務器上只有SQLServer一個程序運行，使用"affinity mask"限制CPU的使用會傷害性能而不是提高性能。 

例如，假定服務器運行了SQLServer，多個COM+對象和IIS，服務器有8個CPU而且是很忙的。經過將SQLServer運行的CPU數量從8個減小到4個，SQLServer線程如今僅僅運行在4個CPU上，而不是8個CPU上。這將減小SQLServer線程在CPU間遷移的次數，減小處理器緩存重載的頻率，減小CPU使用率，從而潛在的提高一些性能。剩餘的4個CPU將用來運行操做系統和其餘非SQLServer程序，減小線程遷移，提高性能。 

例如，一個8CPU的系統，使用SP_CONFIGURE命令設置SQLServer能夠運行的CPU的值以下： 
十進制值 容許SQLServer線程運行的處理器 
1 0 
3 0和1 
7 0, 1和2 
15 0, 1, 2和3 
31 0, 1, 2, 3和4 
63 0, 1, 2, 3, 4和5 
127 0, 1, 2, 3, 4, 5和6

配置一個合適的affinity mask值是不容易的，你應該參考幫助文檔以得到更多的信息。在你更改該選項的值後測試看看設置的值對性能是好仍是壞。除了試錯的方法，沒有更好的方法爲你的服務器設置一個合適的affinity mask值。 

做爲監控的一部分，若是你發現affinity mask使用的不是缺省值，請找出緣由。若是沒有好的答案，將該值修改成缺省值。 

啓用Awe

若是實在Win2000或2003的任何版本下運行SQLServer2000的標準版，或者是在Win2000或2003Server版下運行SQLServer2000的企業版，或者你服務器的內存少於4G，"awe enabled"選項將缺省爲0，意思是AWE內存不被使用。 

AWE（地址窗口擴展）API容許在Win2000或20003 Advandced Server下，或在Win2000或Win2003 DataCenter Server下運行的程序訪問超過4G的內存。SQLServer2000企業版（不是標準版）是AWE可用的，這樣能利用服務器超過4G的內存。若是操做系統是Win2000或20003 Advandced Server，SQLServer2000企業版能使用高達8G的內存。若是操做系統是Win2000或Win2003 DataCenter Server，SQLServer企業版能使用高達64G的內存。 

缺省地，在Windows 2000 and 2003 (Advanced and Datacenter)下運行SQLServer2000企業版，若是物理內存超過4G，SQLServer也不能訪問超過4G的內存。爲了使操做系統和SQLServer2000企業版利用更多的內存，須要完成2個步驟。 正確的配置AWE內存支持依賴於你服務器有多少內存。本質上配置Win2000或Win2003（Advanced或DataCenter）必須在boot.ini文件的啓動行添加下面的語句以打開AWE開關，而後重啓服務器：
？ 4GB RAM: /3GB (AWE支持不被使用) 
？ 8GB RAM: /3GB /PAE 
？ 16GB RAM: /3GB /PAE 
？ 16GB + RAM: /PAE
/3GB開關用來告訴系統容許SQLServer從Win2000和20003自己支持的4GB的內存中使用3GB。若是你不指定這個選項，SQLServer將僅僅值使用服務器第一個4GB內存中的2GB，這樣就浪費了1GB的內存。 

AWE內存技術僅僅用於超過4GB的內存，這就是爲何/3GB開關在你的服務器上被用來使用盡量多的內存。若是你的服務器有16GB或者小於16GB的內存，那麼使用/3GB開關是重要的。可是若是你的服務器有大於16GB的內存，那麼你沒必要使用/3GB開關。緣由是由於爲了使用全部額外的AWE內存，1GB的額外內存須要服務器經過/3GB開關來提供。換句話說，若是你的服務器有大於16GB的內存的話，操做系統自身須要2GB的內存來管理AWE內存，若是你的服務器有16GB或者小於16GB的內存，那麼操做系統置須要1GB的內存，容許SQLServer去使用另外1GB的內存。 

一旦完成該步驟，接下來就是設置"awe enabled"的值爲1，而後重啓SQLServer服務。只有這樣SQLServerf才能使用服務器裏額外的內存。 

使用"awe enabled"選項須要當心一點，就是在打開該選項後，SQLServer再也不動態管理內存了。相反，它會使用全部可用的內存（除留給操做系統的128M的內存外）。若是你要禁止SQLServer使用全部的內存，你必須設置"max server memory"選項（將在後面作詳細描述）來限制SQLServer使用內存。 

做爲監控過程的一部分，你要檢查這個設置的值是多少，是否與服務器的硬件和軟件匹配。若是不匹配，相應地修改這個值。 

Cost Threshold for Parallelism 

使用並行去執行SQLServer查詢有必定的成本。這是由於並行比串行佔用了額外的開銷。可是若是並行的好處高於成本開銷的話，那麼使用並行仍是值得的。 

首要原則是，若是串行執行很快，就沒有必要考慮用並行來完成，評估可能的並行所必須的額外時間也許會比串行長得多。 

缺省地，若是查詢優化器發現一個查詢少於5秒就能執行完成，那麼SQLServer不會考慮並行。能夠使用SQLServer選項"cost threshold for parallelism"來更改5秒這個數字。該值能夠在0到32767之間任意配置。因此若是你設置該值爲10，這就意味着若是一個查詢執行完成少於10秒的話，查詢優化器不會考慮對該查詢進行並行處理。 

大多數狀況下，你不用改變該值。但若是你發現你的SQLServer並行的運行了不少查詢而CPU仍然很高的話，那麼增長該值到一個大於5的值（你須要根據你的情形經過屢次試錯的方法來尋找一個理想的值），這樣會減小使用並行的查詢 的數量，也減小了CPU的使用率，這有助於提高你服務器的性能。 

另外一個考慮的選項是將5減小到一個更小的值，，儘管大多數狀況下可能會影響性能而不是提高性能。一個更小的值在SQLServer的數據倉庫運行不少複雜查詢下多是有用的，由於一個更小的值會使查詢優化器使用更多的並行。 

在你的服務器上使用一個修改的值前，你須要完全地測試該值。 

若是SQLServer僅用一個CPU（要麼是由於服務器上只有一個CPU，要麼由於"affinity mask"設定的值），並行是不會被考慮的。 

若是你發現"cost threshold for parallelism"選項被使用，找出緣由。若是你找不到答案，將其改回缺省值。 

Cursor Threshold 

若是你的SQLServer不使用遊標或者不多使用，那麼從不要更改該選項的的缺省值-1。

"cursor threshold"選項的值-1告訴SQLServer同步的執行因此的遊標，若是遊標的結果集不是很大，那麼它是一個理想值。若是你的SQLServer有許多遊標或者因此遊標的結果集都很大，那麼同步執行遊標不是最有效的方法。 

"cursor threshold"選項對於運行大的遊標來講除缺省值外還有2個值可設置。一個值是0，它表示全部的遊標都異步的執行，若是SQLServer有許多遊標或者因此遊標的結果集都很大，這會提升效率。 

若是SQLServer有些遊標的結果集小而另外一些大，那麼咱們該怎麼辦呢？這種狀況下，咱們能夠根據這些結果集的大小值來爲SQLServer決定一個大小值。例如，考慮把結果集小於1000行的任何遊標做爲小結果集的遊標，而大於1000行的做爲大結果集的遊標，這樣，咱們能夠設置"cursor threshold"選項的值爲1000。 

當"cursor threshold"選項的值被設爲1000，這意味着查詢優化器對於那些結果集小於1000行的遊標採用同步處理的方式。而結果集大於1000行的將採用異步方式處理。 

大多數狀況下，這個選項提供了最好的方式。惟一的問題就是須要決定"cursor threshold"值的大小，這須要進行測試。可是正如你所料，缺省值一般是最好的，若是你肯定你的應用程序使用很是大的遊標而且進行了測試以肯定更改，那麼更改該選項的值有助於性能的提高而不是影響性能。 

做爲監控的一部分，你也須要知道遊標執行的頻率，結果集的大小。這樣就能夠爲你的服務器配置一個最好的值。固然你儘可能在服務器上不要使用遊標，這樣就能夠保留缺省值而沒必要擔憂遊標了。 

Fill Factor (%) 

這個選項容許你建立索引時更改索引的缺省填充因子。缺省地，該值一般爲0。0有點令人迷惑，由於它意味着葉索引頁100％（不是0％）的被填充，可是中間索引頁（非葉子頁）有一些空間而不是被100％的填滿。該選項的取值範圍爲0到100之間。 

當建立索引時沒有指定填充因子的值時系統會使用缺省的填充因子。若是指定了一個值，建立索引時會使用該值而不是缺省值。 大多數狀況下，最好不要修改缺省值。若是你須要一個不一樣的值，在建立索引時指定便可。

做爲監控的一部分，注意該值是否是不一樣於缺省值0。若是是，找出緣由。若是你不能找到爲何要修改缺省值或者沒有更好的緣由，將其改回缺省值。 若是該值已經被更改，請記住任何索引在建立時都會使用這個更改後的缺省值。這樣，你須要從新肯定這些索引是否適合這個填充因子的值。

Index Create Memory (KB) 

index create memory選項用來控制索引建立排序時所需的內存數量。默認值是0，這意味着SQLServer動態肯定該內存數量。在幾乎全部的狀況下，SQLServer會肯定內存的最佳值。 

但在某些狀況下，特別是對於很是大的表，可能致使SQLServer錯誤，由於大索引建立會很慢或根本不建立。若是你遇到這種狀況，你須要設置一個Index Create Memory選項的值，儘管你不得不試錯直到找到最佳值爲止。該選項的合法範圍在704到2147483647之間，它是SQLServer在建立索引時能提供的值，單位是KB。 

記住若是你確實要改變該選項，這個內存值只分配給索引建立而對其餘的操做不起做用。若是你的服務器有更多的內存，那麼這不是問題。但若是你的服務器沒有太多的內存，更改該選項的值可能對SQLServer的其餘產生一些消極影響。你能夠考慮僅在建立或重建大索引時更改該選項，其餘時間改回缺省值。 

和其餘的選項同樣，若是你監控發現該選項不一樣於缺省值，找出緣由，若是找不到緣由或者沒有更好的緣由，將其改回缺省值。 

Lightweight Pooling 

缺省地，SQLServer7.0和2000是以「線程模式」運行的。這就是說SQLServer使用UMS（用戶模式調度）線程運行用戶程序。SQLServer將爲每一個程序建立一個UMS線程，每個線程在SQLServer忙時輪流處理許多用戶程序。爲了達到最佳效率，UMS試圖平衡每一個線程的用戶程序數量，試圖在服務器的全部CPU之間有效的均衡全部的用戶程序。 

SQLServer也有一個優化模式叫纖程模式。這種狀況下，SQLServer對每個處理器使用一個線程（象線程模式同樣），但不一樣的是每一個線程裏運行多個纖程，當正在運行的一個線程對於服務器上其餘運行的SQLServer線程沒有優先級別的時候使用纖程。想一想在某些環境下，纖程做爲輕量級線程，對它的管理比標準的UMS線程用更少的開銷。使用SQLServer的配置選項"lightweight pooling"來開啓和關閉纖程模式，缺省是0，即纖程模式是關閉的。 

全部這些意味着什麼呢？象全部的事情同樣，在一種模式下或者另外一種模式下運行老是有其同意者和反對者。通常說來，當下列全部條件成立時，纖程模式纔是有利的： 
？ 服務器上有2個或更多的CPU（CPU越多，效果越大） 
？ 全部的CPU大多數時間都運行在接近最大值也就是90-100%之間 
？ 服務器上有許多context switching事件（性能監視器爲系統對象：Context Switches/sec）。通常說來，每秒超過5000個context switches 事件就被認爲太高了。 
？ 服務器正在產生使用不多或者根本沒用的分佈式查詢或者擴展存儲過程。
若是以上都知足，那麼將"lightweight pooling"選項打開，也許會看到5%或更大的性能改善。 

可是若是不知足任一條件，將"lightweight pooling"選項打開實際上可能下降性能。例如，若是你的服務器大量使用了分佈式查詢或者擴展存儲過程，那麼打開該選項會明確地引起問題，由於他們不能使用到纖程，即SQLServer不得不來回在纖程模式和所需的線程模式之間切換，從而影響性能。 

和其餘設置同樣，若是你發現該設置不是缺省值，試圖去找到緣由。另外，檢查上面四個條件是否存在，若是是，打開該選項，不然使用缺省值0。 

Locks 

每當SQLServer鎖定一條記錄時，鎖會存儲在內存中。缺省地，"locks"選項的值是0，即鎖內存是動態管理的。SQLServer內部能夠爲鎖保留2%到40%的可用內存。另外，若是SQLServer肯定爲鎖分配額外的內存會引發操做系統級的頁面調整，那將不會分配內存給鎖，相反爲了禁止頁面調整會分配給操做系統。 

大部分狀況下，容許SQLServer動態管理鎖，保留其缺省值。若是你配置鎖內存（合法值在5000到2147483647 KB之間），那麼SQLServer不能動態管理這部份內存，這可能引發SQLServer的其餘區域的性能下降。 

若是獲得一個錯誤消息：超過最大的可用鎖數量，那麼你能夠有如下辦法： 
？ 檢查查詢看是否使用了過多的鎖。若是是，性能可能會由於應用程序併發而受到影響。比改善壞查詢更好的方法是爲跟蹤到的鎖分配更多的內存。 
？ 減小服務器上的應用程序數量 
？ 爲服務器添加更多的內存 
？ 對鎖數量設置一個較高的值（基於試錯）。這是一個最少使人滿意的選項，和給鎖分配內存以阻止SQLServer爲了其餘目的而佔用內存同樣。
最大努力地不要使用這個選項。若是你發現這個選項設置的不是缺省值，找出緣由，若是你找不到緣由或者緣由太少，就改回缺省值。 

Max Degree of Parallelism 

該選項容許你將並行打開、關閉、或者爲某些CPU打開，但不是爲所有的CPU打開。並行指的是查詢優化器使用多於1個CPU去執行查詢的能力。缺省地，並行是打開的而且儘量多的使用服務器的CPU（除非被affinity mask選項限制）。若是你的服務器只有1個CPU，該選項會被忽略。 

這個選項的缺省值是0，這意味着並行是爲因此可用CPU打開的。若是你改變該值爲1，並行對全部CPU就關閉了。這個選項容許你設置並行能使用多少個CPU。例如，若是你的服務器有8個CPU，而你只想讓並行運行在其中的4個CPU上，那麼將該值設置爲4。儘管這個選項是可用的，而想使用它來真正提升性能倒是不肯定的。 

若是並行是打開的，正如多CPU的服務器缺省那樣，那麼查詢優化器將評估每一個查詢使用並行的可能性，會帶來一些開銷。在許多OLTP服務器上，查詢自己一般不會採用並行去運行。這包括標準的SELECT、INSERT、UPDATE、DELETE語句。所以，查詢優化器在評估每個查詢是否值得用並行只是在浪費時間。若是你瞭解到你的查詢可能歷來不須要並行，你能夠經過關閉該選項來得到性能的一點提高，由於不會爲查詢評估並行。 

固然，若是查詢自己能利用並行，你不須要關閉並行選項。例如，若是OLTP服務器上運行了許多相關聯的子查詢，或其餘複雜的查詢，那麼你可能須要將並行開着。你須要測試這個選項看是否有所幫助。 

大多數狀況下，由於許多服務器既運行OLTP又運行OLAP查詢，並行應該保存打開。做爲你性能監控的一部分，若是你發現並行關閉或受限，找出緣由。另外，確認服務器是否是基於OLTP的。若是是，關掉並行也許更合適，儘管你須要經過測試看關閉是否有助於性能的提高。但若是服務器既運行OLTP，又運行OLAP，或者大部分OLAP查詢，那麼爲了全面提高性能最好將並行打開。 

Max Server Memory (MB) & Min Server Memory (MB) 

爲了最佳的SQLServer性能，你須要肯定你的服務器僅僅運行了SQLServer，而沒用其餘的應用程序。大多數狀況下，"maximum server memory" 和 "minimum server memory" 選項設置爲缺省值便可。這是由於缺省值爲了最佳性能容許SQLServer動態分配內存。若是你修改了最大或最小內存設置，可能你會冒影響性能的風險。 

另外一方面，若是SQLServer不能運行在它本身的物理服務器上（其餘程序和SQLServer運行在同一臺物理服務器上），你須要考慮更改最小或最大內存值，儘管這一般是不需的。 

讓咱們仔細研究一下這兩個選項。 

"maximum server memory"選項，當設置爲缺省值2147483647（單位MB），意味着SQLServer動態管理內存，即SQLServer將盡量使用可用內存（除留給操做系統一些必要的內存外）。 

若是你想要SQLServer不使用服務器上全部的可用內存，你能手動設置最大內存。SQLServer能使用的指定的內存在4（你能輸入的最小值）到你服務器上最大的物理內存（但不要分配服務器上全部的內存，由於操做系統也須要）。 

僅當SQLServer必須和同一臺服務器上的其餘應用程序共享內存，或者你想人工保持SQLServer使用可用的內存，你才須要去改變缺省值。例如，若是你其餘的應用程序比SQLServer性能重要，那麼你能夠限制SQLServer的性能。 

若是你試圖手動設置"maximum server memory" 選項的值，你可能會遇到兩種潛在的性能瓶頸問題。第一，若是你分配了太多的內存給SQLServer，而對於其餘的應用程序和操做系統沒有足夠的內存，那麼操做系統別無選擇地要作不少的頁面調整，這將下降服務器的性能。並且，若是你使用了全文索引服務，你必須爲它留出足夠的內存。它的內存不是動態的分配，象剩餘的SQLServer內存同樣，要運行它必須有足夠的適當的內存。 

"min server memory"選項的缺省值0（單位MB），意味着SQLServer動態管理內存，即SQLServer將按照須要分配內存，最小值將隨着SQLServer的須要而變化。 

若是更改"min server memory"選項的值而不設置爲缺省值0，這並不意味着SQLServer自動開始使用這個最小的內存設置，許多人是那樣認爲的，可是一旦因爲須要超過了設置的最小的內存，那麼將永遠再也不小於這個最小值。 

例如，若是你設置了最小值爲100MB，而後重啓SQLServer，SQLServer不會當即使用100MB這個最小的內存。相反，SQLServer僅僅使用須要的內存。若是你從不須要100MB，那麼將從不會使用100MB。可是若是SQLServer使用超過了100MB，而之後再也不須要100MB，那麼這100MB將成爲SQLServer分配的最低內存。所以，沒有理由將"min server memory"選項的值不設置爲缺省值而改成其餘值。 

若是服務器上只有SQLServer，根本沒有理由去使用"min server memory"選項。若是還運行了其餘程序，改變該值可能會得到一些微小的好處，但決定設置爲什麼值是很困難的，而且這個性能的提高基本上能夠忽略。 

若是你發現這些選項的值不是缺省值，找出緣由。若是找不到緣由，或者緣由站不住腳，將它改回缺省值。 

Max Text Repl Size 

"max text repl size"選項能夠設定在執行單個INSERT、UPDATE、WRITEEXT或者UPDATEEXT命令時能夠增添到複製字段的 text 和 image 數據的大小（單位爲字節）。若是你沒用到複製或者複製沒有用到text、image字段，那麼該選項不用修改。 

缺省值是65536，最小值是0，最大值是2147483647（單位爲字節）。若是對text、image數據有不少的複製，僅當數據超過64K，你應該考慮增長該值。但與這些設置的最大值同樣，你將不得不用各類值去實驗看哪一個值在你的特殊環境下效果最好。 

做爲監控的一部分，若是你不使用複製， 正確的值只有缺省值。若是缺省值被更改，你須要調查text、image數據是否被複制。若是沒有，或者若是小於64KB，那麼改回缺省值。 

Max Worker Threads 

SQLServer的配置選項"max worker threads"被用來決定操做系統上的sqlservr.exe進程容許有多少個工做線程可用。缺省值是255個工做線程。SQLServer自身使用一些線程，咱們不討論這些線程。這裏將焦點放在那些由用戶建立線程上。 

若是有多於255個用戶鏈接，那麼SQLServer將使用線程池，即多於一個用戶鏈接使用一個工做線程。儘管線程池減小了SQLServer使用的系統資源，它也能在訪問SQLServer的用戶鏈接之間增長資源爭奪，從而影響性能。 

爲了找出你的SQLServer運行了多少個工做線程，使用企業管理器檢查目前你服務器的鏈接數量。對於每個SQLServer鏈接，都有一個工做線程被建立，最高到"max worker threads"選項設置工做線程總數。例如，若是有100個鏈接，那麼有100個工做線程將被建立。但若是有500個鏈接，但只有255個工做線程可用，那麼只有255個工做線程被使用，其他打開的鏈接共享這些有限的工做線程。 

若是你的服務器有足夠的內存，爲了獲得最好的性能，你要設置"max worker threads" 選項的值爲你服務器曾經達到的最大的用戶鏈接數再加5，但這個常規的建議存在一些侷限，正如一下子咱們看到的。 

前面已經說過，"max worker threads"的缺省值是255。若是你的服務器從未超過255個鏈接，那麼沒必要改變這個缺省值。這是由於工做線程僅在須要的時候建立。若是僅有50個鏈接到服務器，那麼將僅只有50個工做線程，而不是255這個缺省值。 

若是你的服務器一般超過255個鏈接，而"max worker threads"的設置仍然是缺省值255，那麼SQLServer將使用線程池。如今進入了兩難的局面。若是你增長"max worker threads"的值一個線程一個鏈接，SQLServer將佔據額外的資源（更多的內存）。若是你的服務器有不少未被SQLServer或其餘程序使用的內存，那麼增長"max worker threads"的值將提高SQLServer的性能。 

可是若是沒有另外可用的內存，那麼添加更多的工做線程會影響SQLServer的性能。在這狀況下，容許SQLServer使用線程池來提供更好的性能。這是由於線程池使用更少的資源（比起不使用線程池來）。可是，消極的一面，線程池在鏈接之間會產生資源爭奪的問題。例如，共享一個線程的兩個鏈接同時執行一些任務的時候會產生衝突（由於一個線程同時只能爲一個鏈接服務）。 

那麼該怎麼辦呢？簡而言之，若是你的服務器一般少於255個鏈接，保留缺省值設置。若是你的服務器超過255個鏈接，且有更多的內存，那麼考慮增長"max worker threads"設置的鏈接數再加5。但若是沒有太多的內存，保留缺省值。對於有成千上萬鏈接的SQLServer來講，你須要經過試驗找到在額外的工做線程使用額外的資源和爭奪相同工做線程的鏈接之間的分界線。 

也許正如你所指望的，在使用這個選項以前，你要在改變該設置的先後測試服務器的性能，看看SQLServer的性能是提高仍是降低了，從而肯定一個合適的值。 

做爲監控的一部分，按照上面給出的建議來設置該選項的值。 

Min Memory Per Query 

當一個查詢運行時，爲了運行得更快更有效率，SQLServer儘可能分配合適的內存給查詢。缺省地，"minimum memory per query"選項分配的是1024KB，這是每一個查詢運行的最小內存。"minimum memory per query"選項能夠在0到2147483647 KB之間設置。 

若是查詢須要更多的內存運行纔有效率，且有可用內存，那麼SQLServer自動的分配更多的內存給查詢。所以，一般不建議修改該選項的缺省值。 

在某些狀況下，若是SQLServer比有效率的運行有更多的內存，那麼增長該選項的值到一個更高的值（如2048KB或更高）可能提高某些查詢的性能。一旦服務器有更多可用的內存（本質上，這些內存沒有被SQLServer使用），那麼提升該選項的值能全面提高SQLServer的性能。但若是沒有，增長該選項的值可能下降性能而不是提高。 

Nested Triggers 

這個配置選項的確影響性能，但不在常規的方法裏。缺省地，"nested triggers"選項的缺省值爲1。意便可以運行嵌套觸發器（觸發器最多可以嵌套32層）。若是將其設置爲0，那麼將不運行嵌套觸發器。顯然，經過不容許嵌套觸發器，可以全面提高性能，但要以應用程序的靈活性做爲代價。 

請保留該選項的缺省值，除非你要防止開發人員使用嵌套觸發器。一些依靠嵌套觸發器的第三方程序若是關閉嵌套觸發器也會運行失敗。 

Network Packet Size (B) 

"Network packet size"決定SQLServer經過網絡與客戶端會話時信息包的大小。缺省值是4096字節，該值的最小值最大可設爲512字節，最大值依賴於使用的網絡協議所支持的值。 

理論上，改變該值以或多或少適應數據包的大小能夠提高性能。例如，若是數據很小，平均小於512字節，更改缺省的4096字節到512字節能夠提高性能。或者，若是你在作大量數據的移動，如大批量的導入或在處理大量的TEXT、IMAGE數據，那麼增長該值以大於缺省值，這樣會發送較少的包，從而提升性能。 

理論上，這聽起來很好。實際上，無論哪一個，你看到的性能提高不多。這是由於沒有考慮平均的數據大小。某些狀況下數據很小，另外一些狀況數據很大。所以改變這個選項的缺省值一般沒有太多的幫助。 

做爲監控的一部分，當心檢查每個不是缺省值的設置。若是找不到答案，改回缺省值。

Open Objects 

"Open objects"指的是SQLServer能同時打開的對象（包括表、視圖、默認值、觸發器和存儲過程）的數量。該選項的缺省值是0，意味着SQLServer爲了得到最好的性能動態的增長或減小該值。 

不多狀況下，可能會獲得一個信息說打開的對象超過可用的數量，一般這種狀況是服務器內存全被使用了。解決它的最好方法是增長服務器的內存或者減小服務器的負載，如減小服務器維護的數據庫的數量。 

若是上面兩個選項都不知足實際，能夠手動配置給該選項一個適當的最大值。這個問題是雙方面的。首先，決定適當的值須要太多的試驗。其次，給打開對象分配的任何內存將被其餘的SQLServer需求使用，潛在的下降服務器的總體性能。固然，當你改變該選項的值你的應用程序也會運行，不過會變慢。避免改變該選項的值。 

當你監控性能時，若是發現該值不是0， 要麼是有人犯錯誤須要糾正，服務器的硬件過小，爲它添加更多的內存，要麼是服務器工做須要移到另外一個不是很忙的服務器上。 

Priority Boost 

缺省地，SQLServer進程和服務器上其餘應用程序有相同的優先級別。也就是說，沒有個別的應用程序進程在得到CPU時鐘時有比其餘進程更高的優先權。 

"priority boost"配置選項容許改變。缺省值是0，即SQLServer進程和其餘的應用程序進程有相同的優先權。若是改成1，那麼SQLServer有比其餘應用程序進程更高的優先權。本質上，這意味着SQLServer比同一服務器上的其餘應用程序進程有第一優先權使用CPU時鐘。可是這真能提高SQLServer的性能嗎？ 

讓咱們看看一對情形。首先，假定服務器不僅運行SQLServer，也有其餘的應用程序（爲了最好的性能不推薦這樣使用，但真實世界有可能存在這種情形），且有不少的CPU可用。若是是這種情形，給SQLServer一個更高的優先權會怎樣呢？不怎麼樣。若是有不少可用的CPU，提升優先權並不意味着什麼，和其餘程序相比，SQLServer也許得到一些毫秒級的時間，但我懷疑你能注意到這個區別。 

如今讓咱們看看上面這個熟悉的場景，可是假定CPU事實上都耗盡了。若是是這種狀況，給SQLServer一個更高的優先權固然會運行得更快，可是隻有以其餘應用程序運行得慢爲代價。若是這是你須要的，那麼沒問題。但更好的解決方法是提高服務器上CPU的能力或減小服務器的負載。 

但若是SQLServer運行在一個沒有其餘應用程序的專用服務器上且有不少過剩的CPU可用呢？這種狀況下，提高優先權沒有用，由於沒有CPU競爭（除了部分操做系統進程外），並且有不少CPU還可用。 

最後一種情形，假如SQLServer運行在專用服務器上，且CPU沒有空閒，給更高的優先權是一個零和遊戲，這樣作潛在的給一部分操做系統以消極的影響。而SQLServer得到的性能卻不多。 

正如你所見，這個選項不值得修改。事實上，微軟有文檔說明使用這個選項的幾個問題，試圖使用這個選項甚至不多使人滿意。 

若是在你的監控列表裏發現該選項打開，找出目的。若是打開它目前沒有任何問題，你可能會沒有問題的打開它，可是我建議改回缺省值。 

Query Governor Cost Limit 

"query governor cost limit"選項設置查詢所能運行的最高時間限制，這是我承認的少數幾個SQLServer配置選項之一。例如，假定你服務器的一些用戶喜歡運行長時間的查詢，這真正會下降你服務器的性能。經過設置該選項，你能禁止運行任何超過300秒（或者任何你肯定的數）的查詢。缺省值是0，即一個查詢運行多長時間都沒有限制。 

你爲這個選項設置的值是一個近似值，而且基於查詢優化器估計出的查詢運行的時間。若是估計值比你提供的值要多得多，查詢根本不會運行，反而產生一個錯誤。這能節約大量的有用的服務器資源。 

另外一方面，若是用戶不得不爲了完成他們的工做而因爲你他們不能運行查詢，他們將真正感到不快。也許你考慮該作的是幫那些用戶寫更有效率的查詢。這樣，你們皆大歡喜。 

不象個人其餘不少建議，若是你的監控列表裏該值大於0，很好。只要用戶不抱怨，這就是一個好的處理。事實上，若是設置爲0，這兒考慮增長一個值，看看發生了什麼。只是不要加得過小。能夠考慮一開始加600秒，看看發生了什麼。若是沒問題，而後試試500秒，依此類推，直到你發現用戶開始抱怨位置，而後改回前一個值。 

Query Wait (s) 

若是SQLServer很忙且在不斷使用更多的內存資源，它將大量佔用內存的查詢（如那些涉及排序和哈希操做的查詢）排隊等待，直到有足夠的內存運行它們。有些狀況下，沒有足夠的內存運行它們，最終會超時，產生一個錯誤消息。缺省地，一個查詢運行的時間若是超過查詢優化器估計它運行要花費的時間的25倍後，該查詢將超時。 

這個問題的最好的解決方法是給服務器添加更多的內存，或者減小它的負載。若是你不能這麼作的話，一個可選項就是使用"query wait"配置選項，儘管它自己有不少問題。缺省值是-1，等待的時間如上所述，而後引發超時。若是你要時間很大以便查詢不超時，能夠設置"query wait"一個足夠大的值。正如你也許猜到的那樣，你將不得不經過試錯決定該值。 

使用這個選項的問題在於有這樣一個查詢的事務可能會保持鎖，這會引發死鎖或者其餘一些鎖爭奪的問題，最後出現一個比查詢超時更大的問題。所以該選項不建議修改。 

若是在你的監控列表裏發現該選項沒有設置爲缺省值，找出緣由。若是沒有好的緣由，請改回缺省值。可是若是有人完全考慮過它，且你也沒有發現鎖問題，那麼考慮保持現狀。 

Recovery Interval (min) 

若是你有一個有不少INSERT、UPDATE、DELETE的活動頻繁的OLTP服務器應用程序，"recovery interval"的缺省值0（意味着SQLServer自動決定適當的恢復時長）也許不合適。若是你正用性能監視器監視你服務器的性能，注意有一個規則的100％的磁盤寫活動的週期（發生在檢查點運行期間），你要設置該選項一個更高的值如5或10。它表示SQLServer重啓後恢復數據庫所需的最大分鐘數。缺省值是0，實際上，這表示每一個數據庫的恢復時間不超過 1 分鐘。 

使用該選項的另外一個潛在的緣由是若是服務器是OLAP或數據倉庫專用服務器的情形。在這些實例裏，有不少只讀數據庫一般從一個短小的恢復時長裏得不到好處。 

若是你的服務器不匹配上面的任一建議，那麼保留缺省值一般是最好的選擇。 

經過延長檢查點時間，能夠減小SQLServer執行檢查的次數，若是有效，減小SQLServer的一些開銷。在性能和爲SQL花費的時間之間找到一個折中方案須要屢次試驗。爲了減小下次SQLServer重啓須要的恢復時間你須要配置一個儘量小的值。這是由於每次SQLServer服務啓動時，它將經歷自動恢復過程，該選項的值設得越大，恢復過程花費得時間就越長。你不得不決定在性能和恢復時長之間找到一個折中的方案以便最適合你的需求。 

做爲監控的一部分，你要估計該選項目前的設置和它潛在的使用。對於繁忙的OLTP服務器來講，在你決定增長該選項的值看看是否有幫助以前你要作大量的調查。測試是重要的。但若是你的服務器是OLAP或數據倉庫專用服務器，增長該選項的值是一個很容易作出的決定。 

Scan for Startup Procs 

若是獲得正確的配置，SQLServer服務啓動時有能力去尋找自動運行的存儲過程。若是你想在啓動時作一些特定的操做這是有利的，如載入一些特定的存儲過程到緩存裏以便當用戶開始訪問服務器時它已是準備好的。 

缺省地，"scan for startup procs"選項設置爲0，意味着啓動時不掃描存儲過程。若是你沒有任何在啓動時要啓動的存儲過程，那麼這是一個顯而易見的設置。沒必要花費資源去尋找那些不存在的存儲過程。 

但若是你有一個或多個存儲過程想在服務啓動時執行，那麼該選項須要設置爲1，表示啓動時掃描。 

若是你在你的監控列表裏發現該選項的值爲1，檢查看是否有任何服務器啓動時要執行的存儲過程 。若是沒有，將該選項的值改回缺省值。 

Set Working Set Size 

當你要更改SQLServer啓動時使用的最大和最小的內存時就要用"set working set size"選項。這個選項也幫助你禁止任何頁面交換。 

該選項的缺省值爲0，即不使用該選項。要打開這個選項，必須將它設置爲1，而且，最小的內存和最大的內存要設置爲相同的值。該值用來保留等於服務器內存設置的物理內存空間。 

和許多選項同樣，這個選項一般也沒必要使用。僅在服務器是SQLServer專用服務器且工做量很大還有不少可用的內存時才考慮。即便那樣，任何性能的提高也是最小的，你還要冒潛在的沒有留給操做系統足夠內存的風險。測試是該選項成功使用的關鍵。 

若是該選項設置爲不是缺省值的另外的值，檢查最小的內存和最大的內存是否相同，不然這個選項將不會正確的工做。若是存在上面提到的條件而且通過完全的測試，那麼考慮保留設置。不然，改回缺省值（不要忘記改回全部相關的3個設置）。 

User Connections 

缺省地，SQLServer僅分配須要的用戶鏈接數。這容許那些須要鏈接的用戶鏈接，同時最小化內存的使用。當"user connections"選項設置爲缺省值0時，用戶鏈接數動態設置。事實上在全部的環境下，這個設置都時理想的設置。 

若是你改變了該選項的值而不設置爲缺省值，你是在告訴SQLServer將分配一個你指定的鏈接數給它，很少很多。它也將爲每一個鏈接分配內存，不論這個鏈接是否使用。因爲這些問題，且SQLServer能動態有效的處理這些任務，沒有理由改變該選項的缺省值而設置爲其餘值。 

若是你的監控裏顯示該值不爲0，將其改回0。甚至都不要問爲何。

SQLServer數據庫設置性能列表

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址

性能監控列表
數據庫配置選項 缺省值 當前值 
auto_close off 
auto_create_statistics on 
auto_update_statistics on 
auto_shrink off 
read_only off 
torn_page_detection on in 2000
off in 7.0 
compatibility level 80 for 2000
70 for 7.0 
database auto grow on 
transaction log auto grow on 

輸入你的結果到上表 

每個數據庫都須要監控 

做爲性能監控的一部分，你須要檢查你服務器上的每個數據庫和一些基本的數據庫設置。和這套監控列表的其餘監控相比，你會發現該監控是最容易的。爲了方便，你能夠將你要監控的每一個數據庫作一個上表的副本。 

做爲數據庫設置監控的一部分，咱們來看看數據庫選項和數據庫配置設置之間的不一樣。在之前的性能監控列表中，咱們僅僅着眼於那些直接和性能相關的數據庫設置，而忽略了其他部分。 

數據庫選項和數據庫配置設置都能使用企業管理器查看和修改（我偏好它，由於簡單），或者用ALTER DATABASE命令修改。另外，僅對於數據庫選項而言，還能夠使用sp_dboption系統存儲過程去查看和修改它們，但微軟正試圖逐步淘汰這個命令，到SQLServer2000爲止，之後可能再也不支持。 

數據庫設置性能監控列表的第一部分是數據庫選項，第二部分着眼於數據庫配置設置。 

查看數據庫選項 

在這一部分，咱們將僅僅察看以某種方式影響性能的衆多數據庫選項中的6個。察看目前設置的最好方法是用企業管理器，步驟以下（假定用的是sqlserver2000）：
• 在企業管理器裏，展開全部的數據庫。 
？ 右擊你要察看的數據庫，選擇屬性。 
？ 在屬性對話框裏選擇選項標籤。
從這裏你能夠看到全部相關的數據庫選項。記住不是每一個數據庫選項都能在這兒看到，可是咱們感興趣的全部的選項都列在這兒了。讓咱們看看與性能相關的那些選項，它們是怎樣影響SQLServer的性能的。 

Auto_Close 

這個數據庫選項是爲SQLServer7.0和2000的桌面版本設計的，而不是爲服務版本。所以，它將不會被打開（缺省也不是打開的）。該選項所要作的就是在最後一個數據庫用戶從數據庫斷開鏈接時關閉數據庫。當一個鏈接在數據庫關閉後要求訪問它時，數據庫不得不從新打開，這會花費時間。 

這樣有個問題就是：若是數據庫被頻繁的訪問（這是常常的狀況），那麼數據庫會不斷的關閉從新打開，這樣應用程序或用戶在鏈接時會很大的影響SQLServer的性能。 

做爲監控的一部分，若是你發現這個選項被打開，而你又使用的不是桌面版，那麼你須要找出緣由。若是你找不到緣由，或者緣由不多，那麼關閉該選項。 

Auto_Create_Statistics 

當auto_create_statistics打開時（缺省也是打開的），查詢的Where子句用到的全部列上會自動建立統計。這發生在查詢被查詢優化器第一次優化時，假定這列尚未建立統計。全部的列統計能極大的幫助查詢優化器，以便它能爲查詢建立一個優化的執行計劃。 

若是該選項關閉，那麼丟失的列統計不會自動建立，這就意味着當查詢優化器不能爲查詢產生優化的執行計劃時，查詢的性能將受到影響。若是你原意，你仍然能夠手工建立列統計，即便該選項被關閉。 

使用該選項真正沒有負面的影響。剛好第一次列統計被建立，這將在查詢第一次運行前花很短的時間，從而引發查詢潛在的花費更長一點的時間運行。但一旦列統計已經建立，每次運行一樣的查詢時，都將比第一次不存在統計時更有效率。 

做爲監控的一部分，若是你發現這個選項被關閉，你須要找出緣由。若是你不能找到緣由，或者緣由不多，那麼打開這個選項。 

Auto_Update_Statistics 

爲了使查詢優化器作出更快的查詢優化決策，列和索引統計須要更新。確保它的最好方法是打開數據庫選項auto_update_statistics（缺省也是打開的）。這能幫助確保優化器統計是有效的，幫助確保查詢運行時是被徹底優化的。 

但這個選項不是萬能的。當SQLServer數據庫在繁重的負載之下，有時auto_update_statistics可能在不恰當的時候更新一個大表的統計，如一天最忙的時候。 

若是你發現auto_update_statistics在不恰當的時候運行了，你也許要關閉它，而後在數據庫不繁忙的時候手工更新統計（使用UPDATE STATISTICS）。

可是還要考慮的一點是若是關閉auto_update_statistics選項將發生的事情。關閉該選項也許會在一天中不恰當的時候不運行統計更新來減小你服務器的壓力，它也能引發你的一些查詢得不到正確的優化，從而在繁忙的時候引發服務器的另外一些壓力。

象其餘優化問題同樣，你可能要經過試驗來看開關這個選項是否對你的環境更有效。可是首要的原則是，若是你的服務器不是最繁忙的，那麼打開該選項也許是最好的選擇。 

Auto_Shrink 

一些數據庫須要週期性的收縮以便刪除數據庫舊的數據來釋放磁盤空間。但不要企圖用auto_shrink數據庫選項，這可能浪費沒必要要的數據庫資源。 

auto_shrink選項缺省是關閉的，這意味着只有一個方法去釋放數據庫裏的空的空間，那就是手動去作。若是打開該選項，SQLServer將每隔30分鐘檢查看看是否須要收縮數據庫。這樣不只使使用的資源上升（這些資源原本能夠在別處獲得更好的利用），也可能當auto_shrink進程在最繁忙的時間啓動並工做時引發不可預料的瓶頸。 

若是你須要週期性的收縮數據庫，使用DBCC SHRINKDATABASE或者DBCC SHRINKFILE命令手工執行這一步或者使用SQLServer代理或建立一個數據庫維護計劃在不忙的時候進行週期性的調度。 

做爲監控的一部分，若是你發現該選項是打開的，你須要找出緣由。若是找不到或者緣由不多，那麼關閉該選項。 

Read_Only 

若是一個數據庫僅爲了只讀目的，如爲了報表，那麼考慮設置read_only選項（缺省是關閉的）。這將除去那些資源利用多的鎖，潛在的輪流提高它上面運行的查詢的性能。若是你不多更改數據庫，那麼關閉該選項，當要更改的時候再打開。

Torn_Page_Detection 

因爲SQLServer的數據頁面（8K）和NT Server或者Windows Server（512字節）是不一樣的尺寸，可能在電源故障或者磁盤驅動、物理磁盤問題時數據庫會變得不完整。

下面是緣由。每當操做系統寫一個SQLServer的8K數據頁到磁盤時，都必須把數據分紅多個512字節的頁面。在第一個512字節的數據寫完後，SQLServer假定整個8K的頁面已被成功寫入磁盤。因此若是在8K的SQLServer頁面分紅的全部512字節的頁面寫入磁盤以前出現了電源故障，那麼SQLServer不知道發生了什麼事情。這被稱爲殘缺頁。

正如你所想象的那樣，這損壞了數據頁面，也損壞了整個數據庫。沒有辦法將數據庫損壞的緣由歸結到殘缺頁，除非經過一個已知無缺的備份備份恢復。防止這個問題的最好的方法之一就是確保服務器有一個備用電池。但這不能防止全部的問題，由於一個有缺陷的磁盤驅動也能引發相似問題（我曾經見過）。

若是你擔憂SQLServer數據庫出現殘缺頁問題，你能讓SQLServer告訴你他們是否發生（儘管這不能防止問題發生，也不能過後修正它們）。有一個數據庫選項叫作"torn page detection"能在數據庫級打開或者關閉。若是該選項打開，且若是發現了殘缺頁，那麼數據庫會被標記爲不完整，且你基本上沒有什麼選擇餘地只能用你最近的備份恢復你的數據庫。

在SQLServer7.0裏，這個選項缺省是關閉的，且你必須爲你要在上面用這個選項的每個數據庫上打開。在SQLServer2000裏，這個選項默認是爲全部數據庫打開的。

那麼最大的問題是：爲何不僅打開它而變得安全呢？這個問題的緣由在於打開該選項會影響SQLServer的性能。 你記住的不要太多，僅僅記住一點，若是你的SQLServer有很高性能問題，那麼關閉該選項可能有一個明顯的區別。做爲一個DBA，你必須在是否使用該選項上作出決定，爲你的特別的環境作出決定。 

查看數據庫配置設置 

這一節咱們將只查看三個數據庫配置設置，檢查它們是怎樣影響性能的。查看它們最好的方法是用企業管理器，參考下面的步驟（這些步驟適合於SQLServer2000）： 
？ 在企業管理器裏，顯示你的服務器裏全部的數據庫 
？ 右擊你要查看的數據庫，選擇屬性 
？ 從屬性對話框裏，選擇選項標籤查看兼容級別，選擇數據文件標籤查看數據庫自動增加設置，選擇事務日誌標籤查看事務日誌自動增加設置。
讓咱們看看三個相關數據庫配置設置的每個。 

Compatibility Level 

SQLServer7.0和2000有一個數據庫兼容模式，容許爲之前版本的SQLServer寫的應用程序在7.0或者2000下容許。在你想要最大化你數據庫的性能裏，你不要在兼容模式下運行你的數據庫（不是全部新的性能相關的特徵都被支持）。

相反，你的數據庫應該運行在原本的SQLServer7.0或者2000模式下（依賴於你目前運行的版本）。固然，這會要求你修改你的應用程序使其適應SQLServer7.0或2000，但大多數狀況下，這些額外的又是必須的升級應用程序的工做將對提高性能有更多的回報。 

SQLServer7.0的兼容級別是70，2000的兼容級別是80。 

Database and Transaction Log Auto Grow 

咱們將一塊兒討論數據庫自動增加和事務日誌自動增加，由於它們關聯得很近。 

若是你設置SQLServer7.0或2000的數據庫和事務日誌自動增加（缺省也是），記住每當這個選項起做用時，它將花費一些額外的CPU和I/O。理論上，咱們應儘可能減小自動增加發生的頻率以便減小沒必要要的性能負擔。

一個有用的方法時儘量精確的度量數據庫最終的大小。固然，事實上要獲得正確的目的幾乎是不可能的。但若是估計得越精確（有時獲得這個好的估計要花費一些時間），sqlserver不得不自動增加數據庫和事務日誌就會越少，有助於提高你應用程序的性能。

下面一些對事務日誌的獨特建議是重要的。這是由於不少時候SQLServer不得不增加事務日誌的大小，SQLServer不得不建立和維護更多的事務日誌文件，當須要恢復事務日誌時會增長恢復時間。一個被SQLServer使用的事務文件本質上被分紅多個物理事務日誌文件管理。

缺省的自動增加比例爲數據庫和事務日誌的10％。這個自動增加數字對你的數據庫和事務日誌也許有好有壞。若是你發現數據庫和日誌常常自動增加（好比一天一次或者一週幾回），那麼改變這個增加百分比到一個較大的數字，如20％或30％。每次數據庫或日誌增加時，SQLServer都將有一個小的性能降低。經過增長每次數據庫增加的數量，讓增加不是很頻繁的發生。

若是你的數據庫很大，10G或者更大，你也許要用一個固定的增加量來代替百分比增加量。這是由於百分比增加量在一個大數據庫上會變得很大。例如在一個10G的數據庫上一個10％增加率意味着當數據庫增加時，要增加1G。這也許是或不是你所要的。若是這超過了你的需求，那麼選擇每次增加一個固定增加量如100M，也許更合適。

做爲監控的一部分，你須要當心估計你的數據庫看上面的建議是否適合它們，而後作出正確的選擇。

索引性能監控列表
索引列表 你的答案 
你最近是否運行過索引調優嚮導? 
每一個數據庫裏的每一個表是否有彙集索引? 
每一個表的任一列是否被屢次索引? 
查詢裏是否有沒有被使用的索引? 
索引是否太寬? 
鏈接的表的鏈接列上是否有適當的索引? 
索引是否足夠惟一到有用？ 
覆蓋索引是否帶來了好處？ 
索引重建的頻率是多少？ 
索引的填充因子是多少？ 
輸入你的結果到上表。 

審覈索引的使用狀況不是一件容易的任務，但對於你服務器的性能來講是緊迫的

在審覈SQLServer數據庫裏索引的使用狀況的時候，有時我很受打擊。例如，怎樣去審覈超過1500個表的數據庫的索引？審覈單個索引相對簡單些，審覈多個數據庫裏的成千上萬個索引就不是一件容易的任務了。無論這項任務是否容易，對於優化SQLServer數據庫的性能來講倒是重要的。 

在着手處理大量索引的審覈時有兩個不一樣的方法。一個是分紅更小的更容易管理的單元，首先着眼於那些最可能影響SQLServer性能的索引。例如，你能夠在你服務器最忙的數據庫上啓動審覈，若是它有不少表，首先從最多數據的那些表開始，而後逐步到那些少一點的表。這樣，你將在那些最可能有很大實際影響服務器性能的地方看到最初的成就。 

另外一個方法，也是我一般使用的方法（由於我有點懶），就是使用排除法。個人意思是若是看不到數據庫的任何性能問題，就沒必要要評估數據庫的每個索引。但若是數據庫顯示正好存在性能問題，那麼對那些不是最優的索引來講是一個好的調優機會，特別注意它們，尤爲在數據庫任務緊急的時候。若是有大量的索引要審覈，那麼先從最大的入手，由於它們最可能引發性能問題。例如，在有1500個表的數據庫裏，我僅僅當心的審覈大約一打的表（都是很大的表），我認爲它們應該受到最多的關注。

無論怎樣，當你決定審覈你所管理的數據庫的索引的時候，你須要拿出合理的計劃並系統地實現。 

正如你已經看到的，我上面提供的審覈列表不是很長。這是故意的。記住，這一系列關於性能監控的文章的目的是爲了分辨容易和顯而易見的性能問題，不是找出所有。上面列出來的將使你走很長的路去分辨和糾正容易的與索引相關的性能問題。一旦你掌握了它們，就能夠更上一層樓了。例如，本網站上有不少索引相關的提示，大部分都很高級，好比下面的主題： 
？ 普通索引 
？ 彙集索引 
？ 複合索引 
？ 覆蓋索引 
？ 非彙集索引 
？ 重建索引 
？ 索引調優嚮導 
若是你尚未作過的話，你須要複習這些提示的網頁。 

你最近運行過索引調優嚮導嗎？ 

微軟在SQLServer7.0和2000裏給咱們最好的工具就是之一就是索引調優嚮導。它不是一個完美的工具，但它確實能幫助你分辨存在的索引是否正被使用，同時提供能加快查詢的新索引。若是你正使用SQLServer2000，它也能推薦索引視圖的使用。它使用目前你正在數據庫裏運行的查詢，因此它的建議是基於你數據庫是真正怎麼使用的。它用來分析所需的查詢來源於你用SQLServer事件探查器建立的跟蹤。

當在一個新的SQLServer上進行性能審覈時我作的第一件事就是在捕捉到的服務器活動的跟蹤上運行索引調優嚮導。大多數狀況下，它能幫助我快速的分辨出任何一個不被使用的能夠被刪掉的索引，分辨出爲了提高數據庫性能須要新建的索引。

這裏有一些對於在使用索引調優嚮導審覈SQLServer數據庫索引時的提示： 
？ 當你在使用事件探查器捕捉數據時（索引調優嚮導用來分析性能），選擇一天中數據庫正常負荷的具備表明性的時段。我一般喜歡選擇在上午或者下午3點，而後運行事件探查器跟蹤至少一個小時以上。 
？ 一旦事件探查器跟蹤完，索引調優嚮導能夠隨時運行。可是，一個好的想法是在數據庫一段時間不忙的最適宜的時候運行，這是由於使用索引調優嚮導進行性能分析時會影響服務器的一些性能，既然沒必要要，對服務器性能產生負面影響就毫無心義。也要避免在產品服務器上運行分析（嚮導仍不得不鏈接到產品服務器），當執行分析的時候在另外一臺服務器上運行嚮導能夠減小產品服務器的負載。 
？ 儘管要花費更多的時間去完成分析，你須要在索引調優嚮導的幾個選項的設置期間列一個清單來幫助進行完全的分析。這些包括：不要選擇"Keep all existing indexes"（保留全部現有索引），由於你要分辨哪些索引沒有用；指定你要進行"Thorough"（完全的）分析，而不是"Fast"（快速）或者"Medium"（適中）；不要選擇"Limit the number of workload queries to sample"（將要抽樣的工做負荷查詢的數目限制爲）選項，保留"maximize columns per index"（每一個索引的最大列數）設置的最大設置爲16；選擇全部被用來調優的表。經過選擇這些選項，索引調優嚮導將進行完全的工做，儘管要花費幾個小時才能完成，這依賴於跟蹤文件的大小和你執行分析的硬件的速度。注：這些只針對SQLServer2000，SQLServer7.0稍微有些不一樣。 
？ 一旦分析完成，嚮導也許沒有任何建議，也許建議刪除一個或更多的索引，或者建議添加一個或更多的索引，或者建議既添加也刪除。你須要在採納建議以前當心評估它們。例如，嚮導也許建議刪除一個特殊的索引，但你知道該索引是真正須要的。那麼當你知道這不是一個好想法可爲何嚮導建議刪除呢？這是由於嚮導沒有分析在跟蹤文件（僅僅是一個抽樣而已）裏發現的每個查詢，加之你的抽樣跟蹤數據可能沒有包括須要那個索引的查詢。這種狀況下，嚮導也許建議刪除該索引，即便這不是一個好的建議。一旦你檢查到一個索引是不須要的，你應該刪除它。 
？ 若是嚮導建議添加新的索引，那麼你要評估它們，也要和目前表上存在的索引比較看看它們是否有意義，會不會引發潛在的新的問題。例如，一個建議的索引或許能幫助一部分查詢，但它也可能下降每小時成千上萬次的INSERT操做。嚮導不知道這些，你必須決定哪一個更重要，一些查詢運行快了點而INSERT去慢了，反之亦然。 
？ 最後，即便索引調優嚮導沒有任何新索引的建議，這也不意味着新索引是不須要的，僅僅根據跟蹤數據來分析可能不會有任何建議。爲了更好的幫助分辨出須要的索引。你要考慮好幾天運行多個跟蹤以便獲得更多的抽樣數據。即便那樣，索引調優嚮導也不能找出所有須要的索引，但它將找出全部顯而易見須要的索引。
一旦你完成分析並根據建議作出了更改，我建議你再次跟蹤分析以便看看你的更改是否有效果。謹記索引調優嚮導分析不是一蹴而就的事情。隨着時間的推移數據庫的數據發生了潛在的變化，隨着一塊兒變化的還有查詢的類型。因此，做爲一個要點：按期的對服務器進行跟蹤和分析以保持按期的優化。 

每一個數據庫的每一個表都有彙集索引嗎？ 

首要的原則是每一個表都應該有彙集索引。彙集索引一般但不老是應該建在單調遞增的一列上如自增列，或者其餘的值是遞增並惟一的列上。大多數狀況下，主鍵是做爲彙集索引理想的列。 

若是你曾經調優過SQLServer6.5的性能，你也許據說在單調遞增列上建立彙集索引不是一個好的方法，由於它可能因爲磁盤的"hotspot"（熱區）引發性能問題。那個建議在SQLServer6.5中是正確的。 

在SQLServer7.0和2000中，"hotspots"一般不是問題了。只有在每秒超過1000個的事務的狀況下，"hotspot"纔對性能有負面的影響。事實上，"hotspot"在這些環境下是有用的，由於它消除了頁拆分。 

下面是緣由。若是你正在向一個主鍵上建彙集索引的表裏插入新的行，主鍵是單調遞增的，這意味着每一個INSERT將在磁盤上逐個的物理順序出現，所以，頁拆分不會發生，這自己就節省了資源。這是由於SQLServer有能力決定數據是否被插入到有單調遞增序列的表裏，若是是，就不會執行頁拆分。 

若是你正插入不少行到一個堆表（沒有彙集索引的表）中，數據不會按任何特定的順序插入到數據頁，無論數據單調遞增與否。這樣當從磁盤上訪問數據時，SQLServer會花費更多的讀操做。另外一方面，若是給表添加彙集索引，數據被順序的插入到數據頁上，一般在讀取數據時花費更少的磁盤I/O。 

若是數據被插入到一個或多或少有隨機順序的彙集索引裏，數據一般是隨機的插入到數據頁裏，就象堆表同樣，會發生頁拆分。 

那麼說回來，爲了全面的提高性能，最好的建議就是在一個單調遞增列（假定有一列是符合條件的）上添加彙集索引。若是表上有不少INSET、UPDATE和DELETE操做更是應該這樣。但若是表的更改不多，大部分是SELECT語句，那麼這個建議就不是頗有用，爲彙集索引考慮其餘的選擇。 

做爲索引監控的一部分，檢查看看數據庫裏每一個表是否都有索引。若是根本沒有索引，認真的考慮給添加一個彙集索引，參考上面的建議。事實上給表添加一個彙集索引不會比沒有彙集索引時引發性能降低。 

每一個表的任一列是否被屢次索引? 

聽上去這個建議是顯而易見的，但它比你認爲的要廣泛得多，特別是多個DBA每人管理一段時間的數據庫。SQLServer不關心你是否這樣作，只要索引的名稱不一樣它就承認了。因此當檢查表目前的索引時，看看是否有列在沒必要要的重複索引中。刪除它們不只能節約磁盤空間，也能加快對錶數據的訪問和修改。 

重複索引的一個一般例子就是忘記了列上有主鍵，或者列是惟一的，這樣列上會自動建立索引，但是又在上面以不一樣的索引名稱建立了索引。 

查詢裏是否有沒有被使用的索引? 

這裏有另一個顯而易見的建議，但也是一個廣泛的問題，特別是在數據庫正式啓用之前DBA或開發人員猜想的爲數據庫建立的最初的那些索引。僅僅看看錶的索引不會告訴你這些索引是否有用，因此分辨沒用的索引一般是不容易的。 

分辨沒用的索引的最好途徑是使用索引調優嚮導，前面討論過。 

沒必要要的索引，象重複索引，既浪費磁盤空間又對數據的訪問修改的性能沒有多大的好處。 

索引是否太寬? 

索引越寬，明顯地就變得越大，訪問或修改數據時SQLServer就不得不作更多的操做。所以，你應該避免在太寬的列上添加索引。索引越窄，性能越快。 

另外，複合索引，包括兩個或更多的列，也可能出現一樣潛在的問題。一般要儘量的避免複合索引。數據庫使用複合索引越多，經常意味着數據庫的設計有缺陷。 

不可能老是避免寬索引或複合索引，但不得不用時，確信對你的選擇作過仔細的評估而且沒有其餘的辦法幫助提升性能。 

鏈接的表的鏈接列上是否有適當的索引?

基本上，爲了最好的性能，表裏用來鏈接的列上都應該建索引。這是直接了當的建議，也是至關顯而易見的，但爲了最優的JOIN性能監控索引倒是不容易的，由於爲了全面的性能監控你必須熟悉數據庫裏全部執行的鏈接。 

當建立主外鍵關係（一般用來JOIN的）時，不少人都忘記了主鍵列上會自動建立索引而外鍵列上不會自動建立，外鍵列上必須手動建立。 

因爲常常忘記，做爲監控的一部分，你要分辨出表的全部主外鍵關係並檢查每個外鍵列上是否有正確的索引。 

除此以外，你也能使用索引調優嚮導幫助分辨出丟失的鏈接索引，但我發現嚮導不老是能爲鏈接表分辨出丟失的索引。說穿了，除非你知道數據庫裏一般運行鏈接的類型，不然是很難分辨出索引建在哪些列上能得到幫助。

索引是否足夠惟一到有用？ 

僅僅由於一個表有一個或更多的索引並不意味着SQLServer查詢分析器會用到它們。在它們被使用以前，查詢優化器不得不考慮它們是否有用。若是表的列上不是至少有95％是惟一的，那麼查詢優化器最可能不用這個列上的非彙集索引。所以，不要給那些沒有95％惟一值的列上添加非彙集索引。例如，一個只有"yes"和"no"的列上不是至少95％都是惟一的，在這列上建立索引基本上永遠不會獲得使用，咱們已經知道這對性能有很大的拖累。 

做爲監控的一部分，考慮在表上目測數據。換句話說，查看錶裏的數據，再看看索引的那些列。一般，列是否可選來作索引是很是顯而易見的。若是你注意到數據都是男或女，是或否等等，那麼這些數據不可選來作索引，而且它們上面的任何索引都將浪費空間並影響性能。 

覆蓋索引是否帶來了好處？ 

覆蓋索引是複合索引的一種形式，包括查詢裏SELECT、JOIN、WHERE語句引用的全部的列。所以，索引包含了你要查詢的數據，SQLServer沒必要去表裏查找實際的數據了，這樣減小了邏輯或物理I/O，從而提高性能。當非覆蓋的複合索引不能提高性能時，覆蓋索引就派上用場了，大多數狀況下，它確實能提高查詢的性能。

分辨出覆蓋索引在什麼地方最有用是很困難的。雖然索引調優嚮導能有所幫助，但它仍會丟失大量的找到覆蓋索引有用的地方的機會。另外，惟一的方法就是當心檢查你數據庫裏運行的全部查詢，固然這幾乎是不可能的，除非你真的有時間且沒有其餘更好的事情去作。

在這點上，你監控的目的自己不是找出新的覆蓋索引，而是理解它們以便你在你的環境裏遇到它們有用的地方時能從中得到好處。 

索引重建的頻率是多少？ 

隨着時間的推移，索引會出現碎片，這會引發SQLServer訪問它們時下降性能。惟一的解決方法就是按期整理數據庫裏全部索引的碎片。有幾種不一樣的方法來整理，怎樣去整理不會在這兒討論，這個在SQLServer的幫助文檔裏有，本網站之後也會介紹。

你監控的目的是找出正在監控的數據庫的索引是否在按期的整理碎片。整理碎片的頻率從天天每週到每個月不等，依賴於修改的頻率和數據庫的大小。若是數據庫天天要進行不少修改，那麼碎片整理應該更頻繁的執行。若是數據庫很大，這意味着碎片整理要花更長的時間，所以因爲碎片整理過程佔用太多的資源從而影響用戶的使用，因此不能太頻繁的整理碎片。做爲監控的一部分，你要評估碎片產生的頻率，找到最佳的頻率。

至少，若是索引目前沒有重建，而它們又須要重建，做爲監控的一部分，你須要確認一些適當的索引重建計劃。 

索引的填充因子是多少？ 

和索引重建最相關的是填充因子。當建立一個新索引，或重建一個存在的索引時，你能夠指定一個填充因子，它是在索引建立時索引裏的數據頁被填充的數量。填充因子設置爲100意味着每一個索引頁100％填滿，50％意味着每一個索引頁50％填滿。 

若是你建立一個填充因子爲100的彙集索引（在一個非單調遞增的列上），那意味着每當一個記錄被插入（或修改）時，頁拆分都會發生，由於在現存的頁上沒有這些數據的空間。不少的頁拆分會下降SQLServer的性能。

舉個例子：假定你剛剛用缺省的填充因子新建立了一個索引。當SQLServer建立它時，它把索引放在相鄰的物理頁面上，由於數據可以順序的讀因此這樣會有最優的I/O訪問。但當表隨着INSERT、UPDATE、DELETE增長和改變時，發生了頁拆分。當頁拆分發生時，SQLServer必須在磁盤的某處分配一個新的頁，這些新的頁和最初的物理頁不是連續的。所以，訪問使用的是隨機的I/O，而不是有順序的I/O，這樣訪問索引頁會變得更慢。

那麼理想的填充因子是多少呢？它依賴於應用程序對SQLServer表的讀和寫的比率。首要的原則，按照下面的指導： 
？ 低更改的表（讀寫比率爲100：1）：100％的填充因子 
？ 高更改的表（寫超過讀）：50-70％的填充因子 
？ 讀寫各一半的：80-90％的填充因子
在爲應用程序找到最優的填充因子前也不得不進行試驗。不要假定一個低的填充因子總比高的好。低的填充因子會減小頁拆分，它也增長了SQLServer查詢期間讀的頁數量，從而減小性能。過低的填充因子不只增長I/O開銷，也影響緩存。當數據頁從磁盤移到緩存中時，整個頁（包括空的空間）都移到緩存中。因此填充因子越低，不得不移到SQLServer緩存中的頁面就越多，意味着同時爲其餘重要數據頁駐留的空間就少，從而下降性能。

若是你沒有指定填充因子，缺省的填充因子時0，意味着100％的填充因子（索引的葉頁100％的填滿，但索引的中間頁有預留的空間）。 

做爲監控的一部分，你要決定新建索引或重建索引時的填充因子是多少。事實上，除了只讀數據庫，全部的狀況，缺省值0都是不適合的。相反，你想要一個填充因子保留合適的自由空間，按照上面的討論來作

SQLServer應用程序和TSQL性能監控列表 

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址 

性能監控列表
TSQL監控列表 你的答案 
TSQL代碼返回了沒必要要的數據嗎？ 
在沒必要要的地方使用了遊標嗎？ 
UNION和UNION SELECT使用得當嗎？ 
SELECT DISTINCT使用得當嗎？ 
WHERE子句是可SAGE的嗎？ 
在沒必要要的時候使用了臨時表嗎？ 
查詢裏的提示使用得當嗎？ 
使用了沒必要要的視圖嗎？ 
只要可能就用存儲過程了嗎？ 
存儲過程裏使用了SET NOCOUNT ON嗎？ 
你的任何一個存儲過程是以sp_開頭的嗎？ 
全部的存儲過程的擁有者是DBO嗎？引用的形式是databaseowner.objectname嗎？ 
你正爲引用完整性而使用約束和觸發器嗎？ 
事務是儘量的短嗎？ 

應用程序監控列表 
應用程序使用存儲過程（一批TSQL代碼）和使用對象模型如ADO來與SQLServer通訊嗎？ 
應用程序使用什麼模式和SQLServer通訊：DB-LIB、DAO、RDO、ADO仍是.NET？ 
應用程序使用ODBC仍是OLEDB和SQLServer通訊？ 
應用程序利用了鏈接池嗎？ 
應用程序是適當的打開、重用、關閉鏈接的嗎？ 
傳給SQLServer的TSQL代碼是最優化的仍是普通的SQL？ 
應用程序從SQLServer返回了沒必要要的數據嗎？ 
當用戶正修改數據時應用程序保持事務打開嗎？ 

在上面的表裏輸入你的結果 

應用程序和TSQL代碼極大的影響着SQLServer的性能 

在全部能影響SQLServer性能中，被用來訪問SQLServer數據的應用程序代碼，包括TSQL代碼是潛在最影響性能的。但不幸的是，這些是不少DBA都不能直接控制的。所以，當對基於SQLServer的應用程序調優時一般都忽略了這些。

和這一系列文章前面的那些文章同樣，本監控的目的也是找出訪問SQLServer數據的應用程序和TSQL代碼裏容易的性能相關的問題。除了這裏列出的提示，還有大量更多的影響SQLServer性能的因素，但這裏列出的是一個好的開端。

固然，若是你在使用第三方軟件，那麼這部分性能監控不影響你由於你沒有作太多關於代碼的事。但若是你開發了本身的應用程序或應用程序事內部開發的，那麼你應該採用這部分SQLServer的性能監控。

當你回顧下面監控項目的討論時，你很快會發現分辨它們中的一些問題，甚至糾正它們不是一件小的任務。所以，更好的方法是內心帶着這些性能提示來開發應用程序而不是在應用程序開發完後去糾正。當開發新的應用程序的時候你能夠把這篇文章放在左右以便開發應用程序時能第一時間看到相關的性能提示。

TSQL監控列表 

TSQL代碼返回了沒必要要的數據嗎？ 

SQLServer返回的數據越少，操做須要的資源也越少，能夠幫助全面提高SQLServer性能。這聽起來是顯而易見的，但這種情形引發的性能問題我一而再再而三的看到。

開發人員在從SQLServer返回數據時結果返回更多沒必要要的數據，下面是他們常犯的一些錯誤： 
？ 缺乏WHERE子句，除非你要返回表裏全部的數據，而這種狀況幾乎不多，在減小返回行的數量時使用WHERE子句是必要的。 
？ 做爲上面建議的補充，WHERE子句應儘量的具備可選性。例如，若是你僅需返回特定日期的記錄，而不是返回月或年的全部記錄。設計WHERE語句以便能正好僅僅返回須要的那些行，而不要有額外的行。 
？ 在SELECT語句裏，僅僅包括須要的那些列，而不是全部列。一樣，當最可能要返回須要的更多的行時，不是使用SELECT *。 
？ 我將在這頁的後面再次說起該條目，但這裏它也適用。不要對視圖執行SELECT，相反，繞過視圖直接從須要的表裏獲取數據。緣由是許多視圖（固然不是所有）返回比SELECT語句所需更多的數據，而SELECT語句終止返回比須要更多的數據。
萬一你不瞭解它們，下面一些性能問題是由返回沒必要要的數據引發的：有時，返回太多的數據會強迫查詢優化器執行表掃描而不是索引查找；讀數據須要額外的I/O開銷；緩存空間也浪費了，原本能夠被SQLServer爲其餘目的更好使用的；產生沒必要要的網絡流量；在客戶端，內存不得不存儲這些額外的數據，而這部份內存能夠被其餘應用更好的使用；等等。

在沒必要要的地方使用了遊標嗎？ 

任何一種遊標都會下降SQLServer性能。有些狀況不能避免，大多數狀況能夠避免。因此若是你的應用程序目前正在使用TSQL遊標，看看這些代碼是否可以重寫以免它們。

若是你須要一行一行的執行操做，考慮下邊這些選項中的一個或多個來代替遊標的使用： 
？ 使用臨時表 
？ 使用WHILE循環 
？ 使用派生表 
？ 使用相關子查詢 
？ 使用CASE語句 
？ 使用多個查詢
上面每個都能取代遊標而且執行更快。 若是你不能避免使用遊標，至少試着提升它們的速度。找出加速遊標的方法在其餘文章會有介紹。 

UNION和UNION SELECT使用得當嗎？ 

許多人沒徹底理解UNION和UNION SELECT是怎樣工做的，所以，結果浪費了大量沒必要要的SQLServer資源.當使用UNION時，它至關於在結果集上執行SELECT DISTINCT。換句話說，UNION將聯合兩個相相似的記錄集，而後搜索潛在的重複的記錄並排重。若是這是你的目的，那麼使用UNION是正確的。

但若是你使用UNION聯合的兩個記錄集沒有重複記錄，那麼使用UNION會浪費資源，由於它要尋找重複記錄，即便它們不存在。因此若是你知道你要聯合的記錄集裏沒有重複，那麼你要使用UNION ALL，而不是UNION。UNION ALL聯合記錄集，但不搜索重複記錄，這樣減小SQLServer資源的使用，從而全面提高性能。 

SELECT DISTINCT使用得當嗎？ 

我曾經注意到一些開發人員機械地在SELECT語句裏添加DISTINCT，而不論須要與否。從才能的角度看，DISTINCT子句僅在特定功能的時候使用，即從記錄集中排除重複記錄的時候。這是由於DISTINCT子句要求存儲結果集而後去重，這樣增長SQLServer有用資源的使用。固然，若是你須要去作，那就只有去作了。當若是你知道SELECT語句將從不返回重複記錄，那麼使用DISTINCT語句對SQLServer資源沒必要要的浪費。

WHERE子句是可SAGE的嗎？ 

術語"sargable"（其實是一個捏造的詞）來源於"Search ARGument"（搜索參數）的首字母拼成的"SARG"，它是指WHERE子句裏列和常量的比較。若是WHERE子句是sargable（可SARG的），這意味着它能利用索引加速查詢的完成。若是WHERE子句不是可SARG的，這意味着WHERE子句不能利用索引（或至少部分不能利用），相反執行的是表或索引掃描，這會引發查詢的性能降低。

在WHERE子句裏不可SARG的搜索條件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE"和"LIKE '%500'"一般（但不老是）會阻止查詢優化器使用索引執行搜索。另外在列上使用包括函數的表達式，兩邊都使用相同列的表達式，或和一個列（不是常量）比較的表達式，都是不可SARG的。

並非每個不可SARG的WHERE子句都註定要表掃描。若是WHERE子句包括兩個可SARG和一個不可SARG的子句，那麼至少可SARG的子句能使用索引（若是存在的話）幫助快速訪問數據。

大多數狀況下，若是表上有包括查詢裏全部SELECT、JOIN、WHERE子句用到的列的覆蓋索引，那麼覆蓋索引可以代替表掃描去返回查詢的數據，即便它有不可SARG的WHERE子句。但請記住覆蓋索引尤爲自身的缺陷，如此常常產生寬索引會增長讀時的磁盤I/O。

某些狀況下，能夠把不可SARG的WHERE子句重寫成可SARG的子句。例如： 

WHERE SUBSTRING(firstname,1,1) = 'm' 

能夠寫成： 

WHERE firstname like 'm%' 

這兩個WHERE子句有相同的結果，但第一個是不可SARG的（由於使用了函數）將運行得慢些，而第二個是可SARG的，將運行得快些。 

若是你不知道特定的WHERE子句是否是可SARG的，在查詢分析器裏檢查查詢執行計劃。這樣作，你能很快的知道查詢是使用了索引仍是表掃描來返回的數據。

仔細分析，機靈思考，許多不可SARG的查詢能寫成可SARG的查詢。 

在沒必要要的時候使用了臨時表嗎？ 

臨時表有不少特殊的用途，象用來替代遊標，不過它們仍能引發性能問題，若是這個問題能消除，SQLServer將執行得更快。例如，有幾種消除臨時表、減小開銷、提高性能得方法。消除臨時表的方法以下： 
？ 重寫代碼以便你要完成的操做能使用標準的查詢或存儲過程去作 
？ 使用派生表 
？ 使用SQLServer2000的表數據類型。這些不必定更快，須要測試 
？ 考慮使用關聯的子查詢 
？ 使用永久表代替 
？ 使用UNION語句模仿臨時表
每個選項都經常能用來幫助消除你TSQL代碼裏的臨時表。 

查詢裏的提示使用得當嗎？ 

一般說來，SQLServer查詢優化器能很好的完成優化查詢的工做。但不多的狀況下，查詢優化器會失敗，爲了獲得查詢最好的性能須要使用查詢提示來代替查詢優化器。

提示在某些狀況下是有用的，不過它們也是危險的。所以使用提示要特別當心。 

最大的問題之一是遇到大量使用提示的一些代碼，尤爲是這些代碼是在SQLServer6.5或7.0下寫的，如今要轉到2000下。大多數狀況下，SQLServer之前版本選須要的提示在新版本里再也不適用，使用它們其實是影響而不是提示性能。

另外一種情形是應用程序最初作出來的時候也許提示早期是有用的，但隨着時間的推移，存儲的數據自己已發生了變化，曾經有用的提示也許對新數據再也不適用，找出有潛在性能危險並再也不適用的提示。

在這兩種狀況裏，一個好的方法是週期性的從新評估使用的查詢提示好處。你也許發現目前的提示根本沒有好處，事實上是影響了性能。找出這個惟一的方法是在查詢分析器裏測試它們看看實際發生了什麼，而後基於你的發現決定是否繼續使用它們。 
使用了沒必要要的視圖嗎？ 

視圖最大的用途是處理安全相關的問題，而不是一些懶惰的開發人員用來存儲常用的查詢的方法。例如，若是你須要容許用戶特定訪問SQLServer的數據，那麼你也許能夠考慮爲用戶（或組）建立一個視圖，而後給用戶訪問視圖而不是基表的權限。另外一方面，在應用程序裏，從視圖選擇數據沒有好的理由，相反，使用TSQL代碼直接從表裏選擇真正須要的數據。視圖增長沒必要要的開銷，大多數狀況下，返回更多沒必要要的數據，增長沒必要要的開銷。

例如，假定有一個視圖從兩個鏈接表裏返回10列。你想要從視圖裏使用SELECT語句返回7列。實際上發生的狀況是查詢基於的視圖先運行，返回數據，而後你的查詢針對這些數據運行。既然你僅須要7列，而不是視圖返回的10列，更多沒必要要的數據被返回。浪費SQLServer的資源。在你的應用程序裏遵循下面的規則：老是直接訪問基表，而不要經過視圖。

只要可能就用存儲過程了嗎？ 

存儲過程爲開發人員提供了不少好處，包括： 
？ 減小網絡流量和響應時間，提高應用程序性能。例如，經過網絡發送一個存儲過程調用，而不是發送500行的TSQL將更快，資源使用更少。 
？ 存儲過程執行計劃可以重用，駐留在SQLServer內存的緩存裏，減小服務器開銷。 
？ 客戶端執行請求更有效率。例如，若是應用程序須要插入大量的二進制值到一個image數據列而不使用存儲過程，它必須轉化二進制爲字符串（大小會增長一倍），而後發送給SQLServer。當SQLServer接收到後，它必須把字符串值轉回二進制格式。大量的浪費開銷。存儲過程能消除這個問題經過將應用程序傳給SQLServer的二進制格式做爲參數，從而減小開銷提高性能。 
？ 存儲過程幫助提供代碼重用。雖然這些不直接提高應用程序的性能，經過減小代碼量和減小調試時間來提高開發人員的效率。 
？ 存儲過程能封裝邏輯。你可以改變存儲過程代碼而不影響客戶端（假定你保持參數相同也不移除任何結果集的列）。這節約開發人員的時間。 
？ 存儲過程爲你的數據提供更好的安全性。若是你僅使用存儲過程，你能夠移除直接對錶的SELECT、INSERT、UPDATE和DELETE權限從而強迫開發人員使用存儲過程訪問數據。這會節約DBA的時間。
做爲首要的常規，全部的TSQL代碼都應該經過存儲過程調用。 

存儲過程裏使用了SET NOCOUNT ON嗎？ 

缺省地，每次存儲過程執行時，一個消息會從服務端發給客戶端以顯示存儲過程影響的行數。這些信息對客戶端來講不多有用。經過關閉這個缺省值，你能減小在服務端和客戶端的網絡流量，幫助全面提高服務器和應用程序的性能。 爲了關閉存儲過程級的這個特色，在每一個存儲過程的開頭包含下面語句：

SET NOCOUNT ON 

該語句應該包括在你寫的每個存儲過程裏。 

你的任何一個存儲過程是以sp_開頭的嗎？ 

若是你建立的存儲過程不是運行在Master數據庫裏，不要使用以sp_爲前綴的名稱。這個特別的前綴是爲系統存儲過程保留的。儘管使用這個前綴不會禁止用戶定義的存儲過程的運行，但會稍微下降一些執行效率。

這是由於SQLServer在執行以sp_爲前綴的任何一個存儲過程時缺省地首先試圖在Master數據庫裏尋找，儘管那兒沒有，這就浪費了尋找存儲過程的時間。

若是SQLServer在Master數據庫裏不能找到存儲過程，那麼接下來會將存儲過程的擁有者做爲DBO去解析。若是存儲過程在目前的數據庫裏，那麼它會執行。爲了不沒必要要的延遲，不要用前綴爲sp_命名你的任何一個存儲過程。

全部的存儲過程的擁有者是DBO嗎？引用的形式是databaseowner.objectname嗎？ 

爲了最好的性能，同一個存儲過程裏調用的全部對象的擁有者都應該相同，DBO更適宜。若是不是那樣，即對象名相同而擁有者不一樣，那麼SQLServer必須執行名稱判斷。當發生這樣的情形時，SQLServer不能使用存儲過程裏在內存裏的執行計劃，相反，它必須從新編譯存儲過程，從而影響性能。

當從應用程序裏調用存儲過程時，使用分隔符名稱來調用也是重要的。如： 

EXEC dbo.myProcedure 

代替： 

EXEC myProcedure 

爲什麼？有兩個緣由，其中一個和性能有關。首先，使用徹底有分隔符的名稱有助於消除那些和你要運行的存儲過程有潛在的混淆，有助於禁止BUG和潛在的問題。但更重要的是，這樣作SQLServer能更直接的訪問存儲過程執行計劃，而不是輪流訪問，從而加速了存儲過程的性能。固然性能提高很小，但若是你的服務器沒小時要運行成千上萬或更多的存儲過程，這些節約的小段時間加起來就很可觀了。

你正爲引用完整性而使用約束和觸發器嗎？ 

在你的數據庫裏不要執行多餘的完整性特色。例如，若是你正使用主鍵和外鍵約束來強迫引用完整性，不要添加觸發器來實現相同的功能而增長沒必要要的開銷。一樣既使用約束又使用默認值或既使用約束又使用規則也會執行多餘的工做。雖然這聽起來顯而易見，找出SQLServer數據庫裏這些問題並不是不尋常的。

事務是儘量的短嗎？ 

保持TSQL事務儘量的短。這會幫助減小鎖（全部類型的鎖）的數量，有助於全面提高SQLServer的性能。若是有經驗，你也許要將長事務分紅更小的事務組。關於禁止沒必要要的鎖將在其餘文章中介紹。

應用程序監控列表 

應用程序使用存儲過程（一批TSQL代碼）和使用對象模型如ADO來與SQLServer通訊嗎？ 

當應用程序須要和SQLServer通訊時，本質上有3種選擇：使用存儲過程、使用一串TSQL代碼或者使用對象模型的屬性和方法。從性能的角度來看，最有效率的是存儲過程，最沒效率是對象模型的屬性和方法。理論上，應用程序應該僅使用存儲過程來訪問SQLServer。

存儲過程的好處在本文的前面已有所介紹，因此在這裏再也不重複。緊接着第二個方法是發送給SQLServer一串TSQL代碼。若是寫得正確，查詢執行計劃會自動重用，有助於提高性能，儘管你得不到存儲過程的一些好處如減小網絡流量。使用對象模型的屬性和方法的問題自愛慾它們添加了額外的代碼層，從而下降了通訊。另外，經常但不老是，被這些TSQL代碼建立的屬性和方法不是頗有效率的，更影響性能。

應用程序使用什麼模式和SQLServer通訊：DB-LIB、DAO、RDO、ADO仍是.NET？ 

爲了和SQLServer通訊，因此的應用程序都須要使用數據訪問庫（MDAC組件），有幾個庫可供選擇。爲了最優的性能，.NET是首選。若是尚未使用.NET工具，那麼接下來最好的選擇是ADO。在全部的環境下，避免使用DB-LIB（停用但仍支持）和DAO，兩個都很慢。

應用程序使用ODBC仍是OLEDB和SQLServer通訊？ 

若是你在訪問SQLServer數據庫時要在ODBC和OLEDB之間選擇，那麼選擇OLEDB，一般它更快。另外，使用OLEDB容許使用不多的DSN鏈接 ，這樣鏈接維護比基於ODBC、DSN的鏈接更快。

應用程序利用了鏈接池嗎？ 

嘗試使用鏈接池去減小SQLServer的鏈接開銷。鏈接池是指客戶端應用程序在鏈接SQLServer時沒必要在有鏈接需求時每次都創建創建新的鏈接 而使用之前存在的鏈接的術語。這會減小SQLServer的開銷，加速鏈接。

微軟提供了兩種類型的鏈接池。經過ODBC的鏈接池，能夠使用ODBC數據源管理器配置、註冊或調用應用程序。經過OLEDB的資源池，能夠使用應用程序鏈接字符串配置OLDB API或註冊。

要麼鏈接池要麼資源池運行相同的鏈接。相同的鏈接不能兩種池都使用。一樣，鏈接池要工做得有效率，那麼鏈接要重用，而安全實現又很麻煩。對於重用的鏈接，須使用相同的安全環境，不然會自動打開另外一個鏈接，鏈接池會不起做用。本質上，這意味着全部從應用程序鏈接到SQLServer的用戶必須共享相同的用戶賬號。若是不是，當它們須要經過應用程序訪問SQLServer時，每一個用戶將自動打開一個新鏈接。

爲了最大化性能，當鏈接到SQLServer時將幾乎老是要利用一個或另外一個池的方法。 

應用程序是適當的打開、重用、關閉鏈接的嗎？ 

通常說來，SQLServer的鏈接僅在須要的時候打開、使用、而後當即由應用程序關掉。假定你正在使用鏈接池和適當的安全模型，若是鏈接目前不可用會怎樣呢？它將被建立。一旦鏈接被應用程序關閉，它將繼續打開（儘管應用程序認爲它是關閉的），當須要重用時鏈接是可用的。

減小實際鏈接打開和關閉的頻率能減小SQLServer的開銷。一樣，應用程序快速的打開和關閉鏈接，這些都容許造成鏈接池來更有效的重用，也幫助減小開銷，提高性能。

傳給SQLServer的TSQL代碼是最優化的仍是普通的SQL？ 

一些應用程序因爲設計成使用多個數據庫，就使用ANSI SQL替代TSQL訪問SQLServer數據。雖然這樣作能更容易的鏈接到各類不一樣的數據庫，但也影響了性能。TSQL提供了ANSI SQL裏沒有的一些特殊的代碼，這些爲性能提供了好處。理論上，爲了更好的性能，應該使用TSQL來訪問SQLServer而不是普通的ANSI SQL。

應用程序從SQLServer返回了沒必要要的數據嗎？ 

這和TSQL審覈建議裏的一個是相同的。一些應用程序，特別是那些容許用戶瀏覽數據的程序，給用戶返回太多的數據常會引發應用程序放寬對用戶有利的那些數據的限制。例如，我曾經看到應用程序實質上返回了表或視圖的全部行，對應用程序而言，還要排序數據以便用戶的瀏覽。若是行數量不大，那沒問題。但若是行數量巨大，例如100000行或更多，那麼SQLServer在返回這些數據時不得不進行巨大數量的操做（一般是表掃描），網絡也阻塞了。沒有用戶會使用全部的數據。應用程序應該設計成僅返回用戶當時真正須要的數據，而不要多一個字節。

另外一個返回太多數據的例子是應用程序容許用戶執行標準的查詢。若是你必須容許用戶選擇它們本身的標準，重要的一點是禁止偶然返回太多的數據。例如，能夠在SELECT語句裏使用TOP子句，或者在WHERE子句裏包括一些缺省的參數來禁止用戶返回表裏的全部行。

返回沒必要要的數據是很是浪費資源的，也是很容易避免的問題只需稍微計劃計劃。 

當用戶正修改數據時應用程序保持事務打開嗎？ 

這和TSQL審覈建議裏的一個是相同的。大多數應用程序有一個建議：容許用戶查找數據，而後更新。這樣作成功的關鍵是容許用戶這樣作的時候，確保沒有保持鏈接打開－－更新的時候記錄會被鎖住。若是你打開了鏈接，你會建立沒必要要的長時間的阻塞鎖，從而影響性能。

理論上，從應用程序的觀點來看，一旦用戶執行了記錄更新，應用程序將打開鏈接，選擇記錄，而後關閉鏈接。如今記錄出如今應用程序屏幕上。一旦用戶更新了，那麼應用程序須要從新打開鏈接，查看修改過的記錄（假定它是更新了），而後關閉鏈接。事務保持儘量的短是很重要的。

SQLServer數據庫做業性能監控列表 

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址
SQLServer做業監控列表 你的答案 
運行了任何沒必要要的做業嗎？ 
做業調度是在服務器不忙的時候嗎？ 
同一臺服務器上的SQLServer做業有交迭嗎？ 
任何非SQLServer的做業有交迭嗎？ 
做業運行的TSQL是最優化的嗎？ 
檢查做業運行了多長時間嗎？ 
目前的做業有替代方法嗎？ 

在上表輸入你的結果。 

若是你不仔細，SQLServer做業有可能影響性能 

事實上每一個SQLServer都運行一個或更多平常的做業。更可能運行不少每週一次的做業。不幸的是，大多數DBA建立了做業，而後就忘掉了它們，固然除非做業出了問題。但若是做業沒出現問題，一天一天的運行下去的話，大多數做業都會被忘掉。

就像任何應用程序可能影響SQLServer性能同樣，做業也有可能。那些有設計得很差的代碼的做業，或者在糟糕的時間運行的做業，能引發SQLServer重大的損傷。所以，將SQLServer做業做爲性能監控的一部分指很重要的。 

本節將着眼於如何分辨，糾正潛在的與做業相關的性能問題。 

運行了任何沒必要要的做業嗎？ 

建立一個完成特定任務的做業是很容易的，然而當任務再也不須要時忘掉移除它們也是常常發生的事。例如，你也許須要建立一個做業去從幾個表裏每晚移動數據到另外一個表裏，用來產生報表。但若是報表再也不有用，也就再也不有任何須要運行的做業，因此應該移除它們以減小開銷。問題是在做業和報表之間沒有直接鏈接，因此若是報表再也不有用，很容易忘記移除做業。

做爲監控的一部分，檢查運行在服務器上的每個做業，看看做業是否真的須要。若是不須要就移除它。 

沿着這個思路，看看有重複的做業沒有。例如，我曾經看到DBA新手使用維護向導在SQLServer裏建立了做業，而沒有真正意識到它們作了什麼。而後他們又手工添加了一些與維護向導建立的一個或更多做業相同的做業。一樣的事情作了兩次大量的浪費了SQLServer的資源。 

做業調度是在服務器不忙的時候嗎？ 

當你檢查SQLServer裏的每個做業時，看看它們的運行時間。要是做業沒必要要運行在特定的時間，儘可能在SQLServer不忙的時候調度，如晚上或週末，取決於你的環境。

若是你不能確認SQLServer何時是空閒的，用性能監視器作一個超過一週的監控日誌。這將提供給足夠的數據以分辨出能運行非時間敏感的做業的空閒時間。 

同一臺服務器上的SQLServer做業有交迭嗎？ 

這個問題比大多數DBA意識到的要大得多，特別是當SQLServer有不少不少的做業時。當SQLServer上有不少活動時，若是做業能儘量的隨時間分佈則是理想的，不要全部的做業都在同一刻運行。例如，若是你的SQLServer有10個數據庫，你要爲每一個數據庫建立備份的做業，更好的方法是一次運行一個，而不是在同一時間運行全部的做業。

雖然你能經過企業管理器查看做業運行的時長，但沒有一個容易的方法來一個接一個（給每個做業足夠的時間去完成）的手工調度做業，以便它們不產生交迭。這也能作到，但對於有大量做業的服務器來講，你也許須要一個表格來列出全部的做業。做爲一個選擇你能夠考慮使用第三方工具如SQL Sentry（[url]www.SQLSentry.net[/url]），它容許你可視化地管理和查看你全部的做業，以確保這些做業沒有交迭。

因此當你進行做業監控的時候，檢查看看做業交迭狀況，假定這是可能的。若是它們的確交迭了，儘可能從新調度它們以禁止交迭，儘量分散負載到大量空閒的時間。 

任何非SQLServer的做業有交迭嗎？ 

除了SQLServer做業外，你的服務器上也許有一些非SQLServer的做業。有些例子包括碎片整理或磁帶備份做業而不是使用SQLServer調度。既然這些不使用SQLServer調度，它們也容易被忘記，你也許同時終止了一些做業的運行，就像終止SQLServer做業的運行同樣。和SQLServer做業同樣，若是你能在不一樣時間調度這些做業而不是在SQLServer做業運行的時候則是理想的。若是你須要這樣作，在上面討論的表格里加入這些做業。 

做業運行的TSQL是最優化的嗎？ 

就像應用程序、腳本里的代碼同樣，運行在做業裏的TSQL也是須要優化的一部分。TSQL代碼的優化將在其餘地方作介紹，任何有關的索引也應該被添加以便幫助做業代碼更有效率的運行。

因此對於每個有TSQL代碼的做業來講，你應該經過查詢分析器運行它來查看執行計劃，查找潛在的問題，也能夠經過索引向導，查找潛在的索引以提高性能。 

檢查做業運行了多長時間嗎？ 

我已經提過你能使用企業管理器來查看任何做業運行的時長。但我沒有說起的是最好隨時檢查看看這個時長是否有大量的變化。例如，一個特定的做業正常狀況下運行2分鐘，但你發現一週有一次，在星期天，一樣的做業花費了15分鐘。做業時長髮生了重大的改變是一個好的跡象代表做業和其餘在SQLServer上運行的進程有衝突。若是你發現有這類問題，你須要更仔細的調查並分辨出出了什麼問題，而後糾正它。 

目前的做業有替代方法嗎？ 

僅僅由於有做業要運行並不意味着它是手邊完成任務的最好方法。評估每個做業，而後決定是否有更好的方法來完成一樣的工做。例如，或許寫TSQL代碼每晚執行導入比使用目前的DTS包更有效率。或者也許你正運行的做業，使用另外的調度程序去脫離SQLServer運行能更好。但記住關鍵的是，你目前的做業經常不是惟一的解決方法，有更好的可用的能減小服務器開銷的解決方法，若是你花時間考慮一下的話。

使用Profiler找出低效的查詢

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址

監控列表 你的答案 
你分辨過全部長時間運行的查詢嗎？ 
對這些查詢你區分優先次序了嗎？ 
你從新查看過上面區分優先次序的查詢的執行計劃了嗎？ 

在上表輸入你的結果 

第一步是分辨出長時間運行的查詢 

到SQLServer性能監控的這一步止，你應該已經能分辨出全部容易糾正的性能問題了。如今是着手處理更差的查詢（包括存儲過程）的時候了，那些比預期運行時間更長的佔用大量SQLServer共享資源的查詢和存儲過程。

運行慢的查詢執行要花費太長的時間。那麼究竟多長才算長呢？這得由你決定。一般說來，我用5秒做爲一個坎兒。換句話說，任何一個查詢運行5秒或更少一般就算足夠快了，而查詢超過5秒就算長了。這是一個你不得不作出的武斷的決定。在我工做的公司，報表開發人員要寫大量的和我有不一樣標準的徵對數據庫的查詢。他們考慮的時長爲30秒。因此，第一步就是決定多長時間的查詢纔算長，而後在你的服務器性能監控期間使用這個做爲你的標準。

咱們不能無限制的調優查詢。咱們所能作的就是分辨出那些須要更多工做的查詢，而後徵對它們進行調優。若是有時間的話，爲了全面提高SQLServer的性能，能夠着眼於那些稍慢但仍然討厭的查詢。記住有些時候，不管你怎麼努力調優一個特殊的查詢，可能僅有一點或根本沒有性能上的改善。

開始以前 

對於這部分性能監控，你將使用SQLServer自帶的事件探查器。本篇文章僅着眼於怎樣進行性能監控，而不是工具的使用，因此假定你知道怎樣使用事件探查器。若是你之前沒有用過它，查看BOL以得到一些基本的幫助。

在你使用事件探查器捕捉你的SQLServer查詢活動以前，記住下面的：
？ 不要在你要監控的同一臺服務器上運行事件探查器，這對服務器性能有一個明顯的影響。相反，在另外一個服務器或工做站上運行，而後在那兒收集數據。 
？ 當運行事件探查器時，不要選擇比須要收集更多的數據。你收集的數據越多，用來收集它們而使用的資源就越多，這會下降性能。僅僅選擇那些你真正須要的事件和數據列。個人建議是所收集的真正的要簡短。 
？ 在一段典型的服務器運行時間內收集數據，即典型的3-4小時的時間。這也能夠改變，依賴於你服務器繁忙的程度。若是你沒有這樣的時間，你能夠經過一個典型的生產日的幾個不一樣時間段來收集你須要的全部數據。
當你使用事件探查器時，你有兩個選項去啓動它。一個是使用GUI界面，或者若是你喜歡的話，能夠使用內建的事件探查器系統存儲過程。雖然使用GUI有點簡單，但使用系統存儲過程收集數據的開銷稍微的少一些。本文將使用GUI界面。 

收集什麼數據 

事件探查器容許你指定哪些事件須要捕捉，那些事件的哪些數據列須要捕捉。另外，你能夠使用篩選來減小數據而僅要哪些分析須要的社會局。下面是個人建議：

要捕捉的事件 
？ Stored Procedures--RPC:Completed 
？ TSQL--SQL:BatchCompleted 
你也許會驚訝怎麼只有兩個不一樣的事件須要捕捉：一個用來捕捉存儲過程一個用來捕捉全部其餘的TSQL查詢。 

須要捕捉的數據列 
？ Duration (數據須要經過duration來分組) 
？ Event Class 
？ DatabaseID (若是服務器上有多個數據庫的話) 
？ TextData 
？ CPU 
？ Writes 
？ Reads 
？ StartTime (可選的) 
？ EndTime (可選的) 
？ ApplicationName (可選的) 
？ NTUserName (可選的) 
？ LoginName (可選的) 
？ SPID 
你實際上要捕捉和查看的數據包括一些對你來講很重要的數據，特別是duration和TextData；一些就不那麼重要了，但也有用，如ApplicationName和NTUserName。

用於篩選 
？ Duration > 5000 毫秒 (5秒) 
？ 不要收集系統事件 
？ 經過單獨的數據庫ID而不是一次全部的數據庫都收集數據 
？ 其餘適當的篩選
篩選被用來收集數據的數量，使用篩選越多，你能篩選掉的不重要的數據就越多。通常說來，我使用3個篩選，但其餘的也能根據你的情形適當的使用 。其中最重要的是duration。我僅收集那些對我來講很重要的有足夠duration的信息，正如已經討論的那樣。 

收集數據 

依賴於使用的篩選、運行事件探查器收集數據的時間、服務器繁忙程度，你能夠收集大量的數據行。雖然你有幾個選擇，我建議你配置事件探查器保存數據到本地計算機的文件上（而不是你跟蹤的服務器上）而且不設置文件的最大尺寸，相反，讓文件按需增加。你要查看文件的增加量，萬一它沒法控制。大多數狀況下，若是你使用了正確的篩選，文件大小會便於處理的。我建議使用一個大的文件由於若是你那樣作的話很容易分辨出長時間運行的查詢。

正如前面所述，在一個典型的生產期間收集你的跟蹤文件，大約3-4小時爲一期限。當收集數據後，可以使用duration來分類，運行時間最長的查詢出如今跟蹤窗口的底部。當你收集數據的時候有興趣的話能夠看一下子窗口。若是你喜歡，能夠配置在適當的時候自動關閉事件探查器，也能夠手動關閉。 

一旦時間到跟蹤中止了， 事件探查器的跟蹤如今存在本地計算機的內存和磁盤上。如今你準備去分辨那些長時間運行的查詢了。 

分析數據 

我猜你已經能分辨出全部在跟蹤收集期間運行的超過你指定的duration的全部查詢，無論是否是。因此若是你指定duration爲5秒，那麼你將只看到那些運行超過5秒的查詢。根據定義，你捕捉的全部查詢都須要調優。"什麼!但捕捉到了500多個查詢啊! 那但是一項大工程!"那並非你想象的那麼糟。大多數狀況下，你捕捉的不少查詢是重複的。換句話說，你可能在你的跟蹤裏一再地捕捉了一樣的查詢。因此，那些500多個捕捉到的查詢也許僅僅只有10個或50個或100不重複的查詢。另外一方面，也許捕捉到的只是少數的查詢，若是你夠幸運的話。 

不管是少數查詢仍是大量運行慢的查詢，你接下來的工做是首先決定哪個查詢對你的分析和調優來講是最重要的。這須要你設置優先級，由於你可能沒有足夠的時間去分析全部的查詢。 

爲了設置這些長時間運行的查詢的優先級，你可能首先要着眼於那些運行最長的查詢。但當你這麼作時，要記住每一個查詢運行的頻率。

例如，若是你指定一個特定的查詢僅僅是爲了生成報表而一個月只運行一次（碰巧在它運行的時候你捕捉到了），這個查詢運行花了60秒，它可能沒有那些運行花了10秒但1分鐘運行了10次的查詢的優先級高。換句話說，你須要平衡查詢運行的時長和頻率。謹記這一條：你須要分辨並設置那些花費最多SQLServer物理資源的查詢的優先級。一旦你作完這件事，就能夠準備分析和調優了。 

經過查看執行計劃分析查詢 

爲了分析你捕捉到的已經設置優先級的查詢，你須要把代碼移到查詢分析器裏以便能查看執行計劃，分析查詢。本篇文章着重在監控，而不是分析，咱們不會在這裏花費時間去向你展現怎樣分析特定的查詢。這自己是一個很大的課題，將在其餘地方作介紹。 

爲了分析你怎樣移到代碼到查詢分析器裏依賴於代碼。若是你捕捉到的代碼是TSQL，你能夠剪切，而後直接在查詢分析器裏粘貼。但若是代碼是在存儲過程裏，你不得不稍微多作一點工做，由於事件探查器不會顯示存儲過程裏的代碼，而僅顯示存儲過程的名稱，包括傳給它的全部參數。這樣，爲了在查詢分析器裏分析查詢，你必須考慮到存儲過程裏，將代碼複製粘貼到查詢分析器裏。而後，假定那兒也有一些參數了，你不得不手工更改代碼以便它能帶着參數運行而被事件探查器捕獲。 

如今耗時的瑣事開始了，分析每個查詢的執行計劃看看有沒有能改善性能的查詢須要調優。可是由於你已經分辨和設置這些查詢的優先級可，因此你的時間將更有效率。

怎樣最好的實現SQLServer的性能監控 

--王成輝翻譯整理，轉貼請註明出自微軟BI開拓者[url]www.windbi.com[/url]
--原帖地址

最後是怎樣進行SQLServer的性能監控 

到目前爲止，你已經進行了大量的閱讀。在最後這篇關於SQLServer性能監控的文章裏，咱們將講一些爲了最好的實現SQLServer性能監控的最好的實踐。在對你的SQLServer進行任何實際的性能監控以前你須要閱讀這篇文章。 

自定義性能監控 

在這一點上，我假定你已經閱讀了，或者至少瀏覽了全部監控步驟的建議。我猜你也許讀了一些，但那些真正不適合於你。既然大部分的SQLServer安裝稍微有點不一樣，那麼這是有意義的。所以我建議你爲你特定的環境自定義這個監控，添加或刪除一些步驟使其更適合你的需求。 

使用Word或Excel維護你的監控列表 

當你對你的每個SQLServer進行監控時，你須要一個方法去記錄結果。當你有大量的選項時，從這一系列的文章裏複製適合的監控列表到你的Word或Excel文檔做爲起點是比較快速的方法。你可能要爲每一個服務器建立一個單獨的監控列表。若是你決定爲你的監控表格使用Excel的話，你能輸入全部的監控列表項目做爲行，每個監控的服務器做爲單獨的列。這樣你能快速的查看每一個SQLServer的結果。 

設置SQLServer和數據庫的優先級 

若是你管理大量的SQLServer和數據庫，你也許不知道從哪兒開始性能監控。理論上，你應該設置SQLServer和數據庫的優先級，一些須要當即進行最多的性能監控，而其餘的則沒必要進行那麼多的監控。這會幫助你決定從哪兒開始。最可能的是，你將不會當即監控所有。相反，要在能監控的時候監控，按照從最重要到最不重要的順序進行。 

謹記性能監控的關鍵 

當對SQLServer進行監控的時候 ，記住目的是分辨並糾正容易的問題。可是，正如你所料，你將可能也分辨出一些更難於解決的問題。爲了幫助你更好的管理有限的時間，你如今須要着眼於那些容易的問題，把困難的問題留到容易的問題先解決完以後。因此在你執行監控和分辨問題時，按照難易程度分類設置它們的優先級，將困難的問題留待你有足夠時間處理它們的時候。 

不要過早行動 

當你執行監控時，你可能會急於對偶然遇到的問題進行糾正和修改。大多數狀況下，那樣作可能不是問題。但理論上，最好先執行監控，而後基於你的發現，決定正式動手解決你分辨出的問題，而後系統地實現它們。 

一個推薦步驟，但或許會招來不少疑問 

理想狀況下，若有不少的時間，在服務器上執行一個性能基準是一個好的想法，而後執行監控，作任何須要的更改，再執行另外一個性能基準去看看有什麼狀況發生。這會當即讓你知道你所作的是否有幫助，大多數狀況下，沒有作正確的事。雖然這個建議被強烈的推薦，也許從時間來看不很實際。但若是你有時間的話，應該認真考慮。 

另外一個推薦步驟，但或許也會招來不少疑問 

在執行監控以後，你也許發如今單個的SQLServer上全部須要的更改僅只有一兩個，但在其餘SQLServer上，也許須要作一打的更改。若是有那麼的更改要作，不要馬上所有實現它們，僅僅一次一個或幾個的更改也許是一個明智的選擇。這樣，你可以看看每一個或每批更改對服務器產生的效果。若是你一次作了不少的更改，那麼遇到問題時，你將不會知道是由哪一個更改引發的問題，這要求你回滾全部的更改，而後一個一個的測試它們直到找到問題所在爲止。 

這個建議不會有太多疑問 

若是你要作更改的服務器是有緊要事務的生產服務器，你要對你作的更改倍加當心。理論上，你應該在生產服務器應用更改以前在測試用的SQLServer上測試全部的更改。若是你不實踐，那麼每次僅作一個更改，確信若是有任何問題你知道怎樣回滾更改。另外，試着選取一天中不很忙的時候作更改，萬一有問題的話。 

有一個取消計劃 

你因監控而作出的大多數更改應該可以很容易的回滾。但一些也許不那麼容易。在那些狀況下，你須要有一個萬一須要的取消計劃。例如，在你作出任何關鍵的更改以前備份系統和用戶數據庫。那樣，即便出現問題，你也能將你的服務器恢復到更改以前的狀態。我不是嚇唬你不要作更改，但你總應該有所準備。 

記錄全部更改 

當你基於性能監控作出更改時，肯定你對全部的更改作了記錄。這樣，即便後來有什麼問題，你也能更容易的找出錯誤所在。最容易記錄下你的更改的方法可能就是把它們添加到你的監控表格裏，或者其餘你用來收集監控信息的文檔裏。 

每一年都要執行SQLServer的性能監控 

許多SQLServer（並不是所有）隨着時間而改變。設置改變，打了SP補丁，甚至數據也改變了。全部的這些都會影響性能。肯定你SQLServer最優性能的最好方法是作一個手工的性能監控。 

在完成一個監控並更改以後，接下來該作什麼呢？ 

輕鬆一下？哦，不是。恰好相反。記住，這一系列的監控是爲捕捉顯而易見和容易糾正的SQLServer性能問題而設計的。一旦你作完這些，接下來，你要分辨和糾正更難於糾正的問題。前面所說起的性能監控，也許能分辨一些可能問題，而其餘的問題你不得不在它們出現的時候發現它們。不管如何，你要儘量的花費更多的時間分辨和糾正最初性能監控遇到的困難問題。但和其餘事情同樣，着眼於那些引發最大性能問題的問題，而後盡你許可的時間用你的方法去解決它們。祝你好運！