Sql-Server

停止 MSDB 的收縮是否安全?

  • August 24, 2019

在生產伺服器(Microsoft SQL Server 2014)中,文件MSDBData.mdf膨脹到超過 450 GB,幾乎佔用了伺服器中的所有空間(僅剩下 38 GB)。

首先,我在MSDB網路共享上創建了一個備份(通過SSMS -> 活動 -> 備份)。然後我嘗試減小文件的大小(通過 SSMS -> 活動 -> 收縮 -> 文件),但是收縮停止並且沒有釋放磁碟空間。縮小的對話視窗從幾個小時開始就被凍結了。

在 SSMS 的活動監控中,在監控收縮的過程中似乎處於SUSPENDED狀態。

在此處輸入圖像描述

在事件查看器中有幾個事件

IE

(source MSSQLSERVER, eventid 847) beginning with

1. Time-out occurred while waiting for latch: class 'FGCB_ADD_REMOVE'
2. Time-out occurred while waiting for latch: class 'FCB'

問題:關閉SSMS的對話視窗以停止MSDB的收縮是否安全,以便進行進一步調查?

是的,取消該操作是安全的(但您需要耐心等待它完成回滾 - 不要驚慌並停止 SQL Server 服務或重新啟動伺服器;所有要做的就是重新開始回滾)。

在您等待的同時,讓我們解決您的根本問題。

在您手動增加大小以準備更多數據(或者只是在其他人獲取空間之前獲得空間)的場景之外,數據文件的大小會增加,因為您將數據添加到文件中,並且它還不夠大儲存該數據。告訴 SQL Server 收縮一個必須增長以容納更多數據的文件不太可能完成任何事情,除非您首先刪除一些導致它增長的數據。

這可能來自流氓備份作業(可能是第 3 方),它每秒都在執行並填充備份歷史記錄表。或者一個作業執行異常,它正在生成作業歷史記錄並用錯誤填充該表。或者是一個無限循環,用垃圾郵件填充數據庫郵件表。或其他許多東西,特別是如果您將自己的流程的使用者表放入msdb.

要找出佔用空間的內容,您可以使用類似這樣的查詢類似這樣的查詢(存在許多其他查詢)。可能是由於碎片,或大量 LOB 數據,或非常糟糕的填充因子,或過大但填充不足的固定寬度列,或只是行數過多,表很大。但是你必須先找到它並把它清理乾淨,然後收縮才有希望完成任何事情。

刪除您不再需要的數據(並採取任何必要的步驟來確保所做的任何過程都不會再次發生)。使用適當的填充因子重建索引,並設置某種維護常式(如Ola 的腳本msdb)來管理索引,並可能對數據庫(或所有數據庫)的太多文件增長事件發出警報,因此您可以捕捉到這一點問題較早。您可以查看最近發生的所有文件增長事件,例如,使用預設跟踪

然後,使用DBCC SHRINKFILE(不是 SSMS 中的一些 UI hinkiness,或者DBCC SHRINKDATABASE,它也會嘗試縮小日誌,並且會嘗試一次縮小所有內容),一次一點點,以降低文件大小。如果文件目前為 450 GB,並且您釋放了 300 GB(您可以使用sp_spaceused查看上述結果),我會得到一個 200 GB 的文件,比方說(為未來增長留出空間),首先縮小到425 GB,然後是 400 GB,然後是 375 GB,依此類推……您可能需要以較小的塊來執行此操作,例如從 2 GB 或 5 GB 開始,具體取決於底層磁碟子系統的功能。

引用自:https://dba.stackexchange.com/questions/246162