因為資料庫的交易紀錄檔(LDF)過大,從網路查詢到可以用這種方式來壓縮交易檔的大小
USE UserDB;
GO
-- changing the database recovery model to simple.
ALTER DATABASE UserDB
SET RECOVERY SIMPLE;
GO
-- Shrink UserDB_log file to 20 MB.
DBCC SHRINKFILE (UserDB_log, 20);
GO
-- changing the database recovery model to FULL.
ALTER DATABASE UserDB
SET RECOVERY FULL;
GO
執行後,出現以下錯誤,沒辦法壓縮紀錄檔
訊息 3023,層級 16,狀態 2
資料庫上的備份與檔案操作作業 (例如 ALTER DATABASE ADD FILE) 必須進行序列化。 請在目前的備份或檔案操作作業完成之後,重新發出陳述式。
透過查詢指令
SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases;
發現資料庫 MODE 是 FULL 且交易紀錄檔處於 Log_backup
請問在這種情況,得先在SSMS上對記錄檔進行備份,才能對其進行壓縮嗎?
或者是還有其他方式能讓記錄檔變小嗎?
你們都沒跑過 SQL Backup 嗎?
正規專門用來備份 SQL 的軟體, 都會在備份完畢之後, 自動截斷 Log file, 讓他不會一直長大上去; 如果你們每天都有備份, 應該不至於長到太大才對....(還是你們都把: 備份後截斷 Log 這個功能關掉了?)
最佳辦法就是趕快跑一次備份, 然後截斷...
你上面的訊息, 是你想做的動作, 與現有 SQL 的工作衝突, 導致無法執行; 必須先找出有哪工作會相衝, 將他停掉之後, 才能做你要的事情:
https://blog.sqlauthority.com/2014/11/09/sql-server-fix-error-msg-3023-level-16-state-2-backup-file-manipulation-operations-such-as-alter-database-add-file-and-encryption-changes-on-a-database-must-be-serialized/
我比較極端..
先停止SQL Server,再啟動SQL Server,再去壓縮資料庫~
不然資料庫會因為都有頻繁交易~無法壓縮資料庫@@...
另外~我都在挑半夜2~3點才執行..
資料庫有分二種,如果交易記錄你覺得很重要,你可以設定排程,把Log記得清除,
如果交易記錄不是很重要,你可以將資料庫由復原模式:由完整改成簡單,就不會有Log記錄的問題了。