首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 數據庫知識 >  >> MySQL 資料庫 >> MySQL 綜合教學

MSSQL 日誌文件壓縮實操:DUMP TRANSACTION + DBCC SHRINKDATABASE

     編輯:MySQL 綜合教學

適用場景

  • SQL Server 數據庫日誌文件 (.ldf) 暴增,佔用大量磁盤空間。
  • 簡單恢復模式或定期全量備份後,需釋放日誌空間。

兩步壓縮命令

-- 1. 截斷非活動日誌 (簡單恢復模式下有效,完整恢復模式需先備份日誌)
DUMP TRANSACTION 數據庫名 WITH NO_LOG;
GO

-- 2. 收縮數據庫文件 (包含日誌文件)
DBCC SHRINKDATABASE (數據庫名);
GO

參數解讀

命令 作用 注意事項
DUMP TRANSACTION ... WITH NO_LOG 標記非活動事務日誌為可覆寫,**不備份日誌** 完整恢復模式下會破壞日誌鏈,導致無法時間點恢復。**僅限簡單恢復模式或臨時緊急收縮**
DBCC SHRINKDATABASE 釋放數據/日誌文件未使用空間歸還 OS 會導致索引碎片、性能抖動,**生產環境慎用**,維護窗口執行

正規軍做法 (生產環境推薦)

  1. 設置簡單恢復模式 (若業務允許):
    ALTER DATABASE 數據庫名 SET RECOVERY SIMPLE;
  2. 定期備份日誌** (完整恢復模式必須):
    BACKUP LOG 數據庫名 TO DISK='path\log.bak';
    備份後非活動日誌自動標記可復用,無需 DUMP ... NO_LOG。
  3. 收縮文件指定目標大小** (避免過度收縮):
    DBCC SHRINKFILE (邏輯日誌文件名, 目標大小_MB);
  4. 收縮後重建索引** 消除碎片:
    ALTER INDEX ALL ON 表名 REBUILD;

查看日誌空間使用

DBCC SQLPERF(LOGSPACE);
-- 輸出: Database Name, Log Size (MB), Log Space Used (%), Status

避坑清單

  1. ❌ 完整恢復模式下直接 DUMP TRANSACTION ... NO_LOG → **日誌鏈斷裂,無法時間點恢復,嚴重事故**。
  2. ❌ 頻繁 SHRINK → 索引碎片嚴重、下次寫入又要擴展、性能抖動。
  3. ❌ 收縮到極小 (如 1MB) → 業務高峰頻繁自動增長,碎片化更嚴重。
  4. ✅ 監控 Log Space Used %,長期 > 80% 才考慮擴容或調整備份頻率。
  5. ✅ 核心業務**堅持完整恢復模式 + 定期日誌備份**,空間換數據安全。

總結:DUMP TRANSACTION ... NO_LOG + DBCC SHRINKDATABASE 是**緊急止血手段**,僅限簡單恢復模式或測試環境。生產環境請走**正規備份收縮流程**,空間換時間,數據安全第一。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved