SQL 服務器中的日志文件如何在未知時間未備份后收縮？

Question

我最近接管了一個已經使用了 2-3 年的數據庫的管理，它沒有任何事務日志維護計划。 DB 文件為 8 GB，但事務日志文件高達 54 GB。 我開始備份日志文件，我需要回收該驅動器空間。 我已經將我的數據庫與我公司內構建了適當維護計划的其他站點進行了比較，它們的事務日志大約為 4 GB，這是我所期望的。 這是我第一次遇到這個問題。

我對數據庫進行了完整備份，並設置了一個初始事務日志維護計划，但我需要縮小這個 *.ldf 文件，因為它太不成比例了。 我搜索了 Stack Overflow 留言板，希望能找到類似的情況。 基於該研究，我嘗試了 DBCC SHRINKFILE，但這並沒有產生我預期的結果。 我將數據庫恢復到原始（超大日志文件到位）並嘗試了完全-簡單-完全恢復技術來截斷日志，但仍然無法回收空間。 我什至嘗試刪除.ldf 並完成清除（Recovery Pending）狀態的過程。 我回到DBCC CHECKDB修復function，但是在清除（Recovery Pending）狀態后，根本無法備份事務日志。 我開始收到一個 msg 42000 錯誤 50000，它還引用了錯誤 3013。最后，我刪除了整個混亂並將其恢復到原來的 state。 我已嘗試盡可能詳細，如有必要，我很樂意澄清或闡述。 正如我所說，這是我第一次遇到這樣的事情，但我總是從頭開始我的項目。 這是我第一次跳進別人建造的東西中間，當我拿到它時就壞了。

ALTER DATABASE [DBName] SET EMERGENCY;

GO

ALTER DATABASE [DBName] set single_user

GO

DBCC CHECKDB ([DBName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;

GO 

ALTER DATABASE [DBName] set multi_user 

GO

我的預期結果是一個未損壞的事務日志，它的大小適合我的數據庫。 讓這成為一個警示故事，並提醒人們在接受管理別人的錯誤之前提出所有問題。

Answer 1

如果您使用的是 2008 年或更早的版本，您可以嘗試“使用 TRUNCATE_ONLY 備份日志”

否則將數據庫切換到簡單恢復，這將清除日志。 然后運行 DBCC SHRINKFILE 來縮小文件本身的大小。