DBCC 在生產系統上的使用
我們有一個在 Hyper-V 虛擬機（64GB RAM 和 16 個虛擬核心）上執行 SQL Server 2008 R2 的系統。
系統中的另一個 VM（應用程序伺服器）非常密集地訪問數據庫伺服器以進行查詢和數據更新。
我們當時在應用程序伺服器中遇到了兩個主要異常，即執行特定的維護子計劃儲存過程。
兩個例外是：
- >
System.Data.SqlClient.SqlException (0x80131904)：超時已過期。操作完成前超時時間已過或伺服器未響應 (…….)
- >
System.Data.SqlClient.SqlException (0x80131904): 指定版本號 (1859) 的應用程序域因記憶體壓力而被解除安裝，無法找到。（……）
此時執行的維護計劃儲存過程有以下語句：
DBCC FREESYSTEMCACHE ('ALL') DBCC FREESESSIONCACHE DBCC FREEPROCCACHE CHECKPOINT DBCC DROPCLEANBUFFERS經過一些測試，這顯然是導致問題的原因。我還發現：
- 超時異常是由這個引起的：
CHECKPOINT DBCC DROPCLEANBUFFERS
- 記憶體壓力異常是由這個引起的：
DBCC FREESYSTEMCACHE ('ALL') DBCC FREESESSIONCACHE DBCC FREEPROCCACHE不幸的是，我們不知道發生此維護任務的原因。我的第一個想法是刪除此任務，但我不知道不執行這些任務是否會出現更多問題。
這些 DBCC 命令真的有必要嗎？
謝謝
首先，找到完成這項工作的人，將他/她綁在椅子上，在你去吃午飯時聽貓抓黑板。
完成後，在作業執行之前和之後比較長時間的資源使用率和性能數據。我懷疑你會看到性能下降和一些資源在工作執行後變得非常忙碌。您可以暫時暫停工作並密切監視一周，看看會發生什麼。我懷疑您會遇到問題，但與對產品系統的所有更改一樣，仍然密切關註一段時間，並確保您擷取性能、資源使用情況和等待數據。
這些儲存過程通常在測試環境中執行，特別是用於性能測試，以查看特定查詢或整體工作負載在冷啟動等效項上的表現。它還可用於查看系統的特定部分如何處理意外的負載峰值，尤其是儲存。
我們遇到過一個支持工程師，他的標準性能調整方法涉及在生產系統上做這些事情；我們不能足夠快地擺脫他。定期在生產系統上執行所有這些非常接近於每天重新啟動伺服器以保持其健康並在忙碌的一天中進行以獲得最佳結果 - 真的，真的不應該。
不幸的是，答案將取決於它。從您在維護計劃中的內容看來，無論是誰將它們放在適當的位置，都試圖將一天中特定時間的伺服器統計資訊、記憶體和執行值重置為 SQL Server 首次啟動而沒有實際重新啟動 SQL Server 時的狀態.
CHECKPOINT將指示數據庫將記憶體中的所有臟頁寫入磁碟。預設情況下，SQL Server 將對數據庫執行自動檢查點，以確保它可以在特定時間內對數據庫執行恢復。Microsoft 的 TechNet上有更多資訊。如果記憶體中有大量頁面需要寫入磁碟，這可能會給磁碟 I/O 子系統帶來額外壓力，那麼手動執行此過程可能是一個相當密集的過程。CHECKPOINT檢查文章中描述的間隔以查看它是否已從預設值 0 更改可能是個好主意。
DBCC DROPCLEANBUFFERS將清除已從磁碟載入的任何 8KB 頁面的記憶體。這將迫使 SQL Server 將數據從磁碟重新載入到記憶體中，以完成沒有數據駐留在記憶體中的傳入查詢。 MS 的關於緩衝區管理的 TechNet 文章 在 負載很大的機器上執行此命令會增加磁碟 I/O 子系統的壓力，進而可能導致超時。
DBCC FREESYSTEMCACHE ('ALL')- 這將清除 SQL Server 自上次重新啟動以來建立的所有記憶體。您遇到的記憶體壓力異常很可能是由於 SQL Server 必須備份所有記憶體，包括它的過程記憶體，該命令也可以使用DBCC FREEPROCCACHE命令清除。這意味著，對於傳入的每個查詢，如果尚未建構執行計劃，它將對 CPU 和記憶體施加壓力，以在實際執行查詢之前生成執行計劃。@Kin 對 FREESYSTEMCACHE 和 FREEPROCCACHE 之間區別的回答
TechNet 關於 FREESYSTEMCACHE 的詳細資訊
TechNet 關於 FREEPROCCACHE 的詳細資訊
DBCC FREESESSIONCACHE- 將刪除使用 OPENROWSET 和 OPENDATASOURCE 的分佈式查詢的記憶體。這個命令的細節有點稀疏。 SQL SERVER CENTRAL 部落格文章最終，這些命令實際上應該只在您正在調整數據庫以提高性能的開發/測試環境中使用。雖然在生產環境中使用它們可能有正當理由，但除非你有充分的理由偶爾或定期使用它們，否則我會說它們可能會導致更多問題，然後它們正在解決。但是，在不知道它們為何被放置的歷史的情況下，您將需要調查數據庫模式/過程和應用程序，以嘗試確定它們是否存在或存在原因。