性能監控列表 數據庫配置選項 缺省值 當前值 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，也許更合適。作為監控的一部分，你需要小心估計你的數據庫看上面的建議是否適合它們，然後做出正確的選擇。
