SQL Server 備份程序調整
我在一家擁有 20 個全職網站的小公司工作。還有另外 20-30 個微型網站。在 SQL Server 代理備份執行後，我們每天都會遇到站點凍結的問題。當備份服務停止時，我們看不到任何問題。這是常見的嗎？
我們使用的是 SQL Server 2005，備份在周日和周三執行。我還將研究數據庫本身的其他內容，但這是最突出的。
-編輯-我在機器上執行了一個 perfmon 3 天 5/27 到 5/31：
SQLServer:SQL Statistics\Batch Requests/sec 平均值 355.412275 中值 306.610812 最小值 108.9369962 最大值 916.6332837 標準偏差 141.7791552
SQLServer:General Statistics\User Connections Average 83.14025501 Median 77 Min 52 Max 147 Std Deviation 19.27016231
SQLServer:Buffer Manager\Page life expectancy 平均 33.72386157 中位數 21 最小值 0 最大值 246 標準偏差 36.53737617
看起來執行的維護備份在執行時不會引起問題。它在凌晨 3 點以及週日和周三執行，並在大約 2 小時內成功完成。我執行了 SQL Server 配置文件：
我發現其中一個定期執行的 sp 需要很長時間才能執行。
大多數情況下，持續時間為 976（微秒），但有時差異很大：13922851 13025390 13021484 13019531 13018554 13017578 13016601
我沒看錯，對吧？13 秒？
如果我從我的機器上執行相同的查詢，則在幾分之一秒內執行。
-編輯-
我一直在研究阻塞，但我還沒有想出太多。我只是在 SQL Server Profiler 中尋找重新編譯阻塞，但我沒有看到任何該類型的事件 (sp:recompile)。我仍在調查阻塞問題。
當我執行最後一個 Profiler 跟踪時，我還注意到有大量 sp_reset_connection 事件。其中一些 sp_reset_connection 的長度超過 9 秒。這是一種正常的行為嗎？
檢查您是否將備份儲存在與數據和日誌文件相同的物理位置。如果您嘗試將所有活動寫入一個磁碟，那將是一個可能的瓶頸。
此外，如果您使用 3rd 方工具（例如 Litespeed）進行備份壓縮，您可能會消耗比預期更多的 CPU，這也可能導致性能不佳。
高溫高壓
備份作業是否通過網路發送數據，佔用使用者的所有網路頻寬？完整的數據庫備份不應該凍結伺服器，除非 SQLRockstar 說您正在使用某種壓縮並執行 cpu，或者其他一些資源瓶頸。